コラムColumn

■清水吉男氏との出会いのきっかけは？
　清水さんが講師を務めた社外の合宿研修に参加したのがきっかけです。2004年10月29～30日に船橋で行われた高品質ソフトウェア技術交流会（QuaSTom）主催の「要求とその仕様化」という演習付きの研修でした。
　その研修会の内容に感銘を受け、USDMを社内でも普及展開するために清水さんにコンサルティングをお願いしました。その頃、富士フイルムでは商品ごとに7部門ほどの開発部門があったのですが、それぞれの部門で指導を受けたいプロジェクトに手を挙げてもらって、そこに清水さんをアサインして指導していただきました。
　１年間くらいコンサルティングを受けた頃に、SESSAMEで作成していた「話題沸騰ポット」を改版することについて、背景や事情を説明して指導をお願いしたところ、快諾していただけました。

■USDMで要求仕様を記載することのメリットは？
　なぜその仕様にしたのかという理由が仕様と合わせて記載されていることだと思います。それによって仕様の目的や意図が明確になるからです。
　また、USDMで記載した要求仕様は数値化し易く、仕様書をもとに見積もった開発工数と実際に費やした工数を比較しても大きなブレは生じないという清水さんの話の通りの見積精度向上の効果を確認したことも多々ありました。

■清水氏は、その後、2010年に派生開発推進協議会(AFFORDD)を立ち上げられました。AFFORDDとの関わりは？
　その頃の私は職場環境が変わっていたこともあり、AFFORDDの立ち上げには参加できませんでしたが、数年前に長野で開かれたAFFORDDの地方部会に呼ばれて話をしたことがあります。清水さんが亡くなられた後に、生前の清水さんから直接指導を受けた人が講師になって、今の若い人たちにノウハウや考え方を教えるのがよいのではないかという話になったそうで、私のことを知っている人が声を掛けて下さいました。

■USDMは組込みソフトウェア開発の分野で利用されることが多いですが、業務系アプリケーションでも有効だと思いますか？
　はい、USDM形式で要求仕様をまとめることは、開発工程の上流工程で不具合が多く入り込むような状況を解決する手段として特に有効だと思います。
清水さんのこの手法を用いると、まず初めに要求とその要求が出てきた理由を明確にするためのコミュニケーションが必要になり、必然的に開発関係者間の情報共有が円滑になるので、要求事項と開発した製品とのミスマッチが少ないシステム開発につながると思います。
　ヒアリングシートなどで「なぜそうしたいか」を問うことは、仕様の議論を促進し隠れた要求を引き出す助けにもなると思います。

■自動運転等が実用化し、組込みソフトウェア開発の品質がより重要な社会になってきています。若い技術者に向けて要求仕様の分析方法について、何かアドバイスいただけますか？
　仕様書は、関係者のコミュニケーションの結果を確認する手段ですから、人が見て判り易く、レビューし易く記述することが求められると思っています。自分だけがわかる書き方では、どれだけ詳細に正しく仕様を記述したつもりでも、伝えたいこと全ては伝わっていないと思ってよいでしょう。
　自分が「わかっている」ことを人に伝えた時、相手が「わかった」と言ってくれたとしても自分の「わかってほしい」ことを100%伝えられてはいないと思うことが大切です。
　そう考えた背景や理由を伝えない限り、仕様だけでは他の人は同じ考えになれるとは限りません。手段を変え、いろいろな形でコミュニケーションを取ることでやっと伝えられると肝に銘じていると、お互いに齟齬なく深く知り合えるのではないでしょうか。

※このコラムは今回が最終回です。本コラムへのご意見・ご感想はこちらへお願いいたします。