第十一章｜開発と品質は、構造で決まる
品質は、
テスト工程で作られるものではない。
不具合が多い現場では、
個々の技術力よりも先に、
仕事の構造そのものに問題があることが多い。
この章では、
システム開発や品質管理を
技術論としてではなく、
前工程・後工程・言葉のつながりとして捉える。
なぜ品質は後から作れないのか。
その理由を、構造の視点から整理していく。
１.ここまでの基本を糧に、いよいよシステム開発者の心得｜言葉が通じないという問題
―― 技術だけでは立ち行かない場面で効いてくる視点の話
日本語で話せ（笑涙）
筆者は技術者出身ではない。そのことをしばらく話そうと思う。
最初にIT業界に飛び込んだのは、当時は日本で一番大きかったダイエーという小売業の、情報システム部門が分離独立した会社だった。今は流通業の王者をイオンにその座を取られ、ダイエーはイオンの傘下の一ブランドになってしまった。
基礎研修を受けたが、正直言って、何も理解していないに等しかったと思う。Javaの研修もした。HTMLで自己紹介ページを作った。
日本の小売業では最大級のデータセンターも見学した。とても涼しい空調の効いたサーバールームに、水冷式のアレイがあって、冷蔵庫かと思ったらそれがCPUだと聞いて混乱したりした。少なくとも、筆者が知っている、MacやWindows機に搭載されているような、小さなCPUではなかった。
そんなこんなで、配属された部署はソリューション営業第一部と名刺に記載された。肩書などは何もない。他の同期入社の人は、開発一部とか、まだその言葉が普及する前だったがITサービス部（運用保守部隊）に配属された。
初めてのソリューション営業は、小売業の仕組みを理解し、同時にビジネス用語も理解し、IT用語を駆使して、パワーポイントに落とさなくてはならない。殊更に、IT用語には大変苦労した。筆者があまりカタカナ言葉を使いたくないと思った理由も、このころのトラウマがそうさせている。
「そこはアドミニ権限でストアド走らせて、DBに踏み台噛ませて、オブジェクト処理すればいいんじゃね？」とセンパイは言う（例は適当に書いている）。当時の筆者は、主語も述語も目的語も分からない。アドミニをYahoo！検索で調べる。e-wordsに飛ばされてまた検索する。管理者と出てくる。管理者権限と、言葉の意味が理解できたときには、もう、センパイが何を言わんとしていたかなんて忘却の彼方だ。
メモを執れ、とセンパイは注意する。メモを執って、ノートの欄外に分からない言葉をメモして・・・とやったが、欄外が埋まるくらいに、よくわからない用語だらけだ。
技術を学習しようとする皆さんも、この経験を他山の石としていただきたい。誰もが通る道だ。特に、IT業界未経験ならば、言語という日本人にはとっつきにくい、英単語の意味のない羅列を記憶しないといけない開発言語学習は大変だ。
筆者はIT業界でたくさんの失敗をしてきた。そのたびに、「一朝一夕に実力が身につく方法がないか」「センパイや課長さんに怒られない方法はないか」と、対症療法的なものばかり追ってきた気がする。こういう教育のためのテキストを書いている際に、対症療法よりも根本治療の方が近道だとわかっているので、頭の働かせ方を中心にここまで学習してきたのだ。非技術者の立場から14章をお送りする。なぜこんなに後半に出てくるかについては、もはや論を俟たないと思う。
コンピュータはバカだ
具体的に話を進める。
まずはコンピュータの歴史からひも解く必要がある。かと言って技術寄りの事項よりも、現代の開発にきちんと依存関係があることを知ろう。
専用の高価なコンピュータがあって、オフコンが多少廉価で出て、いろいろな業務にコンピュータが活用されるようになると、汎用機という流れになり、その後オープン化の時代となった。そういうことは書籍などでさんざん教えられると思うので、ここでは説明しないが、ノイマンコンピュータ以降、ＣＰＵ、メモリ、ＨＤＤという作りがほとんど変わっていないのは、ノイマンの慧眼というしかない。
このテキストでもたびたび申し上げているが、天才という人たちは、道を作るのだ。そしてその他の9割以上の人間は、それを活用するのみで人生が終わる。悲しいような気もするが、情報化社会の頭脳労働者は、そうやって生きていくのだ。
コンピュータは繰り返し作業が得意だ。最近流行りのAIに関しても、ソフトバンクグループの孫正義さんがおっしゃっていたが、世界中の２億人のエンジニアが、四六時中頭脳をフル回転して出す答え、ソリューションを、瞬時に返してくれるという流れとなる。こういう機械学習と、それを出力する方式が、2020年代になって形になったのがAIだ。
しかし、コンピュータは同時に、バカでもある。やつらはゼロとイチしか区別がつかない。電源のオンとオフしか判別するものがないからだ。よって、最適な解決策を見出すには、プログラムを決めてやらないと、コンピュータは動かない。そのためには処理方式を決める必要がある。
オンラインの反対語は何であろうか。ネット社会の申し子たちは、自信満々にオフラインと答えるかもしれないが、システムの処理におけるオンライン処理の反対語は「バッチ処理」だ。
よく見る図ではあるが、バッチ処理は日々の洗濯物だと思うとよい。例外を除いて、人は洗濯物が溜まったら洗濯機を回すのであって、シャツを一枚脱いだから、すぐに洗濯機を回すということは、通常はない。
一方のオンライン処理は、フランス料理だと思えばよい。出された皿を順番に食べて、食べ終わると皿が下げられる。そして次の皿が来て、もし食べないとそのまま残る。
コンピュータのように、プログラム通り実行するということを得意とするものは、貯めて一気に処理をするバッチ方式か、要求が来たらその場で処理するオンライン方式なのか、プログラムの作りが異なるので最初に決めておかなくてはならない。
同時に、そのバッチ処理やオンライン処理の中で、どのような順番でコンピュータにとっての「仕事」をこなすのか、フローチャートに描く必要がある。フローチャートは明確な書式が決まっているが、開始と終了のマーク、分岐、定義済み処理、他の処理へのジャンプ記号の４つくらいを押さえておけばなんとかなる。それよりも、大事なのは、業務フローがあって、初めてシステムフローが描ける、ということだ。
前工程と後工程の恐怖
SEと省略されるシステムエンジニアは、お客様の業務について明るくなくてはならない。そして、おおざっぱなものでもいいから業務フロー図を書き起こさないと、システムフロー図は失敗する。アルゴリズムを決めるのも、アルゴリズムでは有限回の処理を対象とするので、ループ処理なども含めて、全体概要を理解していないとバグのあるシステムになってしまう。それはもはや、プログラムのバグではなく、要件定義の漏れという形で後工程に影響を与え、後工程になればなるほど前工程に戻った際の「コスト負担」が重くなる。
筆者は日本人の文化しか存じ上げないが、日本人は前工程に戻っての「手間暇」を武勇伝にしたがるよくない大人はたくさんいるが、そこに明確なコスト意識がある人がいない。そのくせ設計のやり直しなどになれば、お客様側が「受託開発の一環だろ」的なことを言われてしまい、追加工数だけかかっても追加費用が出ない、なんていう展開すらあるのだ。
なんでもドライに接すればいいというものではないが、請負業務の範疇であっても、要所要所で工程完了判定を行い、先の工程に進むことをプロジェクトで決議したならば、良いことも悪いことも、プロジェクト全体で享受せねばならない。
要件定義の漏れであるならば、それを言い忘れたお客様側、そしてそれを拾いきれなかったベンダー側双方の言い分をよく聞いて、プロジェクトの遅延を最小限にすべく、双方で努力を怠らないことが肝要だ。犯人捜しなんて始まったら、それはやめましょうと、建設的に提案することがよい。
筆者の同期入社の人たちも、最初から設計に携わることはなく、部分部分のプログラムのお手伝いをしたり、出来たソースをコンパイルしたり、チームメンバーのWBSを整理して、締め切りが今日だの明日だのとおしりをたたく役割をしたりと、そういう風に成長していった。一方の筆者は、ソリューションの提案活動はするものの、技術的背景がないので、いわゆる「口だけ、勢いだけ」の営業マンにしかなれなかった。
プログラマでデビューしても、設計工程に携われるのは相当後になってからだということだ。そしてそのプログラムも、自身でコーディングしてテストまで担当できるのはいくばくかの経験を積んでからなので、その間にバッチ処理とオンライン処理などの実践経験を積んで、何が根幹となっているものかを常に確認しておくこと。業務フローなくしてシステムフローはないので、システムフロー図（アルゴリズム）が不案内であっても、業務については日本語で表現されているはずだから、概略でもいいから業務フロー図を作って、センパイ社員にレビューを受けること。実際にプログラムの学習に入る前に、基本の報連相とは何かを押さえておくことを強くお勧めする。
さて、話が少し逸れてしまったが、ITの基礎を抑え、最も早く実力を身に着けるには、都度都度の対症療法ではだめだというメッセージはこのくらいにして、次に進もう。
3層構造とは
一口にシステムと言っても、構成するサーバー群の要素ごとに、取り扱うエンジニアの領域も異なる。代表的なWEBサーバー、アプリケーションサーバー、DBサーバーという区分にしたって、WEBサーバーを構築するにはそちらに依存する知識と経験が必要だし、アプリケーションサーバーということになれば、皆さんがこれから取り組むであろう言語以外にも、設定ファイルの作り方や、プログラム資産の管理の仕方など、覚えなければいけないことは多岐にわたる。
初心者からは、あたかも無限に広がっているように感じられるかもしれないが、自分の担当領域について知ることが、直近のお仕事には重要なので、それ以外は順次学ぶのだという感覚を身に着ける。データベースに至っては、アプリケーションエンジニアであってもわからない事項がたくさんある。専門家が、DBの移行などまで考えて設計する。
かつてはRAIDを組むなんて言ったら大層な構築の工数がかかったものだし、ハードウェア的な投資も莫大になったものだが、オンプレミス環境からクラウドに移行する時代を迎え、RAIDの考え方も変わってきている。
その代わりにAWSなどを構築するための知識が別途必要になり、手数もかかるようになった。構築する立場が変わればノウハウも異なるのだ。
ＷＥＢサーバーは大量にアクセスしてくるエンドユーザーを、ロードバランサなどを使って仕分けをし、それに紐づくアプリケーションサーバーで処理を行い、実行結果をDBに貯める。そういう基本から逸れないように枝葉の知識を積み重ねていこう。
業務フローが見えたら、今度は画面設計書（のうち画面遷移図と呼ばれるものがメインとなる）及びシステムフロー図（アルゴリズム）を設計していく。画面遷移図で洗い出したすべての画面を画面設計書に起こす。かつては、専用機や汎用機の世界だったので、画面表示も値の羅列だったが、今はGUIの時代になり画面イメージはより重要なものになっている。ユーザーインターフェースが使いにくいシステムは、遠からず廃れる。
ということは、画面が使いにくかったら、ユーザーから、例えば受入テストのときになって、「使いにくいから画面を直せ」となる可能性があるということだ。
画面は、かつてはただの表示領域だったが、システムの大部分を占めるまでになり、例えばそれを記述するHTMLも発達して、CSSやjsを組み合わせればほぼ思いのままに動くようになった。ホームページという枠を飛び越えて、今では商品や製品ごとにWEBページが存在し、画面遷移図もより複雑になっている。HTMLは技術者の本懐ではないと思う向きもあるかもしれないが、極めて重要な言語のひとつとなっている。
マス消費者は、裏で動いている仕組みに興味は持たず、いわんや機能よりも非機能部分の方に着目しがちだ。どんなに優れたショッピングサイトであろうと、「注文ボタン押したら30時間後に在庫があるかがわかります」というサイトでは誰も買い物をしないのだ。
ワンストップトータルソリューション（長い）
トータルソリューションの提供が叫ばれて久しい。画面もオシャレで、反応もよく（これでも、汎用機のスピードに慣れたユーザーが、初期のWEBシステムを触った時ほど、現代では体感スピードに差がないのだが）、そして当たり前のように24時間365日止まらない、こういうシステムが当たり前になっているということは、マス消費者やエンドユーザー目線を持ったエンジニアに大いなる需要があるということだ。
言語の学習などは、社屋にいる間に実施すればいいとして、街角や電車の中で、気になることがあったら、「この事象をシステムでソリューション（解決）するにはどうすればいいのか。画面、アプリ、DBの観点から考えてみよう」と思いをはせてみると、見えないところでの成長が見込めると考える。
ユーザーが受入テストの段階になって、不満を持ったとしても、その不満がプロジェクトの課題になることは相対的に少ない。もちろん、それまでレビューを重ねて、工程完了判定クライテリアできちんと報告をし、プロジェクトマネージャーを始め各方面の承認を得て、スポンサーも納得しているから、ということはある。
しかし、そもそもの話をすると、画面を作り直すことは、画面を作り直すことだけにとどまらず、データベースそのものが変わってしまう。そうだとしたら設計書を書き直さなくてはならないし、いやそもそも要件定義からやり直しとなるけれども、それはだれがコスト負担するんだという不毛な議論になってしまう。
結果的に、ユーザー側がグッと飲み込んでいることも、世の中往々にしてよくあることだ。そして、それが第二フェーズの開発に回されて、追加コストが発生し、やっと新システムに慣れた頃にまた画面が変わってしまうというユーザーにとっては悪循環が発生し、ユーザーは「儲けるはベンダーのみ」と自嘲するが、ベンダーは大して利益にならず、みんな不幸になっていく。
フローチャートとアルゴリズム
さて、フローチャートだ。お客様からある要求が来て、要求を分析し、要件定義を行う。まずは要件定義に、仕様が固まったものを書いていく。項目の羅列になるので、エクセルを使う人が多い。
仕様が大方出尽くしたら、多くのプロジェクトでは、第一弾、第二弾というような、ステップ展開（フェーズ展開）など、予算に応じてスコープを決める。成果物としては、ワードファイルの場合が多いが、業務要件定義書・システム要件定義書がアウトプットとなる。ここまでの責任は、発注主、つまりお客様側にある。
システムベンダーは、あくまで支援だ。基本設計以降が、システムベンダーの受託開発の範囲となる。
フローチャートとアルゴリズムは表裏一体のものであり、要求を実現するために技術者が理解できるよう書き起こすものがフローチャートとなる。コンピュータは０か１かで判断するので、分岐記号であるダイヤは、基本的にそこから２種類の処理が分岐することが望ましい。
経験のあるSEは、フローチャートを起こすと同時に、頭にコーディングが浮かんでいる。そこに至るまでには、過去に焦って冷や汗をかいた経験や、作ったものが見当外れだったという苦い経験を積んでいるからこそ、コードが頭に浮かんでくるのだ。
すべての学習においてそうであるが、ゆっくり進めても到達できない目標を、速く進めることはできない。
英語の長文だって、ゆっくり進んだら、構文が取れる、という、英語を使う現地の人とは異なるアプローチが、日本では確立されていて、その構文を理解することで、最終的には速読につながる。
プログラムの学習も、開発工程の学習も、最初はゆっくりと進める。考えたり悩んだりする時間が８割、作業する、実際に手を動かす時間が２割という感じだ。
慣れてない人は、自分が時間をかけることに対して、「カタチあるものを生産していないと、サボりと捉えられるのではないか」という恐怖症から、学習の工程を飛ばしたり、理解できていないまま確認テストに進んでしまったりするが、確認テストでバッテンがついて慌てて振り返りをするのならば、自分なりのゆっくりしたペースで進めよう。
フローチャートの書き直しは結構辛い、ひとつ論理的なボックスが抜けていて、有識者やセンパイがそれを指摘して、いとも簡単に「修正しておいて」と言うが、線の長さなどを短かくする、という小手先の修正をしてはいけない。設計書の類は、組織の文化としてずっと残り続け、類似のプロジェクトを運営する際に、工数見積の根拠となる（経験法見積という）。
よって、作業者本人だけが、「このフローチャートにひとつボックスを追記するよう指摘されたけど、俺はコーディングするときにそのことを忘れないから大丈夫」というような判断をすると、未来の他の技術者が設計漏れを起こす原因となってしまう。
フローチャートと画面設計書ができたら、両者のリンクを確認しよう。レビューを受ける前に、自分自身で、できれば新しい目で、時間を置いた後に確認すると、思わぬヌケモレが発見される。なので自分の作品をゆっくり推敲する時間を生み出すように、タイムマネジメントをしよう。日々、メールなどを作成しているときも、プログラムを作るときも同じだ。推敲する時間が、品質の向上につながる。小説家でなくても、推敲の時間は大事。
データベースの構造を次に決める。データベースエンジニアでなくても、エンティティリレーションシップを考える。何がキーとなり、どういう正規化が行われれば、お客様が求めるデータを引っ張ることができるのかを整備する。
いよいよ言語に変換していく作業が待っている。現代の主流の開発言語は、上から順に書かれるということではなく、カタマリを作っていって、その相関関係を記述する高級言語だ。研修ではパーツを作ることに終始するかもしれない。
ここで例として、マイクロソフトのエクセルを「初めて」学ぶ人向けの、書籍等の目次を見てみよう。
① ファイルの開き方、閉じ方
② 数字入力、文字入力
③ 罫線と書式設定
④ 日付の設定
⑤ SUM関数
⑥ IF関数
⑦ LOOKUP関数
⑧ ピボットテーブル
⑨ VBA
こんなところであろうか。
書籍等では、例えばパソコンを初めて触った人でも、順次スキルアップできるように、だいたい似たような目次になる。
しかし、20代の人は、高校時代などでもエクセルを触っていたり、Office系ソフトには縁がなくても、タッチタイピングはできたりと、素地があることが多い。そういう人は、ファイルの開き方というのは基礎的すぎて読む気にもならないし、関数も簡単なものならば打てたりするし、昨今ではネットを紐解けば、関数を覚えておく必要もない。AIならば、即座に欲しい関数が文例とともに出力される。
素地のある人は、目次や索引をめくって、辞書代わりに書籍を利用するだろう。言語の学習も、最終的には辞書になるので、全体像をイメージすることが学習となる。
順番に進まないと、ヌケモレがあったせいで先に進めなくなることを恐怖心とする人間の性格は否定できない。
しかしながら、あなたが言語の学習で、順序通りにやっているのにエラーとなる原因は、言語が理解できていないこともあるだろうし、スペルミスをすることが原因となることもあるだろう。
そして人間は忘れる生物だ。記憶は1ヶ月経てば8割なくなるというのは、エビングハウスが忘却曲線で示したが、すべての業務に適用するような関数や定義を具体的に知ることは不可能なので、自分の中で仕分けをし、抽象的な概念にまで昇華することで初めて身につく。
IT業界に飛び込んだあなたは、一生使える言語の知識を身に着けようとしている。始めた当初はツギハギだらけのパッチワーク状態にあった知識が、ジグソーパズルのように徐々に全体像を見せてくる。
一生使える知識の整理が3ヶ月で終わるわけがない。だから焦らないで。そういう開発初心者が経験を得て、あなたのセンパイになっている。
センパイは苦労しなかったのにワタシだけ苦労している、ということはない。みんな毎日苦悩しているのだ。
２.品質管理は、現代でとても重要視されている｜品質は後工程では作れない
―― 品質は最後に頑張るものではない、という前提整理
時は2002年
2002年。世間がシステムの品質に目覚めた年だと、筆者は勝手に思っている。この年にみずほ銀行は3行合併に伴うシステム障害を起こし、その影響はIT業界に多大なものを与えた。
これを機に、金融業界のITシステムに関しては、監督官庁である金融庁のお伺いを立てることになり、そのためには、システム監査と呼ばれる、かつては会計分野のみの監査だけだったものがシステムにも必要になっていき、監査法人は儲かって仕方がない。
システム監査という名称がついた会議は大変な緊張感で包まれ、監査法人の担当者が、キャリーケースにたくさんの書類を詰めてゴロゴロと恭しく会議室に入り、監査を受ける側の、IT部門の責任者たちに数多くの項目を質問する。
それとは別に、大規模プロジェクト中には、監査法人のヒアリングが随時行われ、監査法人はシステム監査の基礎資料となるレポートを大量に作成し、自分たちの存在意義をここぞとばかりに主張する。
彼らは定性的なレポートは作らない。あくまでも客観的、定量的に判断される事項を基に、監査を行う。ソフトウェアの品質に関して、大量のレポートが作られ、例えば、システムリリースが3か月遅れそうという展開が発生してしまった場合、その事態に至った理由等を羅列し、3か月遅れる理由が妥当かどうかを判断し、ＩＴ部門の責任者や経営層に報告する。現場の人間は戦々恐々とした雰囲気の中で監査法人のヒアリングに臨む。
2002年のみずほ銀行のシステム合併の障害は、最大手の銀行のシステムが障害を起こしたということで、しかも直前には三菱東京UFJ銀行も小規模なトラブルを起こしていて、文字通り生死をわかつような事態となった。振込がエラーになったというニュースが出たが、企業間の金銭の授受についてシステムが落ちたら、日本は大混乱だ。
かつて日本がものつくり大国だったころ、トヨタ自動車などをはじめとして、ＱＣサークルが立ち上げられ、小規模ではあるが、どうすればクオリティ、つまり品質を向上させることができるかを検討していたものだ。そして日本製品の品質は、他国に比して非常に高く、1985年公開のバックトゥザフューチャーでも、「日本製なんか使っているから壊れるんだ」というドクに対し、30年後の世界から飛んできたマーティーが「なに言ってんだいドク、日本製が最高品質なんだぜ」とするアメリカンジョークが登場する。
ＩＴシステムの品質に関しては、まだまだ歴史の浅い分野だったので、バグや障害などについて、極めて扱いが低かったが、その文化の末に「銀行がストップする」という事態を招いたことは、日本人がいくばくか安直に見ていた「システムの品質」ということを思い出させて、ものつくり並みに品質を追求しなくては、これもトヨタ生産方式を生んだ日本ならではだと、襟を正すことになった。
品質もそうであるが、モノゴトは大体のケースにおいて、
計画→実行→検証
とたどる。特にプロジェクトに関しては、PMBOKをはじめとして、最大公約数的な手法が定まっている。品質管理のシックスシグマ[1]などはそういう手法の代表例だ。徒にカタカナの手法を自慢することは控えるべきだが、適切なときには自分の引き出しから出せるということが必要だ。
ブラックボックステスト/ホワイトボックステスト
システムを作ったら、ブラックボックスとホワイトボックスの2種類でテストを実施する。考え方はinput→ process→ outputの中で、プロセス部分を黒い箱か透明な箱かでテストする。
システムはソースコードだけではない。ハードウェア／ソフトウェア、外部連結システム、そして基盤に至るまで、複雑に相互に絡み合って、アウトプットを出していく。大きな枠組みでどのようにテストが行われているのか、それを示すのがケースであり、テスト仕様書兼結果報告書である。
現代では、テスト専門の業者があるくらい、テストは膨大なケース数になりつつある。機能・非機能（性能部分に代表される要件）に至るまで、正常系／異常系を含めると、順列組み合わせが等比級数的に増えていくので、全てを技術者単価でできるものではない。よって、機械的なテストに切り替えたり、そのような効率のよいテストツールを開発した企業に外部委託したり、コストが最小かつ期待効果が最大となるように腐心している。
少し脱線するが、現代のゲームのデバッグは大変な様子だ。例えば、ロールプレイングゲームで、水の中を泳げる、という機能がオープンワールドゲームに搭載されると、水際と普通の地面の境界を延々と行き来して、ユーザーにとって、泳げるという感覚がどの画面でも同じかどうかを検証するそうだ。気が遠くなる作業である。
C0テスト
命令網羅とも言う。かつての古いインタプリタ言語のような順番ではなく、高級言語は複雑になっているので、ステップ数も多い。その中で命令系のオブジェクトをすべて1回以上実行し、命令がうまく動いているかを確認するテストである。Ｃはカバレッジ（網羅率）のＣだ。
ゴンペルツ曲線
計画→実行→検証
の計画の段階では、残存バグが時間経過とともにどのような曲線を描くか、摘出されたバグの傾向（トレンド）が平たく、漸近線が平行に近くなるようになる時点はどのあたりかを予測する。しかし、その通りになることは少ないため、実行を通じて、予測を修正していく。
テスト開始当初は、テスト要員も経験曲線がまだ充足されていないので、共通のバグなのか、テストケースに依存するバグなのか、障害として起票する時間も含めて、ゆっくり進み、バグの数は多くなる。最後の方は駆け込みにならないよう、テスト推進側はコントロールしなくてはならない。
アプリの推進がＰＭＯ、テストの推進がテ推、移行の推進が移行推進と呼ばれるが、推進側はマネジメント側なので、企業によって呼び方は異なる。今回のテーマの品質管理の担当は、クオリティのマネジメントオフィスを略してQMOと呼ばれることもある。
最近になって流通している用語だ。これも、いかにシステム開発における品質が注目されているかの証左である。注目されているということは、いやらしい言い方をすれば、金脈が眠っているということだ。テスト専門の業者が跋扈していると述べたが、品質の専門業者もまた、新規ビジネスとして定着しはじめた。第三者評価機関も、プロジェクトにとってはおっかない存在となる。
大きなSIベンダーならば、開発部隊とは別部門で、品質保証部門が設けられ、開発者たちが血道をあげて作り上げたものに、敢えてダメだしをしなくてはならない。言われた方も嫌な気分になるものだが、言う品質保証部門も憎まれ役だ。それはすべて、プロジェクトの円滑な推進のために必要なものだ。
エラー想定
計画段階では、エラーの目標管理数値を定める。もちろん、人の作りしものなので、学者さんが統計ではじき出したエラーの想定がピッタリ適合するプロジェクトなんてありえない。1000のうち６～７の障害を予測していても、前述したようにテスト開始直後は多く出たり、後半になって本来はフラットに近づいて欲しいグラフが、思いとは裏腹に急角度で上がったりする。
大規模なプロジェクトほど人手が不足するので、そこは我々外注部隊の出番が増えることになるのだが、そのプロジェクトで予想されるステップ数は、20本というようなことはない。本数で数えるには物差しが小さすぎるので、1000、つまり1kという尺度で数える。総ステップ数が1Mを超えることも往々にしてある。それに応じて予想される障害起票も膨大になっていく。
マネジメント側は、傾向を確認するために、QC7つ道具の一つである管理図を主に用いる。
3本の線に共通している“CL”という単語は、“コントロールライン”を省略したものだ。Uはアッパー、Lはロワーでそれぞれ上限、下限を示す。例えば２％という管理のラインを定めて、統計だからぶれることもあるので、プラスマイナス（±）0.5％まで管理上許容するのであれば、UCL（管理上限）は2.5％だし、LCL（管理下限）は1.5％となる。
ここから外れるデータは特異点と呼ばれ、たまたまなのか、属人的な要因なのかを調査するというアクションが必要だ。製造を担当した要員が、実はその言語に慣れていなかった、そして他のメンバーはプロ並みだった、などの特性要因があるかもしれない。この例では、障害（バグ）も指摘も多くなる人が1名だけいる、ということになる。全体の平均値には微々たる影響かもしれないが、分散を見てみると、特異点が浮かび上がってくる。それを課題と捉えるかどうかをマネジメント側で判断せねばならない。
耐久テスト/ネットワーク負荷テスト
機能・非機能だけではなく、インフラ回りのテストも行う。皆さんになじみがありそうなものだと、モンスターハンターという恐竜狩りのゲームがあるが、新シリーズが発売される数か月前に、耐久テストやネットワークの負荷をテストするため、時間を限定し、消費者にログインしてもらって思う存分負荷をかけてもらうテストがある。
消費者は、ただ、新しいゲームを体験したいだけである。しかし、ゲームを提供するインフラ側から見ると、自社で作成したバッチコマンドを使って過剰な負荷をかける、というような、机上のテストよりも、実際に、しかも想定できない使用方法を試してくれるのが消費者だ。「何がトラフィックを邪魔していたのか」「まさかその操作をあんな場面で行うなんて」などを振り返ることができる「検証」として、有益なデータを得ることができるメーカーにとってメリットだらけのテストだ。お金を払っていないのに、バグを見つけてくれるという、フリーの概念を活用した、Win-Winの関係にあるテストである。
バグ収束曲線/TAT
テストケースを作成する技術者の作業と並行して、マネジメント側はバグがどのように収束していくかを明確に示す必要がある。もちろん、計画段階では精緻な予測は不可能である。机上の計算であっても、➀解決できるバグを発見し、②そのバグを修正し、③もう一度テストが完了するまでの平均期間を定める。行って帰ってくるという意味を込めてターンアラウンドタイム（TAT）と表現し、通常は日数を単位に取る。
検知予定のバグ数で導いた曲線と残存バグ数が負の相関のグラフとなり、バグ数から遅れることTAT の日数分、右にずれたもう一つのグラフが出来上がる。このグラフと実績のグラフを見比べて、マネジメント計画を立てるのだ。
工程完了判定
テスト工程が終わったら、設計フェーズと同様に、工程完了判定をプロジェクトに対して行い、ウォーターフォールならば、一度承認を得ないと、先に進めない。そして、2002年のみずほ銀行のシステムトラブル以降、システムリプレイスに対して監督官庁への報告が必須となったことを背景に、システム監査の目が行き届いていて、工程完了判定のみならず、システム監査側のお認めをもらわないと、プロジェクトが先に進まない展開が昨今顕著である。
製造側技術者と管理側は、利害を同じくする場合も、対立する場合もある。机上のプランだけ振りかざすマネジメントは嫌われるので、是非技術者視点と管理者視点の両方を持ってほしい。
工程完了判定、カタカナで言うとExitクライテリアは、通常は各チーム（アプリ、基盤、移行など）のチームPMOが作成することが多い。開発を担当するチームメンバーが100人いれば、PMOという集計係とも管理者とも取れる便利屋は10～12％必要とされるので、10人程度要員がいる。
クライテリアと呼ばれる鑑用紙そのものは、フォーマットをプロジェクトマネージャー（PM）側が作成し、定量的な目標値を各々のチームで定め、その工程内での達成度を算出する。例えばアプリチームで、詳細設計の工程で10,000本のプログラムのステップ数を製造し、バグの残存件数を０にする、というような形だ。
ここで締め日という概念について記述する。今日の社会人にとって、週という概念は大変重要なものになっている。よって、週の稼働日数5日間の繰り返しの中で、ある一定の曜日の、多くは18時を以て締め日とする。それまでに5日間の計画と実施内容、つまり予実績をWBSに基づいて技術者は入力する。
一度に大勢の人間がアクセスするので、Excelの表一枚では競合ばかり起こってデータベースとして成立しない。よってRDBMSと呼ばれるプロジェクト管理ツールとデータベースを兼ねたものを、たいていのプロジェクトでは具備していて、そこからデータを前回締め日から今回締め日まで抽出し、Excelを使って集計を行い、プロジェクトマネージャー報告用の資料となる。これが進捗報告だ。
そういう毎週の蓄積が、「エビデンス」となって、クライテリアの証拠として付属資料となる。同時に課題管理表や、リスク管理表、障害レポートなど、種々のエビデンスが文字通り山のように集められ、工程完了判定時には、プロジェクトマネージャーの机に、キングジム数冊分の証拠資料が集まる。
もちろん、全てをプロジェクトマネージャーが目を通すわけにはいかない。基本的に、プロジェクトマネージャーは時間を持っていない。プロジェクトに対する責任を負うということは、同時にスポンサーや金融庁などへの報告義務を負うということだ。
品質報告書もエビデンスとなる。第三者評価も同様だ。そして、そのエビデンスにリンクを貼るような形式でクライテリアが完成し、表題部に大きく
「〇（次工程の準備OK）」
「×（次工程に進めない）」と書かれる。
〇を付けるのも×を付けるのも勇気のある一大イベントだ。そして、全チーム（アプリ、基盤、移行など：アプリチームの中に細分化されたサブチームが20ある、なんてこともザラだ）が〇を出して、かつ次工程の準備が整ったら、製造・単体テストの工程をエグジット（出口）して、次の統合テスト（インテグレーションテスト：IT）に進める、というわけだ。いろいろ表記は揺れるが、完了判定はそのような形で行われる。
すぐさまスポンサーへの報告、金融庁への報告などがあるが、これはプロジェクトマネージャーが胃を痛めればいいだけなので、今のあなたはただ祈っていればよい。
技術者もつらいが、マネジメント側もつらい。マネジメント側は全体を見るからつらいが、技術者は直面するエラーと闘わなくてはならないからつらい。
👉第十二章 移行は、すべての結果が出る日だ
【 固定リンク 】
プロジェクトマネジメントは、言葉でできている
