「リーン開発の現場」は、ソフトウェア開発の物語であり、チェンジエージェントの物語でもあります。チェンジエージェントという言葉を聞き慣れない方もいることでしょう。チェンジエージェントとは「変革の推進者」を意味します。先日、チェンジエージェントの「実践」をテーマとしたイベントを開きました。チェンジエージェントという言葉からは、具体的にどんな振る舞いをする存在なのか想像し難いところがあります。そこで、変革を推進せんとする人たちが現場でどのような課題を捉え、実際にどのように乗り越えていったのかを生々しく語る場を企画しました。このエントリではその一部始終をまとめます。
チェンジエージェントは現場主義
最初の発表は、楽天さんの伊藤宏幸さんです。アジャイルコーチとしてチームを支援しています。
伊藤さんが直面したのは、スクラム経験者ゼロでのスクラム開発、自動テストもまだないレガシコードへのエンハンスなど数々の問題でした。手ごわい問題を前にすると、気が挫かれかねないところです。しかし、伊藤さんは逆にこの状況をどこから改善しても成果に繋がると、むしろ前向きに捉えたのでした。

自分自身で設定したマインドセットが変化を起こす人を下支えする1つになっていきます。
発表では現場を変える具体的なアプローチとして、大きく3つのことを挙げられていました。その一つが、Fail-Fast-Approachです。「失敗から学ぶ」とはよく耳にする言葉です。では実際にどのようにして失敗から学ぶのでしょうか?そもそも失敗ができるコンテキストはできているでしょうか?失敗から学ぶためにも作戦が必要です。ポイントは2つあると思いました。早期に失敗する、そして意図的に失敗する。失敗の結果を容易にリカバリできないくらいの致命傷になる前に、かすり傷程度で済むよう失敗の範囲をコントロールする。例えば「まずは1週間試してみよう」と、期間を区切る。あとで取り戻しが効くように、影響のコストを抑えるべく失敗を設計しているといえます。

また、開発上の学習が遅くなるのはプロジェクトのリスクです。必要な学習はできる限り早期に得ておきたいと考えるものです。プロジェクトの後期になるほど、リスクの健在化がプロジェクトの致命傷にもなりかねません(プロジェクトの残り時間的に「あとで取り返す」が効きにくいためです)。そのために、意図的に失敗を済ませておくというアプローチも有効といえるでしょう。
現場を変えるアプローチ、その2つ目は移動するボトルネックのコントロールです。問題を解決すると、問題が発生した箇所とは異なるところで新たな問題が生まれる。やがて、問題がチームの仕事を止めてしまう。「ボトルネックは移動する」とはTOCの教えの1つです。私たちの仕事は複雑に影響しあっています。例えばどこかのチームが徹夜して機能をつくりこんだところで、完成のために必要なデザインを施すデザインチームが過負荷となってしまっては結果的にアウトプットが途絶えかねません。このような状況で開発チームがいくら機能をつくりこんでもサービスやビジネスの価値を高めることにはなりません。なぜそのような問題が起きるのか。その真因に遡り、問題と結果の因果関係を捉え、的確な対処を打つ。「リーン開発の現場」では因果関係図を用いて、そのやり方を解説しています。
アプロチーチの3つ目は、チーム状況を把握する仕組み造りです。現場を変えようとしたとき、その試みの結果がどうだったのか、どのくらい効果があったのか、数値で示すことができれば次の変化の後押しになるはずです。効果があった、だからさらに次の手を打っていこう。効果がなかった、やり方を変えよう。いずれの場合も計測した数値がその意思決定を助けてくれます。また、数値として変化の結果を捉えておくことは、当事者の動機付けにもなることでしょう。

最後に。発表のタイトルにもなっている現場主義とは何でしょうか。現場主義とは問題を解く鍵は現場にある捉え、現場で打ち手を試しながら考え行動し続ける姿勢のことです。伊藤さんの発表にあった打ち手の数々はどれも現場の匂いがします。伊藤さんが現場に向き合い続けているからこそ得られた変化なのだと思います。
※「チェンジエージェントの物語とは、すなわち現場の物語のことである(後編)」へ続きます。
コメントを残す