株式会社ユーザベースの技術チームブログです。プラクティスを大きく取り入れて日々の開発を進めています。開発チームに参加してみて、ユニークだなと感じたことがいくつもありました。つのことについて紹介します。開発チームのユニークな文化を紹介することです。開発チームの現在のフェーズに固有の部分も少なからずあると思っており、これを読まれた方の組織やチームで、ここに書かれているようなことをただちに実践することを勧めるものではありません。開発チームは、開発を担う機能エリアごとに、数名程度の小さなチームに分かれています。(以後、この「小さなチーム」のことを単に「チーム」と呼ぶことにします)日々の開発(スタンドアップや見積もり、ふりかえり等を含む)はこのチームごとに行うのですが、このチームのメンバーは、数ヶ月に一度入れ替えを行っています。*1個人的には、チームのメンバーがお互いの個性やチームの文化・慣習を知り、チームとして安定してパフォーマンスを出せるようになるには時間がかかるため、頻繁な入れ替えは避ける方がよいと考えていました。チームメンバーを安定させず、メンバーが「流れる」ようにするのでしょうか?今のところ、私は以下の理由があると考えています。製品全体についての知識、および文化を共同所有するため。できるようになることが目的。「さまざまなものが流れる」文化があるため。開発チームでは多くのものを安定させず、常に流れる状態に置いている。「流れる」ことが定常状態であるため、メンバーの入れ替えもそのうちの一つにすぎず、チーム・メンバーのいずれも入れ替えにすばやく適応できる。見ると、「やる理由」と「できる理由」は表裏一体になっています。メンバーを入れ替えることによって知識や文化が撹拌され、それによってさらに入れ替えがやりやすくなる、という正のフィードバックの関係です。開発チームでは、ドキュメントを用いることがかなり稀です。アジャイルソフトウェア開発宣言では「包括的なドキュメントよりも個人と対話を」価値とする、と言われていますが、これほどまで対話(特に口頭での会話)に重きを置くソフトウェア開発組織はかなり珍しいのではないかと思います。アジャイルソフトウェア開発宣言でも「ドキュメントは不要」とまでは言っていない、とはよく言われることで、個人的にも、安定して開発を進めるためには必要十分な量のドキュメントを書いた方がよいと考えていました。ドキュメントを「最少限」と言い切れるほどのレベルにまで減らすのでしょうか?現在の私の理解では、以下の理由があると考えています。ドキュメントを減らせば、会話せざるを得ないため。本末転倒にも見えるが、知識が「流れる」ために必要な仕掛けと言える。知識は撹拌されており、また常に会話する文化があるため。製品についての知識や文化は常に流動し、撹拌されている。常時ペアプログラミングを行なっていてペア間の会話は絶えないほか、他ペアや他チームからの割り込みも奨励されており、「質問されたらすぐに答える」ことが徹底されている。お気付きのように、ここにも正のフィードバックがあります。ドキュメントを減らせば会話が増え、会話が増えれば、さらにドキュメントを減らせるようになります。「属人化を防ぐためにドキュメントを残す」と言われますが、私たちのチームでは、いわば知識が「チーム全体に属人化(属チーム化?)」したような状態といえます。開発チームでは、「担当者を明確にしない」ことがよくあります。チームでのふりかえりを行なった際は次週に取り組むアクションを決めますが、私が初めてチームでのふりかえりに参加したとき、アクションの担当者を決めずにふりかえりが終わったことに驚きました。「ちゃんと決めておかないと、みんな忘れてしまったらどうするの?」と思ったのですね。当たり前といえば当たり前ですが、誰かが覚えているのですね。アクションは次週にきちんと行われました。いえ、一般論としてはアクションの担当者を決める方が確実です。私が初めて会ったチームのふりかえりのファシリテーターだったら、「誰か担当者になってくれますか?」と聞くと思います。開発チームでは、普通なら担当者を決めるであろう場面で、あえて決めない、とすることが多くあります。これはなぜでしょうか?私の考えでは、以下が理由です。「活動の最小単位」をチームとし、何らかのタスクが個人に帰属することを防ぐため。何かを個人のタスクとしてしまうと、そのプロセスについての知識と、責任が個人に紐づいてしまう。ならないよう、万事を個人ではなくチームの関心事にとどめるために、担当者を決めない。いつでも活動の最小単位をチームとしており、そうすることに慣れているから。普段からそうする訓練をしているから。:)チーム全体でこれを意識していると、不思議と補い合うようになります。失敗することも時にはありますが、その都度会話して対応します(ただし、できる限り「担当者を決める」以外の方法で)。2」では「知識」や「文化」が流れていましたが、ここでは「担当」が流れています。開発チームでは多くのものが「流れて」います。私の個人的な感覚では、「ほとんど全てが流れている」と言ってもいいように思います。他にも、今回は紹介しなかったペアプログラミングのやり方や、ミーティングの進め方、製品のデザイン等々、多くの場面が「流れ」の中にあるように感じます。ソフトウェアサービスなので、その開発チームにあって流れは重要です。そのため、「流れ」はそれ自体として目的の一つになりえます。一方で、「流れ」は究極の目的ではないはずです。プロダクトチーム(開発チームもここに属する)のミッションは「技術力で、ビジネスをリードする」です。すれば、この「流れ」の文化はそれを支えるものであるはずだし、そうあるべきです。林が掲げている「最高の開発チームをつくる」は、「流れ」によって支えられる大きな目標の一つなのでしょう。月足らずですが、これからもチームで仕事をしていく中でこの流れの文化の究極の意義を見つけ出し、発展させていくことを楽しみにしています!*1:ちなみに入れ替えを行うこと自体は半ばルール化されていますが、誰が入れ替わるかはメンバー自身の意思によって決まります*2:もしかしたら、チームの中を「漂っている」と言った方がより的確かもしれません。つのことTweet関連記事2019-10-15ペアプロと育休の取得しやすさの関係についてこんにちは。SPEEDA開発チームの鈴木です。SPEEDAのテストエンジニアをやっている工藤です。SREチームの久保です。»プロフィール『経済情報で、世界を変える』をミッションに、企業・業界情報プラットフォーム「SPEEDA」やソーシャル経済ニュース「NewsPicks」、ABMを強力にサポートする「FORCAS」、スタートアップの情報収集を圧倒的効率化「entrepedia」などを提供する株式会社ユーザベースの技術チームブログです。多国通貨」をハンズオンしたら快適で楽しかったGo言語でオブジェクト指向プログラミングの基本(型編)月別アーカイブ検索@Uzabase_Techさんのツイートスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。