• 2026年05月25日
  • blog

インフラエンジニアにおける進捗会議のファシリテーターの役割や重要性への気づき

ただの会議進行だと思っていた自分への反省

こんにちは。製造業関連の AWS インフラ構築・運用を担当しているエンジニアです。

CloudFormation を使った IaC や、CodePipeline での CI/CD 構築、Lambda や CloudFront によるサーバーレス構築など、毎日技術に向き合いながら仕事をしています。

そんな技術寄りの業務の中、毎日行われるチーム進捗会議のファシリテーターを任されることになりました。

正直プレッシャーでしたが、やってみるとファシリテーターという立場から見えるものは思った以上に多く、チームの空気や動きに敏感になる自分がいました。

今回は、インフラエンジニア視点でのファシリテーター経験から得た気づきを 7 つのトピックでお話します。

1. 進捗会議とファシリテーターとは

進捗会議とは、プロジェクトやチームの活動状況を定期的に共有し、進捗状況や課題を確認するための会議です。メンバーそれぞれが担当タスクの進捗を報告し、遅延や問題が発生している場合は、その原因や対策を議論します。進捗会議は、プロジェクトを円滑に進めるための重要な情報共有の場と言えるでしょう。「朝会」なんて言われかたもしていますね。

進捗会議の主な目的は、以下の通りです。

  • プロジェクトの進捗状況の可視化
  • 問題点の早期発見と共有
  • チームメンバー間の情報共有と連携強化
  • 意思決定の迅速化
  • リスクの早期発見と対応策の検討

一方、ファシリテーターとは、会議やワークショップなどの場で、参加者の議論を円滑に進め、合意形成を支援する役割を担う人のことです。ファシリテーターは、中立的な立場で議論を促進し、参加者全員が意見を言いやすい雰囲気を作り出すことが求められます。優れたファシリテーターがいることで、会議の質は大きく向上します。

ファシリテーターの主な役割は、以下の通りです。

  • 会議の目的やアジェンダの明確化と周知
  • 議論の促進と活性化
  • 意見の整理と要約
  • 合意形成の支援
  • 時間管理
  • 参加者間のコミュニケーション促進

今回の記事では、私が担当することになったチームの進捗会議を例に、インフラエンジニアの視点からファシリテーターの役割や経験についてご紹介していきます。

2. なぜ自分がファシリテーターに選ばれたのか

抜擢時の気持ちと不安

ファシリテーターに任命されたとき、正直戸惑いがありました。私はまだインフラエンジニアとしては 3 年目。AWS や CI/CD には日々触れているものの、まだ慣れてきた段階でチームを回す立場を担うとは思っていませんでした。

しかも私はプロジェクトにも直接関わっている立場。現場で手を動かしながら会議の進行もやるというのはかなりのプレッシャーです。

ですが、選ばれた理由を振り返ってみるとこんな点があったのではないかと思います。

  • 現場のタスクや技術的背景を把握している
  • メンバーとの距離が近く対話しやすいポジションにいる
  • 中立的な立場で全体を見渡すバランス感覚がある
  • 技術的な知識を持ち合わせているため、議論の内容を理解しやすい

経験年数よりも、今の立ち位置や日頃のコミュニケーション、そして技術的な理解度が評価されたのかもしれません。事前に状況を把握する癖があったのも、評価された一因かもしれません。

3. ファシリテーターとして学ぶべきことに悩んだ

最初にぶつかったのは、「何から手をつければいいのかわからない」ということ。技術的な設計や実装とは違い、正解が存在しない世界…。

しかも毎日の会議ということもあり、場当たり的な対応ではすぐに破綻することが目に見えていました。

そこでまず考えたのは、前職時の朝会でよく気になっていた内容でした。当時よく思っていたのが以下の5つです。

  • 会議が始まる前に状況を把握していないから、もたもたして遅い
  • 話が長く、要点がまとまっていない
  • 参加者が言いたいことを言えず、本音が出せない
  • 議論が脱線して結論が見えない
  • 意見が対立した場合に、中立な立場を保てない

これらを逆にすれば、「良い会議とはどうあるべきか」が見えてきました。

4. インフラエンジニアがファシリテーターに求められる 6 つのスキル

  1. 事前準備力 会議前に参加者の状況を把握し、スムーズな進行を促す力。アジェンダの作成や資料の準備だけでなく、参加者の意見や懸念事項を事前に把握しておくことが重要です。
    【例】 朝会前に昨夜のアラートやチケット状況を確認しておく。「昨夜バッチ処理でエラーが出ていましたね」と報告者より先に状況を提示し、「今日の作業への影響はありますか?」と問いかけることで、課題の共有と影響範囲の確認を即座に行う。
  2. 論点整理力 複雑な技術タスクの全体像を把握し、要点を絞って会議に持ち込むスキル。技術的な詳細を理解し、議論のポイントを明確にする能力が求められます。
    【例】 各メンバーから出た「NWが遅い」「DB接続に時間がかかる」等の報告に対し、「根本原因は同じようなリソース競合かもしれませんね。今日はまず〇〇サーバの負荷状況の調査に絞りませんか?」と提案し、今日のチームの最優先アクションを明確にする。
  3. 感情の空気読み力 言いたいけど言えない場面で、さりげなく発信を促す力。メンバーの表情や態度から感情を読み取り、適切なタイミングで発言を促すことが重要です。
    【例】 若手が進捗報告で「テストは…順調です」と歯切れ悪く答えた際、「何かハマっていることとかありますか?例えば設定ファイルの反映がうまくいかないとか」と具体例を挙げて問いかけ、言い出せなかった技術的なブロッカーを早期に引き出す。
  4. タイムマネジメント 話が長くなりそうなときに、「それは後で個別に」と切り替えられる判断力。会議の時間を意識し、議論が脱線しないようにコントロールします。
    【例】 15分の朝会で、一人のメンバーの課題報告が詳細な技術議論に発展しそうになった際、「その件は根が深そうなので、朝会後に〇〇さんと別途時間をとりましょう」と介入し、全員が時間内に報告を終えられるよう、会議のテンポを保つ。
  5. 構造化思考 「現状」「課題」「次の行動」を毎回整理して話をまとめる力。議論の流れを整理し、結論を明確にすることで、参加者の理解を深めます。
    【例】 メンバーの報告を聞きながら、「まとめると【現状】デプロイ準備は完了。【課題】性能試験で問題発生。【次の行動】Aさんが原因調査、ですね」とホワイトボードなどに書き出し、チームの認識を揃え、誰が何をすべきかを明確化する。
  6. 中立性 自分の技術的な意見を押し付けず、あくまでパフォーマースタンスでいられること。参加者それぞれの意見を尊重し、公平な立場で議論を促進します。
    【例】 自分のタスクの遅れを報告しつつも、「Bさんの作業遅延はリリース全体に影響してしまいます。私のタスクはそこまで優先度が高くないので、先にそちらのサポートに入りますね」と提案し、個人の都合ではなくチーム全体のゴール達成を最優先する姿勢を示す。

5. 実際にやってみて感じたこと

最初の数日は、ぎこちなさ全開でした。話を遮ることに遠慮して時間が延び、逆に一人が喋りすぎて他の人が黙ってしまう。「ただの司会進行役」では前職時の朝会の二の舞だと痛感しました。

そこで意識を「自分が仕切る」から「チームの対話を促す触媒になる」へ転換。話を構造化して「次の行動は?」と問いかけ、発言が少ない人に優しく話を振る。これを続けた結果、会議がただの「報告会」から「作戦会議」へと変わっていくのを肌で感じました。

メンバーの口から課題だけでなく改善案も出るようになり、チームの一体感が生まれたのです。インフラの構成図を描くように議論の流れを可視化することで、チームのパフォーマンスが向上する手応えを感じた瞬間でした。

6. 結局は慣れと振り返りが大事

ファシリテーションには、技術のように明確な資格や目に見える成果物がありません。だからこそ、日々の小さな振り返りが唯一の成長エンジンになります。私はこれを、コードを改善し続けるように「会議のリファクタリング」と捉えることにしました。

会議後にたった1分、「今日の進行で改善できる点は?」と自問します。時間配分、問いかけの言葉、議論の構造化。この地道なサイクルを回し、勇気を出してチームにフィードバックを求めること。それこそが、知らず知らずのうちにチームの足かせとなっていた非効率な議論をなくし、会議の質を確実に高める唯一の近道だと確信しています。

7. ファシリテーターはリーダーとは違うのにリーダーを意識しだした件

ファシリテーターはあくまで進行役であって、決定権を持つリーダーではありません。

それでもチームの状態を最前線で見ていると、自然と「どうやって良い方向に導こうか」という意識が芽生えてきます。

それは指示や指導ではなく、「気づかせる」「引き出す」「整える」という形でチームに影響を与えていく、もう 1 つのリーダーシップ。それを担えることに今ではやりがいすら感じています。

最後に

AIが議事録をまとめ、タスク整理を補助してくれる時代、会議の運営は確かに効率化されていくでしょう。しかし、だからこそ「人間にしかできないこと」の価値が際立ちます。

ファシリテーションは、もはや専門職だけのものではなく、私たちエンジニアにとってこそ重要な役割です。むしろ構造的に考える力、リスク感度の高さ、冷静な判断といったスキルは、AIが提示するデータやロジックを人間的な文脈で読み解き、議論を導く上で強力な武器となるのです。

もしあなたがこの役割に悩んでいるなら、まずは「話を整理する」「話を聞く」「安心できる空気を作る」ことから始めてみてください。これらはAIには真似のできない、相手の感情や背景を汲み取る繊細な行動です。そして会議前に少し時間を取って参加者の状況を把握することも、人間ならではの配慮を示す重要な一歩です。

ツールが進化しても、チームのパフォーマンスを決めるのは最終的に人と人との信頼関係です。毎日続く会議こそ、その信頼を育むチーム文化の土台となります。だからこそ、そこに本気で向き合うことは、AIに代替されない価値を築くことに他ならないと、私は本気で思っています。

この記事の著者: DTUHブログ編集部

著者の他の記事を見る