議事録インデックスシート(仮)で炎上回避（できたらいいね）

前回の「議事録を制するものはプロジェクトを制する（かもしれない）」で、議事録の書き方と私の Tips を紹介しました。
今回は、作成した議事録をより効果的に使う方法を紹介します。

議事録を読み返すの面倒くさい

後から議事録を読み返すのは面倒くさいですよね。メールでやりとりされていればまだマシですが、それがWordやExcel、もしくはPDFになってたりすると本当に面倒くさくて、議事録を読むこと自体が嫌になって、僕の脳内がプロジェクトの本棚だ、さあ検索しよう！となってしまうかもしれません。

（Windows7 以降はファイルエクスプローラーでファイルを開かなくても内容を確認できるのでいくらか楽になってます。ちゃんと議事録を保管してればね…。）

読み返す時はどんな時？

議事録を読み返す時ってどんな時でしょうか？　どんな目的で読み返しますか？　多分、何らかのトピックについて、どのようなやりとりを経て変化をしていったのか、その過程を確認するために読み返すのではないでしょうか。だとしたら、トピック毎に書き分けておけば短時間で過程を辿れるかもしれない！と思ったので、専用のシートを作りました。それがこちら。ちなみに名前はまだありません。とりあえず「議事録インデックスシート(仮)」としましょうか。

実際には、私が使っていたシートとはレイアウトや項目が若干違います。（項目が説明のしやすい順番になっています）

図「議事録インデックスシート(仮)」 

使い方は簡単です。

1. 議事録を書く
2. 完成した議事録を読み返し「打合せにより決まったこと」を中心に、シートにマッピングしてゆく。あわせて日付も入力する。

以上です。簡単ですね。慣れれば15分もかかりません。これを行うことで、プロジェクトの変遷を簡単に辿ることができます。では、シートの各項目について説明をしましょう。

シートの説明

前提-1 誰が使うのか

最初に断っておきますが、私がプロジェクトに関わるのは下記の立場です。

• プロジェクト営業担当として
• 調達担当として

私が開発チームと一緒になって開発をすることはまずあり得ませんが、お客様やパートナー各社との調整は随時発生するので、プロジェクトの全体観は常に把握している必要があります。ただしプロジェクトの全体観はチームのメンバーにも把握してほしいので、これから説明することは開発者にも理解してほしい内容です。

前提-2 プロセスについて

開発プロセスには様々なものがありますが、ここではPMBOKの5つのプロセスをベースにします。これはどのプロジェクトでも共通する考え方です。

図「PMBOKの5個のプロセス群」

http://2020hindsight.cocolog-nifty.com/blog/2012/07/pmbok-3e14.html

立ち上げ

営業はプロジェクトの「立ち上げ」で多く関わります。この時に発生する情報はプロジェクト計画の起点になります。

計画

「計画」時は、契約を含めてプロジェクトが持つ条件や制約をチームに伝えなくてはなりません。また要員計画によっては要員調達の計画も必要になります。いつ頃にどういったスキルセットの技術者が必要なのかという見通しがわかれば事前に根回しができるのでスムーズに調達ができます（逆に言うと急に頼まれると困ります）。

実行

この時はそんなにやることはありません。上手くいってればの話ですが。

監視コントロール

プロジェクト中は「監視コントロール」の視点で関わることが多いです。プロジェクトが「立ち上げ」、「計画」時に定めたとおりに健全に運営されているかをチェックし、必要であれば是正のために営業的に動きます。

終結

チームがプロジェクトの完了条件を正しく満たしているかを確認します。例えば、成果物の認識がズレていたりしたら請求ができなくなるのでヒジョーーーに困ることになります。ここ、重要です。

これらの活動は、やっているのは私だけど、プロジェクトにかかる契約を始めとする条件や制約、完了条件は仕事をする上で「全員しっかり把握して当然」の話です。「全員しっかり把握して当然」の話です。大事な(ry。

しかし当然すぎるので、「もちろん知ってるっしょ」とか「後で仕事しながら徐々に説明すればいいっしょ」みたいにやってしまうと後で痛い目に合います。全員がしっかり把握しているかどうかの確認は重要です。

全体を見えていない人は、全体を見えている人にとっては不可解な行動をとることがあります。しかし全体を見えている人の多くは、見えていない人の不可解な行動の理由がよくわかっていません。登山と地図の関係に置き換えればわかりますよね。

このシートで扱う情報は「全員しっかり把握して当然」のレベルのものだけです。ここの理解が揃わないと、チームや周囲の関係者の活動がチグハグします。その結果が請求書出せないとかだったりすると全員困りますよね（これはお客様も困る）。

「議事録インデックスシート(仮)」の各項目の説明

「議事録インデックスシート(仮)」の項目は下記です。

 顧客名　……　(1)

プロジェクト名　……　(2)

担当者名　……　(3)

プロジェクト（システム）の目的、背景　……　(4)

スコープ　……　(5)

・機能のスコープ　……　(6)

　-実行環境　……　(7)

　-非機能要求　……　(8)

・システム構成上のスコープ　……　(9)

　-技術的な特記事項,制約　……　(10)

・作業のスコープ　……　(11)

　-開発時の体制/調達　……　(12)

　-時期　……　(13)

・成果物のスコープ　……　(14)

　-プロジェクトの完了条件　……　(15)

契約、支払いに関する特記事項　……　(16)

予算　……　(17)

営業活動におけるステータス　……　(18)

その他のトピック　……　(19)

今後の活動　……　(20)

これらの項目に対して、プロジェクトの「立ち上げ」の際に情報を収集して記入します（もしくは自分が関わりはじめたら）。以降、何か変化がおきたら前述の「使い方」に従って更新します。

(1) 顧客名

お客様の名前を書いてください。お客様の先にプロジェクトの運営に影響力をもつお客様が別にいるのならそれも書いておいたほうが良いでしょう。

(2)プロジェクト名

プロジェクトの名前を書いてください。ただし、プロジェクトの名前はプロジェクト中に変更されることもあります。製品名やサービス名も書いておくと良いかもしれません。

(3)担当者名

お客様の名前と「役割・立ち位置」を書いてください。

(4)プロジェクト（システム）の目的、背景

お客様の業務を正確に把握するのはちょっと難しい時もあるのですが、目的や背景は「そもそも」の話なのでしっかり書いておきましょう。どういった効果を見込んでいるのか、オペレーションコストやランニングコストを下げるとか、新規ビジネスとして展開して顧客を何万人獲得する、新しい技術の検証を行うといった目的が必ずあるはずです。もし、プロジェクトの途中でそれらを達成する見込みがなくなった場合は、残念ですがプロジェクト中止の判断が下される可能性が生じます。営業としてはその辺りの予兆は掴んでおきたいところです。

もし、そういった効果の指標などがまったくない場合やまったく教えてもらえない場合はどうするか？　その時は毎日、神様か何かに祈ることになるかもしれません。（残念なことに、そういった指標がないプロジェクトはあります。あっても教えてもらえないことも多々あります）

(5)スコープ

ここからスコープについてわかる限りの情報を記入します。一口にスコープといっても4種類あります。

• 機能のスコープ
• システム構成上のスコープ
• 作業のスコープ
• 成果物のスコープ

(6)機能のスコープ

「機能のスコープ」は「ユーザー視点のスコープ」と考えても良いでしょう。アプリケーションは顧客のニーズを満たすための機能の集合なので、どういった機能を実現するかという「機能のスコープ」があります。「機能のスコープ」はよく一般的に言われる（意識される）スコープです。

(7)実行環境

実行環境が増えるとそのままテスト工数の増加に直結します。ですので、プロジェクト立ち上げ・計画時点でどの環境での動作を保証するかといった制約をお客様にご了承いただく必要があります。特にモバイルアプリの開発プロジェクトなどでは要注意です。

(8)非機能要求

レスポンスタイムや処理量など、パフォーマンスに関する条件を記述しておきます。

ちなみに、BABOKガイドVer2.0 によると、「非機能要求」という用語を使えるのはソフトウェアアプリケーションに対してのみであり、場合によっては「サービス品質」という表現もあるとのことです。

(9)システム構成上のスコープ

機能を3層アーキテクチャで実現するのであれば、ユーザー・インタフェースの「プレゼンテーション層」，データの加工処理を行う「ファンクション層」，データベースにアクセスする「データ層」があります。もし、ファンクション層、データ層は既存システムをそのまま使い、ユーザー・インターフェースのデザインだけ変更するのであれば、スコープはプレゼンテーション層となります。しかし、機能を実現するためにユーザー・インターフェースの変更だけで済まないのであれば、スコープはファンクション層、データ層にもおよぶかもしれません。もしくは外部システムとの連携や、レイヤー毎に作業分担をするのであればインターフェースの仕様を誰が決めるのかといったこともスコープの対象になってきます。これをシステム構成上のスコープと呼んでいます。

(10)技術的な特記事項,制約

OS、DBMS、言語、SDK、フレームワーク、デプロイ先、通信方式、等々…。まったく指定がないことはありえません。可能な限りの情報を聞き出しましょう。バージョンも必須情報です。

(11)作業のスコープ

作業スコープは、機能スコープ、システム構成上のスコープのどこを誰が担当するのかを記述します。更に付随する作業、例えばテストデータは誰が用意するのか、要件定義、基本設計、詳細設計、実装、テストのそれぞれのフェーズで誰が何を担当するのか、そういったことを記述します。

(12)開発時の体制/調達

どういった職種の人が必要かーといったことを書いておきます。社内のリソースで足りないなら、いつごろからどういったスキルセットの人が必要になるのかも書いておきましょう。

(13)時期

いつごろキックオフをしていつまでにリリースをするのか、作業フェーズのマイルストーンはいつ頃に設定されるのかを書いておきます。

悲しきかな人月商売。仕事が請けられるか請けられないかは、人的リソース次第です。

(14)成果物のスコープ

そして、プロジェクトの作業を通じてどういった成果物を用意する必要があるのかを記述します。中間成果物に対する作業量が多ければ見積もりに影響します。

(15)プロジェクトの完了条件

何をもってプロジェクトを完了したとみなすのかを記述します。前項に成果物のスコープを記述していますが、成果物を納品したら当然、検収がまっています。検収期間の長さは請求タイミングに影響するので、これも把握していて当然の情報です。また誰が検収を行うのかも重要です。ユーザー部門による運用テストを兼ねる場合、私達のような開発企業にとっての当たり前と思っているシステムの常識が通用しないことがあります。またシステムの規模がそれなりに大きい場合、バグ0がリリースの条件になっていたりすると、いつまでたってもリリースできない事態に発展しかねません（お客様は「バグゼロに決まってるだろ」と言うでしょうが…）。この場合はバグ収束率◯◯%という指標が必要になります。

開発をして終わりなのか、カットオーバー（サービスイン）までして終わりなのか、あるいはお客様に対するスキルトランスファーまでやって終わりなのか、もしくは作業終了時に報告書を提出して終わりなのか…。わかってるつもりで進めると後になって地獄の門が開くのでしっかり確認をしておきましょう。

(16)契約、支払いに関する特記事項

ソフトウェア開発における業務委託契約は大きく分けて二つあります。

• 成果物に対して責務が発生する「請負契約」
• 役務に対して責務が発生する「準委任契約」

こうやって表記するとすごく単純で当たり前の話ですが、これらの意味合いと名前がごっちゃになっている人が結構います。なので、委託、請負、準委任といった名前だけて判断しないで、それの意図とするところをよく確認しましょう。

また納品、検収、請求も要チェックです。普通、納品日＝請求日ではありません。

(17)予算

お金です。ソフトウェアの構築にかかる費用の多くは人件費ですが、利用するソフトウェアのライセンス、検証端末、AWSの利用量、AWSの利用量など、プロジェクト完遂までに出て行くお金の項目を洗い出しておきましょう。

(18)営業活動におけるステータス

営業活動におけるステータスプロジェクト全体を通してみると、営業的な活動には下記の活動があります。

• 引き合い
• ヒアリング
• 提案、見積書提出
• 発注
• 契約締結
• キックオフ
• （あれば）中間納品、中間請求
• 納品
• 検収
• 請求
• 支払確認
• 終了

結構いっぱいありますよね。例外ケースには「再見積（再計画）」があります。これらは確実に「お金」に絡むことです。

それぞれの何が終わっているのかを把握するのはもちろんですが、どこまで終わっているかによって、発生する事象へのアプローチが変わることを理解しましょう。ヒアリング→提案、見積書提出の間は、お客様も私達もあらゆる可能性が検証できる時です。何を作る、どう作る。何を使う。どこまでやる。それらはスコープに書いておくのですが、このあらゆる可能性を検証できる時期を過ぎ、発注、契約締結になればそれらはお客様にとっても私達にとっても制約になります。この制約を理解しておかないと、プロジェクトはそもそも仕事として破綻します。予算が決まっているのなら、その予算内でどのようにやりきるかを考えるように、考え方を変える必要があるのです。

制約は私たちの活動を型にはめて窮屈にするようなものに思えるかもしれません。しかしこの制約はお客様にも課せられるのです。それが契約なのです。

付け加えると、制約は自分たちを苦しめるものではなく、利用するものです。

(19)その他のトピック

ここまで扱ってきた項目のいずれにも該当しないような情報があればここに書いておきます。

(20)今後の活動

来週、◯◯の件で打合せをする、とかそういったことを書いておきます。
議事録インデックスシート(仮)の各項目の説明は以上です。

影響しあう4つのスコープ。大事なのは作業スコープ（JK）

機能のスコープ、システム構成上のスコープ、作業のスコープ、成果物のスコープとそれらに付随する項目は、項目としては独立していますが、お互いに相関関係があります。

1. 機能の量が増えた
2. システム構成上のスコープは変らないかもしれないが、他システムと連携したり、実行環境が追加されたら、当然増える可能性が高い。
3. 作業のスコープは確実に増える。あわせてテストの工数も増える。
4. 機能が増えているなら当然、設計書、ソースコード、テストに関連する資料は増える。目録レベルなら変わらないかもしれないがやることは当然増える。

当たり前なんですが、何が変わっても作業のスコープに確実に影響がでます。そして重要なのは作業スコープです。受託的に考えて。

チームを増員しても作業のスコープは増えます。いや作業のスコープというか、単純に作業量かもしれません。コミュニケーションが工数を食いつぶすので、その辺りは効率的にやるように注意しましょう。

まとめ

今回は、書いた議事録を効果的に利用するための「議事録インデックスシート(仮)」の使い方を説明しました。

それにあわせて、議事録インデックスシート(仮)のそれぞれの項目の説明と注意点を説明しました。

議事録インデックスシート(仮)は立ち上げプロセス時から使い始め、計画プロセスの時に、「プロジェクトマネジメント計画書」作成時のインプットになります。

また監視プロセスのツールとして利用することもできます。プロジェクトが健全に運営されているか（計画から大きな逸脱を起こしていないか）を確認することができ、プロジェクトの炎上を防ぐツールの一種になります。

さいごに

議事録インデックスシート(仮)に記述される内容は、プロジェクトそのものの基礎仕様みたいなものです。営業情報、契約条件などすべての情報をすべてのステークホルダーに開示することは難しいのですが、それでも理解しておいてもらわねば困ることは当然あります。そういったことをお客様を含めたチーム全体と、支援をしてくれる人達と共有することで、プロジェクトに関わるすべての人の仕事を円滑にする一助になります。

予想されるQ&A

・何故、Excelなのか？

Wiki を使っても良いと思います。自分およびお客様や使いやすいツールでやりましょう。

レコードがすぐ足りなくなるのでは？

足してつかってください。

まともに書いたら膨大な量になると思うが？

議事録の内容を全てマッピングすることはありません。議事録やその他のドキュメントに一意となるタイトルをつけて、議事録インデックスシート(仮)からは外部参照として記述しておけば大丈夫です。

それでも多くなるようならシートを分割してください(笑)

リスクの項目がない何故か？

どの項目にもリスクがあるはずです。それぞれの項目でどういったリスクがあるのかわかるようにしておけばいいと思います。計画プロセス以降であれば、別途、リスク管理表を作成・管理することをおすすめします。

以上です。