この記事はモチベーションクラウドアドベントカレンダー13日目の記事です。
こんにちは。リンクアンドモチベーション、モチベーションクラウド開発チームの太田です。
この半年間、エンジニアリングマネージャーとしてプロジェクトマネージメントという芸術的活動（大げさ！）に携わっているのですが、日々刻々と移り変わる状況に振り回されながらも学んだ３つのことを紹介したいと思います。
同じようにプロジェクトマネージメントに携わっている方やこれから携わる方の参考になればと思います。
そもそもプロジェクトとは
書籍『「プロジェクトマネジメント」実践講座』によるとプロジェクトとは
独自の目的・目標を設定し、それを期限までに達成させる一連の活動
のことで
要は世の中で目的・目標と期限が設定された活動は全てプロジェクトに位置付けられます。
受験勉強も結婚式の準備も全てプロジェクトですね。
愛すべき失敗たち
新機能開発プロジェクトのプロジェクトマネジメントをしていく中での
- 失敗
- 変えたこと
- 学んだこと
を書いていきます。
1. プラクティスつまみ食い
失敗
巷ではアジャイル開発が流行っているということを知り、僕たちのチームでもアジャイル開発を取り入れようとしました。しかし、実際にはアジャイル開発のプラクティスのうちのバックログ（のようなもの）やデイリースクラム、スプリントレトロスペクティブなどのいくつかのプラクティスをつまみ食いしているだけの状態で、「ウォータフォールではない何か」をしているだけで、どちらのメリットも享受できていませんでした。
変えたこと
朝会や振り返り、各種レビューなどの全ての会議体の目的と参加者（役割）、アジェンダを明確にしました。単にアジャイル開発やウォータフォール開発のプラクティスを真似するのではなく、あくまでそれらを参考にして、僕たちのチームにおけるルールやプロセスを決めました。関係性の視点でいうと、開発手法はプロジェクトチームの対応能力と顧客の要望実現をつなぐものであり、必ずしもプラクティスを全て真似しなくても良いのではと考えました。
また、ルールやプロセスをチームwikiやドキュメントにまとめ、振り返りで改善点が出る度にアップデートしていく習慣ができているため、プロジェクトメンバーのチームに対するオーナーシップも出てくるのではと思います。
学んだこと
アジャイルやウォータフォールはあくまでもプロジェクトを成功させる手段であり、大切なことは期限までに目標を達成させること（難しいのであれば適切に調整すること）である。内部環境や外部環境の個別性に鑑み、ルールやプロセスを自分たちなりに確立することが大切だと学びました。
調べてみるとバイモーダル戦略というものがあると知りました。僕たちのプロジェクトでは機密性の高い組織診断のデータを保持しておくという点でSoRをベースにし、その上でSoEのケイパビリティをいかに獲得していくかが鍵になってきそうだと分かりました。（引用：System of RecordとSystem of Engagement）
2. 「終わりそうです」の落とし穴
失敗
最初に携わったプロジェクトでこんなやり取りをしました
（ある日）
僕「終わりそうですか？」
担当者「終わりそうです」
（数日後）
僕「終わりそうですか？」
担当者「少し遅延してますが、ここから巻き返すので終わりそうです」
（数日後）
僕「そろそろ終わる頃ですか？」
担当者「終わらないです。3日遅延します。」
僕「
」
終わりそうかどうかを聞くだけで具体的な数字やリスクをもとにした会話ができていなかった僕は急に遅れが発覚したように感じました。でも、本当はそのシグナルは何日も前から出ていて、それをキャッチすることができていなかったのです。
変えたこと
当たり前かもしれないですが、下記の3つのポイントを押さえるようにしました。
- 過去の実績を測定すること
- 計画と実績の差を分析すること
- 未来どうなるかを予測すること
計画と実績の差を分析する際に気をつけたことは
単純に作業が見積もりに対して遅れたのか、それとも予期せぬ割り込みで稼働工数が減ったり、タスクの追加が発生して全量が増えたのかを切り分けることです。
そうすることで初めて過去の消化速度が分かり、未来の予測ができるようになります。
車でドライブをしていても、例え到着地点までの残りの距離が同じでも、
現時点まで60km/hで進めたのか、渋滞が多く20km/hでしか進めなかったのかでは到着予想時刻は大きく変わってくるので、現時点までの速度（実績）を知ることの重要か分かります。
学んだこと
進捗管理では過去の消化速度を分析することで未来の予想をすることができます。そして、何によって計画と実績の差が生じたかを分類することで未来の予測がよりクリアになることを学びました。
また、計画と実績の差をチームで分析する際に心がけるべきは「問題を言いやすい環境をつくる」ということです。人はいきなり問題に向き合い、変化していくことに対して抵抗感を覚えるもので、場合によっては本当の問題を覆い隠したくなるものです。リンクアンドモチベーションでは問題に向き合い、変化（Change）していく前に、まずは固まった氷を溶かすような「Unfreeze=解凍」のアプローチが欠かせないと考えております。弊社ではお世話になっている株式会社レクターから下記のようなKPTフォーマットを頂き、週次で振り返りをしていますが、Keepを最初に出し合い、結果という抽象的な数字だけでなく、メンバーの具体的な行動を賞賛しています。これには本当の問題を言いやすい雰囲気をつくるという点で「Unfreeze」の要素が含まれています。
3. 単なる決定事項伝達係
失敗
（ある日）
僕「A機能よりB機能を優先することが決まりました。頑張りましょう！」
エンジニア「・・・（え、なんで？）」
（次の日）
プロダクトマネージャー「xxxの背景でC機能を優先的に開発することはできますか？」
僕「かしこまりました」
（次の日）
僕「やっぱりC機能を開発することになりました。頑張りましょう！」
エンジニア「・・・（え、なんで？）」
プロダクトマネージャーやその他ステークホルダーとの話し合いの上で決定したことをプロジェクトメンバーに伝える時に背景や経緯をきちんと説明できていませんでした。決定の背景には必ずいくつかの比較検討や葛藤があるにも関わらず、最終的な結果のみをメンバーに伝えていたのです。
日々移り変わる状況の中で優先順位やスコープが変化することはある程度仕方ない場面もありますが、その際に決定事項をどのようにプロジェクトメンバーに伝えるかがメンバーの能率を大きく左右することを実感しました。
変えたこと
- しっかりと時間をとって背景や判断基準を説明する
- 定量的に満足度をモニタリングする
朝会で全体の方針に関する決定事項を説明する時間を設け、メンバーの納得感を醸成するようにしました。場合によっては一度に全員に伝えるのではなく、事前に特に関係の深い人に話して意思決定の背景を理解してもらうなど、コミュニケーションの順番にも気をつけました。
また、エンジニアリングマネージャー/プロダクトマネージャーと開発メンバーとの間で意思疎通ができているかをモチベーションクラウド（※）を用いて定期的にスコアリングすることでメンバーが階層間の意思疎通に満足しているかどうかのモニタリングをしました。
※モチベーションクラウドでは特に改善したい項目に対してパルスサーベイを取ることで改善状況をモニタリングできる機能があります。
学んだこと
マネージャーの役割の原点はコミュニケーションの結節点であり、階層間や部署間のコミュニケーションを活性化させるための情報の受発信が大切であることが分かりました。そしてマネージャー次第ではメンバーのモチベーションが0にも100にもなり、結果的にプロジェクトの成功を大きく左右することを学びました。
アメリカの経営学者のチェスター・バーナードが提唱した組織が成立するための条件には下記の３つがあり、いかにマネージャーが「コミュニケーション」に注力するべきかが分かります。
（引用：リンクアンドモチベーションHP）
最後に
当初、プロジェクトマネージャーはいち調整役でしかないと思っていましたが、実際には組織の結節点としてチーム全体の効率やメンバーの能率を大きく左右しうる重要な役割であると学びました。きっと知識や経験だけでなく、人間性もとても大事になってくる役割なのだと思います。なんだか奥が深そうでワクワクします。
個々人のモチベーションが高く、組織成果も出る、そんな開発組織をつくっていきたいと思います。