Lean開発者のスタート: チームのスタートアップ時間の削減

直面している課題: チームの変化

私はここ数年間、多くのチームで働いてきました。そのうちのいくつかは非常に長い期間に渡って仕事をしてきましたが、かなり短い仕事も数多くありました。それらの仕事を通じて、多くのチームに共通して話題になることがある、ということに気づきました、その話題というものは、チーム構成の変動です。通常は、チームだけの力では対処できないようなものが引き金になります。例えば、チームメンバーが病気にかかったり、長い休暇を取ったり、プロジェクトが大きくなったり、新しいプロジェクトが立ち上げられたり、あるいはその本人が(環境の)変化を望んだり、といったことがあります。もしそれらを理解する事前の知識が十分にない場合には、日次スタンドアップミーティングや、ペア・プログラミングといったアジャイル・プラクティスを使ったとしても、役に立たない情報ばかり伝わってしまいます。アジャイルプラクティスは新チームメーンバーが知りたい情報を直接提供するものではありません。そこで私は、新しいチームメンバーの「セットアップ時間」の削減するために、新しいプラクティスを提案します。

待ち行列理論のチームへの適用

• セットアップ - 実際に作業を開始する前の準備をするプロセスに使用される時間です。
• 実行 - 実際に作業を実行するプロセスに含まれる作業項目に使用される時間です。この時間はプロセスの時間と待ちの時間に分割されることもあります。
• 移動 - 次のプロセスに移動する作業に使用される時間です。
• 待ち - 次のセットアッププロセスに入るまで待つ時間です。

リードタイムの後半の２項目(移動時間と待ち時間）は個々のプロジェクトに影響を与えることはありません。そのため、重要になってくるのは前半の２項目(セットアップ、実行)です。新しいチームメンバーのセットアップというものは、いままでいたチームメンバーとほぼ同じぐらい働く開発者に変化するのにかかる時間です。なぜこのような時間をカウントする必要があるかというと、新メンバーを受け入れるためには既存のメンバーが時間をかけたり、取り組みを行って、チームのやり方の要領を伝える必要があるからです。これは、新メンバーが持っている能力を完全に発揮できるまで行う必要があります。実行時間には、新メンバーがチームの中でどの程度の効率で働いているのか、ということが含まれます。

Brooks 氏の「人月の神話」では、プロジェクトに人を追加する際の影響が詳しく説明されています。特に、問題が発生しているプロジェクトについて考察されています。本の中で強調されていることは、新しいチームメンバーがプロジェクトを学ぶ必要があります。(実際にそれを達成しようとすると)、それの多くの人が時間を使う必要があります。こういった活動から、コミュニケーションのオーバーヘッドが発生し、大きな問題になっていく、書かれています。チームの他のメンバーとのコミュニケーションのオーバーヘッドはセットアップ時だけなく、実行時にも継続して発生します。これらの要因を考慮すると、新しいチームメンバーを入れることによって発生するトータルコストは以下の図のようになります。

チームでの活動を向上させることにフォーカスしているプロセスはどれも、実行時のコミュニケーションを削減しようとするものが多い。これらは、新メンバー投入時にかかる時間の削除には目を向けていない。これは、新チームメンバーがどれだけ早くチームになじめるか、チームが新しいメンバーに合わせて内部構造をどれだけうまく変化させられるか、という時間である。

実行時のためのアジャイルプラクティス

すべてのアジャイル開発方法論において、学習は必要不可欠な要素となっています。多くのアジャイルプロセスはフィードバックのサイクルなるべく早くして、反復練習をすることにフォーカスしている。特に、継続的な改善を行い続けることを重視しています。

しかし、プロジェクトに新加入したメンバーと、しばらくプロジェクトにしたメンバーでは、何を学習したいかというニーズは大幅に異なります。

新メンバーに情報を吸収させる方法としては、ただ質問を待って答えるよりも、積極的に疑問を持たせるようにする作戦もあります。Scrumのスタンドアップミーティングで発言されるような「私は昨日・・・をしました」という定型的な文章を聞けば、「(最初からチームにいた)彼らは何について話しているんだろうか？どうすればチームの輪に加われるんだろうか？」という疑問を持たせることができるでしょう。新メンバーに情報伝達の手段としてのペアプログラミングは、状況によって効果も変化します。もしペアのうちの一人が新しいメンバーで、詳細ではなくての全体を見る視点を持っていると効率が上がります。逆に、ユーザストーリーを次から次へと開発をしているチームでは新メンバーの加入による効果はないでしょう。この場合は新メンバーは大きな俯瞰図ではなく、細かい詳細ばかりを次々見せられます。多くの新メンバーが、メインの処理とは絡まないような、細かい情報ばかり与えられてフラストレーションを貯めていく例を、私は数多く見てきました。

プロジェクトの大まかなコンテキスト(前後関係、背景など)を知ることが新メンバーの目標です。彼らは知るべきことを見つけ出し、ドメイン特有の言葉を理解し、チームやその文化の中で仕事をし始めます。もしプロジェクトが複雑であったり、多くのメンバーが加入したりすると、このフェーズにかかる時間は長くなります。

新メンバーがコンテキストの理解を完了すると、今度は詳細の深い知識の学習をし始めます。わずかであっても、コンテキストを学んでおくと関連した情報の吸収が早くなります。大まかなコンテキストを理解している場合には、日次スタンドアップミーティングや、ペアプログラミング、テスト駆動開発、レトロスペクティブなどのプラクティスは付随的な種類の情報を理解するのに役立ちます。コンテキストを理解していない場合には逆に役に立ちません。アジャイル開発のプラクティスは新しいチームメンバーの学習を直接の目的とはしていません。アジャイル開発のプラクティス以外の方法について何か良い別案があるでしょうか？この場合は「セットアップ時間」の削減にフォーカスしている、別のプラクティスを用いることにします。

メンバー投入戦略を用いたチームのセットアップ時間の短縮

以下の短いリストはアジャイルプラクティスに含まれるプラクティスのうち、周囲の情報を完全に理解するのに役立つテクニックをまとめたものです。これらは実際に、私のチームに加わった新しいメンバーに役に立つと判断して取り入れたものです。:

• 事前Ｅメール(source) - 新メンバーがチームに加入する前にプロジェクトの背景を説明するEメールを送ります。このメールを読むことで、新メンバーはプロジェクトに関する書籍を読んだり、スキルを身につけたり、知識を学ぶ機会を得ることができます。
• 大きなビジネス問題へのビジョン(source) - プロジェクトが持っている価値と、プロジェクトを動かす原動力を 新メンバーに見せるセッションを行います。ドメイン固有の言語への理解が得られます。仕事を開始してもすぐにビジョンの方をきちんと向いて働くことができるようになります。
• アーキテクチャの可視化(source) - ダイアグラムを使うと、大きくなったシステムのコンセプトに小さなコンセプトを追加で実装するのがやりやすくなります。可視かを行うと、例えば、現在開発している機能の情報について集中して話をする場合や、いくつかのアーキテクチャがお互いにどのように関連しているのかということを話すのに使用することができます。
• プロジェクトの負債の透明化(source) - 元からいたチームメンバーが、「この箇所は改善しないといけない(今のコードがとても良くない)」と考えていることは素直に話しましょう。そうすることで、「どんなにコードが良くないか」という議論に陥るのを避けて、「どうやって改善するのか？」「どういう計画を立てるか？」ということにフォーカスできます。
• 小さいタスク(source) - 大きくて大量にある仕事を小さなタスクに分割します。そうすると、新メンバーが必要とすると手助けの量を減らします。また、チームメンバーが日常的にこなしている一般的なタスクにはどういうものがあるかを理解しやすくなります。
• 技術ワイガヤ(source) - 日常業務として、同じような仕事をしている仲間を集めて、他の人の役に立ちそうな知識やトリックを共有する会を開きます。この会ではスキルを学ぶこと、共有することに集中します。
• 生徒を先生に(source) - 他のチームメンバーの手助けを新メンバーに伝える役割を与えます。新メンバーは他のチームメンバーにコンセプトを説明したりする必要が出てきます。この活動を通じて学んだことを強化したり、考えを洗練させたりすることができます。
• 個々人のニーズの尊重(source) - 学習のプロセスはメンバー一人一人に合わせる必要があります。ダイアグラム、ドキュメント、CRCカードなど、幅広いコンテキストを描くことができるツールを使って下さい。
• 自由を与える(source) - 新チームメンバーには安全な環境で失敗を体験できるような十分なスペースを与えましょう。学習項目に応じては、自分自身で学んだ方がいいものも多いからです。

プロジェクト内でのメンバーの交換は難しく考える必要はない

アジャイルプラクティスは学習という観点で見ると、すばらしい提案であることは確かです。ただし、それは「セットアップ時間」ではなくて「実行時間」の削減にフォーカスしているため、新チームメンバーにとっては、既存のメンバーと比べると効果は大きくありません。まずは新チームメンバーが持つ学習のニーズが、通常のケースと異なるということを理解してください。そしてチームメンバーの導入に特化したプラクティスをもいい手、この問題に正面から取り組んで下さい。さらに(新メンバー用の)プラクティスを適用して、「セットアップ時間」の減少にトライし続けてみて下さい。

多くの人が会社に入る時に、研修プログラムを学ぶのは主にこういったことが理由になります。あなたが会社に入るときに受けた教育は、プロジェクトの運営に対して果たしてどのぐらいの効果があったでしょうか？

著者について

Patrick Kua氏はThoughtworks社で開発者、トレーナー、コーチをしています。Patrick氏は一緒に働いているチームの価値を高めるのに情熱を持っています。そして、自分の仕事や活動を楽しむことに熱心なメンバーの手助けをすることについても情熱を注いでいます。彼は仕事の中でしていることと、楽しむことを両方とも維持して達成することが、よりよい結果を生むという信念を持っています。彼はこの3.5年間は、アジャイルに取り組む数多くのチームに参加をして、コーチをしたり、リーダーをしてきました。

原文はこちらです：http://www.infoq.com/articles/pat-kua-onboarding-new
このArticleは2007年11月12日に原文が掲載されました）