7 月から SPEEDA 開発チームに参加しました、野口です！
SPEEDA 開発チームでは、XP のプラクティスを大きく取り入れて日々の開発を進めています。
私は入社前から XP やスクラムのようなアジャイル開発手法とその考え方には慣れ親しんでいたのですが、SPEEDA 開発チームに参加してみて、ユニークだなと感じたことがいくつもありました。
この記事では、SPEEDA 開発チームで私が特にユニークだと感じた 3 つのことについて紹介します。
- おことわり
- その 1: チームのメンバーを「安定させない」
- その 2: 属人化を防ぐためにドキュメントを「残さない」
- その 3: 担当者を「明確にしない」
- そうやってどこへ行きたいのか、そしてこれから
おことわり
この記事の目的は、SPEEDA 開発チームのユニークな文化を紹介することです。
これらの取り組みには、SPEEDA 開発チームの現在のフェーズに固有の部分も少なからずあると思っており、これを読まれた方の組織やチームで、ここに書かれているようなことをただちに実践することを勧めるものではありません。
私自身、チームに入ってからしばらく経ちますが、まだ十分には消化しきれていない部分もあり、これからも実践しながら考え続けていきたいと思っています :)
その 1: チームのメンバーを「安定させない」
SPEEDA 開発チームは、開発を担う機能エリアごとに、数名程度の小さなチームに分かれています。（以後、この「小さなチーム」のことを単に「チーム」と呼ぶことにします）
日々の開発（スタンドアップや見積もり、ふりかえり等を含む）はこのチームごとに行うのですが、このチームのメンバーは、数ヶ月に一度入れ替えを行っています。実際、私が入社してからも一度入れ替えがあり、7 名いたメンバーのうち 2 名が交代しました。 *1
個人的には、チームのメンバーがお互いの個性やチームの文化・慣習を知り、チームとして安定してパフォーマンスを出せるようになるには時間がかかるため、頻繁な入れ替えは避ける方がよいと考えていました。
では、なぜあえてチームメンバーを安定させず、メンバーが「流れる」ようにするのでしょうか？
今のところ、私は以下の理由があると考えています。
- やる理由: 製品全体についての知識、および文化を共同所有するため。
- 個々のチームに知識を閉じず、開発チーム全体で製品全体を共同的に理解し、開発・保守・運用できるようになることが目的。また、文化についても同様。
- できる理由: 「さまざまなものが流れる」文化があるため。
- チームメンバーの入れ替えに限らず、SPEEDA の開発チームでは多くのものを安定させず、常に流れる状態に置いている。「流れる」ことが定常状態であるため、メンバーの入れ替えもそのうちの一つにすぎず、チーム・メンバーのいずれも入れ替えにすばやく適応できる。
よく見ると、「やる理由」と「できる理由」は表裏一体になっています。メンバーを入れ替えることによって知識や文化が撹拌され、それによってさらに入れ替えがやりやすくなる、という正のフィードバックの関係です。
その 2: 属人化を防ぐためにドキュメントを「残さない」
SPEEDA 開発チームでは、ドキュメントを用いることがかなり稀です。
アジャイルソフトウェア開発宣言では「包括的なドキュメントよりも個人と対話を」価値とする、と言われていますが、これほどまで対話（特に口頭での会話）に重きを置くソフトウェア開発組織はかなり珍しいのではないかと思います。
アジャイルソフトウェア開発宣言でも「ドキュメントは不要」とまでは言っていない、とはよく言われることで、個人的にも、安定して開発を進めるためには必要十分な量のドキュメントを書いた方がよいと考えていました。
では、なぜドキュメントを「最少限」と言い切れるほどのレベルにまで減らすのでしょうか？
現在の私の理解では、以下の理由があると考えています。
- やる理由: ドキュメントを減らせば、会話せざるを得ないため。
- やや本末転倒にも見えるが、知識が「流れる」ために必要な仕掛けと言える。
- できる理由: 知識は撹拌されており、また常に会話する文化があるため。
- 「その 1」で紹介したように、SPEEDA の製品についての知識や文化は常に流動し、撹拌されている。また、常時ペアプログラミングを行なっていてペア間の会話は絶えないほか、他ペアや他チームからの割り込みも奨励されており、「質問されたらすぐに答える」ことが徹底されている。
おそらくお気付きのように、ここにも正のフィードバックがあります。ドキュメントを減らせば会話が増え、会話が増えれば、さらにドキュメントを減らせるようになります。
よく「属人化を防ぐためにドキュメントを残す」と言われますが、私たちのチームでは、いわば知識が「チーム全体に属人化（属チーム化？）」したような状態といえます。
その 3: 担当者を「明確にしない」
SPEEDA 開発チームでは、「担当者を明確にしない」ことがよくあります。
たとえば、チームでのふりかえりを行なった際は次週に取り組むアクションを決めますが、私が初めてチームでのふりかえりに参加したとき、アクションの担当者を決めずにふりかえりが終わったことに驚きました。「ちゃんと決めておかないと、みんな忘れてしまったらどうするの？」と思ったのですね。
しかしこれは杞憂でした。当たり前といえば当たり前ですが、誰かが覚えているのですね。
アクションは次週にきちんと行われました。
とはいえ、一般論としてはアクションの担当者を決める方が確実です。私が初めて会ったチームのふりかえりのファシリテーターだったら、「誰か担当者になってくれますか？」と聞くと思います。
他にも、SPEEDA 開発チームでは、普通なら担当者を決めるであろう場面で、あえて決めない、とすることが多くあります。
これはなぜでしょうか？
私の考えでは、以下が理由です。
- やる理由: 「活動の最小単位」をチームとし、何らかのタスクが個人に帰属することを防ぐため。
- 何かを個人のタスクとしてしまうと、そのプロセスについての知識と、責任が個人に紐づいてしまう。そうならないよう、万事を個人ではなくチームの関心事にとどめるために、担当者を決めない。
- できる理由: いつでも活動の最小単位をチームとしており、そうすることに慣れているから。
- つまり、普段からそうする訓練をしているから。
「やる理由」についてはともかく、「できる理由」については「やっていたらできるようになった」という理由しか思いつきませんでした :)
チーム全体でこれを意識していると、不思議と補い合うようになります。失敗することも時にはありますが、その都度会話して対応します（ただし、できる限り「担当者を決める」以外の方法で）。
「その 1」と「その 2」では「知識」や「文化」が流れていましたが、ここでは「担当」が流れています。*2
そうやってどこへ行きたいのか、そしてこれから
ここまで紹介してきたように、SPEEDA の開発チームでは多くのものが「流れて」います。
私の個人的な感覚では、「ほとんど全てが流れている」と言ってもいいように思います。他にも、今回は紹介しなかったペアプログラミングのやり方や、ミーティングの進め方、製品のデザイン等々、多くの場面が「流れ」の中にあるように感じます。
では、「流れ」それ自体が目的なのでしょうか？
おそらく、Yes でもあり No でもある、と言えます。
ソフトウェア開発という営み自体が絶え間ない流れの中にあり、SPEEDA はソフトウェアサービスなので、その開発チームにあって流れは重要です。そのため、「流れ」はそれ自体として目的の一つになりえます。
一方で、「流れ」は究極の目的ではないはずです。
ユーザベースには「経済情報で、世界を変える」というミッションがあり、それを支える SPEEDA プロダクトチーム（開発チームもここに属する）のミッションは「技術力で、ビジネスをリードする」です。だとすれば、この「流れ」の文化はそれを支えるものであるはずだし、そうあるべきです。
たとえば、以下のインタビュー記事で CTO の林が掲げている「最高の開発チームをつくる」は、「流れ」によって支えられる大きな目標の一つなのでしょう。
私はまだチームに参加して 2 ヶ月足らずですが、これからもチームで仕事をしていく中でこの流れの文化の究極の意義を見つけ出し、発展させていくことを楽しみにしています！
