これまで説明してきた「四つの約束」は会社の理念である。これに対して，これから説明する「六つの仕掛け」は実際の開発作業を支える考え方と仕組みである。今回は「ソフトウエアの規模を正しく見積もる」「作業プロセスの設計と基準作業時間を設定する」「分割と並行開発を進める」という三つの仕掛けを説明する。
仕掛け1：ソフトウエアの規模を正しく見積もる
ソフトウエア開発の歴史の中で見積もりほど不安定なものはない。特にJavaのように資産の数が多く，フレームワークや自動生成，部品の活用が一般的な開発言語を使う場合には，従来のステップ・ベースの見積もりでは対応できなくなってきた。つまり，規模が算定できないものを作っているのがプログラミングの世界である。これでは工業化も生産性も何も議論ができないことになる。まずは規模を基準で測定して決定できるようになることが重要である。
富士通アプリケーションズは2004年に，ステップ数による見積もりから機能ベースの見積もり手法である「ファンクションスケール法（FS法）」に全面的に切り替えた。機能ベースの見積もりにはファンクションポイント法（FP法）が有名だが，FSの特徴は一画面あたり5分程度で見積もれることにある。短時間で見積もれることは，大きな工数を掛けずに何回でも測定できるということである。あるプロジェクトでは，基本設計中に毎週測定し直すことによって，規模増のリスク，設計完了か未完かの判定に活用している。
現状では，生産性は「時間/100FS」，品質は「バグ件数/100FS」といった具合に，100FSに基準化して目標設定が行えるようになっている。これが工業化実現のバックボーンとなっている。
仕掛け2：作業プロセスの設計と基準作業時間を設定する
富士通アプリケーションズの工業化における中心的な考え方は，作業プロセスの明確化にある。従来のように一人の人間が設計からプログラミング，テストまですべての工程を担当することは，品質，納期，コストのすべての面で個人に依存することになり，極めて属人性の高い開発となる。作業をプロセスに分解して，入力と出力，作業内容とその手順を明確化し，事前の教育，訓練をすることにより，誰もがそのプロセスを担当できるようになる。これは従来のように人に仕事を割り当てるのではなく，プロセスに人を割り当てることになる（図）。
 |
| 図●作業プロセスの定義 [画像のクリックで拡大表示] |
プロジェクトはプロセスを設計する人，プロセスを守らせる人，そしてプロセスを実施する人で構成し，プロジェクト開始前にプロセスの設計と各種手順書と訓練計画を準備し，さらに量産試作を行い，プロセスの検証を行う。ここで問題を明らかにし，実際のプロジェクト開始とともに人を大量投入して訓練してプロセスを実行する。これにより，高い均一性と短期大量開発を保障できる。
同時に各プロセスには作業時間が100FSあたりで設定されている。これを基に，要員のスキル，総FS数，何回目の作業かなどの要素を入れ，それぞれの担当者にとっての作業時間（これを基準時間と呼ぶ）を算出する。これを基に仕事票からの作業実績データと合わせて進捗管理を行う。重要なことは「遅れているか」ではなく「なぜ遅れたか」にある。そこに課題があり改善のネタがあることを意識して進めることである。
従来からソフトウエア開発の現場では「何としてでも今週中に作れ」式の作業管理が見られたが，富士通アプリケーションズの方式では，あるプロセスの作業時間が8時間とするとスキルの低い人の基準時間は10時間となり，高い人は5時間となる。何時間残業かを決定することで無理の無いスケジュール設定が可能となる。
あるプロジェクトでは，詳細設計から結合テストまでの工程を143のプロセスに分解している。このプロセスには次工程へ進めるかのチェックや品質確認のプロセスも定義されており，プロセスを守る限り品質も担保していくことができる。
仕掛け3：分割と並行開発を進める
プロセスを分解していくと無駄なプロセス，並行して作業できるプロセスを見つけ出すことができる。これはプロセスを細分化すればするほど明らかになってくる。プロセスの設計が終わるとそれをフロー化して，役割との関係でフロー図を作成して，並行開発可能な部分を見つけ出す。このようにして開発期間の短縮を図っている。
最近の開発では顧客要件の確定の遅れ，基本設計の遅れが常態化している。開発工程での期間短縮の持つ意味は重要である。
|
