余りにも品質や標準化を知らないエンジニアが多いのは技術進化が加速し過ぎているからか

品質管理や標準化を実践しないエンジニア
レビューをしたり、トラブルになりそうな、いや、トラブル中かな...、なプロジェクトをインタビューしたり、していると、どう考えても、ソフトウェア品質をどのように作り込もうとか、顧客の要求する品質を実現するための作業の標準化をどのようにしくみを仕立てるかを考えて行動しているエンジニアが少ないように思えてなりません。

個々のプロジェクトでの例で言えば、あるエンジニアがどのプロジェクトをキャリーしても、同じような品質のトラブルを引き起こしたり、作業の段取りでトラブルを毎度起こすエンジニアが入れ替わり立ち代わりモンスターのように現れてくるのです。
ある組織という単位の例もあって、その組織の中で、違うプロジェクトで同じようなトラブルを何度も引き起こすのです。ドキュメントの品質しかり、プロジェクトのキャリーの仕方にしかり。これは、ナレッジや組織の中のコミュニケーションの問題のように思えるかもしれないけれど、ちょっと違うかな、と思うのですよ。

なんで目的で品質管理や標準化をするか知っているの？
そんなにトラブを起こしているのは誰が原因なのか、と問われれば、メンバの育成やビジネスの責を負うラインマネージャに他ならないです。でも、すべてがラインマネージャにその職責を持っているのだからと丸投げしてしまうのは浅はかだと思わざる得ません。ラインマネージャがその責を負っていても、現場でビジネスをキャリーするのはエンジニアであって、そのエンジニア一人ひとりが意識を持ってプロジェクトをキャリーしなけれならないからです。

それにしても、技術の進展はワタシがエンジニアの末席に入るようになったころと比べ、加速しているように思えてなりません。次々とシステムを支える技術や少し前までは無風地帯だったシステム開発手法にまでムーブメントの波が寄せるようになっています。新しい技術や手法が現れたからといって、それまでの技術や手法と入れ替わることはありません。今までの上や横に新たな技法や手法がアドオンされてしまう。後になってこの世界に参入するエンジニアとしては、それこそ、覚えなければならないことがあまりにも多い。

だからと言って、エンジニアが過去や今の技術や手法をすべて覚えることは現実的ではないし、その必要性もないけれど、そうは言っても、誰もが学び、実践しなければならないこともあると思っています。

その一つがソフトウェア品質であり、標準化です。先の例に当てはめれば、同じエンジニアが何度も繰り返して品質のトラブルを起こしているなら、顧客の要求するソフトウェア品質を実現出来るような具体的に認識できるモノとして引き出せていないことや顧客の要求する品質を実現するための段取りをストーリとして組み立てられないために、品質を作り込むための作業手順を落としてしまうようなことに気付かないというようなことが、その結果としてソフトウェア品質と標準化の目的を知らずにプロジェクトに携わっているのだろう？ということを結果として表わしているのではないかと思うのです。

ソフトウェアの品質とは、顧客がソフトウェアで実現したいビジネス要求そのものです。だからこそ、その要求をソフトウェアで実現できるように導き出さなければならないし、その要求を求められる品質としてどのように実現するか具体的な作業水準の振る舞い形が標準化に当てはまります。

品質が“なぜ”必要か、その目的を知らないからこそ「バグが出たら直します」と言う言霊として現れるのだと思うのです。少なくとも、顧客の品質を作業の振る舞いで作り込もうとするなら、バグは決して失くせないと思っていても、そんな言い方はしないだろう、と思うのです。なぜなら、バグを作り込むような振る舞いなんてしないのだから。その姿勢には、確固たる意志があるものです。

同じように、標準化も品質に連携するもので、顧客の要求を品質として実現するための振る舞いを形として表わし、実行するものに過ぎません。だからこそ、標準化をしようとしないエンジニアのアウトプットは見過ごすことができません。

平等に与えられた時間をどう使うか
バグはその出現したときのエクスボージャに出るものです。大なり小なり。でも、品質を意識手振る舞っていないなら、品質を作り込むときの見落としや標準化されない振る舞いによる作業の抜け漏れで思いがけない程の影響を与えるトラブルを引き起こすことを想像することは難しくありません。実際、直撃を受けたことはなくても、冷っとしたことやハッとしたことは誰でもあることだと思うのです。

今、目の前にある仕事を責任もってやるには、その仕事に必要な技術を学び、実践することを応援します。ただ、その仕事を実践する上で、あまり学ぶ機会のないだろう、ソフトウェアの品質や標準化を知らずに何度も手戻をするよりは、ある程度の技術を身につけたタイミングで、その先に必要となるソフトウェア品質を作り込むための知識や標準化をすることの目的とその実現の仕方も忘れずに身に着けて欲しいと思うのです。