1年半取り組んだWebプロジェクトマネジメントを振り返って、やって良かったこと、やっておけば良かったことをすべて書く
おはようございます。いしげ（@oturu333）です。
このブログは モチベーションクラウド Advent Calendar 2018 - Qiita 1日目の記事として書いています。
今回は過去私が1年半に及ぶWebプロジェクトのPMをした経験を語ろうと思っています。
この記事でお話することについて
プロジェクトの概要は既存のWebシステムの全面リニューアルです（MCSではありません）。
ざっとやっていたこと
- サービスをすべて作り直す（リプレイス）
- PHPのメジャーバージョン2つくらい一気にあげた
- CakePHP -> Vue.js + Laravel の構成に変えた
- AWS構成をがっつり変えた
- 一部マイクロサービス化した
- 機能の見直し、UI全刷新
- ドキュメントが全然なかったのでいろいろ作りつつ進める
当時の私の立場は、開発チームのマネージャーであり、今回お話するプロジェクトの企画者であり、PMであり、サーバサイドのエンジニアでした。
開発手法、プロジェクトマネジメント手法などの記事はたくさんあるのでここでは言及せず、当時の私自身も知りたかった、PMのより具体な部分「実際何をやるものなの？」を書いていきます。
また、PMと同時にマネージャーでもあったので、プロジェクト中にマネージャーとして意識していたことなどもまとめてみます。
そして最後に反省している点に言及します。
やってよかったこと
ピープルマネジメント
みんなで決めること、一部の人で決めることを分けた
このプロジェクトの企画骨子は私が作りましたが「こんなことやりたいんだけどどう思う？みんな何がしたい？」という意見を集めました。
PHPのバージョンの上げ方からお察しいただけるところもあると思いますが、プロジェクトの目的の一部として、だいぶ積もってしまった技術的 / 非技術的負債の抜本的な解消、そしてエンジニアのモチベーションのアップがありました。
長いプロジェクトになることは見えていましたし、人は誰かにやらされるのは嫌いなので「みんなで考えたこのプロジェクトを成功させよう！」というストーリーからモチベーションを作りたかったのです。
また、メンバーと仕事をする上で「この四象限の2つ以上を同時に達成する」ということを意識していたというのもあります。
その点で「メンバーと一緒に計画を立てる」はとっても素敵な案件で、人間関係、部下育成、仕事の改善が一気にできてしまいます。おすすめです。
タスクを依頼するときもただお願いするのではなく、一部のスケジュール管理と一緒にお願いしたり、設計からお願いしたり、コミュニケーションを取りながら進めたりすることで複数を達成できます。
目的をみんなで決めたことの副産物として、プロジェクトの方向性がずれそうだなとなったときにこの目的に立ち返ることができたことが良かったです。
「このAPIはこういう設計で良いですか？」
「その設計だと目的のこれに反してるからこうしたほうが良いと思うけど、なんでそうしようと思ったの？」
「実は…」
のような会話ができ、判断に迷うポイントが減りました。
逆にみんなで決めなかったことは技術採択やサービス設計など、要するに決めでしかないところです。みんなから意見はもらうところもありましたが、最終決定は少人数で行いました。
どこまでがみんなで決めるべきで、どこまでがそうでないべきなのかはっきり言語化できていません。今後のお題にしようと思います。
プロジェクトの事前準備
1. 参考になるプロジェクトの事例を集めて共有した
リニューアル、リプレイスなどの手法や、過去リニューアルプロジェクトを経験した方々の知見をあさりました。
特に以下の「backlog UI リニューアルの舞台裏」はリリース後にまで触れられていてとても参考になりました。
2. 事前にやらないことを決めた
やらないことを定義したのは以下の理由です。
- ただでさえリスキーなリプレイスという手段を選んでいるので、最大限リスクを回避するため
- 長期間プロジェクトのため内外からの要望に変化が起こる可能性が高い。もともとの要望を変えないため
具体的にやらないと定義したことは以下です。
- 既存スキーマの変更は基本行わない（リスクヘッジ）
- 変更してでもやるべきと判断できる改修は、現サービスに先行して反映させることをルールとした
- 新機能の開発（リスクヘッジ、要望変化への対応）
- 既存機能の拡張、縮小、削除はあり。ただし新規機能はなし
3. プロジェクト後（リリース後）の対応方針について定めた
事例調査や、自分たちの経験から「おそらくリニューアル後に十分な計測期間を取らないまま、元に戻したほうが良いという話になる可能性はあるよね」という議論になりました。（プロジェクトの性質上「戻す」のは無理なので、必死に直すことになりますが）
定めたことは以下のようなものです。
- リニューアル後はお問い合わせが増えるだろうし、批判的な意見も出るであろうということを「ほぼ確実に起こること」としてチーム全員に共有した
- 慣れたUIが変わるので仕方ない
- 一定期間の計測をしてから方針を判断するということの合意をとった
- 上記の内容を会社全体に周知
- 社内ユーザーからの声にも対応するため
4. プロジェクトゴールのその先について事前に語った
負債返却を含めたプロジェクトだったため、1→10というよりはマイナス→0でした。
「とりあえずスタート地点に立とう」と。
プロジェクトが始まる前から、プロジェクトのその後にやるべきことを平行して整理していこうという話をし
- 全員の方向性がずれないよう、事業のミッション・ビジョンの制定
- 負債をなるべく生まないためのルール、フローの整備
- ドキュメント作成と既存ドキュメントの整理
などを行いました。
メンバーもしんどい時期もあったと思いますが「これ終わったらこんな機能作るべきだと思う！」「デザインスプリントやってみたい！」など活発に話ができたのはとても楽しかったです。
進捗管理
1. 進捗は誰が見ても分かるようにした
ガントチャート（は作ってないですが）などを作成するも予実がずれていって、結局今の進捗はどうなってるの？という状態になることってありがちかなと思います。
予実を数値化し、今どういう状態なのか分かりやすくするようにしていました。
2. スモールステップの進捗目標を立て、週次で振り返った
プロジェクトの全体スケジュールが年超えだったので、月次の進捗目標を立てました。
しかしそれでも何かを改善するにはチェックポイントが足りないので、振り返りは週次で行っていました。
振り返りと言っても、数字をSlackでコメント付きで送るというものです。
オンスケだったら感謝と喜びのコメントを。遅れ気味だったら「なぜ遅れているか」の共有、実行中・考えている改善施策の共有などと、フォローのお願いなどを行いました。
3. コアメンバーで進捗について語り合うチャンネルを作り、改善策を出し合った
この板ではスケジュールコミットに関わるメンバーだけで以下のようなやりとりをしていました。
- 進捗が芳しくないときに、どうやってスピードを上げられるか（ボトルネックの特定）の議論
- 私が気づいていなくても「このままだとやばいと思います」というアラート発信
チャンネル内で話した、ボトルネック特定と解決策の例
- レビューに時間がかかりすぎる
- 画面デザインの仕様書が見づらい
- 複雑な画面から優先してZeplinへの移行を行った
4. 基本的にはロジカルに、たまに無茶なお願いをした
基本的には根性論で解決せず1つずつ課題に対処しましたが、これはあとはもう頑張るしかない！となった時もありました。
そのときは「友情・勝利・勇気」がキーワードになっていました。楽しかった。ランニングハイ。
アサイン調整、タスク管理
以下のようなことを工夫していました。
- 共通機能、複雑な機能はなるべく前倒し
- メンバーのアサイン時期を調整する
- 参考になる1つ目の処理は、技術力の高い人にお願いする
やっておけば良かったこと
事前にちゃんとお勉強することが必要だった
プロジェクトマネジメント手法を何も知らずにPMをしていました。無知ゆえに経験と勘ですべてをこなしました。
プロジェクトが終わってからCCPMなどについて勉強しましたが、もっとこうできたなと思うことがいくつかありました。
- なるべく早く終わらせたいという要求もあり、無茶な進め方をしたところがある
- 正しい進め方が分かっていなかったので議論ができなかった
- タイムラグのあるタスクを調整しきれなかったり
- CCPM を取り入れたり、要素分解してスケジュールを考えたりすれば、もう少し不安要素の少ないマネジメントができたかもしれない
- 検討漏れ（結合テスト後の修正の時間が特に大きかった）タスクが発生し、プロジェクトバッファをだいぶ食い尽くした
もともとあった開発プロセスの課題が顕在化した
進捗に遅れが出たときに発見されたボトルネックは、プロジェクト中だから発生したわけではなく、もともと存在していたものもありました。
プロジェクトの前に見つけることができていれば良かったなと思います。
- 気づいていたけど着手できていなかった問題も顕在化した
- 気づいていなかったものに関しては、マネージャーとして興味のチャンネルが狭かったなと感じる
1人で抱えすぎた時期があった
進捗を可視化しても感じ方はそれぞれで、私は「もうちょっと今はすすめないとなー」と思っても、メンバーはそうじゃなかったり。結果1人でタスクを抱え過ぎたりしました。
私のほうからコミュニケーションができなかったなと思います。
途中からメンバーとそういう話をするようにしてから、だいぶ楽になりました。
突然ですが、マネジメントのおもしろさについて少し語る
エンジニアとエンジニアリングをどのようにマネージメントしたらいいかが面白くて、知的で、リスペクトされる仕事にならないと怖いので誰もやりたくない仕事になってしまう。そうすると、いつまでもエンジニアリングの経営が日本に宿らない。だから #EMFM とかで少しでも面白い仕事だよと伝えたい
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) November 25, 2018
マネジメントは楽しいです（という引用…ｗ）ピープルマネジメントも、プロジェクトマネジメントも。
知的な仕事なのに人間味があって泥臭いところもある。
マネジメントをやるようになってから自己開示に勤しんだり、組織や人について知ろうと思うようになったり、自分の中の変化がたくさんあって驚いています。
自分が何をしたいのかを見つけられれば、エンジニアリングマネージャーは楽しいです。と思ってます。
この記事のまとめ
- 不確実性をへらすための事前準備
- プロジェクト運用に対する知識 ☓
- プロジェクトの方針の決定 ◯
- プロジェクト後の方針の決定 ◯
- スケジュール設定 ☓
- 事前から解消できる問題の回避 ☓
- プロジェクト中
- その他
- このプロジェクトのPMができてよかった ◎
- 辛かったけど楽しかった ◎
事前準備をしっかりやりましょう。お勉強しましょう。きちんと会話してPDCA回しましょう。目的があれば厳しい状況でも楽しめるので、全力で楽しみましょう！が今の私のまとめです。
このプロジェクトを始めるときに「しんどいこともあると思いますが、二度とこんなことやりたくないと思うようなプロジェクトにだけはしないようにしよう。せっかくの挑戦の機会を楽しもう！まぁ、二度と起こしちゃいけないけど」というようなことを言ったことを覚えています。
終わったあとに「まぁあと数年はやらなくても良いかなー」なんて話せたのも良い思い出です。
良い経験をさせてもらいました。感謝をこめてログを残しますm(_ _)m
ハッシュタグ #弊社のろけ話 のツイートから見えた、みんなが自社を好きな理由ベスト5
おはようございます。こんにちは。こんばんは。いしげ（oturu333）です。
ツイッターのハッシュタグ #弊社のろけ話 を眺めていたところ、これをまとめたらみんなが大好きになる会社の特徴が分かるのでは？と思ったので、なるべく具体的に集計、ランキングしてみました。
ランキングは2018/10/27現在のツイート121件を対象に、1ツイートで複数要素があるものは分解して出しています。
主観でカテゴライズしているところはあるのでご容赦くださいm(_ _)m
具体的なコメントは抽象的にまるめているものもあります。
第一位 人が好き
みんな大好き編
- 優しい、良い人が多い
- 自分だけじゃなく家族のことも思いやってくれる
- 褒めてくれる、認めてくれる
- 自発的に働ける人が多い
- 個性豊か
- 口だけではなく行動する人が多い
- 約束を守る
- 働きにくい人が少ない
上司大好き編
- 上司がフランク
- 優しくも厳しい上司が好き
- 上司が部下を鼓舞してくれる
- 社長がおもしろくて冗談が通じる
第二位（同率） オープンコミュニケーション
- 企画や事業にも意見が言える
- GithubやSlackの活用により、考えや議論をオープンにしようという文化がある
- 職種間、役職間の隔たりがない
- 意見が言いやすい。意見を尊重し合える
- 言いたいことを言っても引きずらない。建設的な議論ができる
- 意見や助けを求めると、みんなが議論に参加してくれる
第二位（同率） 適切な権限委譲 / チャレンジができる
- 提案したことをやらせてもらえる
- やりかたや手段（技術採択など）を自分で決められる
- 求める以上、経験以上の裁量を与えてもらえる
- 学んだことを実務でやらせてもらえる
第四位 福利厚生に満足
- 旅行プラン、娯楽施設が割引きで利用可能
- 社員旅行
- 職場飲食（ランチ、おやつ、飲み物など）が安い、無料
第五位（同率） 尊敬できる人が多い
- 尊敬できる先輩が多く学びがある、楽しい
- 社員全員Github使える
- 全員が自立している
- 本質的、長期視点の議論ができる人が多い
第五位（同率） 変化を恐れないマインド
- 未来志向ができる
- 内省ができる
- 悪しきルールは変えていく文化。変わることに抵抗がない
- 変化に協力的な人が多い。変えようと声をあげると協力者が多く名乗り出る
- 変化が多くて飽きない
第五位（同率） 仲が良い
- 仕事終わりに和やかにお酒を飲めたり、ゲームをしたりできる
- 上司をいじれる
- メンバーが会社になじめるよう、上司が手助けしてくれる
- おふざけできる
第五位（同率） 勉強を支援してくれる
- 通常業務内で成長のための時間を取れる
- 勉強会参加や本の購入などの予算が十分ある
- ランチLTがある
- みんなで切磋琢磨する空気がある
- 社内合宿がある
- 大量の本を置くための本棚を購入してくれた
番外編（順不同）
- オフィスの環境が良い
- オフィスの立地が良い
- 仕事のツール、環境（マシンスペックなど）に満足している
- 給与が適正 / 評価に納得ができる
- 休みが取りやすい
- プロダクトや事業内容が魅力的
- 役職者との物理的、心理的距離が近い
- ワークライフバランス
- フレックス制度
- 会議が少ない
- 部署や役職の希望が通りやすい
- 副業可能
- 服装、髪型が自由
- 仕事に関係ない備品を購入してくれる
いかがでしたでしょうか？
#弊社のろけ話 を眺めていると、自社を大好きな人が多くてほっこりします。
良い会社のエッセンスがぎっしり。ぜひツイッターも覗いてみてください。
調べてみたら思ったより少なかった！女性エンジニアの人数を算出してみた
はじめまして、いしげ（@oturu333）と申します。Web系のエンジニアです。
私のキャリアは未経験でエンジニアになったことから始まり、28歳でチームリーダー、29歳でマネージャーを経験し、今はフリーランスとしてIT企業のコンサルティングに同行したり、開発案件の受託をしたりしています。
エンジニアになってから「女性のエンジニアって珍しいよね」「自社に何人くらい女性エンジニアいるの？」という質問はよく聞かれましたし、
個人的には、同年代（20代・30代）女性エンジニアでマネージャー経験者はどのくらいいるのかなと気になっておりました。
肌感としては女性エンジニアも、マネージャー経験者ともに少ないことは感じていたので、定量的に理解しようと思います。
（今回は主にソフトウェアエンジニアに限定して調査しています）
1. 他職種と比較したソフトウェアエンジニアの女性比率の比較
IT人材を巡る現状について （データ編） / 経済産業省 情報処理振興課によると、IT技術者の女性比率は以下の通り。
ソフトウェアエンジニアの女性比率は14.4%です。
他職業と比較してもIT技術者の女性比率は少ないことが分かります。
2. ソフトウェアエンジニアの女性の数
ソフトウェアエンジニア人口は20代後半〜30代が最も多い層となっています。
女性エンジニアは上記の通り全体の14.4%で、46,610人です。
ソフトウェアエンジニアに限らず、IT技術者は他の職業と比較して平均年齢が若い傾向があります。
3. 日本企業の女性マネージャー比率
2017年国際労働比較 / 独立行政法人 労働政策研究・研修機構によると、日本企業全体においては、女性マネージャー比率は、12.5%です。
4. 日本企業における年齢別管理職割合
国勢調査によると、職業に係わらず30代女性マネージャーは0.2%です。
20代のデータはありませんが、40代になっても0.3%なので、20代も0.2%未満程度でしょう。
5. 以上の数字から、20代・30代女性エンジニアマネージャーの数を考える
この章はあくまで推測の数字になるため、悲観的、中間的、楽観的な数値を算出してみました。
それぞれにおいて、マネージャーのうちの10%が20代・30代だろうと仮置きしています。
5.1 悲観的観測
エンジニアは他職種と比較してそもそもの女性比率が低いです。
そのため、全職種の女性比率 : 女性マネージャー比率 = 43.2% : 12.5%
という計算式を、ソフトウェアエンジニア女性比に置き換えると、女性エンジニアマネージャー比率は4.98%。
この比率で計算すると、女性ソフトウェアエンジニアマネージャーは232人となります。
5.2 中間的、楽観的観測
3の数字を利用し、他職種と同じくソフトウェアエンジニアの女性の12.5%がマネージャーだとすると、20代・30代のソフトウェアエンジニアマネージャーは583人となります。
また、4の調査の数字を利用し、全体の0.2%が女性マネージャーだとした場合でも、932人となります。
まとめると、
悲観：232人、中間：583人、楽観：932人となりました。
エンジニアは他職種と比較して女性比率が低い上に、スペシャリストコースに進む方も多いため、悲観〜中間の数値が現実味があるのかなと思います。
6. まとめ
ソフトウェアエンジニアのすべての女性の総数は46,610人。
そのうち20代・30代は34,740人、さらにマネージャー経験者は多くて500人くらい。
ボリュームゾーンの20代・30代の中でもマネージャー経験者は1.4%。
100人の20代・30代女性ソフトウェアエンジニアに会って、1、2人会えるかどうか。
7. 感想 / および自分語り
現状なぜ女性エンジニア、マネージャーが少ないかについては言及しませんが、女性エンジニアが少ないことは、今後さらに女性が活躍しにくい環境を作るんだろうな、と想像します。
というのも、自身がマネージャーになるときも、本当はぎりぎりまでお断りしようと思っていました。
周りに女性エンジニア、及びマネージャーがいない（エンジニアでない女性マネージャーも少ない）状況で、自分に務まることなのか、結婚・出産などの未来を考える上でやるべきなのかという悩みがあり、また、相談する相手もいなかったからです。
そもそも、エンジニアの仕事は忙しいので、将来的にエンジニアを続けるべきかどうかも当時は迷っていました。
私の場合最終的にとりあえずマネージャーになってみた結果、なって良かったと思ってるんですが（笑）そういう悩みを相談できるコミュニティーなどを今後やっていけたら良いなと思っています。
