続・想定外の想定――品質を作りこむ
前回のブログ記事「想定外の想定」のアクセス数が1700を超えました。ありがとうございます。私のコラムでは、通常500アクセスぐらいなので、前回の記事は皆さまの関心が高かった内容だったのだな、と（もしくはタイトルにだまされた？）。
別に便乗するわけではありませんが、「コンテキストを残す」というテーマを前回に引き続き、今回も、お話しさせていただこうと思います。
○システムの品質
この最近、私は現在開発しているシステムの品質をどう高めるか、というテーマを持っておりおります。半分パッケージ半分カスタマイズというシステムを、営業しつつ、カスタマイズしつつ導入しつつ、バージョンアップしつつ、というのが主な仕事になるのですが、客先が多くなり、またはシステム規模も大きくなり、加えて開発者も増えて、という状況の中、どうしても品質の確保が大きな問題となってしまいました。
何度か大きな失敗もしてしまい、その度に反省会を開くのですが、その中での多くの意見は
- ドキュメントがないから
- 試験が足りなかった。もしくは試験期間が短かった
- 誰かがチェックしていなかった
の3つに尽きてしまいます。当然、その対策は
- ドキュメントの整備
- 試験をもっとしっかりやる
- 誰かがチェックする
の3つになってしまいます……。
まあ、間違いではないのでしょう。バグをなくすには、すべてのデータ、全ての状況、全ての機能を全パターンで動作させるのが一番です。そのためには、そのすべてが分かるドキュメントが必要ですし、確認漏れがないように二重三重のチェック体制を作ることも必要でしょう。
しかし、実際問題としては納期の問題、リソースの問題、コストの問題、環境の問題にて、なかなか理想な試験ができないのが現実です。ドキュメントの問題1つとってもそうですが、具体的にどの様なドキュメントが必要で、そのドキュメントを整備するのにどれくらいの工数がかかり、そのドキュメントを作成するヒトとカネをどうやって調達するのか、この問いに回答できる人は誰もいません。
ましてやドキュメントが多くなればななるほど、システムに追従させることが大変になり、あまりにドキュメントが多くなりすぎると今度は利用する際に時間が掛かってしまい、コストは2乗3乗と膨らんでゆきます。
しかし、これはドキュメントの必要性を否定しているわけでは決してありません。
現実的なドキュメントは具体的にどの様なドキュメントで、それをどうやって整備し、運用するか、という現実解が悩ましいと言っているのです。
試験にしても同様。全ての試験をするのは実質無理。だとしたら如何に試験項目を減らしても品質を担保できる方法はどうすればよいか。その答えが欲しい。
○なぜ、そうなっているか？ を残す
そういった状態で現場を眺めていると、1つのアイディアが思い浮かびます。
究極の答ではありませんが、もし実現すれば品質はかなり向上しそうに思えます。
それはコンテキストを残す、ということ。
設計にしろコーディングにしろ、多くの人がかかわったり、システム自体が大きくなってゆくと一番議論になるのが「なぜ、そうなっているか（そうしたか）？」というテーマです。
機能追加の設計時、「あれ、この機能、なんでこんな動作になってんだっけ？」
コーディング時、他の人が作成したコードをみて「なんで、こんな処理したんだ？」
デバッグをしていると、「なんで、こんなバカなことを……」
導入後しばらくしてお客さまから問い合わせがあり「この仕様は誰が決めたんだ？」
もっとも悲惨なのが、なぜそのような処理になっているか分からずに修正すると、別の所に影響が……。そうなってくると後はモグラ叩き状態。
例えば、設計書やシステムそのもの、もしくはソースコード上に検討者や設計者の脳内ダンプが残せたら。そしてそれが、別の人にトランスファーできたら。
少なくとも地雷を踏むことはなくなります。
そしてそれ以上に、そこは真剣に検討（設計）されたのか適当に処理されたのか、勘違いが
あるのかないのか、ということがわかります。そうなれば、早い段階で過ちやリスクを把握できる様になるのではないでしょうか。
○現実的には
現実的にコンテキストを残す方法としては、今のところドキュメントかソースのコメントとして残すより他はないように思えます。ところがこの方法では、前述しましたドキュメントのジレンマに陥ってしまいます。
そうではなく、もっと簡単に大量の情報を脳内から外部に記録できる。そしてすべてを別の人の脳内に入れるとパンクしそうなので、必要な時に必要な情報をPUSHしてくれる。そんな仕組みが発明できたら。
人類はまだまだ、考えを外に出し、記録し、トランスファーする最適な方法を考えついていない、ということを思い知らされます。もしかしたらインターネット上にある検索システやソーシャルネットワーク、Twitterなどのツール類がもっともそれに近いのかもしれませんが。
……そういう荒唐無稽な事を考えている暇があれば、さっさとドキュメントを整備して試験をやれ！ というツッコミを覚悟の上で。
コメント
K.Oumi
こんにちは。
「欠陥がない事」って、「品質」の部分でしか無いのに、重要テーマとせざるを得ない現実っていうのも、けっこうつらいですよね（＾＾；
ハムレット
こんにちわ。
今回の記事、ちと、違和感を感じます。
> ドキュメントの整備
> 試験をもっとしっかりやる
> 誰かがチェックする
ってあくまで手段だと思います。要はそれぞれドキュメントにもテストにも品質があるので、そこをどう高めていくかって論議が無ければ何時まで経っても堂々巡りな気がします。
要は、想定外の想定とありますが、物事を想定する為の技術と云うのは有る程度確立されてきているわけで、それこそがいわいる工学（エンジニアリング）と呼ばれるものではないでしょうか。例えばUMLについても、単なる表記法だけでなく、UMLの仕様の意図や変遷の歴史をもう少し勉強すれば、物事を想定する為にどのような工夫がなされているか、判るように思えます。
山無駄
はじめまして。K.Oumi さん。
確かに、全体は部分の総和ではない。という事を考えると、品質の全体からする
と「欠陥がない事」という事がどれだけの意味を持つかですよね。
言い過ぎ？
山無駄
こんにちは ハムレット さん。
今回は頭の整理をする暇も、遂行する暇もなかったので言いたいことを伝えて
切れていないかもしれません。
>ってあくまで手段だと思います。要はそれぞれドキュメントにもテストにも
>品質があるので、そこをどう高めていくかって論議が無ければ何時まで経っ
>ても堂々巡りな気がします
これは私もそう思います。
>要は、想定外の想定とありますが、物事を想定する為の技術と云うのは有る
>程度確立されてきているわけで、それこそがいわいる工学（エンジニアリング）
>と呼ばれるものではないでしょうか。
特に最近工学を標榜している研究者にフラストレーションを感じている身から
意見させてもらえれば、工学は「想定されたものを現実解にする」というスタン
スである様に思えてなりません。
詭弁的なものの言い方をさせてもらえるなら、「想定」は「想定」した段階で
「想定外」が産まれます。「想定内」については工学は取り扱えますが、
「想定外」を工学で取り扱う事はできません。
>UMLについても、単なる表記法だけでなく、UMLの仕様の意図や変遷の歴史をも
>う少し勉強すれば、物事を想定する為にどのような工夫がなされているか、判る
>ように思えます。
私はUMLの仕様の意図や変遷の歴史に詳しいわけではありませんが、表記法だけ
でなく仕様の意図や歴史をを知ることにより視座があがる、という意味では感覚
的に分かりますし、これが今回の内容の趣旨となります。
・・・いただいたコメントの趣旨に応えてます？
ハムレット
そうですね。そもそも工学とは何かって共通認識がないといけないですね。
個人的にはソフトウェア工学の目的は、ソフトウェア開発の各段階での営為に対して、評価指標や設計と検証に対する方法論を与えることだと思っています。
判りにくいかもしれませんが、想定の方法と想定結果に対する評価も工学の重要な役割だと思っています。ただソフトウェアの場合、他の工学（例えば建築など）と違い、数値評価が難しいので、色々と工夫が必要だと思いますが。
山無駄さんはコンテキストについて書かれていましたが、それが重要になるのは、システムが不可視なものであるため、システムの全体像とその境界を描くことが非常に難しいからだと思います。
境界を定めて全体像を描いた後に、機能構成とデータ構造を階層的に整理して制約条件を満たす形で実現可能な姿に持っていくことが本来、分析から設計フェーズで行うことだと考えています。
例えば、機能構成をデータフローで示すだけでも、フローの上流から下流へと言う判断基準で、プログラム設計から実装、試験、また障害対応について、合理的な着手の順番が見えてくると思います。
話し始めると色々あるのですが、現場で仕事をしていて良く見るのは、全体像を見ないままに、目の前のプログラムの課題対応に終始して、暗い森で迷っているようなプロジェクトです。そんなプロジェクトに全体的な機能構成やデータフローは無いのと尋ねると、殆どの場合は該当するものが無いというのが私の周囲での現実です。
山無駄
ハムレット様
少し議論が横道にそれますが、ある研究会で大学の先生が話していたことを
ご紹介します。まだ私案レベルだが、と前置きして話しておられました。
１．科学とうのは純粋科学から基礎科学、応用科学と体系化されている。
純粋科学・・・自然科学、生物科学、人文科学、社会科学（日本は文系、
理系と大別される）
基礎科学・・・数学、物理、化学、生物学、等々
応用科学・・・工学（電気電子、機械、建築）、経済学、経営学 等々
２．アカデミアはこの体系に従って、勉強してゆき、実社会が抱える問題に応え
ようとしている
３．ところが実社会の抱える問題等のは、もっと混沌としており、単純に各々の
学問領域のみで解決できることはとても少ない
４．これらを解決しているのは主に経営者、と呼ばれる人たちで、この人たちは
主に経験と勘をもって問題解決にとり組んでいる
５．実世界の問題を解決するには、科学は領域が狭くなり、専門性が高くなって
いるため、逆のアプローチ（科学の領域を取り払い、実社会の問題から再構
築する）が必要となる。これを実学と仮名する
６．今後大学が抱える課題は、科学は実学のギャップを如何に埋めるか、だ。
図があるともっとわかりやすいのですが、先生の私案ですので私の解釈も含めて
文章にしました。
これを聞いた別の先生が、
「今、大学では学部、修士、博士と段々に狭領域且つ高専門性になってゆく。
企業は実社会の問題を解決してもらいたいから、高学歴の人間を高報酬で雇っ
ているはず。しかし、この話では、高学歴で高報酬だからといって、期待され
る現実問題の解決はできない、という事にならないか？」
この感覚は良くわかります。学生と一緒に共同研究をやっていますが、学生から
「こういったデータをください。そうすると、こういった理論でシミューレーシ
ョンができて、この様なアウトプットを出せます」
と依頼されるデータは、まず学生に提供することができません。
学生が求めるデータはシミュレータのインプットとなるデータで、実社会では
そんなに都合のよいデータは存在しません。逆にそんなデータがとれるのであれ
ば、別に産学で共同研究をしなくても、産側で答が出せる、という結果になって
しまうのです。
品質、というものを考えた際に、この辺りの議論が示唆に富んでいるように思え
ます。例えばバグが一つもないが、誰も使わないシステム。みな一所懸命使って
いるが、何も効果を生まないシステム。みな一生懸命つかって効果も出ているが、
その効果以上にメンテ費用がかかるシステム。みな一生懸命使って、メンテ費も
含めて効果が出ているが、システム会社にとって赤字になるシステム。みなが
一所懸命使い、効果も出、システム会社も儲かっているが、社会として問題があ
るシステム等々。
こういったものも含めたうえでの品質、というものを考えた際に、ひとつの工学
分野で答を出し得るものなのでしょうか。
>全体像を見ないままに、目の前のプログラムの課題対応に終始して、暗い森で
>迷っているようなプロジェクトです。そんなプロジェクトに全体的な機能構成
>やデータフローは無いのと尋ねると、殆どの場合は該当するものが無いという
>のが私の周囲での現実です。
この部分確かに同意です。
データフロー図すらない、のはPJが混迷になる原因の一つだと思います。
でも例えばデータフロー図があったとしても見えるのは「全部像」までで、
「全体像」を共有する為には、もっとコンテクストを共有化する仕組みが必要
である様に思えてならないのです。