ソフトウェア品質の鍵は上流工程にあり
テストやレビューを「しっかりやる」「有識者を立てる」「厚く実施する」などといった"ふんわり？"とした対策が取られやすいソフトウェア開発の現場ですが、お客さまの大半は納得されていません。と言うか、そういう対策で問題が再発しなかった開発現場を私は知りません。
でも、２０年近く減るどころか、そんな回答でお客さまが納得してくれると思っているマネージャーやエンジニアは、どんどん増えていっているような気がします。ビックリです。
プロジェクトの失敗原因を分析すると、「マネジメント」「（超）上流工程」に問題があることが多いことがすぐにわかります。
このサイトの調査では、
「不十分な要件定義」50% ・・・（（超）上流工程起因）
「不十分なスコープ定義」17% ・・・（マネジメント起因）
「リスクマネジメントの不足」15％・・・（マネジメント起因）
「コミュニケーションの問題」14％・・・（マネジメント起因）
「リソースの不足」 3％ ・・・（マネジメント起因）
おっと、実に99％が「マネジメント」と「（超）上流工程」が原因であると言っていますね（逆にビックリです）。
（超）上流工程が原因となるのは、主に
顧客から要件を十分に聞き出せない
聞き出した要件を仕様として整理出来ないまま下流工程に進んだ
などのために、手戻りが多発するパターンです。そう、すべては手戻りすることがプロジェクト失敗の原因なのです。しっかり決め切れていれば、一度決めた内容を覆すような手戻りは発生しないはずなのですが、如何せん、（超）上流工程はお客さまにとってもまだまだ要望が整理されていない状態ですので、お客さま主導で進めようとすると、こうした事象が起きやすいのは仕方がないことです。
（超）上流工程の品質を高めることで、下流工程もスムーズに進められるのは、開発を経験したエンジニア、あるいはマネージャーであれば誰もがわかっていることだと思います。ですが、その改善活動がいつも後手に回っている企業が、Tier-1、Tier-2等に関わらず、圧倒的に多いのが実情です。
その原因は、上流工程では業務知識、ＩＴ知識、コミュニケーション能力などのそれぞれに高い専門性と実現スキルが求められるため、どうしても属人的になりやすく、そのノウハウを社内で共有するのは難しいと考えられているからです（たぶん、大量のシチュエーションと選択肢を整理すれば、やってやれないことは無いと思うけど）。
しかし、（超）上流工程でも納品物は明確です。
仕様書、定義書、設計書、ダイアグラムなど、納品物のドキュメントに記載すべき項目が漏れなく用意されており、かつそれらの成果物にコミュニケーションの齟齬が起きにくいような様式が採用されていれば、そこを埋めるために動くべき行動はおのずと見えてきます。つまり、上流工程においても、標準テンプレートによってゴールを見せることで、属人化のリスクをある程度抑えることができるのです。
では、どのようなテンプレートを用意すれば上流工程の品質を改善できるのでしょう。
一例として挙げるならば、「トレーサビリティ」が担保できた成果物構成を心がけるだけで、品質が１つあがります。
一般的な製造業のみならず、およそプロセス志向によって進められる作業はすべて、この「トレーサビリティ」が求められています。
トレーサビリティ、すなわち「追跡可能性」。工程から工程、工程から作業、作業から成果物、成果物から成果物、そして最後に納品物に辿り着くまでの経路を開始時点から納品段階あるいはプロジェクト終結段階まで追跡が可能な状態を指します。またはその「しやすさ」のことです。
なぜ、このトレーサビリティが必要かと言うと、何をするにしても、起源となるものがどこにあるのか不明なものほど信頼・信用がおけないものはないからです。これは「どこ産の農作物かわからないものは不安で買えない」と言うのと同じです。
そして、それは当然、システム開発においても同様で、「その決断の元となる情報は何か」「その設計根拠の元となる仕様は何か」「そのテストで全ての品質が網羅できていると言う根拠となる設計はどこか」と言った、トレーサビリティが必要になってくるわけです。
そうしなければ
「あれ？そんな機能作るはずだっけ？」
「え、こんな挙動する仕様だったっけ？」
みたいなことが起きても、その元情報がどこに存在しているのかわからないと言う状況に陥ってしまいます。何をもとに、何を根拠に、作成しているのかわからない開発ほど、お客さまが不安になることはありません。
みなさんが一般消費者の時には、そう思うのが当然と言う人が多いと思います。
たとえば、ユーザーから受注入力画面への仕様変更要求があった場合、もちろんその画面は修正しますが、実はその変更が売上入力画面や帳票にも影響を及ぼす、といったことが把握できなければ不具合や手戻りにつながってしまいます。
また上流工程は、これから作成するシステムをお客さまに説明し、システムの完成イメージを共有する場でもあります。そのためにはお客さまが望む要件が、どの機能に実装されるのか説明できる資料が必要です。
以上の観点から、標準化定義では上流工程で使用するドキュメントに、このトレーサビリティを意識した機能改善を追加することが望まれています。
当然ながら、トレーサビリティの確保は、工程の途中、作業の途中から始めてもあまり意味はありません。効果ゼロではないでしょうが、希薄になるでしょう。
なぜなら、その前工程までに記録から漏れてしまったものは、人の記憶の中にしか情報が存在せず、それまでに置いてきたフラグをすべて回収することができない可能性が跳ね上がってしまうからです。行うのであれば、最初の段階からでなければ効果は極端に小さなものとなってしまいます。
ゆえに、マネジメントでいえば「計画」、開発技法でいえば「上流工程」と言うように、最初の第一歩こそがすべての品質の要となるのです。西にゴールがあるのに、最初の第一歩が東を向いていたら、東に進めば進んだ分だけ、戻る労力が必要になるのは自明です。
まず開発を始める前に、システムを構成するための要素成果物がすべて追跡可能な状態になっているかどうか確認しましょう。これは責任をもって商品をお届けする姿勢の第一歩です。これができていないと言うことは、
「（自分たちが作った）商品に対して責任を持てない/持たない」
と言っていることと同義になりえるのだと知っておかなくてはなりません。
他にも、作成者のドキュメンテーション能力に依存した様式は品質を損ねやすい傾向が強く出てきます。たとえば
こんな感じ。私が１社目の大手SIerに入社した当時は、こんな感じの設計書様式でした。当時はまだまだヒヨッコでしたので気になりませんでしたが、今にして思えば、なんてひどい設計書様式なんだろう…と思います。
この手の様式の問題点は大きく２つ。
・ほぼ100%フリーフォーマットであること
・自然言語を多用しすぎていること
（書き手の語彙力と読み手の読解力に、100%依存していること）
です。エンジニアリングの能力以外のところに、完全に依存してしまっていて、どんなにエンジニアリング能力が高くても、コミュニケーション能力が低かったり、書き手と読み手の間のコミュニケーション能力に差がありすぎると、技術力と関係のないところで品質が劣化してしまう、と言う点です。
日本語は、他の言語と比べても「なんとなく」同じような意味を持つ言葉が多い自然言語です。たとえば
・ＡをＢに設定する
・ＡをＢに登録する
・ＡをＢに代入する
・ＡをＢにセットする
・ＡをＢに渡す
・ＡをＢに上書きする
・ＡをＢに追加する etc.
など、同じような意味合いの言葉でも、書き手の気分によっていくらでも表現の自由度が出てきます。しかし、言葉の意味を正しく理解し、その通りに実装しようとすると、おそらくは異なった実現方法を使ってしまうこともあるかもしれません。
特に超上流工程では、まだまだいきなりプログラミングができるような設計は行いません。もっと上位の「概要」「概念」と呼ばれるような情報整理の段階です。そんななかで曖昧な表現を行うと、なおさら読み手によって解釈の違いが出てくることは不思議でもなんでもありません。
私たちは、まず私たち自身を過信しないところから始める必要があるのです。
「自らを信じない」
「自らを人間（不完全な存在）であると自覚する」
「自らを完璧と思わない」
「（成功のためなら）自らを疑ってかかることも辞さない」
過信した己が、常に人並み以上の結果を出せるなどと思わず、常にリスクを想定し、常に疑ってかかる…こういうとネガティブと言われることも多々あるのですが、私はこの"攻めのネガティブ"こそが、エンジニアリングには欠かせない重要な要素の１つだと思っています。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。