重要なことは一覧に記載させよ。見える範囲は、一覧が決める
itpjstudy
これまでの回で、「トレンド」を把握することが、状況を見える化するために非常に有効だということをお話しました。今回は、そのトレンドを把握するための前提となる「一覧」についてお話します。
何気なく利用している一覧ですが、うまく使えれば、威力は絶大です。一方で、正しく利用できていないと、見える化は全く進みません。今回は、一覧の意義について、深掘りしていきます。
一覧には、全てが載っている
まず、一覧とはそもそも何でしょうか
ひと目で全体が見渡せるようにまとめられたもの
そうです。一覧を見れば、全体が見渡せるのです。プロジェクトでは、全体を見渡すために、色々な一覧を利用します。これらの一覧を利用することで、色々なモノの全量を把握します。
見える化のスタートとして、まず、全量が分かっているということが非常に重要です。当たり前すぎて、意外に忘れがちですが、これが非常に重要です。
プロジェクトにおける主要な一覧
| 成果物一覧 | プロジェクトが作成すべき成果物が全て載っている |
| 業務機能一覧 | プロジェクトが取り扱うべき業務機能が全て載っている |
| インタフェース一覧 | プロジェクトが取り扱うべきインタフェースが全て載っている |
| 開発対象一覧 | プロジェクトが開発すべき機能が全て載っている |
| シナリオ一覧 | プロジェクトがテストすべきシナリオが全て載っている |
| データ移行対象一覧 | プロジェクトが取り扱うべき業務機能が全て載っている |
| 不具合一覧 | プロジェクトが対処すべき不具合が全て載っている |
| 課題一覧 | プロジェクトが対処すべき課題が全て載っている |
さて、「一覧」には全てが載っているとお話しましたが、そこには色々なものを載せることができます。次は、そこを少し深掘りしていきましょう。
何を見たいのかも、一覧で決められる
一覧のすごいところは、知りたい対象が全て載っているだけではありません。知りたい内容（＝管理したい内容）を決められるところです。
例えば、課題一覧では、「どんな課題があるのか」ということだけでなく、検討の状況、優先度、誰が主担当で検討を進めているのか、いつまでに検討を終わらせなければいけないのか等、色々な情報を持たせることができます。
それにより、課題の状況を、より立体的に見える化することができます。
- 課題ID
- 課題タイトル
- 詳細説明
- 重要度/優先度
- 主担当
- ステータス
- 発生日
- 完了日
- 対応期日
- 対応内容/対策 など
さらに、プロジェクトの特性に応じて、管理する情報を足すこともできます。
リーダ
それぞれの課題に、どのチームが関わっているのか、ひと目で分かるようにしたい
メンバ
承知しました。それでは、課題一覧に「関連チーム」という列を追加します。
リーダ
それから、それぞれの課題が、業務課題なのか、システム課題なのか、体制上の課題なのか、どんな属性を持ったものなのか、パッと分かりたい。
メンバ
「カテゴリ」を加えます。そうすれば、どんな種類の課題なのかがひと目で分かります。
情報が多すぎると、管理自体が煩雑になり、課題一覧がきちんと更新されなくなるリスクも高まりますので、なんでもかんでも情報を増やすのは得策ではありません。しかし、プロジェクトごとに、ポイントとなる情報については追加することが、非常に有効です。
一覧の重要性を改めて理解頂いたと思いますが、一覧の効用は、まだまだあります。
トレンド把握も、一覧ありき
以前の回でお話した「トレンド把握」も、一覧があるからこそ出来るもののひとつです。
多くの一覧には、日付の情報が入っています。その日付を利用することによって、トレンドの把握が可能になるのです。
ちなみに、一覧の重要な特性として、全ては載っているが、その時点断面のものでしかない、ということがあります。
「現時点での」すべてが載っている
来週には一覧の行数（対象数）が増えているかもしれないし、ステータスも変わっているかもしれません。
つまり、一覧というフォーマットでは、その時点断面の情報は非常によく分かるものの、時間の経過でどのように変化してきているのかは把握しづらいのです。
そのため、一覧のフォーマットを、折れ線グラフというフォーマットに変えて、トレンドを把握するのです。
ただ、大事なことは、その折れ線グラフも、一覧があるから作成できるということ。まずは、一覧をきちんと管理して最新の情報にしておくということが、非常に大事なのです。
意思を持って、一覧を使いこなす
これまで話をしたように、一覧には色々な情報が詰まっています。そして、大切なことは、この情報を意思を持って活用していくことです。
リーダ
最近、設計変更や仕様変更が多発して、開発作業が遅れがちだ。いつも、設計開発ミーティングのなかで、急に相談されるから、打ち手も限られる。
でも、それらも、もともとは何らかの課題から派生したもののはず。課題一覧から、将来設計変更や仕様変更になりそうなものを識別して、早めに関与するようにしよう。
リーダ
打ち手が遅いのは、設計変更や仕様変更に対してだけではない。この前のステアリングコミッティでも、マネジメントへの共有が遅いと言われてしまった。
マネジメントに関わりそうな課題については、フラグ付けをして、プロジェクトリーダとして早めに入り込むようにしよう。
このように、一覧には、プロジェクトの様々な情報が網羅的に管理されており、色々な活用の仕方があります。
ただし、これには、「一覧に、必要なことが全て書かれてある」という前提があります。そして、多くのプロジェクトで、そうではない実態があるように感じています。
最後に、この点についてお話します。
一覧の運用がうまく行くかどうかは、PMOや事務局次第
さて、以前の回 "プロジェクトの規律はPMO次第" でも、お話しましたが、ルールを徹底するのは、とても大変です。プロジェクトに関わる人達に、必要な情報を一覧にきちんと書いてもらうには、継続的な努力が必要です。
一覧の運用が不完全なケースについて、少し例を挙げてみます。
不具合一覧に、全ての不具合が載っていなかったケース
リーダ
システムテストを止めている不具合すべてに対して、対応方針を決定した。明日から、テストの進捗が劇的に改善するはずだ。
メンバ
すみません。まだ、不具合一覧に記載できていないものが、たくさんあります。
不具合対応を優先するため、一覧への登録が後回しになってしまって...
これは、本当によくありがちなシチュエーションです。現場の対応を優先するあまり、見える化が損なわれている典型例です。
どんなに忙しくても、まず一覧に記入することを義務付けることが大事です。逆に、一覧に記入できていない状態が続く場合は、現場で何か問題が起きていると考えて良いと思います。
二重管理になっていて、全体が把握できていなかったケース
リーダ
システム影響がありそうな課題すべてに対して、対応方針を決定した。新しい仕様変更はもう出てこないはずだ。
メンバ
あ、まだ仕様変更になりそうなものがあります。
設計書のレビュー時に貰ったフィードバックのなかに、たくさん候補が有ります。フィードバック一覧で管理していて、課題一覧には反映してませんでした。
こういった「二重管理」も、プロジェクトでよく見かけます。
現場チームは、自分たちの作業をやりやすくするために、独自の管理シートなどをつくりがちです。それ自体は、悪いことではありません。しかし、本来プロジェクト全体で管理したい枠組みを損なうような場合は、問題です。
何のための一覧なのか、趣旨を繰り返し丁寧に説明することで、漏れを防いでいくことが肝要です。
今回は、プロジェクトで何気なく使われている「一覧」の重要性と効用についてお話しました。
一覧の効用を最大限活用するためには、PMOや事務局の絶え間ない定着化の努力が必要ですが、一覧を使いこなせるようになると、プロジェクトの見える化が一気に進みます。また、見える化ができれば、色々な問題への打ち手も的確にできるようになります。
今回は、「一覧」を取り上げましたが、マスタスケジュールや各種マトリクスなども、同様の役割が期待できます。また別の機会に取り上げたいと思います。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
