PR

 かつてプロジェクト・マネージャ(PM)の業務といえば,メンバーが書いた仕様書や設計書,議事録などプロジェクトに関連する文書の加筆・訂正が3割を占めていた()。しかし,近年のPMは,文章指導に占める割合が減少し,会議や社内調整,事務作業と言った仕事の割合が増えてきているという。

図●プロジェクト・マネージャの業務
図●プロジェクト・マネージャの業務

 筆者の知り合いのあるPMなどは,自身のプロジェクトにおいて文章指導は皆無であると言い切る。これは非常に危険な状況である。PMが文章チェックを省略したことによる失敗は意外に多い(表)。

表●文章チェックを省略したことによる失敗の例
カテゴリ チェックしなかった文章 失敗内容
メール ~顧客の皆様からご回答をいただければ~ 「顧客」という表現は失礼な表現であるとクレームが入った。「お客さま」とすべきであった
要件定義書 ~日本円でだけ精算~
~日本円だけで精算~
「だけで」と「でだけ」を取り違えたためにプログラムの修正を余儀なくされた
仕様書 申込書の銀行口座振替欄か郵便口座振替欄にチェックがはいっていれば,自動で口座番号をセットする 「~か~」という部分をプログラマがORと判断した。[銀行口座振替欄] OR [郵便口座振替欄]としたため、両方にチェックが入っている申込書を受け付けた際にセットされる口座番号が不定となった
設計書 コードAが1000でない,およびコードBが2000でないものを削除する この文章の通りに実装するとすべてのコードが削除されるプログラムとなる
設計書 配列A[ ] と配列B[ ] に128kバイトを割り当てる 配列Aと配列Bの両方に128kバイト割り当てるのか,それとも配列Aと配列Bに合計で128kバイト割り当てるのかが分からない

だけで?でだけ?

 失敗例を一つ示そう。筆者の知り合いにB君という中堅のPMがいる。彼は高校卒業後すぐにプログラマとして活躍し,2~3年のSE経験を積んだ後,PMに昇格した。IT業界ではよくあるキャリアパスだが,SE経験が若干短い。彼の人柄を見込んだ上司が抜擢したのである。

 B君がPMとして初めてシステム開発を担当したときのこと。開発するシステムは,国際間の料金精算を行うシステムであった。あるとき,B君は後輩SEのC君と一緒にユーザーの元へヒアリングに行った。その際,次のように言われた。

 「精算ファイル出力は日本円だけでできるようにしてほしい」。

 数日後,C君が「先日のヒアリング内容をとりまとめて要件定義書を作成したので,チェックしてほしい」と言ってきた。B君はその要件定義書を軽く一読しただけでC君に返した。文章チェックを怠ったのだ。

 プロジェクトは順調に進み,単体テスト・フェーズに入った。プログラマ出身ということもあり,プログラミングに自信のあるB君は毎日時間を見つけては各プログラマの間を歩き回り,単体テストを見て回っていた。ある日,テストの結果を見て,疑問が浮かんできた。

 「なぜ精算ファイル出力のテスト結果が日本円しか出力されていないのだろう?」。

 早速,B君は担当プログラマに尋ねてみた。どういうわけか確かに詳細設計には「日本円しか扱わない」と書かれている。そこで,その原因を追及すべく仕様書をひっくり返してみると,要件定義書に次の一文があるのに気が付いた。

 「精算ファイル出力は日本円でだけ行えるようにすること」。

 これがすべての根源であった。「日本円でだけ行える」の一文を基に基本設計がなされ,詳細設計,実装と進んでしまっていた。これを担当したプログラマは,日本円以外の入力が入った場合には,日本円部分を精算ファイルとして出力し,それ以外をエラー・ファイルとして出力していた。当該プログラムとしては詳細設計通りである。

 しかし,本来この部分の仕様は,日本円と外貨が混在して出力されるべきだったのだ。先のヒアリングでユーザーが語っていたのは「日本円しか入力されなくてもエラー扱いしないでほしい」という意味だったのだ。ヒアリングを行ったB君とC君は,共にこの意味を理解していた。しかし,C君が要件定義書に「だけで」と書くべきところ「でだけ」と誤って記述してしまったばかりに,プログラマに間違って伝わってしまった。PMのB君が文章チェックさえしていれば,このミスは防げたはずである。

 幸いにも,このケースの場合には,B君が比較的早期に発見したのでプロジェクト全体に与える影響は軽微なもので済んだ。しかし,一歩間違えればリスケジュールを余儀なくされる可能性を秘めていた。ドキュメントの誤りは大きな手戻りを招く。要件定義書の1行は,プログラムの20万ステップになることもある。その1行が間違って書かれていれば,20万ステップが無駄になる。