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
