アジャイルなチームのつくりかた

アジャイル開発をはじめるときに、最初に取り組むことは何でしょうか?

適用可能なプラクティスからはじめたり、スクラムなどの手法を採用してその枠組みにはまるように進めたりと、何からはじめるのかはメンバの基礎知識や現場の状況などによって異なります。

しかし、

最初に取り組むべき最も重要なことは「チームをつくる」こと

であると思っています。

新しい課題の出現

チームは、チームメンバみんなでやってみて、失敗して、改善して、を繰り返していくことによって、アジャイルなチームへと成長していきます。
はじめは、チームメンバがそれぞれ異なった知識・経験を持っていても「ヨーイドン」でスタートすることにより、チームメンバみんなで経験してきたことが積み重なって今のチームをつくりあげていると言えます。

このように、これまでは何もないところからチームをつくりあげることに注目し、さまざまな情報を収集したり、できることから実践したり、と改善を続けてきましたが、ここ数年の間に新しい課題が出てきました。

それは新メンバの参入です。

「チームをつくる」ことを最優先に考えて取り組む

新しいメンバは、アジャイル開発の(知識を持っていたとしても)経験が無い場合が多く、きっちり詳細まで書かれた仕様書が渡されて作業をしてきた人にとってはまったくの別世界に思えることもあります。
たとえアジャイル開発の経験があったとしても、チームが異なれば重視する価値も異なるため、これもまた別世界に思えることもあります。

新しいチームで新しい案件を手掛けるのと違い、ある程度の文化が出来上がったチームに新しいメンバが加わることは、チームのベロシティが(下がるとまではいかなくとも)上がらなくなってしまい、より良い価値を提供し続けることに支障がでることになります。そして、新しいメンバにとってもチームの文化に慣れるまでにはたくさんの時間がかかってしまいます。

このような課題を解決するためにも「チームをつくる」ことを最優先に考えて取り組んでいくことが必要です。計画を立てるときにも、コーディングするときにも、テストをするときにも、どのような場面でも基礎となる大事なことです。

それでは、今の自分のチームが取り組んでいる「チームをつくる」ための要素のうち、最も大事にしている3つの要素を紹介します。

「チームをつくる」ために最も大事にしている3つの要素

【1】理由を考える

「その資料は誰に向けたもの?」
「その機能はなぜ必要なの?」
「その作業は何のためにやっているの?」

チームの中では、日々、このような質問が飛んでいます。

企画書、提案書、設計書、報告書など、ドキュメントを作成する機会はたくさんありますが、必死で書いていると誰に向けた資料なのかわからない資料になっていることが多々あります。

誰に向けたものかを常に意識する

簡単なところで言うと[する][される](システムがすることなのか、人がすることなのか)があります。

これはひとつの例ですが、ひとつの資料の中で「誰に向けて」が変わると、表現も変わり記載する内容も変わってきます。

資料は読む人に理解してもらうために作成するものなので、必要な情報を理解しやすい形で表現できるよう、誰に向けたものかを常に意識しています。

機能を使うのも[人]、機能を作成するのも[人]

機能を作成するときにも、最終的にユーザがほしい機能と異なるものを作成していることがあります。

詳細仕様書のように細かなところまで決まっていたとしても、ユーザのイメージと出来上がりには必ずといって差が出てきます。もしかすると詳細仕様書に書かれていることが間違っているかもしれません。

機能を使うのも[人]、機能を作成するのも[人]。

その機能がなぜ必要なのかを共有することが、チームメンバ間での認識の相違を減らしチームとしての成果を一定の品質に保つことに繋がります。

ドキュメント作成、コーディング、テストなどなど。作業にもいろいろなものがありますが、作業を完了させることを意識しても、なぜその作業が必要なのかを意識していないことが多いです。

作業をして作り上げたものがユーザの利益を生み出してこそ、その作業の意味があると思っています。

もちろん、ユーザの利益に直接つながっていないこともありますが、長期で見ると大いに貢献していることもあります。
逆に言うと、ユーザの利益を生み出さない作業は「ムダ」なのです。
ムダを少しでも減らして、それ以上の価値を提供できるように、作業の意味を意識しています。

【2】ツールに依存しない

「チケットに書いてあったのでそのように対応しました」
「Wikiに残してあるので探してみてください」

チーム内でのやりとりですが、これは良くない例です。

開発を行う上で必要なツールはたくさんありますが、その中でもチーム内で共有すべき情報を扱うようなコミュニケーションツールは注意が必要です。
例えばRedmineやWikiは、実際に活用しているツールですが、これらのツールに依存しすぎると、メンバ同志のコミュニケーションが減り認識の相違が生まれてくる可能性が高くなります

状況は常に変わる

チケットに限らず仕様書でも同じですが、書かれている内容は書いた時の決定事項であり、今の決定事項ではないため、書かれている通りに作成できたとしても、すでに状況が変わり最終的にユーザがほしいものとは異なるものが出来上がり、手戻りというムダな作業が発生してしまったことがありました。

このケースは、チケットの内容を更新していないことが問題だと捉えることもできますが、すべての内容をリアルタイムに更新して最新の状態を保たせることは不可能に近いので、常にメンバ同士、目と耳と口でのコミュニケーションを意識しています。

なぜか?・・・状況は常に変わるのだから!

これらのツール自体はとても良いツールであると思っています。

要は「ツールをどのように使うか」が、これらのツールを活かしてチームとしての成長につなげられるかのカギを握っていると言えます。
「ツールを使っても使われない」ということです。

【3】アジャイルだから

「アジャイルだからこれをやってみよう!」

このような言葉はチームの中で一切出てきません。

アジャイルだからユニットテストをするとか、アジャイルだからチケット駆動にするとか、目的がアジャイルになるとプラクティスを正しく行うことに注意が向き、結果、ユーザにとってもチームにとっても正しいことを行うことができなくなってしまいます。

目的がユーザやチームの[人]へ向いた取り組みを行う

ユーザへこんな価値を提供できるからこんなプラクティスをやってみようとか、チーム内の認識を合わせて進めるようにこんなツールを使ってみようとか、目的がユーザやチームの[人]へ向いた取り組みを行うことにより、アジャイルなチームになっていきます

アジャイルにするのではなく【アジャイルになる】ことがとても大切です。

ここまで紹介した要素は、アジャイルなチームへ新メンバが参入するときの課題を解決するためだけでなく、新しくチームをつくるときにも同じように採用できるものです。さらには、システム開発に限らずどのようなことにも通じる要素であると思っています。ですので、この記事を読んで頂いている同じ課題を持つみなさんにとってもヒントになれば幸いです。

さいごに

チームメンバみんなが [人のために]考え、[人のために]実践し、[人のために]改善する。

この取り組みが[人]を幸せにするということであり、まわりまわって[自分]を幸せにすると信じています。
ここで言う[人]とは、ユーザでありチームメンバであり・・・プロジェクトに関わるすべての[人]を指しています。

すべての[人のために]、そして[自分のために]、さらなる進化をしていける。

そんなアジャイルなチームをメンバみんなでつくっていきたいですね。

Follow me!

この記事を書いた人

阿部智紀
阿部智紀
トラスティア株式会社 専務取締役
テクニカルディレクター
長期に渡り、アジャイル開発を推進・実行しています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です