再考。プロジェクトマネジメント

ソフトウェア開発に必要なものには、技術力とマネジメント力の２つだと言われます。

技術力は、プレイヤーとして働くための個人の能力のことを言い、マネジメント力はプロジェクトというチームを動かすための能力のことを言います。

現在、デジタル化が進むにつれ、開発されるソフトウェアのステップ数は膨れ上がり、何百万ステップという巨大なソフトウェアを作ることは、能力的にも、時間的にも一人では到底できる代物ではありません。

ソフトウェア開発に関わる人が増えることによって、人間関係という全くロジカルではない代物が、ロジカルな作業の塊であるソフトウェア開発の中心に鎮座することになったのです。

マネジメントは、サラリーマンの世界では、「管理能力」として昔から存在しているものですが、ITの世界のプロジェクトマネジメントは、かなり特殊なものと言っていいでしょう。

なぜかと言えば、ただの管理のように現状を維持する目的で行われるものではなく、プロジェクトマネジメントが「結果」を出すために行われるものだからです。

ここでは、プロジェクトマネジメントについて再考してみたいと思います。

■　ITプロジェクトの「ミッション」＝Q（品質）×C（コスト）×D（納期）

前提として、ITプロジェクトそのものがビジネスの戦術の一つとして行われる以上、数字が求められます。それが、Q（品質）、C（コスト）、D（納期）の３つです。

１）Q（品質）

単純に言えば、開発したソフトウェアやシステムにバグが無い（バグゼロ）ことを言います。
バグゼロであることを証明する活動が、品質を確保することです。

しかし、何を、どこまで、どうやって証明できるか、明確な指標や方法は、あってないようなものとい言わざるを得ません。それでも、バグゼロのソフトウェアやシステムを生み出すことが宿命とされます。

２）C（コスト）

たとえば、新商品を企画する場合、結果として、売上を増加（＋）させることが求められます。
しかし、ITプロジェクトは、逆で、決められた予算（コスト）を計画的に消費（－）することが求められます。いわば「いかに上手にお金を使えるか」がプロジェクトの成功要因の一つとなります。

３）D（納期）

時間は、お金と違って貯めることもできませんし、いくら予算があったとしても、お金で買うこともできません。ITプロジェクトが始まると、後で時間があるときにやろうという考えは、納期を遅延させるリスクを大きく跳ね上げることになります。時間に追われるというよりも、納期までの残り時間を頭に入れながら、日々、前傾姿勢で自ら時間を追っていく感覚が必要です。


上記QCDを確保するには、ITプロジェクトにおいて、「管理」と「マネジメント」を同時に実施することで、「量」と「質」を確保します。

■　プロジェクトのエンジン

プロジェクトを進めるために、PDCAサイクルを回す必要があります。

１．Plan（計画）
　プロジェクトの目的、予算、スケジュール、体制など、プロジェクトを実行するための準備をします。

２．Do（実行）
　計画に沿って、プロジェクトを進行させます。

３．Check（評価）
　プロジェクトの状況を確認し、課題を整理します。

４．Action（改善）
　課題に対して対策を考え、実施します。

ITプロジェクトでは、以下のように、Plan(計画)を中心に、Do（実行）/ Check（評価）/ Action（改善）を高速に回転させていきます。

進まないプロジェクトとは、PDCAサイクルのどこかで滞っていることになります。
例えば、計画に無理がある、実行できるスキルが足りない、課題が放置されたまま改善されないなどです。

■　「ソフトウェアエンジニアリング」と「開発プロセス」

ソフトウェア開発には、「ソフトウェアエンジニアリング（工学）」と言われる標準化（Standard）された管理手法があります。これは、高品質なソフトウェアを効率的に作るためのガイドラインに相当するものです。

ソフトウェアエンジニアリングの主な管理対象は、以下となります。

１）工程管理

要求定義、システム設計、プログラム設計、プログラミング、単体テスト、結合テスト、システムテストなど、ソフトウェア開発のフェーズが工程です。

プロジェクト毎に、工程の中の作業を洗い出し、担当を割り当てることをWBS（Work Breakdown Structure：作業分解）と言います。WBSは、作業の内容と工数、期間がわかる単位まで細分化し、それを工程内の作業として、スケジューリングします。

工程の並べ方、実施回数などは、開発手法によって異なります。開発手法は、大きく「ウォータフォール型」、「インクリメンタル型」の２つに分けられます。（参考「弱者のための『ITプロジェクトの構造』入門」）

２）品質管理

前述したように、品質を可視化し、管理できるようにするには限界があります。
そこで、ソフトウェアの作り手であるITエンジニアの行動に紐付いた「ミス」をカウントすることで代替します。

「ミス」は、仕様変更、設計変更、バグであり、これらの数と開発規模（総ステップ数）の比（数 / 総ステップ数）が品質指標として使われます。

また、「レビュー」と呼ばれるプロジェクト内の他エンジニアによる設計資料やソースコードの目視確認によっても、「ミス」をカウントします。レビュー時間と開発規模（総ステップ数）の比（レビュー時間 / 総ステップ数）、レビューでの指摘数（設計資料やソースコードのミスの数）と開発規模（総ステップ数）の比（指摘数/ 総ステップ数）が品質指標として使われます。

３）原価管理

予算の消化具合をモニタリングします。定期的あるいは逐次、費用を集計し、予算内に収まっているかを確認します。また、発注前の見積もりを確認し、予定外の無駄な予算の消費を防ぐことも行われます。（予実管理）

４）要員管理

ITエンジニアの適正配置、補充などを行います。
プロジェクトに参加するITエンジニアに必要なスキルを習得させるために勉強会や研修を実施したり、OJT（On the Job Training）で教育することもあります。

しかし、昨今の短納期化するプロジェクトでは、そのような余裕はなく、はじめからスキルと経験のある即戦力の人材しかプロジェクトに参画させないというプロジェクトが増えています。

「開発プロセス」とは、ソフトウェアエンジニアリングの「工程管理」と「品質管理」に深堀し、開発組織内で独自に細かく決めた社内規約のことを言います。各工程完了時に「審査」が実施され、遵守されているかどうかを厳密にチェックされます。審査を通過しない限り、次の工程に進むことが許されません。

開発プロセスが組織的に追求されて最適化が進むと、開発現場では「マイクロマネジメント」が横行し、開発実務との乖離（かいり）が大きくなります。そうなると、本来、ITプロジェクトを効率化するはずのソフトウェアエンジニアリングが、ITプロジェクトの推進の大きな障壁になることもあります。

■　インファイトか、アウトボクシングか

PDCAサイクルを回すには、現場手動で「問題解決」を繰り返す「オンサイトマネジメント」が必要となります。リアルタイムにプロジェクト内部の情報を入手し、情報を整理し、その場で判断を下し、すぐに行動に移していきます。その結果として、ソフトウェアの品質を確保することができます。

一方、ソフトウェアエンジニアリングを基本とする開発プロセスは、プロジェクトのアウトプット（成果物）をデータとして、客観的にソフトウェアの品質を判断し、開発プロセスとの齟齬を是正措置として実施します。これは、開発プロセスに合わせていけば、自動的にソフトウェアの品質を確保できるという前提のもとで行われます。

問題解決のスタイルをまとめると以下の表のようになります。

ボクシングのスタイルで言えば、PDCAサイクルは「インファイト」で、開発プロセスは「アウトボクシング」とたとえることができるでしょう。

どちらか一方だけでは、プロジェクトは立ち行かなくなります。

プロジェクトを戦うための正しい姿は、インファイトを中心に、必要なときにアウトサイドボクシングを取り入れるスタイルです。問題解決は、原則、PDCAサイクルにて処理し、進捗、品質、予算などの日常的な管理を開発プロセスを使って行っていきます。

■　原則「問題解決を中心とし、ソフトウェアエンジニアリングを取り込む」

ソフトウェアエンジニアリングは、自己中心的な行動を取りがちなITエンジニアに対して規律を与えてくれます。特に、プロジェクトの中で、仕事をするには他者と協働することが必須の条件となります。
そのためには、お互いの作業の同期やレビュー、バグや問題解決のための情報のやり取り、日々の工数や費用の管理など、プロジェクトが姿勢を維持できる程度のルールは必須です。

PDCAサイクルにて行う問題解決を中心に、そのために必要な管理を主体的にプロジェクト内に組み込むことです。ITエンジニアによってプロジェクトを自律的に運営するためには、組織的な「開発プロセス」に謳われているからではなく、プロジェクトに参画するITエンジニアが自ら有用と判断した「管理」を取り入れて実施する必要があります。

■　まとめ

組織が決めた「開発プロセス」を鵜呑みにし、開発プロセスを中心に据えた管理主導のプロジェクトの運営したとしても、残念ながら想定通りにいくことは、まず、ありません。

しかし、世間では「プロジェクマネジメント＝管理」の側面ばかり焦点があたり、本質的なプロジェクトの活動に一向に日が当たらず、失敗ばかりが積み重なっているように思えます。
ITプロジェクトが下請分業構造にならざるを得ない現状を考えると、管理強化を声高に唱えることも仕方ないと思う反面、理想と現実のハザマで発生する問題をさばきながら前進すること、それがプロジェクトを進める唯ーの手段ではないかと思います。

このような正しい認識は、ITエンジニアのモチベーションに大きく依存するところでもあります。
これまで放置されてきたITエンジニアをモチベーションを上げる方法、それは報酬だったり、新しいキャリアであったりするでしょう。あるいは、良好な人間関係といったものかもしれません。

プロジェクトを成功に導く鍵は、表面的な管理ではなく、もっと奥深いところにあります。