どうもgoyaです。

前職で提案して採用された2H5H制のはたらき方について紹介したいと思います。

前職は、大きな現場のチームメンバーとしてお仕事をしておりました。

goyaはメンバーの不満を大切にしたいと常日頃から考えていました。
（もちろん、不満を育てるという意味ではなく、解消・解決して気持ちよく業務を効率化させるという意味です）

チームメンバーは当時10人ほど居たのですが、そのメンバーからは「情報共有が足らない」とか「ミーティングが多すぎる。作業時間が足らない」とか相反するような不満が出ていました。

なぜ、その様な不満が出るのか。

「情報共有が足らない」

まさにその通りなのだと思います。

欠席したり、たまたま離席している間に「雑談から話が盛り上がって、決まってしまった内容」とかが共有されずに、取り残されてしまうメンバーが居ました。

また、レビュー指摘時に「それ、聞いてないよ」なんて事もありました。

レビューで問題を発見できたのは良いことかもしれませんが、状況共有不足は解消しなければなりません。

「ミーティングが多すぎる。作業時間が足らない」

これは、つまり仕事がしにくいという事なのだと思います。

当時、「ミーティングが30分、個人作業できる時間が30分、またミーティングが30分」なんていう状況もザラにありました。

エンジニアの仕事は集中力が必要な仕事ですし、会議と個人作業では頭の切り替えも必要です。
つまり、切り替えが多いと切り替わるまでのオーバーヘッドの時間がかかりパフォーマンスが発揮できなかったり、忘れてしまって「なにやろうとしてたんだっけ？」なんていう状況を生みやすくなってしまうのです。

タスク管理は、各々でやらなきゃいけない部分はあるのですが、チームの問題はチームで解決するべきでしょう。

そこで提案したのが2H5H制です。

2H5H制

当時は、1日の労働が7.5時間でした。

でも、朝礼・PCの起動（Windows Update）・メール確認・今日やることの確認等々していると30分くらい軽く過ぎてしまいます。

1日働けるのは、（定時で上がるとして）正味7時間がいいとこでした。

しかし、1日7時間働けるという前提で仕事を見積もると、「会議をすればするだけ、時間が取られてしまう」「会議のせいで作業が進まない」という感覚に陥るのです。

その様な状況ではストレスも溜まりますよね。

そこで、1日を7時間から2時間（2H）と5時間（5H）に分けて考えます。

その2Hはチームミーティングの時間として決めます。カレンダーに入れて予定として計上します。

個人作業、外部とミーティングなどは極力5Hでやってください。というルールです。

なので、1日5時間働けるものだとして見積もりをお願いしました。

毎日2H、ミーティングする時間があれば「状況共有が足らない」というのは、時間的な側面からは解消できるでしょう。あとは状況共有の仕方を工夫するだけです。

2Hの中で、設計レビュー、コードレビュー、新しい案件の状況共有をします。
また、その2Hの枠の中から毎週水曜日は改善Mtgというのを行っていました。
突発ミーティングも定例ミーティングも2Hに収める努力をします。

「でも、毎日2時間もミーティングって必要なくない？」と思うでしょう。
もちろん必要ないです。

ミーティングが不要だった場合や、早くミーティングが終わってしまった場合は、それはボーナスタイムです。個人の作業時間が増えるのです。

逆にミーティングが2Hで足らない日もあるでしょう。
しかし、明日に行うなどして2Hを極力守ります。
（チームメンバーの作業時間を保証するためです）

この様な考え方なら、

○ミーティングが分散しないので「ミーティングの数が多い」とは思わないでしょう。

○もともと決められたもので、ストレス無く仕事ができれば「ミーティングの時間が長い」という不満も無くなるでしょう。

○1日5時間という見積もりをして、その通りに仕事ができる。むしろ見積もりより実働作業時間が増えるのであれば「作業時間が足らない」という不満も解消できるでしょう。

○毎日最大2時間状況共有ができれば、状況共有不足も大幅に改善できるでしょう。

という事で、チームに2H5H制のはたらき方を提案して採用して貰っていました。

まあまあ、良かったと思ってます。

ただ、この2H5H制が採用できるのはチーム単位でシステムを運用しているとか、そういったパターンの場合です。

現職では、評価のためのチームとプロジェクトのチーム、しかもプロジェクトが複数掛け持ちのマトリックスな形なので、このはたらき方が採用できなかったりするんですが、このはたらき方自体はおすすめです。

Enjoy team building!