アジャイル戦略論 「チーム作りの巻」 ～ わたしの場合

RSGT2021にプロポーザルを出しました。３人で自分の言葉でチーム作りを語ってみようという話になりまして、まず私の分の概要を書いてみました。

Regional Scrum Gathering Tokyo 2021 - アジャイル戦略論 「チーム作りの巻」～すべての基礎はチーム作りにあり。 | ConfEngine - Conference Platform

まずはさっと脳内をダンプするというレベルなので、みなさんのご意見をいただければ幸いです。10行くらいの概要と、本番スライドが作れるといいなぁと、差し当たって考えております。

ここから原稿です。

1. 一人目の仲間を作る

デレク・シヴァーズが有名なTEDトークで語った通り、何かの社会的な活動を起こす際に、一人目のフォロワーが鍵となる。何かを始める時には、まず先行者を探し、フォロワーになれないか考えてみるのがよい。適切な先行者がおらず、リーダーにならざるを得ないときは、一人目フォロワーを見つける必要がある。
https://www.ted.com/talks/derek_sivers_how_to_start_a_movement?language=ja

一部の方の期待を裏切ってしまうかもしれないが、アジャイル戦略論は、アジャイルという武器を使ってあなたをリーダーにする話ではない。アジャイルという企業活動上の新しい必然を、企業の中に定着させるためにどうすればいいか、ということだ。だから、あなたに権力があればそれを適切に使い、ないなら権力を持った人とうまくふるまうことによって、目的を達成しよういう立場をとる。それゆえ、まずビジョンを共有し、自分の持っていないものを補完してくれる仲間が必要なのだ。

2. 話し合いながらアウトプットする

未来は決まっていない。アジャイルな考え方とやり方を、組織の人々がどのように体現するようになるかは、全く予想もつかない。しかし、現在のような激しい競争環境のなかで、かつ技術人材も潤沢とはいえないあなたの環境で、実のある成果をどのように、文字通り「ひねり出して」いくかを考えないといけない。発想だけでなく、なるべくコストも期間も使わずに最初の成果(Low Hanging Fruits)を手に入れるために、何ができそうか、二人で考える必要がある。今使えるリソースは何で、どうであれば成果といえるのか。足りないものはなにか。多少のはったりは必要かもしれないが、基本的には大きなリスクを会社や上司にとらせないで最初の勝利を得るには何ができるか。(ちなみにここで大きな借りを作ってしまうと、要求水準が高まって、無理な成果を求められたり、叱責されることになるので、できれば大きな借り物をせず、バットを短く持って振りぬきたい。借りるにしても少人数からとしよう。踏み倒しても許してくれるような信頼関係のある相手=パトロンがいれば最適だ)。

Software in 30 Days でスクラム共同創設者の二人は「パイロットプロジェクト」の選び方として、2つ選ぶように推奨している。失敗してもリスクの小さい新規事業のようなものと、社内で重要な機関となるプロジェクトだ。もし、上級の管理職の指示やサポートの上で行うならば、そうした戦略がよいだろう。もしそれほど支援を得ていないのであれば、もっと軽量に始めるほうがよいように思う。組織を一切いじらず、既存のチームである程度始められるならそれが一番良い。

3. ものの置き場を確保する

仲間と初期の目標を決めたなら、まず大事なのが、ものの置き場を確保することだ。そんなことあとでいいと思う人もいるかもしれないが、トヨタ生産方式でも、道具の位置を決めることはとても重要と考えられているという(要出典)。企画はどういうフォルダに置くのか、ソースコードや成果物はどこに置き、誰に見てもらえるようにするのか。デリバリー先のサーバやハードウェアはどこか？ネットワークは用意できているか？実は多くのアジャイルコーチングの現場で最初に問うのがこの点だ。遅いプロジェクトは、だいたいここができていないか、複雑すぎるか、後回しで考えていない。アジャイル最大の敵が、堅牢というか、昔ながらすぎる会社のITインフラだったり、そうした人々の無知だったりするのっではなかろうか。まずそうした部門への味方づくりが必要という場合も少なくない。

社内の根回し、というと大げさだが、あなたがもし「相手が何者かもわからない人から特別対応を求められた」としたら、どうするか考えてみてほしい。上司と相談のうえで、正式に断る理由を考えるのではないだろうか。こちらも忙しいのだ。特に何かをなそうとしている人であればあるほど、忙しいので、関係ないことに巻き込んでほしくないものだ。社内で最初に成果を出すためには、ここは避けて通れない。同意してくれない相手でも、戦わないですむような線引きをしておくことが重要だ。しばらくはお目こぼしをお願いして、その間に成果を出せばよい、かもしれない。

4. 成果をアピールする

成果がでるかどうかは、進め方次第だろうが、忘れてはいけないのは、アピールすることだ。人は、やらせてほしいときにお願いすることは熱心だが、やり終わった後の宣伝は面倒くさがる。しかし、やったことをアピールすることはとても重要だ。組織にとってもあなたにとっても。アピールによって、次のステップに向けての理解を醸成することができる。逆にアピールできないとしたら、目標が間違っていたということかもしれない。アピールの仕方も求められるものも組織文化によってまちまちだ。誰も聞いてくれなさそうな時は、社外コミュニティで発表するのがよいかもしれない。もし社内が社外発表を許容しないような文化なら、コミュニティの先達に相談してみるだけでも、自分の立ち位置が明確になるはずだ。

5. やったことをふりかえる

自分たちでやったことをふりかえる時間をとることも極めて重要だ。まず、ノーム・カースの最優先指令「どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」を肝に銘じよう。そして、自分たちがやってきたこと、できていることを認識する。そのうえで、次の実験をどうするか、考えてみるのだ。

kawaguti.hateblo.jp

6. 技術的負債を解消する

ソフトウェアシステムというのは、おそらく、いつか破綻する構造物だ。一度書いたものが永遠に動き続けると考えるのは幻想にすぎない。しかも現代のソフトウェアのほとんどは他社が作ったライブラリにそのほとんどを依存しており、自分が書くコードなどはほんの一部、多くても1%にも届かないだろう。既存の優れたライブラリや仕組みを使って、自分たちのしたいことを組み上げるのがソフトウェア開発というものだ。常に陳腐化するし、常に不確実性というものが存在する。すでに書いて動いエイルコードでも、不断の注意をもって学び続けなければ、容易に操作不可能になる。様々な階層のテストを書く、リファクタリングを行ってコードを改善する、などは自分たちのコードをチームで再学習することにもつながる。中身がわからないのに、次の一歩を効率的に進めることはできない。アジャイルの要諦は、迅速に作れるチームを作ることだ。自分たちの作ったいるものに徹底的に慣れる必要がある。