こんにちは、エンジニアのウエです。Timers inc.では、プロダクトマネジメントの役割を担っています。理想とするチームは、皆が納得した仕事に集中し、ビジネスに貢献し、そして余暇を十分に楽しむ集団です。アジャイルやウォーターフォールのような開発論、リスク管理手法やミーティング技法などは、その目的のための手段であると考えています。

では本題へ。

盗まれたとんでもないもの

あなたの心時間です。

15年近く前になりますが、私自身は「今日もミーティングで一日が終わってしまった」という経験がよくありました。そして残念なことに、参加しているミーティングや自分自身が開催しているミーティングは以下のような状態も多く、満足いく時間の使い方がなかなかできませんでした。

ミーティングの悪い現象

内容の割に時間だけがかかる
何を目的としているのか、曖昧なままミーティングが進行している
ほとんどが配布資料を読み上げるだけ、それ以外に得られた情報は極わずか
自分には関係ないとばかりに内職をしている参加者がいて必要なことが共有されない

過去、自分自身も見よう見まねで漠然とミーティングを開催していました。上記のような現象にぶつかり、対策としてアジェンダ書いたりその場で決定事項書いたりファシリテーションについて学んだり書籍に書かれている内容を実施しました。経験を積めば少しこなれてもきました。

でも「うまく時間内にそれっぽい進行することはできたけど、中途半端な結論になる」という悪い現象が現れました。本来ミーティングには目的があって、集まって意味があることを皆で達成するためにあるべきだとは思ったものの、うまく皆の知恵を集めてゴールにたどり着けた実感がありませんでした。

もともとしゃべることは不得意でミーティングには苦手意識もあり、場当たり的な改善ではこれがうまく解決できませんでした。

改善へのアプローチ

うまくいっている人には何か暗黙の了解があると仮定し、観察やヒアリングを通して「暗黙の了解」の言語化と抽象化を試みました。これは自分自身の整理のためでもありましたが、次から次へと新たなメンバが成熟していないミーティングを運営する状態が続いては意味がないので、組織全体の向上につなげる目的もありました。

うまくいっている人の「暗黙の了解」の言語化

私自身が観察した範囲で気がついたのは大きく以下の3つでした。

ミーティングの位置付けを事前に個別に説明して回って微調整している
位置付けごとにミーティングの進行方法を変えている
ミーティングに参加する人にお願いしたいことを明確にしている

このそれぞれを説明します。

ミーティングの位置付け

一口にミーティングと言ってもいろいろありました。自分の参加したミーティングを思い出して、位置付けを以下のような形で整理してみました。

問題解決
意思決定
利害調整
ブレインストーミング
知識伝達
報告(問題提起)

他の説明もしたいところですが、発散するのでここでは問題解決を例に説明を続けてみます。

問題解決は、トラブルやお客さんの困っていることを前に、解決すべき問題を考えて解決方法を決めることが位置付けになると考えています。すぐに解決できる場合はミーティング中や直後に実行して終わりますが、時間がかかる場合は人を集めて協力して解決するケースもあると思います。その規模が大きくなってくると、作業や役割を整理して、どんな段取りで行うかの計画も整理して、コミニュケーションやリスクの鑑みながらプロジェクトとして推進されていくという理解です。

ミーティングの進行方法（例：問題解決）

例えば上記のうち、問題解決ミーティングの位置付け（ゴール）は、対応方針について合意することだとすると、その合意に至るためには、皆が今の問題と問題が解決した状態について同じ認識に至ることが最低限必要だと考えました。

手段としてはAsIs/ToBe/CanBe定義やギャップ分析などの思考フレームワークやベストプラクティスを参考にできそうでした。 AsIs/ToBe/CanBeとは以下のような現状、あるべき姿、現実解の概念です。現状とあるべき姿にはギャップがあります。 f:id:timers-tech:20170803111537p:plain

このギャップには原因があり、原因を生んだ問題点があります。その問題点を解消する方法を考えます。

ステップとしては下記のように進めることを考えました。

AsIs(現状)を理解する
ToBe(あるべき姿)を明らかにする
AsIsとToBeのギャップの原因を発見する
原因に対する問題点を定義する
問題点を解消する対応案を考える
実施可能な対応案から、CanBe(現実解)を定義する

参加する人にお願いしたいこと（例：問題解決）

前述のステップを進めるための参加者の役割は、例えば下記のように定義できます。

問題を抱えている人
- AsIsとToBeを定義する
- CanBe定義の議論を主導する
参加者（有識者）
- ToBeについて意見を交換し、AsIsとの差を埋めるための解決策の議論とCanBe定義に参加する。

特にうまくいってやっている人はこの事前準備を行っていて、下記の段取りを事前に整理していました。

AsIs/ToBe/CanBe定義と解決案（複数）
解決案の評価とブレイクダウンを相談
その他、未決定事項のたたき台を作成する（大まかなスケジュール/体制/各メンバに期待すること）

まとめ

事前にある程度の型で検討をすることで、その場で皆が初めて考え始めてしまうようなことはだいぶ減りました。必要な段取りや役割を共有することで一足飛びに手段ありきで議論が始まってしまうことも減りました。事前に考えうる範囲での網羅や検討をすることで「中途半端な結論に終わる」と感じるミーティングも減りました。

上記のようにミーティングについて考えていくうち、下記のような抽象化に至りました。

ミーティングにはゴールが必要である。
ゴールに至るにはシナリオが必要である。
シナリオを実施するには協力する参加者が必要である。

これらの段取りは「ミーティングにはデザインが必要である」と言い換えてもいいかもしれません。

ちょうど、Timersではミーティングについて皆の興味が高まり、勉強会として上記の考え方を話してみました。題材にしたのはキックオフミーティングです。チームが立ち上がる時期はマネジメント上も多くの注意を払う時期であり、プロジェクトの最初のミーティングは重要なミーティングです。

課題感を持っているメンバも多かったため、実践的なやり方とのギャップをディスカッションすることができました。ディスカッションの過程では「そもそもこれまでキックオフという言葉に馴染みがなかったので前提が全く違った」「プロジェクトのキックオフとスプリントのキックオフでやることの認識に差があった」などの気づきが得られました。これらのギャップを言語化してフィードバックを得ることでより良い一歩を踏み出せると考えています。

また一つ組織が進化できるよう力を尽くしたいと思います。