本記事では、会議にフォーカスしてお話をしています
一作業者目線の執筆です
「理想論だろ」って思う方も多いと思いますが、一意見として聞いてください
ちにみに...。今回は読書感想文です。結構面白かったのでおすすめ。
今回は...。
大規模開発において発生しやすい事象、「チームサイズの増加による複雑性の悪化」 について言及しようと思います。
特にリモートワークが多い業界という事情もあるので、無視ができない事象だと思います。
現象の整理
まずはどういう現象なのか整理します。
チームサイズの増加による複雑性の悪化って？
どうしても、規模の大きな開発になればなるほど、チームサイズって自ずと膨らみますよね。
企画は△社、デザインは●チーム、アプリ開発は〇チーム、インフラ/ネットワーク周りは□チーム、テストは■チーム、保守は☆チームというような開発を想像していただいたら話は早いかと思います。
自社のみで完結するプロジェクトであればまだいいんですが、協力会社だったり2次受け・3次受けと業務を委託したり、フリーランスの方へ業務の外注をしていたり、と複数の会社を跨ぐ開発を行っている場合はさらに複雑性が増しそうです。
浮上する不満
私はここまでの大規模プロジェクトには携わったことはありませんが、（Drupal開発という特性もあって）比較的中規模・大規模なプロジェクトにアサインすることが多いです。
規模の大きなプロジェクトならではの、「それ意味あんの？」と感じていたことがいくつかありました。
（もちろん今は改善されまてます。）
例えば...。
・この会議にこの人数いる？
・アジェンダがないのにこの人数で集まる意味は？ゴールはどこなん。
・時間も人数もかけて話をしたのに、成果はこれだけかい。
・この件、担当は誰だっけ。
私は、エンジニアとしてプロジェクトにアサインすることが多いです。
会議に多大な時間をかけた影響で、成果物をあげることができないこと多々あります。
正当な理由があったとしても、成果物をあげれてないという事実は変わりません。
申し訳ない気持ちは出てきますよね。みなさんもそうだと思います。
原因はどこに...。
いろんな要因はあるかと思いますが、私は「チームサイズの増加による複雑性の悪化」に耐えれてないからだと考えています。
どんなチームでもサイズが大きくなるとぶち当たる壁がこれなのかなと。
乗り越えられるかどうかは別として。
2枚のピザ理論
これってあれだ。「2枚のピザ理論」とリンクしますよね。
ピザ 2 枚では足りない大きさのチームを編成すべきではない
Amazonが提唱しているんですね。結構面白いんでぜひ記事も読んでください。
生産性の高い会議がしたいなら 「2枚のピザを食べられる人数で」ってことです。
こうなったらいいのに...。と思うこと
2年間現場で開発前線に立って感じたこと。
001. 全体に関わる内容だとしても、会議は絶対に2枚のピザを食べられる人数のみで行う。
ここのポイントは「全体に関わる内容だとしても」です。
- どうしても全員を集めなきゃいけない理由ってなんですか？
- アジェンダと議決内容の共有だけじゃ事足りませんか？
- 形式的にみんなで会議をしてても、本質として会議を行ってるのって一部のメンバーじゃないですか？
（止まらなくなりそうなのでこの辺でにしときます。）
僕としては、正直どうだっちゃいいです。
一作業者なので。
でも、意義のある時間を送りたいですよね。
002. アジェンダと議事録の共有はマスト
会議にかける人数を制限する分、ここの徹底がかなり重要です。
全員（不参加メンバーも含め）がアジェンダと議事録を確認する。必要であれば不参加メンバーも議題の提供・議決内容への提言をする。
これが僕の理想です。
（理想のレベルが低いですか？見えてないだけでできてないチーム多いと思いますよ。）
「そこにコストをかけれない？」
いやいや、この規模のプロジェクトで交通整理を行う人がいないのは致命的です。
003. 現場レベルの「方針確立・擦り合せ」には絶対にファシリテーターを設置する
これもマストですよね。
この会議も2枚のピザ理論は適用されます。
全体の交通整理する人がファシリテーターとなればスムーズかもですね。（負担大きそう）
全てのミーティングの議事録が共有されてさえいれば、「この会議ではこう決めたからもう一度検討し直して。」といったことは起きないはず。
その場合は議事録作った人の責任と思います。
004. 各人の役割を明確化
簡単なチーム構成
- PM（交通整理をする人）
- 仕様/要件確認する人
- 設計する人
- フロントエンド開発する人
- リーダー（レビュー対応含む）
- 作業者 A
- バックエンド開発する人
- リーダー（レビュー対応含む）
- 作業者 A
- インフラ／ミドルウェアの開発する人
- リーダー（レビュー対応含む）
- 作業者 A
こんなに人を投入するかどうかは置いといて、レイヤーに応じて誰が担当なのかは決めておくべきだと思います。
もちろん限界はあるので状況に寄って柔軟に対応すればいいと思います。
会議に誰を呼べばいいのか、という意味でも役割の明確化は必須。
特定の個人への責任の集中や、見えないタスク(名もなき家事っていうんですかね？)の発生を防げます。
005. 会議の開始はアジェンダができてから
リモートワークが多くなった背景もあり、「とりあえず話しましょう。」って意外と多くないですか？
でもよくよく考えてください。
「とりあえず話す」ってなに？
って思いません？
もちろん、話したほうがはやい場合もあります。
ただ、文章読めるように教育されてるんで文章で送ってからでも遅くないはず。
文章に残さないと、週明けにはきっと忘れてますし、他メンバーはなんのMTGをしているか把握できません。
まとめ
例えば...。
- この会議にこの人数いる？
- アジェンダがないのにこの人数で集まる意味は？ゴールはどこなん。
- 時間も人数もかけて話をしたのに、成果はこれだけかい。
- この件、担当は誰だっけ。
少なくとも、私が抱えているような現場レベルの不満は解消できると思います。
もちろん、マネジメント側を経験したことないため、穴があるんだろうなということは理解しています。
ぜひ、そちら側の意見も聞ければ幸いです。（コメント下さい）
現場からは以上です。
ちなみに…。
僕あんまりパーティあまり好きじゃないです。
ピザを食べれない人が出てきますからね。
（翻訳：発言の機会が少なくなり他の作業をする人がでるから。）
2枚のピザをちょうどいいくらいの人数で食べれればいいのに...。と思います。