とあるPJの立て直し: プロジェクトを引き継いだら

　とあるプロジェクトの立て直しの記録に基づいて、プロジェクトマネジメントをテーマにシリーズで書き残したいと思います。引き継ぎのプロジェクトは「現状」があるため、新規のプロジェクトとはまた違ったやり方が求められます。アジャイルの考え方をどのように適用し、スクラムをどう導入したのか、みなさまの参考になりますと幸いです。

要旨#

現状を正確に知ることから始めよう
何から対応するのか優先順序を整理しよう

ある日呼び出されて#

　「呼び出し」というものはいやな予感しかしないものですが、このときの呼び出しも例外ではありませんでした。「とあるプロジェクトのプロジェクトマネージャーがいなくなるので引き継いでほしい」そう告げられました。このときの私は、そのプロジェクトの存在は知っていましたが、プロジェクトマネージャーが適切に遂行しており、特段の問題はないという程度の認識でした。他に当てもないと言うことで、担当していたプロジェクトが佳境ではありましたが、もう少しで一段落するタイミングだったこともあり、引き継ぐこととなりました。

　はじめに、可能な限り早く権限を移譲してほしいというお願いをしました。何事においても少しでも早く着手することはよい方向です。しかし、このときの前任者は去るギリギリまで「負担をかけないこと」を理由に権限を渡すことはしませんでした。若干の違和感はありましたが、プロジェクトの概要、システムの概要、ドキュメントの場所、定例への参加などわかりやすい情報の引き継ぎから始めていきました。そうして、前情報からは特に課題らしき報告はなく、平穏な引き継ぎが目されていました。権限がないため、顧客との契約、開発人員の契約、予算等について具体的な部分は後回しになっていました。

　引き継ぎフェーズで引き継ぐ想定のシステムを触ってみると低品質であることは一目で分かりました。引き継ぎ期間の間にもシステムがうまく動いていない報告を上げると、「開発中なのでまだ触らないで」「既知の問題」といったありきたりな回答が返ってくるため、課題をタスクとして記録するにとどまっていました。

蓋を開けてみると#

　このプロジェクトが本当に順調であれば、この記事は生まれないわけです。最初に得られる教訓はこうです。

悪い情報は積極的に隠蔽される
前任者がいなくなる真の理由があるかもしれない

　しかし、ことの本質をつかむのはなかなか難しいところです。前任者を理由もなく疑うことも憚られます。後に振り返って事前に何か対応できたかと言えば、予兆はシステムの品質が低いことくらいでした。この時点でここを執拗に深掘りしていれば、隠蔽され引き継がれなかった内容に少しだけ早くたどり着けたかもしれません。しかし、その程度です。むしろ快く前任者を送り出してあげた方がよい行いではないかと思います。

　権限を引き継いで全体像が見えるようになったあとは驚きの連続でした。驚きの過程は割愛しますが、8回ほど驚いてから大きく8つの問題として整理しました。

品質の課題
- これまで完成とされ、できているはずの機能が動いていない

顧客関係の課題
- 顧客との関係が良好ではない

契約の問題
- 請負契約にも関わらず、要件定義がなく完成の定義がない
- 「アジャイルでやる」と書かれている

開発体制の問題
- 開発者が初期から全員入れ替わっており、最も長いメンバーでも直近1年
- 残っていたメンバーは3人（2-3年目の若手2名と4−5年目のリーダー）

見積もりの問題
- 顧客とリリースが3ヶ月後で調整済みで、確約したらしい三大機能の開発が残っている
- 人材と期間とコストが明らかに見合っていない

設計の課題
- ログイン画面表示まで2分ほどかかる
- 多少データを入れると各所でタイムアウトが起こる
- クラウドの上限制約に引っかかる箇所が多い
- DBの設計が正しくなされていない（正規化されていない）

セキュリティの課題
- セキュリティリスクがこれまで考慮されていない
- ぱっと見ただけでも脆弱性がある（すぐにインジェクションできる）

市場分析不足
- 競合他社を見ており、市場を見ていない機能要件
- 顧客不在のシステム開発

　互いの課題は密接に絡み合っています。些細なところでは、各種アカウントのマスターパスワードが引き継がれていない、ドメインの連絡先が更新されていない、といったこともありました。

Cynefin Framework#

　一度にすべての課題に取り組むことは難しいため、各課題の状況を踏まえて整理します。こうした状況の整理に役立つフレームワークの一つに「Cynefinフレームワーク」というものがあります。クネビン、カネヴィンなどと発音されます。

　混乱（Confusion）、カオス（Chaotic）、複雑（Complex）、煩雑（Complicated）、自明（Clear）といった形で状況に応じてマッピングを行います。

混乱（Confusion）は、以下の4つのいずれのドメインにも分けられていないものです。以前は無秩序（Disorder）とされていたもので中央に位置します。
カオス（Chaotic）は、予測そのものが不可能で、対応方法が不明なものです。COVID-19の最初期段階などがよい例です。一般的に行動し、観測することから始めます。
複雑（Complex）は、主に課題の本質を捉えるために試しみながら考えるものです。まさにアジャイルを適用する状況と言えます。
煩雑（Complicated）は、多少状況の把握は必要ですが、概ね対処方法が見えているものです。これまでの経験や知識を活用して解決していきます。
自明（Clear）は、対応が明確で、本来であれば事前に対応し回避できたであろうものです。問題として顕在化した以上は対策を行います。以前はSimpleと呼ばれていました。

　以下は、実際に私がマッピングしたものです。実際はもう少し小さい粒度でマッピングしましたが、大きくカテゴライズするとこのようになりました。これは私から見たこのプロジェクトの状況であり、専門性やバックグラウンドが違えばまた違った分析となります。幸いなことに混乱やカオスな状況はなく、ほとんどがきちんと対応をすればどうにかなる煩雑と自明領域の問題でした。複雑に残る問題については現時点では情報が足りず、状況をより詳細に分析しながら対応方法を探索することになります。

近道はない#

　何か一つの手立てですべてが建て直る状況はそうありません。Cynefin Frameworkのようなものを使って状況を整理した後は、順序立てて一つ一つの課題と向き合います。以降はこれら8つの課題について見ていきます。