海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium を読んだ。
全体としてとても面白く読ませていただいた中で、特に気になるところがあったのでそれに関する所感を書いてみる。「エンジニアのチーム構成・組織構成」というパートだ。
ちなみに、どちらが良い悪いみたいな話でもなければ同記事に対する異論反論でもない、ということは初めに強調しておきます。
ヨーロッパの開発チーム構成
同記事の「エンジニアのチーム構成・組織構成」に以下のようにある。
それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的にチームに加わるという移動の仕方もあります。
「おおー、それでうまく回る…のか？」というのが第一印象だった。
というのも、プロジェクトベースで開発するこのスタイルは僕が受託開発をやっていたときや、現職でかつて採っていたスタイルだが、デメリットを強く感じるようになり止めたものだったからだ。*1
プロジェクトベースの開発のデメリット
プロジェクトベースの開発のデメリットに関する私見。初めに書いた通り、良い悪いを論じたいわけではなく、こうしたデメリットをどう扱うのかが気になっている、という記事なのでメリットについては省略する。
長期的観点の不足
一般的に言えば、プロジェクトベースでの開発はリリース以降に起きることに対する長期的な観点が不足しがちになる。プロジェクトを終わらせることがチームの達成すべき目標であり、それ以外を優先するインセンティブが低くなるからだ。
長期的な観点の例は、運用・(技術的|プロダクト)負債・アーキテクチャなど、製品が継続的に改善・成長しつづけるためには避けて通れないが、初期開発のタイミングではある意味"ごまかし"がきくところ。*2
DevOpsを実践する現職においては、開発したものの運用は自分たちで行っているために起きにくい問題ではあった。
しかし前職のSIerで案件・プロジェクトベースで働いていたときは納品第一でいっときの完成を迎えたものの、運用において取り返しのつかないコストを払う羽目になった例も幾つか見た。
「短期的には安くつくが、長期的には高くつく」問題にどう対処しているのか気になるところ。
余談だが、システム開発における"外注"も短期的には安くつく（かもしれない）が長期的には高くつく可能性の高いものだと個人的に思っている…。このあたりは『エンジニアリング組織論への招待』にもより詳しい説明があるので深掘りしたい方はどうぞ。
適切な契約の交渉と納品物のクオリティを監督する能力が、社内に存在しない場合、仮に一時的に満足のいく関係を築けたとしても、長期的には、蓄積された取引コストを引き受けることになります。
もう一点余談だが、長期的観点という名目でのオーバーエンジニアリングは同記事中での指摘と繋がるものがあるかもしれない。
そもそも運用は？
これは単純な疑問で、そもそも開発したものの運用はどのように扱われるのか気になる。
受託開発における保守案件のようなプロジェクトが始まり、nヶ月単位でまた解散と集合を繰り返すのだろうか？
ビジネスとの分断
プロジェクトが発生するまでの流れを超大雑把に考え、
起案・企画 → 見積・予算確保 → 開発開始
という流れになるとすると、開発者が参加するのはどこからか。最右端の開発開始からだとすると、すでに作ること・作るものが決定してしまっていたりしないだろうか。
その場合、開発開始〜開発中にプロジェクトの根本的な欠陥に気づいたり、見積・予算の不確実性に振り回されたりしたときに「やることは決まってしまっているので覆せない」みたいなことが起きないだろうか。
そうしたなかでビジネスサイド（という言い方はあまり好きではないが）とエンジニアリングチームのパワーバランス（という言い方もあまり好きではないが）において前者が強すぎる事に対し、エンジニアリングチームから不満があがったりするかもしれない。
話が飛躍するかもしれないが、職能別にチームを区切ることで、開発者をテンポラリな労働力と捉える"外注感"や職能間の対立構造を生みやすいというのが個人の経験としてはある。
合わせて読みたい：
「開発チーム」で本当に大丈夫か考える - Speaker Deck
個人的観測範囲での潮流
個人的観測範囲においては、事業会社で製品開発しているところはプロジェクトベースをやめてメンバーを長期的に固定した職能横断型チームを作る方にシフトする潮流があると感じている。（それだけに上記記事の内容に意外性を感じた次第）*3
ざっくり言うならばタイトルの通りプロジェクトに付くかプロダクトに付くか、というのが一番の違いとも言える。
現職では上記のような問題（＋その他の幾つかの問題）に対処するため、特定のプロダクトの特定の機能・サービスについては個別のチームを設けることにした。このチームの中にWeb engineer, Designer, Product owner, iOS/Android Engineer, Data analystなど各々の専門性を持つメンバーを集め、長期的にプロダクトや機能を磨き込み、ビジネス上の目標を達成することを目指す、という形だ。
チームに対する帰属意識は高い一方で「何をするために集まっているのか」を中心に据えているため、記事中にある「日本の開発チーム」（以下に引用）とはやや趣が異なるかもしれない。
日本の開発チームはより参加しているメンバーによってアイデンティティを持つ団体になっている印象を受けました。何をするために集まっているのかより誰が集まっているのかの意識の方が高い気がします。チームの人と飲みに行ったり、チームビルディングのアクティビティーがあったり、社員旅行で基本チームメンバーとしか行動しなかったり、よりチームというユニットが中心になっている事が色々なところから伝わってきます。日本は元から上下関係を大切にする文化もあり、チームに関してもメンバーを育てる・メンバーの面倒を見る・チームの先輩から学ぶという意識が強いと感じました。
とはいえプロジェクトベースの開発とは異なるのは明らかだ。「ひとまとまりで動くことで意思決定の質と速度を最適化できるチームの最小単位」*4による開発は、SquadやTribeといった概念を用いて説明されるSpotifyモデルにも当てはまる。
これについてはWantedly社の記事などが大変参考になる。
SquadとOKR - 開発チームが無駄なく高い成果を出すために大事にしていること | Wantedly Engineer Blog
full-stack agile - Team Organisation: Squads, Chapters, Tribes & Guilds
また、近年隆盛を見せるMicroservicesの実践に伴うチームのマイクロ化においても達成したい組織・チーム構造はSpotifyモデルと似通ったものがあるのではないかと思う。
「これらはヨーロッパでなくアメリカでは？」という突っ込みがありそうだが、紹介した記事のタイトルでも「海外と日本でのソフトウェア開発職の文化」と二分してたので、まぁそこは大目に…。
所感なのでオチもないが、プロジェクトベースでも上述のような問題をうまく解決する手法があれば知りたく、もしくは上述のデメリットをプロジェクトベースでの開発に帰するのは誤りだといった指摘も歓迎です。「うちはこうしているよ」話も更に大歓迎です
*1:全てが同時多発的に頻発していたわけではなく、ぼんやりと感じつつあったものが爆発する前に舵を切った
*2:もちろんプロジェクト終了後に変更や運用が発生しない製品については関係のないことだ
*3:これに対する課題もあるのは承知の上 https://daipresents.com/2017/cross-functional-team/
*4:https://www.wantedly.com/companies/wantedly/post_articles/134301 より
