試験工程の作業の管理については、以前に記事を公開していました。
以前の記事は要望に応じて執筆したものでしたが、試験工程の管理手法しか書いていなかったので、今回は要件定義・設計・製造工程の作業の管理について執筆しました。
今回の記事もウォーターフォールを前提とします。
それぞれの工程の概要については、ウォーターフォールモデルとＶ字モデルを参照してください。
また、今回の記事では、見積もり手法やWBSといった計画段階の手法は対象外とし、実作業が行われるようになった後の管理手法についてのみ書きます。
(1)各工程のトレーサビリティの確認
開発工程は、クライアントと合意を取った要件を元に、徐々に設計や製造に落とし込んで行くという形で進められます。
品質を確保する上で欠かせない観点の一つは、要件から設計、製造への落とし込みの過程で、落とし込みがなされなかった要件や設計が存在しないか、という観点です。
落とし込みの過程で漏れがないかどうかを確認する上では、それぞれの要件や設計の項目について、それが後続の工程で設計・製造行為に対象になっているかをトレースして確認することが重要になります。
視覚的なイメージとしては、以下の図の通りです。
ウォーターフォールの案件を進めていくにあたっては、工程を推進する者が上記のような観点を持つ必要があります。
場合によっては、上記のような確認を、Excelやスプレッドシートのような形式でドキュメントに残した方が良いです。
(2)課題・指摘事項の管理
会議の場で、もしくは各関係者が作業を進める中で疑問や気付きを得たタイミングで、関係者間で検討・対応が必要な課題が発見されることがあります。
また、会議や机上でのレビューを行う中で、確認や対処が必要な指摘事項が見つかることもあります。
品質を担保する上では、これらの課題や指摘を挙げるだけでは不十分であり、それらが計画的に抜け漏れなく対応されるかどうかを見る必要があります。
以下では、課題や指摘を管理する上で、どのような形式でドキュメントを残す必要があるのか、その目的も合わせて書いていきます。
【ドキュメントの形式】
ドキュメントの形式は大きく分けて「議事録」と「管理表」に２つに分けられます。
・議事録
後に「言った言わない」問題のような認識齟齬が発生することを防ぐために、会議中での意思決定の流れを記録に残すために作成するものである。
社外のクライアントや社内の意思決定者（経営層）との会議後に作成するような正式なものであれば、WordやExcelで決まった書式で書く必要がある。
開発者間の会議で個人的・チーム間で用いるようなものであれば、メモ帳やExcelでフリーフォーマットで書いて構わない。
・管理表
前述の通り、工程を進めていく中で課題や指摘が挙がることがある。
その課題や指摘を抜け漏れなく管理するため、Excelやスプレッドシートのような形式で表を作ることもあれば、BacklogやJiraのようなチケット管理ツールを用いることもある。
チケット管理ツールのイメージとしては以下（リンクはBacklogの公式ページ）。
https://backlog.com/ja/lp/
【議事録に必要な情報】
議事録には、会議を特定する情報と、会議での発言内容を記録する必要があります。
具体的には、以下のような情報が必要になります。
・会議のタイトル
必要に応じて目的を併記。
・開催の日時と場所
・主催者と参加者の一覧
・会議の中で用いたドキュメント名
・会議中での発言内容
最低でも決定事項を書く必要がある。
決定事項に至るまでの議論をどこまで書くかはプロジェクト次第だが、通常は、生産性を考慮して、決定事項に至るまでの議論の流れを、発言者の名前と共に要約して書く。
全文を文書形式で残す必要があるプロジェクトは少なく、全文を残す必要があるとしても、録音データの添付で代替する場合が多い。
【管理表に必要な情報】
管理表には、最低限、個々の課題や指摘の内容を書く必要があります。
また、レビューに対して作成されるものであれば、レビューの開催情報を記載する必要もあります。
これらの情報は、記録を取って対応されたかどうかを確認するために必要です。
議事録に記載した決定事項も、その決定事項が実際に実施されるかどうかを確認するために、管理表の形式に落とし込んだ方が無難です。
また、レビューに関しては、品質管理に必要な情報も記載する必要があります。
レビューの開催情報について記載する場合は、以下のように、レビューを特定する情報を記載したり、品質管理に必要な情報を記載したりする必要があります。
・会議のタイトル
・開催の日時と時間の長さ
時間の長さは(3)にて後述する品質管理の役に立つ情報の一つである。
・参加者の一覧と参加人数
参加人数は(3)にて後述する品質管理の役に立つ情報の一つである。
・レビュー対象の成果物名とページ数
ページ数は(3)にて後述する品質管理の役に立つ情報の一つである。
・指摘事項件数
これも(3)にて後述する品質管理の役に立つ情報の一つである。
指摘の数をカウントすれば良いが、挙げられる指摘の中には指摘扱いするべきではないものも含まれるため、それは除外するべきである。
個々の課題や指摘の内容については、以下のような情報を記載します。
・通番やタイトル
見つかった課題・指摘を一意に特定するための情報。
報告書上や会議の場で「『課題のNo.3 顧客検索画面での入力補助機能の検討』の対応状況に関しましては…」といった書き方・言い方をするため、通番と簡潔なタイトルがあると便利。
・発見日と発見者
会議の場を通して書かれたわけではない課題に関しては、発見日・発見者の情報を記載することで、後のヒアリングの助けになる。
・課題や指摘の内容
・課題や指摘の対応方針と対応状況
課題や指摘がどのように対応されるのか、経過を追うために必要な情報となる。
・ステータス
課題や指摘ごとに「未着手」「実施中」「対応確認中」「対応完了」のようなステータスを持つことで、課題や指摘の対応状況を管理しやすくなる。
「未着手」「実施中」のままの課題や指摘が多ければ、品質が低いまま作業が先に進んでいる、手戻りのリスクを抱えた状態である、ということを示唆している可能性があるため、管理の上で注意するべき情報である。
・対象機能
これも管理の上で注意するべき情報である。
この項目に着目することで、どの機能で課題・指摘の対応残が多いのか、どの機能で指摘が多いのかを見ることができ、進捗確認や品質強化が必要な対象を絞り込むことができる。
・対応完了予定日と対応完了日
対応状況を管理する上で役に立つ項目である。
この項目に着目することで、いつ頃に課題や指摘が対応されるのかを知ることで予定を見通しやすくなる、予定通りに作業が進捗していない状況にいち早く気付くことができる、といった利点を得られる。
・指摘の発生原因
レビューにおいては、なぜその指摘が上がってきたのか、背景を確認するべきである。
例えば、「前工程の不良」が多いケースと、「担当者への周知・徹底の不足」が多いケースでは、取るべき対応が全く異なってくる。
（前者は前工程の品質強化、後者は担当者へのレクチャーが必要になる）
また、指摘事項の一覧には、対応を伴わない念押しの確認や、担当者の認識誤りに基づく対応不要の指摘が挙げられることがある。
これらについては、品質管理の対象から除外するよう、「指摘ではない」のような発生原因とする必要がある。
(3)プロジェクト全体を巻き込んだ課題・指摘事項対応
軽微な課題や指摘への対応であれば、担当者が対象ドキュメントを修正しそれを確認することで対応が完了します。
しかし、以下の２つのケースについては、担当者だけでは対処することができず、プロジェクト全体を巻き込む必要があります。
・変更要求
計画変更に伴う新たな予算を確保する必要がある場合
・品質強化
次工程に向けた品質を確保するために担当者に追加作業を命じる必要がある場合
ここでは、プロジェクト全体を巻き込む必要がある対応について、要点を記載します。
【変更要求】
計画自体を変更する必要があり、その変更に伴う予算を確保する必要がある場合に、変更要求と呼ばれる作業が必要になります。
変更要求は、主に、要件定義完了後に、システムを実運用するために新たな要件の追加が必要であることに気付き、その必要性をクライアントの担当者も理解しているような場合に発生します。
変更要求を行うためには変更要求書を作成する必要があり、変更の内容とその背景、変更を行うことのコストと便益、変更を行わなかった場合の影響、等を記載する必要があります。
その変更要求書を元に、クライアント企業若しくは受注企業で決裁権を持つ経営層が審査し、変更を行うか否かを決定します。
【品質強化】
品質強化は、次工程に影響を及ぼす品質問題を発見した場合に発生する追加作業です。
品質問題は、「担当者からの問題提起」「会議でのやりとりに違和感を覚えた管理者による気付き」「管理表や成果物を見た管理者による気付き」等の定性的な要因により見つかることもあれば、レビューにて計測できる品質を示す数値（メトリクス）のような定量的な要因により見つかることもあります。
定量的に品質を見る場合には、以下のような数値に着目します。
・(レビューの長さ * レビューの参加人数) / レビュー対象の成果物のページ数
一つ一つの成果物に対して十分な量の時間をかけてレビューしているか、を示している。
この数値が少ない場合は、レビュー工数を十分にかけられておらず、指摘を挙げきれていない可能性がある。
・指摘事項件数 / レビュー対象の成果物のページ数
一つ一つの成果物に対して実際にレビューで指摘を挙げられているか、を示している。
この数値が少ない場合は、レビュー者の技術力不足、レビューの開催方法の問題等により、必要な指摘を挙げきれていない可能性がある。
また、この数値が多い場合は、成果物の品質が低いことにより指摘が挙がり続けている可能性がある。
効率的に品質強化を行う上では、品質問題を引き起こしている箇所を特定することが肝要です。 品質問題を引き起こしている箇所を特定できれば、その箇所に対してのみ品質問題に対応するための人員を投入した上で、集中的に追加レビューや成果物の作り直しを命じることで、最小限の資源で品質問題に対処することができます。
品質問題を引き起こしている箇所を特定するためには、以下の観点で見ることが鍵となります。
・似た内容の機能に着目する
成果物を作成する際、システム全体としての統一感を持たせるために、似た機能を参考に作成していることが多い。
そのため、一つの機能に問題が発見された場合、似た機能にも同じような問題が生じている可能性が高い。
・成果物を作成した担当者や協力会社に着目する
品質問題は、担当者のスキルや協力会社の参画体制によって引き起こされている場合がある。
スキルや体制の問題が品質問題の根本原因であると考えられる場合は、担当者の再教育や人員交代、協力会社の参画体制の見直し等を行った上で、追加レビューや成果物の作り直しを命じることが有効となる。
・機能の複雑性に着目する
他システムとの連携が多い、実現しようとしている機能が技術的に高度、実現しようとしている機能の業務ロジックが複雑、等の理由で、品質問題が発生しやすい機能が存在する。
そのような難易度が高い機能に対しては、業務面や技術面のスペシャリストを必要に応じて投入する必要がある。
大規模なプロジェクトでは、上記のような形で作業の管理を行っています。
足元で上記のような作業管理を行うことで、品質・進捗・費用が計画通りになるようにプロジェクトを進めることや、計画通りにならない場合に適切に対処することが可能になります。
作業者の立場で案件に参画しているとしても、上記のような知識を元に行動することができれば管理者から重宝されるため、大規模プロジェクトに携わっているのであれば知っておいて損はありません。
コメント