会議の質は変えられる ~デジタル化を前に進める問いの構造~

1. デジタル施策の会議で、進捗はなぜ見えにくいのか

デジタル化の取り組みでは、進捗確認の会議が定期的に行われます。投資が行われ、人が動き、外部ベンダーや現場部門も関わる以上、進み具合を確かめる場は必要です。

ただし、デジタル施策の進捗は見えやすい仕事ではありません。製造や物流のように形あるものが順に出来上がっていく仕事では、遅れや滞留が比較的目に入りやすいことがあります。しかしソフトウェアや業務設計は、途中段階の実態が外から見えにくく、会議資料や報告文だけを見ると順調に映りがちです。その裏で、要件の曖昧さ、構想のずれ、運用設計の不足、現場との認識差が少しずつ蓄積していることは珍しくありません。こうしたずれは初期には目立ちにくく、実装や移行の段階でまとめて表面化しやすいものです。

さらにデジタル施策には、前段の判断が後段の制約として積み重なる、という構造があります。ある時点では小さな確認事項に見えても、それがデータ設計や業務フロー、権限設計、例外処理に波及し、後から大きな戻りを生むことがあります。しかも、遅れの原因が技術・業務・組織の層をまたいで絡み合って現れることも多く、技術課題のように見えて実は業務要件が未確定だった、業務課題のように見えて実は部門間の合意が取れていなかった、というケースは珍しくありません。

「打ち合わせを実施しました」「予定どおり進んでいます」という報告が、安心の材料にならない理由はここにあります。進んでいるように見えることと、将来のやり直しコストが減っていることは、別のことなのです。

2. 会議で確認すべきなのは、意思の筋道である

では、会議では何を確認すべきなのでしょうか。

ここで最初に確認しておきたいことがあります。会議で背景や意思を問う目的は、担当者を試すことではありません。施策や組織が描いているストーリーと、現場で起きていることの方向性が合っているかを、一緒に確かめることです。下記関連記事でも論じたように、個々の判断が局所的には正しく見えても、全体のストーリーに沿っているかは別の問いです。会議はその整合性を定期的に確かめる場であり、ずれがあれば早めに修正する機会でもあります。

その目的を共有したうえで、確認すべき内容を四つに分けると整理しやすくなります。

2-1. 事実

何を実施したのか。誰と話したのか。何が完了し、何が未完了なのか。これは土台として必要です。ただし、事実は確認の出発点であって、終着点ではありません。

2-2. 背景

なぜその行動を取ったのか。どの論点が問題になっているのか。「現場責任者と会議を持った」という報告があれば、問うべきは「なぜその会議が必要だったのか」「どの論点を確認したのか」「どのような認識差が見えたのか」ということです。「要件を整理中です」という表現も同様で、何が未確定で、どの判断を待っているのかが見えなければ、状況を正しく把握したことにはなりません。

2-3. 意思

見えてきた状況に対して、どう進めるつもりなのか。何を優先し、何を保留し、どこに支援を求めるのか。ここが曖昧なままだと、会議で課題は共有されても前進はしません。確認すべきなのは「頑張ります」という姿勢ではなく、「次に何を、どう動かすか」という具体的な意思です。

2-4. 次の判断

次のマイルストーンはどこか。その時点で何を評価し、結果に応じてどうするのか。

ここで問いたいのは、マイルストーンを「締め切り」として管理しているか、「条件付き分岐点」として設計しているか、という違いです。多くの場合、マイルストーンは進捗を測る節目として扱われます。しかし本来は、ある評価をした結果、次にどちらへ進むかを決める判断の分岐点です。「その時点で何が確認できれば次に進むのか」「逆に何が見えたら立ち止まるのか」が事前に設計されているかどうかで、マイルストーンの意味は大きく変わります。

この視点は、PoCの設計とも重なります。下記関連記事で論じたように、節目に「何が確認できれば次へ進むか」という条件が設定されていなければ、検証は「やってみた」という記録になりがちです。会議で問うべきは、次の節目の日付だけでなく、その節目での判断条件が設計されているかどうかです。

この四つは、単なる報告の型ではありません。施策のストーリーと現場の意思が合っているかを揃えるための、問いの型です。

3. 良い会議は、支援すべき課題を切り分ける

背景と意思を確認する意義は、理解を深めることだけではありません。課題の性質を見極め、適切な解決経路につなげることにあります。

デジタル施策で起きる課題には、いくつかの層があります。担当部門や推進チームの努力で解消できる課題、たとえば確認漏れ、段取りの甘さ、論点整理の不足などは、改善の意思と再発防止の設計を確認すればよいでしょう。

しかし、すべての課題がその範囲で収まるわけではありません。部門横断の利害調整が必要な論点、現場運用の変更を伴う論点、追加投資やスケジュール変更を要する論点、専門性の高い外部支援が必要な論点もあります。こうしたものは、担当者の努力だけで解決しようとしても限界があります。

加えて、デジタル施策では技術・業務・組織の課題が絡み合って現れることが多いという点を忘れてはなりません。開発の遅れに見えても背景に業務要件の未確定があり、さらにその背景に部門間の合意が取れていない論点が潜んでいる、ということは珍しくないのです。だからこそ、「現場で解ける種類の問題か」「経営の判断や外部の支援が必要か」を切り分けて確認することが重要です。

この切り分けができていない会議は、遅れを指摘し「頑張ります」を受け取る場になりがちです。切り分けができると、会議の役割が変わります。現場で解くべきものは現場に委ねる。部門横断で扱うべきものは関係者を巻き込む。外部支援が必要なら必要性を明示する。経営判断が必要なら、どの判断材料が不足しているかを揃える。こうした切り分けができている会議は、監視の場ではなく、施策を前に進める支援の場になります。

4. 意思を問うことは、マイクロマネジメントではない

ここまで述べると、「そこまで細かく確認すると、現場を縛るマイクロマネジメントになるのではないか」と感じるかもしれません。しかし、背景と意思を問うことは、作業を逐一管理することとは異なります。むしろ、任せるために必要な確認です。

4-1. システムが確認できることと、人が確認すべきこと

タスクの消化状況、期限、マイルストーン、課題票の更新状況といったものは、現在では多くがプロジェクト管理ツールや課題管理システムで把握できます。会議の場で人が時間を使って確かめるべきなのは、そうした事実だけでは捉えきれないものです。

なぜその判断をしたのか。何を優先しているのか。どの不確実性を重く見ているのか。次の節目をどう置いているのか。そうした意思の部分が、施策全体のストーリーと整合しているかを確認することが、会議の本来の役割です。下記関連記事で論じたように、任せることと管理することのあいだには対立ではなく設計の問題があります。意思がストーリーに沿っているのであれば、細かな作業への介入はむしろ減らせます。逆に、作業が進んでいても意思が施策のストーリーからずれているのであれば、早めに軌道修正しなければなりません。会議で確認すべきなのは、行動の量よりも、判断の筋道なのです。

4-2. 会議ができないときの報告設計

会議の時間を十分に確保できないケースもあります。その場合でも、確認すべき構造は変わりません。業務報告や進捗報告にも、事実だけでなく背景と意思、そして次の判断を含める型を持たせておくことです。

報告に最低限含めるべき項目として、たとえば次の四点を設けておくと、会議が短くても判断のポイントをつかみやすくなります。

• 何をしたか（事実）
• 何が見えたか（背景）
• どう判断しているか（意思）
• 次に何を確認するか（次の判断）

この型が定着すると、報告を受ける側も問いを立てやすくなります。また、報告を書く側にとっても、自分の意思を言語化する習慣につながります。会議の質とは、場の時間や頻度だけで決まるものではありません。何を報告させ、何を問い、何を次の判断につなげるかという設計で、かなりの部分が変えられます。

結び

会議の質は、参加者の能力や熱意だけで決まるものではありません。何を確認し、何を問い、何を次の判断につなげるかという構造が、会議を単なる報告の場から、施策を前に進める場へと変えます。

事実だけを確認する会議では、報告は積み上がっても、次の判断条件は整いにくいのです。背景と意思を問う会議では、施策のストーリーとのずれが早めに見え、次の判断を整える余地が生まれます。

会議での問いが変わると、問われた側の準備が変わり始めます。準備が変わると、次の会議で見えるものが変わります。そのゆっくりとした変化が、デジタル施策の不確実性を少しずつ減らし、判断の質を積み上げていく土台になるのだと思います。