はじめに
ソフトウエア開発のプロジェクト管理を行うにあたり、基本的にはチームで取り組むのが一般的です。 関係する人数が多ければ管理面も複雑化していきます。 しかし、意識することで失敗を減らすことができる知識や法則、原則がいくつか存在します。 今回はこれらをご紹介します。
パーキンソンの法則
概要
「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」
与えられた時間が長ければ長いほど、仕事がその時間に合わせて増える傾向があるという法則です。
事例
３人日の作業量の仕事を（リスク込みで）5日間の期限で依頼した場合、
リスクが発生しなかった場合でも、（無意識的に）開始時期の先延ばしや、
生産性を調整し、与えられた期間の５日間かけて仕事を完遂させます。
その結果、生産性悪化や、リスク等で確保していたバッファ期間の意図しない消費が発生します。
対策
- 明確な締め切りを設定
作業を振る際に、リスク等のバッファ期間は作業者本人ではなく管理側で把握し依頼します。 - タスクを細分化
大きな作業を細分化し、それぞれに短い締め切りを設定します。 - 進捗確認
定期的に具体的な進捗を確認し、生産性や課題の状況を把握します。
上記１、２について作業担当者とも認識合わせを行い、しっかりとした目標を立てることが重要です。
期待される効果
生産性悪化の防止や、リスクで確保しておいたコストを適切に使用することが出来るようになります。
ブルックスの法則
概要
「遅れているプロジェクトに人員を追加すると、プロジェクトはさらに遅れる」という法則です。
事例
１０人月分の遅れが発生したプロジェクトにおいて、単純に１０人追加したとしても
遅れが解消するどころか悪化を招き兼ねません。
これは、新しいメンバーを追加すると既存メンバーによる教育や、コミュニケーションチャネルの
増加による調整コスト、情報共有コスト、タスクの複雑度が指数関数的に増加していくためです。
これは遅れ分のリソースを単純に追加したとしても、解消されない（最適解ではない）ことを意味します。
対策
- 計画の精度を上げ、リスク管理を徹底する
必要なスキルセット、リソース含めた詳細計画を立て、事前にリスク検討を行うことで、 要員追加によるオーバーヘッドの発生を低くすることが可能です。 - 小規模チームの維持
チームの規模を広げすぎずコミュニケーションチャネルを限定することで、効率化に繋げます 規模拡大についてはチームの分割も視野にいれます。 - 段階的なリソースの追加
計画を立て小規模チームの維持をしたうえで、必要なリソースを検討し段階的に追加していくことで、 新規リソース追加による混乱を極小化していきます。
期待される効果
新規リソースの追加によるプロジェクトの混乱を防ぐこと、また法則を理解しておくことで、 依頼者への急なリソース追加に伴う混乱を説明することが可能となります。
グッドハートの法則
概要
「計測結果が目標になると、その計測自体が役に立たなくなる」
これはある数値を目標に設定してしまうと、なんとかその数値をクリアしようという意識に向いてしまい、
本来の目的を見失うことを指す法則となります。
事例
例えば開発生産性について目標を設定してしまうと、品質を落としてでもクリアしようとする人が
現れたりする可能性があります。
他にも試験工程において、IPAの統計を元にした開発規模からのテスト項目数や不具合数に近づけたり、
もしくは試験項目数指標をクリアしただけで満足してしまい、本来の目的である品質を図るという観点が
抜けてしまったり（指標範囲内なので品質も問題ないだろう）します。
対策
- 目的をしっかりと定義し、複数の指標値を設定
単一の指標値だけではなく複数設定することで、多角的な視点から確認できます。 そのうえで目的達成出来ているかを確認しましょう。 - 行動の確認とフィードバック
指標を得るための行動を確認し、目的意識を落とし込んだうえで、結果を得るためのプロセスに対して フィードバックしていきます。 - 指標の最適化
形骸化された指標ではなく、プロジェクトの特性毎に必要に応じて指標を見直すことで、 指標を最適化します。
期待される効果
指標のみを信じた結果、目的とは離れた地点へ着地することは稀にあることです。 結果が出てからでは遅いため早い段階で見直しをかけることが可能となります。
KISS（Keep it simple stupid）の原則
概要
今まで挙げてきた法則とは違いますが、システム設計やソフトウエア開発において、 シンプルで分かりやすい設計を心がけるべきだという原則です。
事例
単純な計算なのに複数のクラスやインタフェースを作成する、拡張性を意識しすぎるあまり 不必要なデザインパターンを使用する、仕様が徐々に複雑化していき、コスト見合いとなった結果、 なし崩しの機能追加となり、可読性や保守性が著しく落ちたものが出来上がったりします。
対策
- シンプルなモジュール化
モジュールの独立性を高め、単純な機能のみを持つようにします。 - 冗長的な部分や複雑なロジックの排除
保守性等も考え、なるべく冗長的な記載をなくし、シンプルな構成を心がけましょう。 - シンプルで直感的なUI
複雑度が高いものは便利ではありますが、引き継ぎ等で担当が変わると使われなくなっていきます。 シンプルなUIを前提として設計しましょう。
期待される効果
最終的にシンプルな設計構造の方が、リリース時の障害発生率が低く、高い保守性が維持され、 運用開始後の障害発生率を抑えることが可能です。そのためより長く使われることになります。
またシンプルな仕組みの方が、結果的には拡張性も高いと言えるでしょう。 色々便利な機能を付与したいとお客様からの要望も来ると思いますが、 本当に必要な機能をシンプルに設計するための指針としていきましょう。
最後に
プロジェクトとは独自のプロダクト、サービス、結果を創造するために実施する、 有期性のある業務という定義とされています。 基本的には（類似はあるものの）前例がないため、管理者やリーダーは プロジェクトの目的達成を目指し様々なことを検討する必要があります。
今回ご紹介したような法則・原則を生かすことで、プロジェクトの成功率を少しでも上げていきましょう。
