読者です 読者をやめる 読者になる 読者になる

Masa / Lino Blog

Masanori Satoh ( Masa / Lino ) の徒然ブログです

アジャイルチームを機能横断チームにするために実践した5つのこと

アジャイル

アジャイルチームは機能横断(職能横断とも言います)チームであるのが、望ましいといわれます。

画像には大した意味はありません・・・。

その理由は、メンバーがチームに貢献する姿勢などいくつかあると思います。
私が一番メリットに感じている点は、チーム全体として考えたときに個人の作業遅延をチームでカバーできるということです。
例えば、Aさんの作業が6時間遅れていたとして、Aさんの担当作業を別のメンバーでも担当できれば、早く作業が進んでいるメンバーをAさんのリカバリーに当てることができます。
また、機能横断チームであれば、メンバー同士で新しいアイディアを出したり、アドバイスしやすくなります。自己組織化も進みやすいと思います。

ただ、一言で機能横断チームを作るといっても、実際にやるのは大変難しいです。
特にSIerの場合、SE(設計者)、プログラマー、テスターが独立しているというのは珍しくないでしょう。


そこで、私のチームが機能横断チームになるために実践した5つのことを説明します。

1. 可能な限り自動化する

ユニットテストやインテグレーションテスト、ビルドからデプロイまで、可能な限り自動化をしました。
Jenkinsなどの継続的インテグレーションツールで、ボタンをひとつ押せば、誰でもテスト環境へのデプロイまで行なえる環境を作ります。
これにより、基本的なタスクのやり方をツールが担ってくれるので、このタスクはどうやればいいのだろう、と余計な時間を使わずに住むようになります。

2. タスクの完了定義を明確にする

アジャイルでは、タスクの完了定義を明確にすることは重視されています。
機能横断チームという観点では、タスクをこなす上で、何をすればいいか分からない状態というのは、メンバーにとって非常にストレスです。
例えば、計画会議の段階で、A機能の実装であれば、作成機能のプロダクトオーナーとの意識あわせ、コードレビュー、ユニットテストカバレッジ100%など、各タスクの完了定義を明確にしておきます。
そうすれば、急にメンバーのリカバリーに入ったとしても、何をやればいいか分かりやすいので、すぐにタスクに着手できます。

3. ノウハウをWikiにまとめる

アジャイルでは、イテレーティブに徐々に機能を追加リリースしていきます。
つまり、リリースに必要な作業というのは1回だけやるのではなく、何度もやる可能性が高いです。
そういったノウハウをWikiにまとめて、2回目にやるときは、そのWikiを見れば、他の人でも作業できるようにしておきます。
開発作業では、ハマる作業は、他の人がやってもハマる可能性が高いので、その点でも有効でしょう。

4. 同じ部屋で作業をして、コミュニケーションをとりやすい雰囲気を作る

3. ノウハウをWikiにまとめる。でノウハウを書いていても、全てをアウトプットすることは難しいでしょう。
また、機能横断チームといえど、やはりメンバーによってスペシャリティは異なります。
作業中に困ったときやアイディアが不足しているときに、すぐメンバーに聞けるというのは重要です。
アジャイルのプラクティスで、共通の作業部屋で仕事をするというのは、こういった点でも重要だと思います。

5. 新しいタスクにチャレンジしやすい風土を作る

リリースごとに、メンバーが違うタスクを行なえば、必然的に機能横断的なチームができていきます。
ただし、アジャイルではタスクへのアサインは行なわず、サインアップを基本としているので、新しいタスクにチャレンジする風土を作る必要があります。
これは、なかなか難しいのですが、例えば、チームが助け合う姿勢ができていれば、新しいタスクにチャレンジするときに、サポートしてもらえるので、チャレンジしやすくなるのではないでしょうか。


これらの点が、機能横断チームを作るポイントでしょう。
また、アジャイル開発ではないウォーターフォール開発などでも、機能横断チームは有効に働くと思います。マリッジナンバー(トラックナンバーとも言います)を下げることもできるますし。ただ、ウォーターフォール開発の場合は、いわゆるSIerの請負ピラミッド構造が問題になることでしょう。