【ソフトウェア開発】第三者検証、その後

先日、こんなつぶやきをしましたが、実際そんなことをしようとされた企業様がいたのです。で、その検証を私にさせようと…。

以前も書きましたように「第三者検証」自体は悪いことではないのですが、あくまで品質向上の領域で活用するものであって、品質保証を求められるケースでは有効ではありません。

今回は、ある不具合によって解決（是正）はしたものの、「なんでこんな不良がそのまま残ってるんだ。御社の開発はこんなことも見つけられないのか。どんな開発の仕方してるんだ。」みたいなお叱りを受けたうえで、今後の再発防止（プロセス品質の保証）を求められているケースです。

で。

本日、そのお叱りを受けてしまった企業様にご説明してきました。そのうえでご提案しました。

「品質保証を求められている課題では、第三者が確認できることなんてたかが知れていますし、仮に私のようにエンジニアリングや品質を理解しているものが急に割り込んだところで、私たち第三者が持っている『答え』を押し付ける形になってしまい、逆に現場の今までの流れを無視した負担の押し付けにしかならない可能性があります。スケジュールにもコストにも優しくありませんし、だからと言ってその分を請求しようとしても、ユーザーさまも首を縦に振らないでしょう。

ですので、次のような流れで改善活動をされてはいかがでしょうか。

　①現場の現在の各業務や成果物の流れを図表化（下図）する
　②起きた不良/欠陥に対して、①のどこに問題があったのかを特定する
　③再発させないためにはどう改善すればいいかを、
　　現場のエンジニアに提出させ、①で作成した図表に追記する
　④その進め方で問題が再発しないと言う「根拠」を彼らエンジニア自身に
　　責任を以って説明させる。その内容をマネージャーやユーザーが聞いて
　　納得できる説明であれば良しとする
　⑤①⇔③の変化点のみチェックリスト化し、クロスチェックを行う。
　　マネージャーが抜き打ちサンプリングチェックを行ってもよい

あえて外部の第三者を使わず、現場内に閉じて改善サイクルを運営することで、リアルタイムな対応が可能となり、またメンバー達が自らの過ちに対して常に意識しながらプロジェクト進行できるようになります。定着速度はその分、圧倒的に早まると思います。

すでに何かしら不足している部分があることが判明しているとはいえ、いったん出来上がった「進め方」がある以上、あえて外部の第三者に引っ掻き回されるよりは、現状の進め方に対して「必要十分で、且つ最低限の負担で済む」改善活動を行った方が現実的ですし、そうしようと思ったら、これが最適解ではないでしょうか。

てな感じです（あくまでサンプルですが）。

細やかな課題やユーザー様からの要求…と言うか不満？みたいなものもあったみたいですが、それらも逐一私の方で「答え」を用意しました（まぁそこまでする義理も無かったのですが、即答できる内容でしたので）。

「一度、この提案を以ってユーザー様にご確認ください。かなり理詰めな方だと言うことですが、一般論、正論の観点から見ても、論理的に落ち度はありません。現場の現状を踏まえたうえでのご提案ですので、最も実現性が高く、おそらくそれ以上の代案はそうそう出てこないと思います。一通り、ユーザー様のご要望にすべて叶う内容となっていますので、『ダメ』とおっしゃることは無いでしょう。」

補足

ＩＴ企業の上の方々はﾁｮｲﾁｮｲ勘違いされているのですが、ＩＴそのものが欧米由来の「プロセス志向」をベースにできている以上、日本古来の「結果良ければすべて良し」みたいな考え方では絶対に上手くいきません。たまたまうまくいったとしても、安定的な事業にならないか、属人的な取り組みにしかなりません。

「ヒト」ではなく「企業」の力にするためには、常に

　「正しい進め方(プロセス)をするから、正しい結果になる。
　　だから、進め方そのものから改めなさい。」
　「結果だけがよくても、進め方がよくなければ、
　　結果が正しくなる根拠は決して説明できない。」

と言う考え方が必要になります。

けれども、経営層や管理職層になると、数字（売上、利益）ばかり追いかけるようになり、「結果」以外に興味を持とうとしなくなります。しかも、実務をしなくなってしまっているから、エンジニアリングのプロセスについてすでに知見もなく、指導もできなくなってしまっている人が多いと思います。

結果、ＩＴの現場は常に正しい進め方を「教えてもらえず」「継承されず」「育成されず」と言う状態に陥り、一人ひとりのエンジニアに努力や苦労することを期待し、個人努力に依存してしまっていくことで、準ブラック化するのだと思います。

私の中ではなんとなく

「技術」… technology「モノ作りのための力」
「開発」… engineering「正しくモノ作りするための進め方を構築する力」
「管理」… management「構築された進め方を推進しコントロールする力」

と切り分けて考えています。ですが、いざ開発現場を見てみると「技術」ばかり追いかけている人が多く、「開発」のあり方や必要性を真剣に考えている人がものすごく少ないように感じます。当たり前のことですが、「開発」を理解できていない人は「管理」もできません。

「開発」→「業務」と置き換えればＩＴ現場でなくても、どこの業界でも考え方は一緒ではないでしょうか。適切な決断も、判断も、『知る』からこそできることです。知らないのにマネジメントするなんて、そんなのただの曲芸でしかありません。

ですから、「結果」しか見ようとしないで、「プロセス」を軽視し、プロセスについて知ろうとしない経営者や管理職ばかりの会社は、大抵ブラック化していくことになるのだと思っています（たまたま私が見てきた企業様がそうだっただけかもしれませんが）。