もちゅろぐ

iOSやSwift、モバイル設計だったりRailsについてまとめていく

健全なチームの成熟のために自分が意識していること

普段プログラマという仕事をしつつそれ以外のことをしてることもあり、それの一部について考えまとめたもの。

対象読者

  • リーダーやさらに上になりたいがどうすればいいか分からない
  • 新しくリーダーになったけど振る舞いが分からない
  • リーダーとかには興味ないが手戻りが嫌

非対象読者

  • 楽したい人

どっちも大事だけど、どっちにも寄らないよう自分が意識していること

  • しつこい人にはならないように気をつけている(前者)
  • 反対にカオスにならないように指摘や提案して是正も意識してる(後者)

前者を怠ると周囲からうざがられ、なんか前に進んでない感も体感としてある 後者を怠るとコミュニケーションコストがかさみ全体として前に進まなくなる。 エンジニア目線としてはスイッチングコストや議論だらけで仕事にならない。

下記に順番に説明する。

しつこい人にはならないように気をつけている

これを怠る、つまりしつこいと周囲からうざがられ、なんか前に進んでない感も体感としてある

ケース1. 会議時間を無駄にしないために会議での共有事項を指摘する

そのままで会議で共有されても会議の場で背景説明、課題分解、ブレスト、アイデア選択が起こり会議の時間、つまり会議参加者の時間を無駄にすることは目に見えてる。だから事前に出来ることを行い会議では選択だけに集中すべき。と指摘や提案する。

ケース2. 議論において観点漏れ防止や自分のポジション情報提供のために第三者として介入する

ミニマムで進めようと話している所に、「そのミニマムだとこちらに影響するのでミニマムとは呼べない」と指摘し提案する。

邪魔している錯覚がおきる

このようなケース1と2を何度もし続けているとフットワークを重くしてしまったような感覚に襲われる。 なぜなら、話がうまく進んで簡単に済む作業の雰囲気だったけど、自分が指摘したことで作業が増えたからだ。 でも実際に指摘をしなかったら後々で指摘または発覚してより大きい手戻りが起きる。

カオスにならないように指摘や提案して是正を意識する

これを怠る、つまり指摘や是正を怠るとチームのコミュニケーションコストがかさみ全体として前に進まなくなる。 エンジニア目線としてはスイッチングコストや議論だらけで仕事にならない。

先のしつこい人になるのを恐れ流れに任せてしまうと、情報伝達が正しくできず関係者に情報が伝わっていなかったり、全部を知っている人がいなくなったりする。その結果幾度となく対話が必要となり抜けてる観点に関して議論が続く。 そして気づいたら事前に計画的に物事を進めたときよりも開始時間早いけど終わる時間は遅くなる。

無駄な手戻りや伝達フローがゴタゴタはなぜ起きるのか

このようなことが起きるのは、各自自分の仕事で忙しいし、それが自分にとって大事だと思っているからだ。 自分の持っている仕事が周りにどれぐらい影響するかといった逆視点で考える時間を事前にやらないからだ。 当然といえば当然の結果だ。自分の存在意義を出すために担当してる仕事を全うするのはもっともな考えで受け取った仕事を次の人に渡すってのは仕事の基本フローだ。

しかしそれはチームワークという観点においては視野不足である。 下に簡単なポジション別の図を用意した。かなり簡単な図なのでどういった図なのかは見れば分かるはず。

f:id:motom552:20190325223343p:plain

  • これで言うところの作業aまたは作業b担当の目線、つまり来た仕事をこなし次へ回すだけでいると周りの関係者や他人の仕事なんて見えるわけがない。
  • 仕事の規模が大きくなるリーダもそのリーダ目線でいると他ラインの関係者が見えない。

これでは齟齬や手戻り、無駄が起きて当たり前なのだ。 つまり全員自分のポジションよりひとつ上の視野でいないと無駄な手戻りが起きるという事実に気づかないといけない。

それが出来るようになるまでは誰かがカオスにならないように是正し続けるしかない。

チームの成熟度によっては両方不要になる

長いこと同じメンバーで同じプロダクトいると知識を覚えたり、プロセスに慣れてたり、対話や共有などコミュにおいての観点漏れが減り、とても効率よく話が前に進む。 これは何回も体験したことなので自信のある間違いない事実。 アジャイルではこの成熟度はベロシティ安定させる重要な指標となる。 なぜならベロシティ安定について考えると、案件への理解度と必要スキル十分による見積もり精度の向上、イレギュラーや割り込みといった見積もり外の作業やコストを抑えることが重要だと気づくからだ。

チームの成熟度を上げるには土台が強固であること

この成熟度を上げるにはメンバーがコロコロ変わらないことは当然として、チーム内の健全な環境を維持することが前提として大事になる。 健全とは情報フローの確立、状態の見える化、人間関係の安定、スキル差の収束を指す。

そのために自分はカオスとガチガチの間を意識してる

土台が整いチームが健康になるまでは誰かが是正し続けることが重要になる。健全なチームに健全なプロジェクトは宿る。

健全を害することは簡単なこと

  • 会議の資料で時間がないから手を抜いて口頭で話す
  • 効率化ために従来のやり方をぶっ壊す

時間がなくて手を抜くと必要ないから手を抜くは同じ時短でも差は天地並

重要度を理解できていないから手を抜くのと重要度を理解できてるから手を抜いてるのと同じだ。 重要だと分かっているのに時間がなくて手を抜くとか愚かな行為はしないはずだ。通常なら重要ではない他に手を抜くべきだ。

プロセスをぶっ壊すってのは課題や提案にありきであってただやり方を壊すのは停滞と手戻りしかない

現プロセスフローよりももっと効率良いフローを目指すことはとても良いことだが、 だからといって何でもかんでもビルド&スクラッチすればよいというものではない。 通常実務においてうまく動いてるプロセスもあれば動いていないプロセスが混ざっているものだ。 プロセスフローにおいて効率が悪い、時間がかかるといった課題があってこそ効率化を図るべきだし 現プロセスフローよりよりよい方法案があってこそ効率化を図れるべきだ。