プロセス品質を大前提とした戦略的マネジメントモデル

以前、自分の中でプロジェクトマネジメントの前段階として、

　「プロジェクトプロセス」を具体的にどのように構築すべきか？

という観点から、戦略的品質マネジメントモデルというものを構築し、そのざっくりとしたところをご説明しました。

当時「こんなの考えたよー」という簡単なご紹介だけにとどめたのは、そのマネジメントモデルをさらに具体化すれば『金になる！』と思ったのもありますけど、厳密にはそれくらいの価値があると思ったからこそ、次に再就職した時にその企業で活かし、企業価値を高めることにつながる…その貢献ができると考えたからですけど、どうにもそーいった観点では求められていないようなので一般公開してしまおうかと思います。

問題提起

そもそも、Ｂ２Ｂのソフトウェア開発における

　・トラブルの起きやすさ
　・品質保証の難しさ
　・現場担当者の疲弊
　・結果としての離職率の増加や副次的な組織力の低下

と言った課題／問題は多くのSIer、ベンダーが皆一様に抱えていることでしょう。

「業界」という単位で見た時、やはりソフトウェア開発の業界は他の業界と比べてもかなり離職率、転職率は高い方だと思います。もちろんサービス業全体がかなり高い業界ではあるのですが、ホワイトカラーというかデスクワーク中心の企業体のなかではやはり歪です。

今でこそわかりやすいブラック企業はずいぶん減りましたが、ソフトウェア開発の現場でも「トラブル」が発生すると半ばブラックに近い業務体質に変わります。

　・きちんとマネジメントの教育や育成を受けてないのに
　・中途半端に「知識がある」「話せる」というだけで抜擢され
　・あとは放置で全責任を負うことになる

結果、エスカレーションもロクにデキず（やらず、あるいはやり方も知らず）気がつけば大トラブルになっていて、心身ともに疲弊し、場合によっては業界を去っていく…という20～30代のエンジニアやプロジェクトマネージャーは少なくありません。

会社の体質や管理職の責任感に問題があるわけですが、そもそも組織や人のせいにしても何も改善されることはありません。人を変えたところで次の人が必ずステキマネジメントをしてくれるという保証はありませんし、今後常にそういった人だけがマネージャーになるか？というとそう言うわけではありませんので、「人」に責任を求めて「人」を挿げ替えるだけで何とかなると思っていると、いつまで経っても根本解決ができない組織の出来上がりです。

真因は「人」の力量に依存することを良しとした制度や仕組みを許容する姿勢であり、それらをプロセスによって矯正し、

　仕組みが遂行されていることを監視・評価する役割
　仕組みを定期的に見直し、最適化を図る役割

によって「人」依存から脱却すればいいわけです。

ただし「仕組み」を採用する場合、なかでもマネジメントに関わる仕組みを採用する場合は、トップダウン型の強い環境整備が必須となりますので、経営層や中心となる管理職層に相応の理解や牽引力が伴わなければ根付きませんので注意が必要です（ボトムアップで企業体質が変わるなんてことは絶対にありません）。

解決方法

さて、ではその仕組みによる解決方法ですが、これからお話しする方法は適用可能なスコープとして「設計」「実装」「テスト」が明確に分割できていて、それぞれの情報トレーサビリティが確保できる範囲であればどのような開発モデルでも適用可能です。

手戻りコストを最小限にしつつも「自分たちのやっていること、作ったものの品質を保証できること」を大前提とした最適なマネジメントをするためのプロセスを進めていくために重要なのは

　『情報』

を適切に扱うことです。

簡潔に言えば、

必要十分なアウトプットを生成するためには、そのためのプロセスが必須。
必要十分なプロセスを遂行するためには、そのためのインプットが必須。

というだけです。インプット→アウトプットに変換するまでの情報の取り扱い方…言い換えれば『コミュニケーション』が適切であればいいわけです。

設計書を作成する作業などをはじめ、ソフトウェア開発にかかるほぼすべてのタスクを『コミュニケーション』という視座から見ることのできる、さらにはその視点から開発プロセスを検討、構築できるプロジェクトマネージャーやアーキテクトはなかなかいないのではないでしょうか。

コミュニケーションを「話す／聞く」とか「書く／読む」というただの手段でしか見れていないようでは理解は追いつかないことでしょう。あくまで

　「必要十分な情報を正確に伝達される」
　「伝達した情報が相手との間で共有される（され続ける）」

ことだと考えれば、目的達成のためにどうあるべきか？という観点で実施することが可能でしょう。これをプロジェクトの開始（計画）から納品されるまでの各タスク、各成果物を"点"とするなら、それら点を"線"で結ぶと次のようになります。

すると、それぞれの各タスク（プロセス）は「どのような成果物をアウトプットとするためにどうあるべきか」、各成果物（アウトプット）は「次のプロセスのインプットとして用いるためにどうあるべきか」という見方ができることがわかります。すると、

　・何の情報が必要か
　・どのような表現であるべきか

は否応なくわかります。元々、レビューやチェックというのは『あるべき正解』があらかじめ用意されていて、その通りに実現しているかどうかを評価するものです。むしろそうなるよう定めておかなければプロセスとしてもアウトプットとしても駄作というわけです。ですからレビューや検証というのは

　「定められた答え通りのアウトプットとなっていること」

という見方をしなければなりません。レビュアの力量や経験則を頼りにその場の気づきや思い付きで「後だしジャンケン」のように好き勝手言っていいものではないのです。これも「適切な情報をあらかじめ伝えておく」という視点で見ればコミュニケーションの一環と言えるでしょう。プロセスのすべてをコミュニケーションという位置づけで考えることができなければ、このマネジメントモデルを使いこなすことは一生できません。

たとえば、基本設計工程の一般的な成果物として「画面設計書」を考えてみましょう。

基本設計の前工程にあたる要件定義とは、お客さまの要求事項を「業務」「システム」「機能」「非機能」と言った切り口の仕様として「どのような実現結果となるべきか」を定義する工程です。

次工程にある画面設計では『前工程で定義した業務仕様を実現するための一機能仕様』という切り口で実現方法を模索しますのでそうした機能仕様を『画面』という形でどのように実現するかを具体的に決めていくことになります。

　・取り扱うデータ（変数化する箇所）
　・レイアウト/デザイン（静的定義）
　・アクション/イベント（業務ロジックの開始トリガー）
　・変化する処理結果（動的定義）

が中心になってきます。これらの情報だけで単一機能に対する「操作」と「操作結果」は読み取れるようになるわけです。ここでは処理の中身ではなくなんらかの処理が行われた結果、処理前からどのように変化したのかを明確化します。そう…いわば「ブラックボックス」なわけです。当然、この設計内容を検証するためのテスト手法は「ブラックボックステスト」となります。

処理の中身に触れないと言うことは、プログラムという視点では検証しない（できない）ということでもありますので当然物理設計も不要となりますよね。

すると「画面設計書」とはどのような情報が必要なのかがわかってきます。さらにどの情報を、どの粒度で記載すべきかについては、

　・次工程のインプットとして必要十分であること
　・テスト工程のインプットとして必要十分であること

という観点から考えていけば、レビューの観点なんて

　「どのインプットから引用した結果、この情報となるのか」
　「次工程のインプットとして必要十分となっているか」
　「テスト工程のインプットとして必要十分となっているか」

以外に必要ありません。そこにレビュア独自の観点や考え方なんてものは必要ないのです。これを一人ひとりのレビュア（有識者）の力量に依存すると

　・レビュアごとに品質のレベルが異なる
　・同じレビュアであっても時間経過ごとに言ってる内容や粒度が異なる

ということが当たり前のように起きてしまいます。そうならないよう、各成果物の様式や記載ルール、再利用先の観点などを加味して、レビューのチェックリストをあらかじめ作っておき、機械的・画一的に検証ができるようにしておくことです。

もちろん、システム固有のものや、業務固有の条件などによってインプットにない情報がある場合はどうしても有識者に頼らなくてはならなくなってしまいますが、本来はそう言った情報も余すことなくすべて記載しておけば、機械的なチェックによる品質の保証は確実に行えるようになっています。

裏を返すと、手を抜いてインプットに含めないから、有識者の記憶や認識という不確かなものに頼るというギャンブルを冒さなければならなくなるわけです。当たり前ですが「人」の記憶や認識に依存した時点で、品質を100%保証する術は無くなります。論理的に証明する手段が存在しないからです。

あらかじめレビューの具体的なチェックポイントを特定、周知することで、

　①作成時にチェックされるポイントを理解して作成できる
　②レビュー時に指摘される件数が激減する
　③手戻りコストが劇的に抑えられる

という効果をもたらします。よくIPAやJUASなどで数年に一回、テスト密度やバグ密度の調査結果が公開されていますが、私は個人的にあーいったデータを再利用しようという気にはなれません。

機能の複雑度や採用しているソフトウェアアーキテクチャ、プログラム言語、プロジェクトに参画するメンバーの平均的力量、顧客の特性、顧客側の事情や都合、計画時から推進する品質レベル等、プロジェクト一つひとつの条件が異なる以上、すべてを同じテーブルにおいて平均値化したところで何の参考にもなりません。個人の力量なんて殆ど数値化できないものですから参考に「できない」よいうより「してはいけない」と言った方が正しいかもしれません。

私が推進している方法を実際に行えば、作りこみ品質が圧倒的に向上するため、バグ密度は圧倒的に少ないものとなるでしょう。当然、IPAやJUASの定義するバグ密度は参考することはできません。しても（良い方向に）大きく乖離してしまうだけで評価価値を見出せないからです。

さらに言えば、参考にしたところで平均値より「多い」「少ない」というのは製品品質に何の影響も与えません。たとえば基準よりバグ密度が低ければそこから読み取れるのは

　・作りこみ品質が異様に高い
　・テスト品質が圧倒的に低い（テストケース不足）

のいずれかにしかなりません。そして、テストケースについてもテスト密度なんてものが同様に公開されていますが、それもなんのアテにもなりません。テストの品質とは、単純に

　「テストケースが論理的に品質が保証できる形で網羅されていること」

です。密度が高いか低いかで測るものではありません。そもそもPOA、DOA、OOAそれぞれのアプローチによってもプログラムの複雑度は大きく変わりますし、プログラムの複雑度が変われば同じ処理であってもテストケースの数は異なってきます。少なくともプログラム行数をベースに測定しても何の意味もありません。

テストケースを洗い出し、テスト仕様書を作成した際にしっかりレビューしていれば、その時点でテスト品質は保証されたも同然です（もちろんテスト仕様書通りに実施することが前提ですが）。

すると、実際にテストを実施する時には

　・テスト品質が圧倒的に低い（テストケース不足）

かどうかなんて議論が再発することはありません。そう、「作りこみ品質が異様に高い」一択となるわけです。バグ密度がどんなに基準より下回っていても、調査１つ必要ありません。何のコストをかけなくても、するべきことをしていれば論理的に何も問題が無いことが証明できます。

結果、品質は情報のトレーサビリティによってきちんと保証されつつも、大幅に手戻りコストを低減し、スケジュール的にも、コスト的にもマネジメントの負担を大きく軽減してくれることでしょう。

また、同じ技術要素、同じ成果物様式であれば、設計レビューやテスト仕様書レビューのチェックリストや観点表は再利用が可能です。

毎回毎回プロジェクトごとに準備する必要は原則ありません（あるとしたらプロジェクト内で独自性のある"何か"を採用している場合のみ）。少なくとも、要件定義や基本設計と呼ばれる工程に限って言えば、多少のことで変更を必要とすることはないはずです。

詳細設計…つまり処理ロジックそのものを設計することについては必要か否かについて賛否両論あるので何とも言えません。そもそも詳細設計という工程が「何のために必要か？」を理解しているエンジニアが昔に比べて少なくなった…という側面もあります。ゆえに大手SIerでもなかには単体テストあるいはホワイトボックステストを実施しない企業も出てきています。ホワイトボックステストを実施しないのであれば詳細設計自体、あまりあっても意味がありません（検証するテスト工程がないのですから）。

もちろん、実装工程以降をニアショア、オフショアにする場合などは、情報伝達ツールという観点から必要になってくると思いますが、ホワイトボックステストを実施しないというだけで、品質保証上の必要性としては意味をなくしてしまう点は覚えておくと良いでしょう。

あらかじめ「答え」を用意しておくことには色々なメリットがあります。というかデメリットが原則ありません。一つひとつのインプット、プロセス、アウトプットを線でつなぎ、プロジェクトの完了まですべて紐づけられていれば、間違いなく事前に「答え」を用意しておくことは可能です。

たとえば、昔関わったとあるプロジェクトでは、既存資産を流用するという話になって、それぞれの既存資産がどのような関係性で作られるものなのか紐づけたことがあります。

そこから紐づかない成果物を洗い出すこともできますし、洗い出した結果「どうすれば品質を担保することができるのか」検討することも可能になります。

各成果物のなかのどの欄のどの内容が「何をインプットとしているのか」「何をアウトプットとしているのか」「次のタスクで何のインプットに使われるのか」を明確にすれば、どのようなレビューやチェックをすればいいかも大半がわかるようになってきます。

たとえば「項目定義」というのであれば、その取り扱うデータのサイズや型、処理のinputにつかうのか、outputに使うのか、書式は、禁則文字は、活性/非活性は、タブ順は、etc.…色々なことをインプットの観点、アウトプットの観点それぞれから明確化しなければなりません。これが明確になるとバリデーションの要否もわかってきますし、データベース設計が進むと編集仕様などもハッキリしてきます。すると異常系（想定内異常）に関する仕様も明確になってきますし、その結果としてエラーメッセージや配色による表現などの仕様も固まってきます。

こうして設計様式の中に記載する内容や粒度がクッキリと明確になってくれば、次工程やテスト工程を想定した時に、どのようなチェックを行えばいいかも自ずとわかってきます。実際、各工程、各タスクの書式/様式が決まれば実プロジェクトのサンプルが無くても、チェックリストを作成することは可能です。

また、既存資産の流用時はきちんと調査しておかないと、安易に「流用すればそのぶんコスト軽減できて楽だべ？」とか何の根拠もなく用いてしまうと、手痛いしっぺ返しを食らうことになりますので注意が必要です。

こういうことは新規、改修、再構築いずれの場合であっても変わりません。全てのインプット、プロセス、アウトプットを明確にすることで事前にさまざまな「バグ」を作りこむ機会がグッと減ることになるでしょう。

最後に、作りこみ品質を徹底的に向上させることで、実際に低減されるコストを試算するのであれば、このような式になるだろう…という事例をざっと載せておきます。

まぁ実際にはデータを取りつつ、妥当な係数値などを洗い出していく必要はありますが、このような流れで大幅にプロジェクトコストの低減や、メンバー、マネージャーの負荷軽減が実現できることでしょう。

開発標準（開発体系）のようなものが部門内や企業内に存在していれば、こうした仕組み、マネジメントモデルを導入することはさほど難しくありません。その開発標準（開発体系）が定める成果物に照らし合わせたチェックリストを作成することができるからです。

企業のなかで成功事例を積み上げつつブラッシュアップしていけば１年もしないうちに企業として１つの柱、１つの強みにできたかもしれませんが、前職を含めて実現できる見込みはなさそうなので、私の中で風化する前に公開することにしました。

ソフトウェア品質（データの品質）を応用する術を持ち、コミュニケーションの本質を理解できる人が少しでもそのエッセンスを取り込んでトラブルプロジェクトを減らしたり、プロジェクトメンバーの負荷を大きく低減したり、さらにはプロジェクトスケジュールやコストの冗長的な消費を減らして利益貢献や顧客満足度向上につなげてくださることを陰ながら祈っています。

説明は以上となりますが、ここで貼り付けた各資料ページの元ネタとしてpowerpointも以下に置いておきます。