ディスカッションの目的は、「共通フレーム2013」と比較し作業プロセスに内在する問題点を発見することでした。問題を重みづけし、順次ガイドラインに盛り込んでいくことで、開発プロセスの見直し作業を完了する予定でした。

「共通フレーム2013」を読み込むことで開発プロセスが整備される。きっとそうに違いない。なぜなら、あんなに苦労して経典を手に入れたのだから。

わたしは、この作業を進めるにあたってかような幻想を抱いておりました。しかし、いくら読み込んでも「魔法の杖」が見つからないのです。

【共通フレーム2013 共通フレーム概説より】

1. 共通フレームの目的

共通フレームを産業界で「共通の物差し」として用いることにより、国内における「システム及びソフトウェア開発と、その取引の明確化」が可能となるだけでなく、増大するシステム及びソフトウェア開発の国際取引においても相互理解を容易にするなど、市場の透明性を高め、取引のさらなる可視化を実現する。

5.2　共通フレームで取り決めていないこと

（１）文書化の詳細を規定しない

共通フレームは、文書の詳細な規定は行っていない。

共通の物差し。。。文書の詳細な規定は行っていない。。。

あッ！

わたしに見えていた「魔法の杖」はこの瞬間、「三菱鉛筆」であったことを知りました。

なるほど。共通フレームからあるべき作業プロセスをマッピングすることで社内の作業の品質が向上するわけではないということでしょう。それはそうだ。

しかしながらせっかく社内の作業プロセスを洗い出しているのですから、前回「共有した問題点」を改善する施策を盛り込むことにします。

銀の弾丸

共通フレームと社内の開発プロセスをマッピングしただけでは、「やっぱり上流は大事だよね」「手抜きしちゃだめだよね」等々、タスクの「抜かす」「省く」を、ルールとチェックで縛るのが限界です。しかし根本的な問題として「顧客合意したにも関わらずテスト段階、納品後に仕様が変わる」といったタスクの品質については是正できません。

テクニカルプロセスに関する、先人たちの知恵が詰まった問題解決メソッドを手に入れるため、あちこちの情報をかき集めました。

「発注者ビューガイドラインの公開」

むむむっ。IPA頑張っている。先人たちの知恵がまとめられている。

今度は「銀の弾丸」を手に入れたここちです。

さっそくガイドラインを参考に、いままで使っていた成果物テンプレートの修正作業を行い始め、設計エリアについてテンプレートを修正を行います。

問題は何か

テンプレートへ「発注者ビューガイドライン」を反映する作業に明け暮れ、ひと段落したとき、グループディスカッションを開催しました。

「ルールや担当者の意識が改善しなければ、タスク品質は向上しない」

「テンプレートで目に見える問題が解決するのか疑問」

恥ずかしながら、テンプレートの作成に没頭しているうちに、テンプレートを作ることがゴールになっていたことの指摘を受け、懐に隠し持っていた「銀の弾丸」は「チオビタドリンクの空き瓶」であったことに気づいたのでした。

フレデリック＝ブルックス氏の"No Silver Bullet"（銀の弾丸などない）では、

＜wiki pediaから引用＞

ソフトウェア開発の複雑性について

• 偶有的な複雑性は、ソフトウェア開発者自身が発生させていて解決可能な問題に間連する。例えば、アセンブリ言語のプログラムコードの記述と最適化や、バッチ処理によりもたらされる遅延は、偶有的な複雑性に由来する。
• 本質的な複雑性は、解決するべき問題によってもたらされる。そして本質的な複雑性を取り除くことはできない。もし利用者が30の異なることを行う1つのプログラムを望む場合、この30のことは本質的であり、開発するべきプログラムはこの30の異なることを実行しなければならない。

過去に行われてきたソフトウェア技術の発展は、ソフトウェア開発における偶有的な複雑性を攻略した。 ただし偶有的な複雑性に対する攻略であって、本質的な複雑性に対する攻略ではない。

利用者が３０の異なることを行うことを望むならば、テンプレートは３０の中に入っていたのか？

仕事の仕方。。。