AIニュース11.05 要件定義に生成AIをどう使うか。任せてよい作業と、任せない判断 / 10.29 客先の生成AI利用ルール、参画したら最初に確かめること
ナレッジ約9分で読めます

上流の資料は「前提・制約・未決」を分けて書く

検討資料の「前提」欄には、性質の違うものが混ざりがちです。前提・制約・未決事項に分けて書く型と、会議での使い方をまとめました。

構想や要件定義の資料を作るとき、多くの人が冒頭に「前提条件」の欄を置きます。そこに思いついたことを並べて、本文に進む。よくある書き方です。

ところが数週間たつと、会議でこんな声が出ます。「その前提、誰が決めたんでしたっけ」「それはまだ検討中のはずですよね」。資料を書いた側は、決まったこととして書いたつもりでした。読んだ側は、書き手の仮置きだと思っていました。どちらも悪気はありません。欄の中身が混ざっていただけです。

この記事は、客先に参画して検討資料を書く立場の人に向けた話です。前提の欄を「前提」「制約」「未決事項」の3つに分けて書く型と、それを会議でどう使うかを整理します。

「前提」の欄には、性質の違うものが混ざっている

まず、よくある前提の欄を思い浮かべてみます。たとえば、次のような行が並んでいる場面です。

  • 既存の品目マスタは、そのまま新システムに移す
  • 本番切替は、工場が止まる長期休暇中に行う
  • 帳票のレイアウトは現行どおりとする
  • 海外拠点は今回の対象外とする
  • 外部の物流会社とのデータ連携は、相手側の仕様に合わせる

一見、同じ種類の情報に見えます。でも中身はばらばらです。

品目マスタの話は、書き手が「たぶんこうだろう」と仮に置いたものかもしれません。本番切替の時期は、工場の稼働計画で決まっていて、プロジェクトからは動かせない条件です。帳票の話は、業務部門の誰かが会議でひと言言っただけで、正式には決まっていない可能性があります。海外拠点の話は、経営層がすでに判断した範囲の線引きです。物流会社との連携は、相手の都合で変わりうる外の条件です。

この違いが見えないまま資料が回ると、読む人は自分の都合のよい解釈で読みます。業務部門の人は「帳票は現行どおり、で決まったのか」と受け取り、別の担当者は「あれは仮の話だった」と覚えている。食い違いが表に出るのは、たいてい設計や見積の段階です。そのときには、もう手戻りが大きくなっています。

前提・制約・未決事項を、それぞれこう定義する

分け方はシンプルです。書き手の立場から、次のように定義します。

前提は「この資料は、これが正しいとして書いた」という条件です。崩れたら、資料のどこかを書き直す必要があります。前提は、書き手が置いたものでもかまいません。ただし、誰かに確かめて合意を取るまでは、仮置きであることを隠さないようにします。

制約は「プロジェクトの中からは動かせない条件」です。予算の上限、法令や社内規程、他システムの更改時期、工場の稼働計画、相手先の仕様などがここに入ります。制約を変えたいなら、プロジェクトより上の判断が要ります。資料の書き手が勝手に緩めてはいけないものです。

未決事項は「まだ決まっていないが、決めないと先に進めないこと」です。誰が決めるのか、いつまでに決めるのかが付いて、はじめて意味を持ちます。決める人と期限がない未決事項は、ただの心配ごとのメモになってしまいます。

この3つを分けると、資料を読む人がそれぞれの行に対して取るべき態度がはっきりします。前提には「合っているか確かめる」。制約には「知っておく。変えたいなら上に相談する」。未決事項には「自分が決める側なら、期限までに決める」。読み手が何をすればよいかが、欄の名前だけで伝わります。

パートナー募集日本を代表する大手メーカーなどのプロジェクトを、上流から一緒に動かしませんか。
パートナー登録する→

1行ごとに書いておく項目

分けただけでは足りません。それぞれの行に、少しだけ情報を足しておきます。手間に見えますが、後で問い合わせに答える時間を考えると、先に書いたほうが早く済みます。

  1. 内容:何を前提・制約・未決としているか。一文で、主語をはっきり書く。
  2. 根拠:誰がいつ言ったか、どの資料に書いてあるか。会議名と日付、資料名でかまわない。
  3. 崩れたときの影響:この行が変わったら、資料のどの部分を見直すか。
  4. 確認相手:合っているかを確かめる人、または決める人。
  5. 期限:未決事項なら決める期限。前提なら確認を取る期限。

特に効くのが、根拠と影響の2つです。

根拠が書いてあれば、「誰が決めたんでしたっけ」という問いにその場で答えられます。逆に根拠の欄が書けない行は、書き手の推測である可能性が高い。その行は前提として置くにしても、仮置きだと明記します。根拠を書こうとした時点で、自分の思い込みに気づくことは多いものです。

影響の欄は、読み手に優先順位を伝えます。「ここが違うと、移行方式の章がまるごと変わる」と書いてあれば、相手はその行を真剣に読みます。「ここが違っても、画面項目が1つ増えるだけ」なら、後回しにしてよいとわかります。すべての前提を同じ重さで並べると、読み手はどれも流し読みします。

書き方の例

たとえば帳票の話なら、こう書き分けます。前提として置くなら「帳票のレイアウトは現行どおりと仮定して画面と出力の設計範囲を見積もった。根拠は業務部門との打ち合わせでの発言で、正式な合意はまだ取れていない。変更が入る場合、出力機能の範囲を見直す。確認相手は業務部門の責任者」。未決事項として置くなら「帳票レイアウトを現行どおりとするか、見直すか。決める人は業務部門の責任者。期限は基本設計に入る前まで」。

同じ話題でも、どちらの欄に入れるかで、相手に求める行動が変わります。迷ったら、未決事項に入れておくほうが安全です。前提として書いてしまうと、黙って通る危険があるからです。

書くときにつまずきやすいところ

この型を使い始めると、いくつか同じところでつまずきます。気づいた範囲で挙げておきます。

  • 前提の欄が長くなりすぎる。思いつく条件を全部書くと、誰も読まなくなります。崩れたときに資料の中身が変わるものだけに絞ります。
  • あいまいな言葉で逃げる。「原則として」「必要に応じて」「別途協議」は、前提にも制約にもなりません。どんなときに例外になるのか、誰と協議するのかまで書くか、未決事項に移します。
  • 客先の言葉をそのまま写す。会議での発言は、文脈がないと意味が変わります。「現行どおり」が、見た目のことなのか、項目のことなのか、運用のことなのか。書き手が言い換えて、相手に確かめます。
  • 自分の推測を制約に入れる。「この基盤では難しいはず」は、確かめるまでは制約ではありません。技術的な制約だと思っても、根拠の欄が埋まらないなら前提か未決事項として扱います。

もう一つ、書き手の側の心理にも触れておきます。参画して日が浅いと、未決事項を多く並べることに抵抗があるかもしれません。「こんなにわかっていないのか」と思われそうだからです。

実際には逆です。何が決まっていないかを正確に並べられる人は、プロジェクト全体を見ていると受け取られます。わからないことを前提の欄に紛れ込ませて書くほうが、後で信頼を落とします。未決事項を隠さないことは、上流で信頼される書き手の条件の一つです。

会議では、欄を読み合わせてから本題に入る

この型は、書くだけでは効きません。会議で使ってはじめて意味が出ます。

やり方は、資料の説明に入る前に、3つの欄を短く読み合わせることです。全部を読み上げる必要はありません。影響の大きい行と、今回新しく足した行だけで十分です。

このとき、聞き方に気をつけます。「この前提で合っていますか」と聞くと、たいてい沈黙が返ってきます。沈黙は合意ではありません。忙しい参加者は、よくわからないまま黙っているだけのことがあります。

代わりに、影響と一緒に聞きます。「品目マスタをそのまま移す前提で書いています。ここが違うと、移行の章を書き直すことになります。コード体系を変える話は、いま出ていませんか」。こう聞くと、相手は自分の知っている情報と照らし合わせて考えます。「そういえば、製造部門でコードを統一したいという話があった」と、ここで初めて出てくることがあります。資料の段階で出てきてくれれば、手戻りはずっと小さく済みます。

未決事項は、会議の最後にもう一度触れます。「今日決まったのはこの2つです。残りのこれは、来週の業務部門の定例で決めていただく、で合っていますか」。決める人に、その場で口に出してもらうのがこつです。議事録にも、未決事項の行をそのまま写しておきます。

制約は、上の人がいる場で確かめる

制約の欄は、担当者レベルの会議では確かめきれないことがあります。予算の上限や、対象範囲の線引きは、決めた人が別にいるからです。担当者が「たぶんそうです」と言っても、それは根拠になりません。

制約の行は、推進責任者や部門長が出る会議で、一度は読み合わせておきます。資料の冒頭に置いておけば、わざわざ時間をもらわなくても、説明の流れで確認できます。「海外拠点は対象外、という線で進めています」と口に出しておけば、後から「海外も入れるつもりだった」と言われたときに、いつの時点の合意だったかを示せます。

前提が崩れたときに、慌てないための動き方

上流の検討では、前提はかならずどこかで崩れます。崩れること自体は問題ではありません。崩れたことに気づかず、古い前提のまま作業が進むことが問題です。

前提が崩れたら、まず欄の行を書き換えます。消すのではなく、変更前と変更後がわかるように残します。いつ、誰の判断で変わったかも一行添えます。資料の版が進んだとき、どこで方針が変わったのかを追えるようにするためです。

次に、影響の欄を見て、見直す範囲を決めます。ここで影響の欄を書いておいた効果が出ます。どの章を直せばよいかが、すでに書いてあるからです。見直しにかかる作業が大きいなら、その場で直し始めるのではなく、まず客先の担当者に伝えます。「この前提が変わったので、移行の章を見直します。スケジュールにこれだけ影響が出そうです」。作業量と日程の話を先に出しておくと、後で揉めにくくなります。

準委任で参画している場合、作業の範囲や優先順位は客先と相談して決めるものです。前提が変わって作業が増えるなら、黙って抱え込まずに、相談の材料として出します。前提の欄は、その相談をするときの根拠にもなります。契約や作業範囲の扱いで迷うときは、自社の担当者や契約に詳しい人に確かめるのが確実です。

期限を過ぎた未決事項を、前提に格上げしない

よくあるのが、未決事項の期限が過ぎても決まらず、作業を止められないので、書き手が勝手に前提に移してしまうことです。「決まらないので、現行どおりと仮定して進めます」。これ自体は現場では必要な判断です。ただ、黙って移すと、決める側の人は「決めた覚えはない」と後で言えてしまいます。

移すときは、移したことを伝えます。「期限までに決まらなかったので、現行どおりの前提で進めます。違う結論になった場合は、この範囲を見直します。決めていただく期限を、次はこの日に置き直させてください」。未決事項の行は残したまま、前提の欄に仮置きを足す形にします。決めるべき人が決めていない、という事実を消さないことが大事です。

欄を分けると、資料以外の仕事も楽になる

この型は、検討資料のためだけのものではありません。続けていると、ほかの仕事にも効いてきます。

たとえば、課題管理との境目がはっきりします。未決事項のうち、期限を過ぎて決まらないもの、決める人がはっきりしないものは、そのまま課題として上げる候補になります。どれを課題にするか迷ったとき、欄の行を見れば判断の材料がそろっています。

見積の話にも使えます。上流の作業量を見積もるとき、どの前提で数えたかを書いておけば、前提が変わったときに見積を見直す理由を説明できます。見積の数字だけを出すと、前提が変わっても数字だけが一人歩きします。数字の横に前提の欄を付けておけば、相手も「この前提が変わったから増えた」と納得しやすくなります。

引き継ぎも楽になります。数年単位のプロジェクトでは、途中で担当が替わることがあります。新しく入った人が最初に読むべきは、資料の本文よりも、この3つの欄です。何が決まっていて、何が動かせず、何がまだ宙に浮いているか。それがわかれば、本文はあとから追いつけます。自分が新しく参画した側なら、最初に既存の資料からこの3つを抜き出して整理してみるのも、現状をつかむよい方法です。

次に書く資料から、冒頭に3つの欄を作る

型を一度に完璧に使う必要はありません。まずは次に書く検討資料で、冒頭の「前提条件」を「前提」「制約」「未決事項」の3つの欄に分けてみてください。各行に根拠と影響を一言ずつ添えるだけでも、資料の読まれ方は変わります。

そして、その資料を説明する会議の最初に、影響の大きい行を1つだけ読み上げて、「ここが違うと、この章が変わります」と伝えてみてください。相手の反応が、それまでの「前提でいいですか」とは違うはずです。そこで出てきた一言が、後の手戻りを一つ減らします。上流の仕事は、こうした小さな確認の積み重ねで前に進んでいきます。

#ドキュメント#要件定義#上流工程
Strut
Partners
この記事を書いたのはStrut Partners 編集部

ITコンサルティング会社 株式会社ディシェアー の編集部です。大手メーカーなどのITプロジェクトに上流から参画してきたコンサルタントの知見をもとに、記事をお届けしています。

あわせて読みたい

日本を代表する大手メーカーなどのプロジェクトを、上流から一緒に動かしませんか。

ITコンサルタント・エンジニアの方を、業務委託のパートナーとして募集しています。

パートナー登録する→