問題解決の必須条件

問題解決において自ら解決できない場合、他者、他部署に依頼することもあると思います。私は基本的に「依頼される側」にいるのですが、依頼される側であるがゆえに、せめて依頼する以上は最低限の条件を整えてほしいなといつも思うのです。

自分で解決できず誰かに依頼する場合、それを可能にするのは大きく分けて

　①作業要員として手伝ってもらう
　②解決そのものをしてもらう

の２種類となるかと思います。

①の場合はワーカー（作業者）として、②の場合はリーダーやマネージャーといった委託者あるいはコンサルのような支援者として参加することになると思います。まぁ①については指示に従っていればいいだけなので、作業に必要な環境条件さえ整っていれば問題ないでしょう。

大変なのは②のケースです。

問題を起こした当人、あるいはその上司では解決できない場合、他の人や部署に助けを求めることがあります。その際、支援する側としてはどうしても必要なものが

　過去経緯の事実情報

です。トレース情報と言い換えてもいいでしょう。少なくとも私の知る限り、この「情報」が少ない案件では手伝えることがあまりありません。お客さまとの交渉や説明でも必ず後手に回ってしまうからです。後手に回って、現場をかき乱すことほど周囲の信頼を損ねるものはありません。

ですから、経緯を知るための「情報」は絶対必要としますし、できるだけ詳細に、できるだけ時系列に、そしてできるだけ記録に残っていることが望ましいのです。

しかし、こう言った情報をすべて提供してくれる現場と言うのはなかなか見かけません。それもそのはず

情報のトレーサビリティを管理しきれていないから問題となっていて、
しかも自分たちだけでは解決できない状況に追い込まれている

わけですから、私が参画したところで「情報がない」と言う状況は変わるわけがありません。裏を返せば、日頃から「情報の管理」ができていれば、こうした問題がそうそう出ることはありません。

各フェーズの設計書、課題管理表、そして議事録にメールのやりとり、これらが各フェーズに空白地帯を作らず、すべて揃ってくれていると、問題解決のプロなら大抵のことは対策できます。

できないのはただ１つだけ。

　「やってない」

と言う問題だけです。言い換えれば、大幅に進捗が遅れて取り返しがつかない状態。しかも、その理由が（外的要因はともかく）

　「やれることは色々あったけど、
　　相手のせいにするばかりでやるべきことをやってない」

と言うケースの時です。この場合だけは「やってなかったんだったら、やれよ！そしたら解決するよ！！」と言いたくなります。

"責任"とは綱引きではないので、仮にお客さま側にも同等の落ち度があったとしても、そのせいで自らの落ち度が減るなんてことはありません。やるべきことやってないのであれば、「その間、給料もらう資格あったの？」と言いたくなります。

実際、このような状況に陥った場合は、お客さまとの間で責任の擦り付け合いとなる泥仕合以外に立てられる対策案はあまりありません（色々状況を把握できるようになると、起死回生の一打がみつかることもあるんですけどね）。保証すべき品質対象となる成果物やプロダクトがないわけですから、第三者としてはまったくお役に立てない可能性が高いと言うことです。

むしろ、その他責ばかりするリーダーなりマネージャーなりを生贄にして、お客さまと共闘した方が幾分マシかもしれません。

また納品物等が詳細に決められている場合は、中間成果物の体裁を無視してスピードアップを図る…と言う策も採れません。基本的には自業自得ですので、自らで責任を取らなければならないかと思います。

しかし、上記の理由以外の場合…つまり、

　「やることはやってたけど、やり方に問題がある場合」

については、大抵対策が立てられます。
より良いやり方に変えればいいだけだからです。

もちろん手戻り等は多少なりとも発生しますが、問題を「問題」のままで放置するわけにはいきませんし、放置したところで何かが解決することは絶対にありません。より良い対案が出ないのであれば、手戻りコストが発生する中で、最も負担の少ない選択肢を取ればいいし、それ以外の手段はありません。ここからは「手段」の引き出しの多さがモノを言いますね。

大抵の仕事には必ずどこかに「ムダ」があります。

その「ムダ」を特定し、冗長的なムダを抹消していけば、手戻り分の工数を捻出するのも不可能ではありませんから、そのムダを特定するところから始めればよく、その際に最も重宝するのが「過去経緯の事実情報」だったりするわけです。

ただし、先ほどと同じように納品物や成果物に対する頑ななルール（縛り）があると、打てる手段の数もそれだけ減っていきます。特に「契約書」縛りや「法令」縛りは強制力が強いので、注意が必要です。

ここでは体裁ではなく、本質的に重要なポイントを抑えることが肝要となってきます。

ソフトウェア開発の問題としてよく起きやすいのが、

　結合テストまでは自社が行っていて、
　システムテストや受入テストはお客さまが実施してたのだが、
　お客さまのところでバグが頻発しすぎて収拾がつかなくなった

と言うケースです。これの次に起きやすいのは

　単体テストまで来たけれど、進捗がまったく進まなくなってしまい
　かなり遅れて無理やり結合テストに進んでみたら、
　バグだらけで収拾がつかなくなってしまった

というケースではないでしょうか。

後々になって不良が多発するのは

　①作りこむ際に、不良を混入させても気付けない仕組みになっていた
　②確認する際に、不良を見つけることができない仕組みになっていた

のいずれか、あるいはその両方だけです。かなり抽象化したので、これで全て包含されます。それ以外で不良が多発する原因はありません。

システムテストや受入テストで「出るべくして出る不良」については問題は一切ありません。むしろ、そのフェーズだからこそ検知されるのは至極当然のことです。結合テストと観点が重複していないのであれば、それは「システムテスト以降でなければ絶対に出ない不良」と言い切れるからです。計画的にそうなるよう、テスト観点を設けているのであれば、

　それ以前に検知した場合
　　→観点が重複している（マネジメントの問題）
　それ以降に検知した場合
　　→観点が漏れている（プロダクト品質の問題）

となるだけです。「出るべくして出る不良」は適正なのです。

しかし、単体テストや結合テストで発見すべき不良が結合テストでは見つからず、お客さまの実施するシステムテストや受入テストで散見されるようだと、その期間に行われた仕事はお客さまの目から見ると

　それまでのフェーズ作業をサボっていた

と見えてしまいます。実際、やるべきことが行えていないのですから、どう言い繕っても「すべきことをしていなかった（≒サボっていた）」事実に相違ありません。

エンジニアはその力量によって、月単価50～100万もの大金をお客さまに請求しています。その期間中、当該エンジニアが責任をもってテストを行う価値としてお支払いいただくのです。

にもかかわらず、保証すべき品質を保証できていないまま、お客さまに提供していて最後に何食わぬ顔して請求するのかと思えば、お客さまも相当お怒りになられることでしょう。

「予算が無い」とか「スケジュールがきつい」とか言い訳は色々あるのでしょうが、そんなものは当初の見積り精度が甘いことやマネージャーの作業コントロールが不出来なゆえに起きているのであって、お客さまに言い訳できるような代物ではありません。こうした言い訳に対し、

　「その理由で不良を作りこむことが正当化できるのか？」

と言う問いに"YES"と答えられる人はおそらくいません。つまりは言い訳としての正当性すら欠いているということです。

逆に"YES"と言うのであれば、対策そのものが必要ありません。お客さまをきちんと説得できるだけの材料があるということですし、不良混入のまま納品すればいいだけです。

上記のようなシチュエーションの場合、

①作りこむ際に、不良を混入させても気付けない仕組みになっていた
②確認する際に、不良を見つけることができない仕組みになっていた

すでに工程も終盤に差し掛かっていますので、①の作り込み時の品質はあまりたいした問題ではありません。しかし、同じ原因によって、他にも不良が作りこまれた可能性があります。

　・もし、個人の認識ややり方に依存したものであれば、
　　個人が作った範囲を徹底的に見直す
　・もし、ルールや基準、手順に依存したものであれば、
　　全体を徹底的に見直す

と言う手段を取りましょう。

②の品質については、そもそも結合テストの観点があまりにも不足していたことを意味します。最後の砦が穴だらけだったと言うことです。おそらくは

　・テスト観点を洗い出した、チェックリストを作ったエンジニアの、
　　テストに対する知見があまりにも低かった
　・チェックリストに係る粒度や観点などに関するルールや
　　そのルールを踏襲しているレビューなどがなかった

と言ったことが容易に想像つきます。

「設計書の内容」「お客さまの行われているテスト観点」そして「起きている問題の傾向」を掛け合わせると、結合テスト(ソフトウェアスコープ)までの品質観点であれば、具体的な対策案は容易に検討が可能です。

一般的にシステムテストや受入テストは、実機やそれに近い環境を使う関係上、ソフトウェアだけでなく、ハードやネットワークなどのインフラも含めたシステム仕様を理解する必要があり、プロジェクト内容を見てみないことにはどこまで対応できるか、安易に言えません。

しかし、ソフトウェア単体であれば、「プログラムでできること」以外の観点が不要となるため、基本設計書（つまり、機能仕様）さえ明確に存在していれば、さして難しくありません。

あとは、お客さまの行われているテストと、そのテスト観点のどこに問題が偏っているのかを見れば、

　「結合テスト完了までに見つけるべき不良」
　　　　　　　　　　or
　「システムテスト以降で見つけるべき不良」

かによって、対策範囲が決定します。

　前者であれば、「対策＋類似問題の調査、見直し」
　後者であれば、「対策」のみ

で済むからです。

前者は見直した結果、対策箇所が多くなるようであれば、お客さまのテスト環境へのリリースは早めにさせてもらう必要があります。そうしないと、次から次へと不良として列挙されてしまい、心象が悪くなるからです。

稀に、仕様書だけ書いたら、設計書の欠けらも作らない…と言うプロジェクトを見ますが、基本設計レベルの記録類すら残らない状態で問題が起きるようでは、原因は十中八九それだとしか言いようがありません。

要するに、「人の脳内記憶だけでは、安定した成功は望めない」という前例を作ったことになるからです。おそらくは「設計書」の存在理由を知らずにエンジニアをしているのでしょう。

せめて、設計書類をロクに作成しないのであれば、プロトタイピングモデルや、アジャイルモデルのように、お客さまを巻き込んだ実装検証を繰り返す（イテレーション／スプリント）ような開発手法に切り替えるべきです。完全な請負で、ウォーターフォールモデルのまま採っていい選択肢ではありません。