計画・進捗の精度向上とリスク管理：現場の声からプロセス改善を深掘りする（1）（1/2 ページ）

組み込みソフトウェア開発現場が抱える課題を明確化し、その解決策のヒントや気付きを共有する本連載。毎回開発現場で顕著化しやすい問題・課題をテーマとして掲げ、開発現場の生の声を基に深堀りしていく。（編集部）

[清水 祐樹 横河ディジタルコンピュータ株式会社，＠IT MONOist]

はじめに

　本連載は、横河ディジタルコンピュータ主催「組込みソフト開発現場が抱える課題の解決を考える勉強会」での議論を基に、組み込みソフトウェア開発現場で抱える課題やその解決策のヒント、気付きを読者の皆さんと共有することを目的にしています。

　そもそも、この勉強会は自らの活動や考えを客観的にとらえて、深く考えていただく場を提供するために企画された全6回のワークショップです。組み込みソフトウェア開発現場で顕著化しやすい問題を各回のテーマとし、プロセス改善活動にかかわっている方々や、現状に問題を感じておられる方々に参加いただいています。

　今回は、プロセスの構築において基本となる、計画策定と進捗（しんちょく）に焦点を当て、「計画・進捗の精度向上とリスク管理」と題して、ディスカッションを行った第1回勉強会の内容を踏まえ、プロセス改善を深掘りしていきたいと思います。

計画時に何を検討するか？

　計画策定と進捗の管理（監視）で最も基本的なことは、立案した計画に対して、差がないかをチェックし、是正していくことです。そのためには、どのような計画を立てるかが大変重要になってきます。

　まず、ソフトウェア開発の計画を策定するに当たり、勉強会の参加者たちがどのようなことを検討し、明確化しているのかを洗い出しました。

プロジェクトの目的と目標を明確にする 担当者（担当組織）とその役割 要求から導き出される成果物の構成要素 成果物の規模（作業量） マイルストーン 実施する会議の定義（会議体） 構成管理のルール リスクの明確化と管理ルール 品質目標：プロジェクト完了後の目標（出荷後不具合0件など） 品質目標：プロジェクトの途中段階での目標（上流工程でのレビューの完了基準など）

　検討する項目がいろいろと挙がりましたが、「目的・目標」は物事を進めていくうえで非常に重要です。各種計画を立案するときや、プロジェクトを監視、是正していくうえで、判断、決定を迫られたときに、最大のよりどころになります。これをソフトウェアの開発者のみでなく、要求の提供者（顧客）や営業部門、サービス部門などの、利害関係者と共有することが、意思決定をするときに大変役に立ちます。

　読者の皆さんの計画の中には、目的や目標は書かれていますか？

　また、「品質目標」ですが、プロジェクト完了後の品質目標は、継続的にプロセス改善活動を実施していくうえでは必須になってきます。一方で、顧客や要求の提供者にとっては、自分の依頼したプロジェクトの品質が重要なので、上流工程からの品質目標を定めて品質を作り込むことが重要になります。上記の項目（発言）でいうと「レビューの完了基準」がそれに当たります。

計画策定はどのような単位で実施するか？

　次に、それらの計画を策定する単位について考えました。計画の策定をどのような単位、範囲で実施するかは、プロジェクトの状況の見え方や、プロセス自体の運用に掛かる負荷に大きくかかわってきます。

			見積もりを実施した単位で計画を策定する

　実際のプロジェクトでは見積もりの作業自体も1つの作業です。また、実際の見積もり作業も計画策定と同様に、プロジェクトが進むにつれて、試算、概算、詳細のように段階的に詳細化されます。この発言での「見積もり」は、営業部門や顧客などからのシステムに対する概算見積もりの粒度に相当するでしょう。

			開発する製品単位で計画を策定する

　これは顧客や営業部門、企画部門などからの依頼に対して、作成する製品やソフトウェアの種類を明確にし、パラメータなどでの機能切り替え、実行モジュールの分割などを考慮し、プロジェクトの範囲を決定します。派生製品が多く、多品種製品のソフトウェア開発では、このようなパターンが多いのではないでしょうか。

			ある期間（半期や四半期）で見えているソフトウェア開発全体で計画を策定する

　作成するソフトウェアの種類が非常に多く、少人数でいくつもの製品を手掛ける組織では、このような見積もりの単位が適していると思います。

　作成するソフトウェアや組織によって、適切な計画を策定する単位・範囲は異なります。これをどのように設定するかによって、利害関係者との調整、コミットメントなど、プロジェクトの中で考慮しなければならないことに大きな差が発生します。組織で標準となるプロジェクトの範囲を見つけだし、それをベースに計画を策定し、組織としてプロジェクトの状況を、共通の指標で見えるようにすることが重要です。

何が計画策定を難しくしているのか？

　計画策定の概略は共有できました。しかし、計画の策定は容易ではありません。そこで、計画時の問題点や、計画変更が発生する要因について考えてみました。

			顧客、営業組織などからの要求の不明確さと追加／変更

			プロジェクト外で発生する突発作業

　これらは、どちらの組織にも共通の問題といえるでしょう。顧客とのやりとりについては、以下のような発言が複数の方から挙がりました。

			初期に決めた仕様に基づいたプロトタイプを見せると、「この機能が入らないと使いものにならない」とか、「いったことと違う、こういう動作にしなければダメだ」などといわれる

			プロジェクトの初期の段階では顧客も開発する側も、明確な仕様を定義することができず、プロジェクトを進める中でいろいろなことが見えてきて、仕様が膨らんでいく

　また営業部門とのやりとりでは、

			他社でこのような機能が入ったので、うちも入れなければ勝負にならない

			この機能を入れてここまでにリリースできれば大きなビジネスチャンスになる

などとプレッシャーを掛けられているようです。

　しかしこれらは、競争を行っている企業として避けて通れない現実でもあります。プロジェクトにかかわる開発部門、顧客、営業部門などが、納得感を持ってプロジェクトを進めていくことが重要です。

納得感のためにできることは何か？

　では、「納得感」を得るためにできることは何でしょうか。

　CMMIのプロセスエリア［決定分析と解決］などを参考にして、プロジェクトの目的・目標に沿った論理的で皆が納得できる判断、調整の仕組みを、組織として構築することで解決に近づけるのではないでしょうか。

　そのためには、自分たちの作業をきっちりと見積もり、スケジュールを明確にして信頼性のある計画を策定し、進捗状況、負荷状況を見えるようにすることが最初の一歩です。

　では、計画・進捗の精度を向上させるために、現場ではどんなことをしているのでしょうか？

			担当者には割り込みを考慮せず見積もりを行わせ、PL、PMがバッファを考慮する

			1日を6時間と考えて見積もりを行っている

			マネージャーがマイルストーンを与え、担当者→チームリーダー→プロジェクトリーダーと段階的に計画を立て、検証と妥当性の確認をしている

　まずは工夫を凝らし、精度の高い計画を作り上げることです。そして、変更要求、追加要求が発生した際は、それに掛かる工数、日程、コスト、対応することによって得られるメリット、対応しなかった場合の損失、影響を与える作業の工数、日程、損失などを定量的に計測し、皆が納得できる妥協点を、目的・目標に基づいて探っていくことになります。

			製品に対してのトラブルの対応や、問い合わせ対応などにも、多くの時間が取られて、前向きなプロジェクトの計画に対して大きな影響を与えてしまう

　これらは、個々のプロジェクトではなく組織として対応していくことが重要です。

			問い合わせの一時窓口を設けてできる限りそこで対応する

			過去の経験からプロジェクトの完了後の作業に対するリスク管理、プロジェクト間でのリソース調整などを行っている

との発言もありました。

　また、

			社内では製品の価格の中でソフトウェアは「0円」

と発言していた参加者もいました。とても悲しいですよね。納得感には程遠い状況です。

　当然ですがソフトウェア開発に価値がないわけではなく、変更には人も時間もかかります。そのような状況で何かを選択することは、何かを捨てることになります。捨てるものが「開発者のモチベーション」であっては絶対に良いモノ作りはできません。