back to basics

ワタシ達のプロジェクトチームはいつでも基本に立ち戻ることができる。

ワタシ達のプロジェクトチームは、いつも同じやり方をする。それは、プロセスを自分たちで作るから。でも“いつも”同じではないんだ。しくみが思うような結果を得られなかったり、もっと、簡単なやり方を思いつけばいつでもそのプロセスを変えることができる。

なぜなら、それはそのプロセスはワタシ達がワタシ達チームのふるまいを決めているだけだから。だから、プロジェクトの中で初めてのしくみにトライしたり、プロセスをカイゼンして試してみたりする。

と思っているのはワタシだけか
手順の視覚化を取り入れたり、TiDDを取り入れたり、リポジトリの共有をはじめて大分経つけれど、なぜ、それを取り入れたのか本質を分かってくれているメンバはどのくらいいるのかとても怪しく感じることがある。

“何か”おかしい、という感覚を持つことは大切なことだと思っている。何かを感じようと思わなければ、まだ識別されてもいないリスクを知ることは難易度が高いのだ。トーストを齧った女の子と駅に向かう路上でぶつかるにもきっかけが必要なように、識別できていないリスクを知るにもきっかけが必要なのです。

確かに、違和感を、何か噛み合わない感覚を持ったのは確かなことなので。

そもそも、TiDDやリポジトリの共有や手順の視覚化なんて、自分から取りに行かなくてもメンバなら情報の隔てなく共有できるようにしたくてしくみを導入しているんだ。だ、けれど、それが上手くしくみとして回っていないと微塵でも感じたのであれば、なぜこのようなしくみをしているのか、場を持って話した方が良い時期なのかもしれない。

基本はアナログ
back to basics.　基本に戻るならアナログが良い。いやデジタルから始まっているものなら、デジタルの基本のキに戻ってもいいけれど。

戻る理由が、違和感を感じたふるまう“しくみ”なのであるから、人がふるまうしくみは体感させた方が頭だけで理解するより納得感が高いと思っている。ので、アナログで。

TiDDが“頭”で理解できていても、チケット駆動になっていないならカンバンを使おう。それも壁やホワイトボードを使った人手を掛けた、しくみに。もちろん、TiDDとしてのtracは継続するのだけれど、メンバが触れるチケットは一時的にポストイットに置き換えよう。

視覚で認識し、指で感触を得て、腕を使ってポストイットをタスクの進捗に合わせて動かそう。それを裏では、TiDDに入れておこう。

チームの成長には試行錯誤とトレースが必要で
チームは勝手に育つものではないんだ。アホなマネージャはリーダがいれば勝手に育つしチームの課題もリーダが率先して解決してくれると思っている。

バカか。そんなことあるわけないんだ。課題は課題として識別して、解決しないといけないホントの課題を解決するアクションプランを“実行”しないといけないんだ。

そしてそれをトレースして、解決して初めて何が課題だったかがわかるんだよ。それを幾度も越えていく経験を踏ませないとチームは“成長”なんて1ミリもしないんだ。それはエンジニアの成長と同じだし、エンジニアの成長より厄介だ。エンジニア一人ではなくエンジニアの集まりなんだから。

さて、チームには基本に立ち戻る時間が必要だ。それはマネージャやプロジェクトマネージャがそれをしないとあとあと困ると見通しを付けているから。だから、プライオリティは高いのだ。

早速、はじめよう。