何を「元」にして開発しているのか

もう定年間近のあるエンジニアの方に「会社としてレビューするためのルールとか基準ってないんですか？」と言われました。厳密には、現場で大問題を起こして、お客さまからそう言われたんだそうで、何も答えられなかったらしいです。

実はあるんです。４～５年前から用意してました。

部課長どころか、全社員にも幾度となく展開し、実際に活用しているプロジェクトもあるというのに、興味がない間、みんなまったく見向きもしてこなかっただけで。

それに、仮にそんなルールや基準を与えられると、何も考えずにただ従うだけしかしないでしょう。いえ、従えるならまだいいのです。お客様向けのポーズに使うだけで、何一つ活用していなければ、お客さまを裏切る結果になるかもしれません。「どんなプロジェクトでも100点を出せるルールや基準」なんて存在するはずもないのに、提供することによって思考停止されるのでは、出すに出せません。

さらに言えば、今まで何年、何十年と属人的に開発し、勝手に納品してきたのでしょう。その中には、納品後に不良とならなかったものや、お客さまから満足されたものもあったはずです。その経験則を言語化し、情報を整理し、体系として纏めないのはなぜでしょう。

　・管理系、監視系、制御系
　・Web系、アプリケーション系、モバイルアプリ系、組込み系

と言うように、対象領域の違いや技術領域の違いによって、まったく異なるシステム依存の品質要求特性があるため、現場で長年培ってきた経験則こそが最も純度の高いデータであり、ルールであり、基準となるはずなのに、なぜそれを今までまとめてこなかったのでしょう。

もちろん、私のまとめたものも、私の知識と経験の集大成であって、そこに後付けでＩＳＯ（国際標準化機構）、ＪＩＳ（日本工業規格）の規定を絡めたり、ＩＰＡの公開している体系に合わせたりしているだけにすぎません。

結局のところ、誰かが個人知を組織知にするしかないのです。

ＩＴの世界では、建築の世界や医療の世界のように、一つひとつの仕事の仕方に対して法や規格、基準の強制力が乏しく、ソフトウェア開発の進め方については企業や個人に一任されており、確立された「これ！」と言う体系がありません。

だからこそ、個々人が経験してきた知識を整理し、まとめ、継承し、時代や技術の進歩にあわせてカスタマイズしていかないと、いつまで経っても属人的な進め方は変わりませんし、属人的な進め方が変わらない限り、マネージャーやチームメンバーのアタリ／ハズレによって、今後もホワイトかブラックかは運任せにしかなっていかないのでしょう。

ですが、そういう「自分では一度も個人知を整理してこないで、ルールや基準を自ら作ろうとせず、属人的な進め方しかしてこなかった」リーダーやマネージャーには、改めて次の３点について説明しておきたいと思います。

「ルールや基準が必要」と言ってはいけない

少なくとも、今までのシステム開発において、ルールや基準を必要とせず、自分本位にレビューやテスト観点をひねり出してきたのであれば、間違っても「ルールや基準がない」ことを言い訳にしてはいけません。

ルールや基準は、プロジェクトの都度、作るものです。テンプレートがあっても、そのまま鵜呑みにしていいなんて話はありません。テンプレートは所詮テンプレート。結局のところ、プロジェクトごとの特性にあわせてテーラリング（仕立て直し）をしなければならないのは変わりません。

もしも、この言い訳に逃げてしまった時、それは、

　これまで納めてきた数多くのシステムでは、
　その品質を何一つ保証していなかった

ことを自白するようなものだからです。レビューにせよ、テストにせよ、確認したところは保証できるかもしれませんが、確認していない部分に対して「確認しなくてもいい」と断言できる根拠を持ち合わせなかった可能性があるからです。

多かれ少なかれ、自分なりに正しいと思ってルールや基準、手順などに縛られずともとりあえずは納品してきたはずです。結果論的に、納品後不良が発見されていないシステムだってあるでしょう。

ですが、「ルールや基準が必要」と言ってしまうと、少なくともこれまでやってきた「ルールや基準がない」まま進めてきたすべてのプロジェクトにおいて、未だ潜在的な不良が残っていることを示唆します。

プロを名乗るならば、安易に今までの決断や行動を覆すような、無責任で尻軽なことをしてはいけません。

「ルールや基準がない」と他責にしてはいけない

もしも、これまでルールや基準、手順が無いままレビューをしてきたのなら、何を根拠にレビューしてきたのでしょうか。経験年数を重ねれば重ねるほど、「有識者」ともてはやされ、率先してレビュアーに押し上げられてきたはずです。そして、自らも有識者だからと自分を認識し、実に偉そうに作成者に対して指摘をしてきたはずです。有識者は、レビュアーは、ただ気づいた点を指摘すればいいと言うわけではありません。レビュー観点が網羅されていて、抜け／漏れが無いようにしなくてはいけなかったはずです。

ですが、そのレビューの観点は、毎度毎度気分や思い付きでいうだけのものでしたか？自分の中に確固たる自信や裏付けがあって、チェックしていたものではありませんでしたか？

もし、そうであるならば、それらをすべて書き出してください。
それが「基準」でありベースラインです。

そこで書きだすにあたり「自信が無い」「書き出せない」と決して言ってはいけません。そう言ってしまったが最後、「ルールも基準も、何もない中で」有識者と持てはやされ、レビュアーとしての立場に身を置く責任のすべてを放棄する（過去もずっと放棄していた）ただの無責任に成り下がってしまいます。

今後、レビュー観点に自信が無い、レビュー観点やチェックリストを書きだせないと言うのであれば、それはレビューする資格が無いと言うことです。どこかのだれかがレビューについての観点やルール、基準を作ってくれない限り、絶対にレビューしてはいけません。

レビューの大観点は２つある

さて、上記の２つの話をまずは大前提としたうえで、実際に

　「じゃあ、レビューするにあたって、
　　どういったところに気を付けなければならないのか、
　　わかるもんなの？」

と言うと、大抵のことが実は機械的にわかるようになっています（全部ではありませんが）。その機械的にわかる部分とそうでない部分を大別すると

　・情報固有の観点
　・業務依存の観点

となります。これは、私なりの解釈になりますが、国際規格ＩＳＯが規格化しているデータの品質モデル（ISO 25012）と同じ考え方になります。

この品質モデルは元々、ソフトウェアが取り扱うデータの品質の在り方をモデル化したものですが、プロジェクトを「システム」と置き換え、プロジェクトメンバーととの役割を「機能」と置き換えた場合、プロジェクト活動において作成される中間成果物（ドキュメント群やテストデータ等）は、システムの中で流れ、機能間のコミュニケーションを滞りなく成立させるための「データ」と同じ位置づけになります。

そして、レビューの観点が機械的に導き出せる部分というのは、「情報固有の観点」となります。

　・ドキュメントの構成
　・ドキュメントに書く様式および内容
　・ドキュメント間の記述情報の紐づき

などによって、そこに記載される「情報」は、どのような機能、どのような仕様であったとしても、ドキュメントや各記載欄のルールに従って記載することが義務付けられます。そのため、業務や仕様、利用背景などを一切考慮に入れることなく、記述ルールに従っているかどうかのレビューが可能になるわけです。

この考え方は、単項目レベルにおいてはテスト観点にもそのまま使えます。

以前書いた記事のような感じですね。

有識者…なかでもシステムが利用されるシーンに深くかかわっている人が行えるレビュー観点が「業務依存の観点」です。こればかりは、文書化されていないのであれば、実際に利用されるシチュエーションがイメージできていないとなかなか見いだせない可能性があります。

だからこそ、要件定義や基本設計と呼ばれる「上流工程」では、お客さまのレビューが行われることが多いんですね。逆にいえば、一つひとつの仕事領域をMECE（漏れなく、ダブりなく）に実現しようと思ったら、お客さまのレビュー領域はお客さまに任せてしまえばいいと言うことです。

つまり、私たち開発側の人間がレビューにてチェックすべきは

　「情報固有の観点」

のみでよい（「業務依存の観点」はお客さまが実施する場合に限る）、あるいはそうせざるを得ないと言うことです。お客さまが実施しない場合、リスクは格段に跳ね上がります…が、実現できないわけではありません。ありとあらゆる組み合わせを網羅することはさほど難しくないからです。

　メモリ、ファイル、データベース

主にこの３種のリソースに対して、ＣＲＵＤが明確化されており、且つ同タイミングで同リソースの同項目にアクセスする可能性がある場合、これに対して、全てのパターンを網羅すればいいだけです。

ただまぁ…こんな人海戦術的なことをすれば、基本的にスケジュールを順守することは難しく、プロジェクトが破綻してしまいかねません。業務的に、実現は可能ですが、現実的な対応ではないので、お客さまを巻き込む努力の方が数百倍マシなのではないでしょうか。

最後に

どちらにしても、エンジニアの基礎的なスキルだけで、レビュー観点を網羅することは不可能ではない、と言うことだけは確実です。

その点を踏まえて

　「自ら、レビューやテストについての理解を深める気があるか」
　「自分たちでは解決する力量を身につける気はないか」

そのどちらかをハッキリさせた方がいいでしょう。ただ、プログラミングのスキルだけがあれば「開発」ができる、と言うわけではありません。プログラミングスキルだけで実施できるのは「製造（設計書の翻訳）」だけです。

エンジニアとして「開発」ができるようになりたいのであれば

　「業務仕様の理解／要求の分析」
　「設計」
　「テスト」

についても、プログラミングスキルと同じくらい熟達する必要があります。