「有識者」に頼らない仕組みを作るためには

そもそも「有識者である」ということ。

それは真面目に取り組み、情報を整理して、知識を自分の血肉として取り込んだ人の総称です。その道でそれなりに優れている人のことです。もちろん道に固執しすぎるとつぶしが利かなくなったりしますけど、それでも何も知らない人に比べればそのパフォーマンスは雲泥の差になる、あるいはなりやすい人と言うことなのでしょう。

逆に「有識者」ではないと言うのは

　・新参者で、経緯や情報の整理が途上にあり、追い付いていないもの
　・情報を整理して、理解する努力を放棄したもの

のいずれかではないでしょうか。有識者になるための努力を続けていてまだそのレベルに至っていない人は仕方のないことですが、後者の場合はもう色々社会人あるいは組織人としてアウトかもしれません。

そうして「有識者」にもたれかかってすべてをゆだねてしまうと、責任や仕事量を

　"押し付けるもの"と"押し付けられるもの"

に大別されていくようになります。そうやって知識やスキルを修得することを放棄し、既存の有識者やそのために努力する人を利用し、過重労働偏重を容認するようになっていくとまじめな人、素直な人は疲弊してしまったり退職に追い込まれることになったりするわけです。

なにより押し付ける側で気楽に過ごしてきた人たちは、その"有識者"がいなくなった途端、無能者の集まりとなってしまい、チームとしても、組織としても破綻してしまいます。残るのは、有識者足らんと努力してこなかった無能だけの集団…なんてホントに笑えません。

有識者に頼って末永くビジネスを継続したいのであれば、なによりも有識者を丁重に扱っておかなかければなりません…が、そうすると無能者は淘汰されていくことになるので「有識者が、無能者によって優遇される企業」というのはまず実現しないのではないでしょうか。

そういった危険な組織や環境を作らないために、真に適材適所を構築していくためには絶対に

　「仕組み」

が必要になります。「人」の上に「法」を持ってくると言う考え方です。

仕組みには遵守すべき『ルール（基準）』と、徹底すべき『プロセス（手順）』があります。この双方を定義できるか否か、その定義に経営者も含めすべての社員が従えるか否かが、仕組みを統括する責任者あるいは管理者と呼ばれる人の能力の見せ所となります。

しかし、仕組みとかプロジェクトマネジメントとか堅苦しいことを言われてもまず何から手を付けていいのかわからないでしょう。

たとえば「働き方改革」と言われても、

　「残業抑制以外、何をすればいいのか…」

という多くの企業と同じことになるはずです。この「働き方改革」と同じレベルの言葉を用いるのであれば、仕組みの構築改革とは

┌──→②作り方の改革→──┐
①作らせやすさの改革　　　　　　　　　④作られるモノの改革
└──→③進め方の改革→──┘

と定義することだと言えます。

①作らせやすさの改革

これは環境の改革です。
今までやってきたこと、顧客や上司が指示すること、それらはみなさんにとって開発しやすい条件が整っていますでしょうか。あるいはそう言った観点で世の中にどんな働きやすい環境があるかを知らずに、何となく開発していたりしないでしょうか。

環境を整えようとせずルールやプロセスで縛ろうとすると、必ず負担が増えます。それは働きやすさとは180度異なる結果となってしまうことでしょう。過去多くのブラック企業は、何一つ環境を整えずに従業員に無理を強いたからブラック企業となったのです。

②作り方の改革

みなさんの『ソフトウェア開発』では

　どのような工程があって、
　どのような成果物を残して、
　どのようなチェックの仕方で

開発してきたでしょうか。

それは誰がやっても同じパフォーマンスが出るようなルールやプロセスが明確になっていますか？ベテランでも、新人でも、最低限引き出せるパフォーマンスは同じになっていますか？

もし人によってまったく結果やパフォーマンスが異なるのであれば、それは属人的で、チームや組織として確立されていないと言うことです。ただの"個人事業主の集合体"でしかありません。

作り方の雛形を用意すると言うことは、開発体系（開発標準）を定めるのと同義です。

③進め方の改革

プロセスを効率的に進めるためには、進める順番や関連性、情報の共有方法などを明確にし、チームや組織内においてある組織活動に対して困ったり、悩んだりしないようにしなければなりません。

そのための引率役として、「人」ではなく「ルール」や「プロセス」が誘導するのがこの『進め方』であり、即ち『マネジメント』となります。

④作られるモノの改革

こうして①②③が用意され、その仕組みに従ってモノを作ってきたからこそ、初めて「作られたモノ」が妥当であるかどうかを第三者が評価できます。

一般的な製造業における品質保証は、こうしてできるのです。

　①作りやすい環境を整える
　②作るためのルールや方式を定義する
　③作っていく手順を明らかにする

その通りに進めた結果として、できたモノの検証結果に正当性がついてきて、正当性があるから、論理的に正しいものであると証明することができるのです。

仮に東大入試の試験で、あてずっぽうで答えだけ書いて、途中式を何も書かなかったら、点数は０点になるのと同じことです。

ソフトウェアの品質も、最後の最後だけ、正しく動いているように見えたら正しい…と言うわけではありません。"正しい手順で作った"結果として、"正しく動く"から「正しい」と証明できるのです。

この品質保証のあり方を理解しないエンジニアたちが、適当に我流でモノを作って、「思った通りに動けばＯＫ」と言ってしまうから、時として、

　大きなトラブルをおこしたり、
　ミスがでた時に「他には問題が無い」ことの説明ができなかったり

して、延々とムダな工数を使い続けることになるわけです。

ソフトウェアの品質を保証する仕組み

立ち返って、本来ソフトウェア開発においては、品質保証（Quality Assurance：ＱＡ）と言う存在は不要だと私は思っています。昨今のＱＡに期待されるのは、ある意味で仕組みとはかけ離れたところから「有識者」としてプロジェクトの品質（プロダクトだけでなく）に介入して欲しいと言われるようなポジションになっているような気がします。

本来、プロジェクトマネジメントの中で「正しい作り方」や「正しい進め方」を定義し、そのルールやプロセスに従って開発してさえいれば、「正しいプロダクト」になるようコントロールできるものです。そのルールやプロセスに従って開発しさえすれば、性悪説に従って第三者に評価されなくてもいいようになっていなくてはならないものです。

ですが実際には、マネージャーやリーダーは完璧に「正しい」ルールやプロセスを構築することができていませんし、エンジニア達も自身にとって「良いと思う」開発はできても、それが本当に完璧なものかどうかなんて考えてもいません。

結局、そういう人依存のノイズが「正しいプロセス」通りに進めようとさせないために、先入観を持たない第三者が介入しなければならないということなのでしょう。「仕組み」が機能しない最大の要因なのかもしれません。

製造業の言う品質保証は、

まず試作し、
その試作で成功した作り方を、ラインに乗せて量産するプロセスを作り、
その結果として全く同一の品質ができていることを証明する

ために、本当にそうなのかどうかを『出荷検査』と言う形で評価する考え方を持つことができますが、ソフトウェア開発の場合、量産はコピペで済んでしまうため、出荷検査が必要ありません。

しかも、Ｂ２Ｂのソフトウェア開発は、原則として一品モノ開発です。

常に注文を受けてから、オーダーメイドで作ることになります。似たようなものを作ることはあっても、全く同じものを作ることはありません（コピペで済むから）。

ですから、プロジェクト単位で都度、品質のあり方を定義しなければならず、『安定して同一製品を同一品質で作り続ける（量産）』と言う考え方ができないため、プロジェクトマネジメントごとに独自性を持った「品質管理」をしなければなりません。

国際規格のPMBOK（ISO 21500）、10の知識エリアに

　品質マネジメント

があるのはそのためです（いや、ソフトウェア開発のためではないけども。ＩＴ業界でPMBOKを利用する場合はそうなる、と言う意味で）。

私がソフトウェア開発業において、品質保証は意味を為さないと思うのはそのためです。

それでも無理やり『検査』『評価』だけしかしようとしない品質保証が介入すると、必ずマネジメントに大きな影響を与えます。少なくとも製造業の考える品質保証は、ソフトウェア開発には当てはまらないのです。

ソフトウェア開発において、どうしても品質保証を要求するのであれば、プロジェクトマネジメントにおいて、

　①作りやすい環境を整える
　②作るためのルールや方式を定義する
　③作っていく手順を明らかにする

のうち、最低でも②が必要です。品質だけではなくプロジェクトとして成功させたいのであれば、③も必要になります。さらに収益も欲しいのであれば①と言う土台を用意しなければなりません。

これらを無視して、

　「よく解ってないけど、品質保証"だけ"してほしい」

と言う要望に応えることは、残念ながら天地がひっくり返っても不可能です。そのことを理解できていないからこそ、要求するのでしょうけども。

とはいえ、品質保証に、開発方法論やマネジメントを尋ねるのは筋違いです。品質保証の本分でできることは、エンジニアが

　このやり方に従って開発すれば、確実に成功する！

と定めた「作り方」や「進め方」をもとに、本当にその通りに作られているか？進められているか？をチェックする仕組みを作ることだけです。つまりはレビューやテストの手法、観点を定義したり、チェックリストの作り方や作るルールを定義するだけです。

実際のレビューやテストはその工数をもらっている、エンジニアの中から実施されることになります。レビューやテストを替わりにしてあげることはできますが、一緒にすることはありません。なぜなら、既にすべきことを定義した後であれば、誰が実施しても同じ結果にしかならないからです。

技術や開発のプロフェッショナルとしての自覚があるのであれば、エンジニアは自らを『ソフトウェア開発とは？』と言う本質を理解し、「作り方」や「進め方」の能力を磨き、改善し、最適解を修得し続けなければなりません。

もし、その「答え」を自分なりに持つことができるようになれば、その時初めて、品質保証を第三者に依頼することが可能となります（思い込みではなく、証明できる「答え」でなくてはなりませんが）。

そして、それを第三者に評価してもらうことなくプロセスを監視・コントロールできるようになれば、いずれＱＡは必要としなくなるでしょう。