これまでに頂いたプロジェクトマネジメントについての相談は、大きく２種類あったように思います。
- プロジェクトが計画から遅れていることが常態化してしまっている
- 「プロマネをちゃんとやれ（強化しなさい）」と、顧客から要求されたり経営層から大号令がかかっている
ここでは１つめのカテゴリから例を取って、実際にどのような戦略をとったかというところまでを紹介します。
Contents
1. 相談内容
お話しを伺ったり現場アセスメントを通じて確認したチームの困りごとは以下の通りです。
背景
- 開発計画、進捗管理、問題解決管理など、一般的なプロジェクトマネジメントは全社的に行われている
- トップレベルに全社計画があり、その下に回路・機構・ソフトウェアなどのチーム別計画が存在している
- 全社計画・各チーム別計画とも、Microsoft Projectを使用してガントチャートベースで管理されている
- 全体企画部署（あるいは顧客）、回路設計部署などから要件が出てくる（仕様はFixしない、変更が入る）
問題： 困っていること
- 予測できない割り込み作業が多く、計画実行の工数が圧迫される（変更要求のための仕様検討・技術調査など）
- 割り込み作業にどのくらいの工数が必要となるか見通しが立ちにくく、予想以上に大きな工数を消費される
- チームメンバーが今現在なにに工数をとられているのか計画書をみてもわからない
- 結果的に作業が計画通りに進まず、遅れが常態化してしまっている
2. 原因分析
アセスメント ＋ チームの皆さんとのディスカッションを通じて、困りごとの原因分析を行いました。
大げさに / 形式主義的にやることは滅多にないですが、それでも先入観や安易な結論の落とし穴にハマるのを避けたいために、分析はどんなに簡易的であったとしてもチームのみなさんと共に実施します。
たとえば「なぜなぜ分析」なら以下のようなイメージで真因を探ります。
- 予測できない割り込み作業が多い → なぜ？
- 他部署の状況がわからない
- 先を予測した動きができていない → なぜ？
- リスク管理ができていない → なぜ？
- ガントチャートと不具合管理表を追うことに手一杯で、そこまで手が回らない → なぜ？
- 不具合対応から発生する工数をガントチャートに反映させることだけでも手間がかかりすぎている
- リスク意識が低いかもしれない → なぜ？
- そもそも例外事象は多くなかった（が最近増えている気がする）
原因となりうる要素を、視野を広げて幅広く(1)、安易に結論せず深く(2)、探索して主要な原因と考えられるものを洗い出します。
3. 戦略
どう対策を講じてゆくか、活動方針を検討します。私たちから提案もしますが、やはりチームのみなさんの現場感覚のほうが正確なことが多いので相談しながら進めています。
課題： どこを攻めるか
最初の突破口をどこにするかチームの皆さんと共に決めます。ダムに穴を開けるように小さな努力で大きな変化を誘発しうるポイントが理想です（言うのは簡単ですが）。
実際には５点くらいに絞ったのですが、ここでは２点のみ記します。
- 変更は多発するものという前提がなく、あくまで例外処理として付加的に扱われている
- 影響： ガントチャートと変更依頼リストの二重管理になり、必要工数の把握が複雑になる → 工数が読めない
- 変更要求を無判断に受け入れており、その影響がソフトウェア開発チーム外へ情報提供されていない
- 影響： 結果的にソフトウェア開発チームが勝手にスケジュール遅延を引き起こしそれが常態化していることになっている
戦術： どうやって攻めるか
他社の事例など紹介しながらチームのみなさんと方向性をつくってゆきます。
- 変更要求の発生を前提にした開発プロセスに組み変える
- チームへの全てのインプットを要求と不具合に分類し、要求を追加要求と変更要求とに分類する。便宜上初期要件も追加要求として扱う
- 全社標準のウォーターフォール的な開発プロセスではなく、要求（と不具合）を起点とした開発プロセスに組み変える
- チームへのインプットを全て ITS（Issue Tracking System、Jiraなど）に登録して、タスクも一元管理・追跡する
- 段階的受入れをルール化し、他部署との情報共有を進める
- 要求は、まず登録し(1)、一次分析を行い(2)、分析結果と粗い工数見積りを記録する(3)
- チーム内で吸収できない大きい影響をもつ要求については他部署に情報共有した上で受入れ判断に参加してもらう（最初のうちは形式的であってもよい）
実際には、
１．上記の「入口側」への対策と共に「出口側」を固定することでチーム内部を混乱させる外来要因を減らしつつ、
２．同時にチーム内部の活動の優先度判断・進捗モニタリング（のための定例ミーティングなど）の手法を改善することで、
開発を “アンダーコントロールな” 状態にすることを第一段階の目標としました。
“第一段階”について補足
いきなり完璧を目指す目標設定は、その目標と現状のギャップが充分小さいとき以外はおすすめしていません。
最初に想定した「完璧」が、いざ実現してみると「これじゃなかった」となるのはよくあることで、且つゴールまでの道のりを大きくとりすぎるとゴールに到達する前に環境が変わってしまう、というリスクもあるためです。
小さな有効打を継続的にうち続ける進め方をおすすめしています。
Agileについて補足
上記をみて「つまりアジャイルにしようとしているのでは」と思われたかもしれません。
製品開発期間を短くしたい、また開発中も市場変化に追従して方向修正したい、というビジネス上の要求が強まりつつある以上、ソフトウェア開発チームはどうしてもアジャイル的な開発に移行することを避けられないだろうと予想しています。
ですがだからといってアジャイルだけを強調しすぎると、入口も出口も放置したまま内部だけScrumにしよう、みたいな火に油を注ぐ話になりかねないので、そこは慎重に進めるべきだろうと考えています。
3. この後の進め方
ここまでに定めた方針を具体的なアクションプランへ落とし込んで、ソフトウェア開発力強化支援の Step 2 が終わります。
プランの実行フェーズ（Step 3）では開発チームへの伴走を基本にしつつ、状況に応じて組み変えたプロセスの定義・文書化、ツール類の整備などの追加支援を行います。
最後に振返りを行い（Step 4）、得られた成果、残存課題、次の段階へのアイデア出し、今回の活動全般の振返りなどを実施してプロジェクトをクローズします。
4. まとめ
一見してプロジェクトマネジメントの問題であったとしても、ソフトウェア開発チームではプトジェクトマネジメントと開発プロセスとの関係が密で、両方同時に手を打つことはよくあります。場合によっては、ソフトウェアアーキテクチャの見直しが突破口になることさえあります。
またソフトウェア開発プロセスの組み変え・調整のためには、他部署との関連を含めた組織アーキテクチャ視点が重要です。
プロジェクトマネジメント強化が目的であったとしても、開発チームのみなさんと議論しながら複眼的な視点に基づいて対策を立案・実施しています。