開発組織について学んで考えたやつ
7月は開発組織について改めて勉強してたので、その内容を書きます。
開発組織がどうあるべきか、自分がどう振る舞うべきかが主眼。
問題意識
今までいた会社だと、ウォーターフォール開発とアジャイル開発を経験していて、自社開発企業のアジャイルの方が圧倒的に品質高い、というのを経験している。
ただアジャイルといっても厳密なスクラムではなくて、なんちゃってアジャイルではあった。チームが上手くいっているときと、そうでないときも経験した。
一昔前のWeb系企業のチームビルディングは「優秀な奴を採用して、ミニマムルールで運営せよ」だったと思うけども、なんとなく空気が変わってきているのかなと思う。便宜上この記事では「ドリームチーム方針」と呼ぼう。今でも採用基準高く保って、少数精鋭のスモールチームつくって、自由に開発させるドリームチーム方針は、自社開発企業の人材運用のキモではある。けれどWeb系企業も年季入った会社が多くなってきたので、開発生産性の測定だとか人材評価だとか効果計測とかそんなんが求められるようになってきた。コアなプロダクト開発を行うために管理系タスクを切り捨てがちなドリームチームと相性が悪い。
ガチのスタートアップならドリームチーム方針でいいと思う。いや、でもスタートアップだとそもそも人が集まらなくて、なんとかかき集めないといけないという問題があるか。どっちかっていうと売上が立ってきて以降の話。
一般的には社員数100人超えたあたりから組織化を考えなければいけない。ただ何も考えずに組織化すると、単なるフィーチャーファクトリーができるだけになる。
問題意識としては、組織の規模が一定大きくなっても、開発組織としていい感じの状態を保つためにはどうしたらいいか、というところ。
学んだこと
そんな問題意識から、アジャイルについて改めて学び直すことにした。あとたまたまFindyが開発生産性カンファレンスなるものを開いていたので、それも見た。
「アジャイルサムライ」
まず大昔に読んだ「アジャイルサムライ」を改めて読み直した。
https://amzn.to/4euHivc
これ昔受託開発でやってたときに読んで、「こんな開発したいなあ」と思った本だけど、今読んでも有益だった。今も俺のソフトウェア開発の姿勢はこういうことだと思う。形式より本質を、仕様書より動くコードを提供する。
でもさすがに内容は古くなっているし、今の自社開発企業とはだいぶシチュエーションが違う。この本だとシステム開発の発注元がある想定だけども、自社開発だとそもそも自分たちのプロダクトだから、納品なんて概念もないし。
もう少し厳密なアジャイル開発
そもそもアジャイル開発とかスプリントイベントとかもうちょっと厳密に知ろうということで、調べているとちょうどいいブログがありました。吉羽さん(ryuzee)というアジャイルコーチが公開しているブログ。
フィーチャーファクトリーの記事は先に引用したけども、それ以外にもいい記事がたくさんある。Deep Diveシリーズが特に良くて、
これらは全て一読の価値がある。
アジャイル開発の原理に従えば、開発組織のベスプラが見えるかなーと思って調べてたんだけど、逆に厳密なスクラム開発は違和感を覚えた。たとえばスクラムガイド2020にプランニングは最大8時間、レトロスペクティブは最大3時間（※スプリントが一ヶ月の場合）と書かれているらしく、シンプルに長すぎんだろと思った。
いやでも長すぎると感じるのは会議内容が俺のイメージと違うのかもしれない。仕様詰めたり話し合ったりをプランニングの中でしているイメージなのかな……
過去iOS開発をしていた会社は、なんちゃってアジャイルだと思っていたけれど、そのぐらい緩い運用の方がまだ幸せな気がする。あとスプリントゴール決めたことないけど、これはあった方がいい気がする。「このスプリントの目玉はこれです」みたいなのはなんとなくあったんだけど。
スクラム開発で上手くいく人たちはたぶんスクラム要らないし、チーム運営上手くいってない人たちが導入して失敗事例積み上げていってそうな印象。いずれにせよスクラム開発、そんなに幸せにならないような肌感。実際にスクラムでやったことないので、強くは否定できないけども。
こんな記事もあった。
開発生産性
開発生産性カンファレンスから、二つ引用。
ベロシティ測定が地雷というのはあるあるな気がする。
両プレゼンともに納得感が高い内容だけど、じゃあ現場でどう開発生産性の測定を運用するかは特に答えが明示されていないので、現場のベスプラみたいなのを漁る必要がありそう。
「測りすぎ」
ちょっと前に話題になった本で、未読だった。自分が抱えていた問題意識と合っている内容なので、読むことにした。
https://amzn.to/3UxoTEU
歴史学者が大学運営に関わったときに定量評価と戦ったのをきっかけに、多くの組織で定量評価が上手くいっていないことを指摘している本だった。ソフトウェア開発チームに落としこむと、KPIを立てて盲信するのではなくて、ソフトウェアの目的をしっかり論理立てて考えて、その上で計測をしよう、になるのかな。
チェックリスト
- どういう種類の情報を測定しようと思っているのか？
- 情報はどのくらい有益なのか？
- 測定を増やすことはどれほど有益か？
- 標準化された測定に依存しないことで生じるコストはどんなものか？実績について他の情報源があるか？
- 測定はどのような目的のために使われるのか、言い換えるなら、その情報は誰に公開されるのか？
- 測定実績を得る際にかかるコストは？
- 組織のトップがなぜ実績測定を求めているのかきいてみる
- 実績の測定方法は、誰がどのようにして開発したのか？
- もっとも優れた測定でさえ、汚職や目標のずれを生む恐れがあることを覚えておく
- ときには、何が可能なのかの限界を認識することが、叡智の始まりとなる場合もある
「フィードバック入門」
ちょっと趣旨ズレだけど、「フィードバック入門」というのも読んだ。これはどちらかというと組織の中でネガティブなことをどう伝えるか。
- コンフォートゾーン/ストレッチゾーン/パニックゾーン
- コンフォートゾーン=悪とされてるけど、専門職だとその限りではないよなと最近思っている。その人のスキルが十分高くて、本人もコンフォートゾーンにいるの納得していて、会社にメリットあって、がそろえば別にいい気がする。たとえばベテランの医者とかはコンフォートゾーンに居続けても許される。スキルを保つ努力ができれば……現実的にはぬるま湯にいてだんだん錆びついてくるパターンは多い
- SBI評価を伝える。これはいいと思う
- Situation, Behavior, Impact
- 具体的な評価
- 「xxのとき、xxという行動して、xxという影響があった」
- フィードバック、どうしても感情的になってしまうので、SBI評価に従うと良さそう
研究の知見によれば三分の一のフィードバックはパフォーマンスの向上につながるどころか低下につながっています。フィードバックは諸刃の剣です。これから紹介する手順を参考に適切なフィードバックを行うことが重要です。
- フィードバックを実施した結果、しなかったより悪くなったケースが1/3らしい。ここなんだよな
- 全体的に中間管理職向けというか、おっさん向けの記述
- よくある反論パターンとかは実践的で良いかも
- アンコーチャブルな人がいること、などにも触れられていて良かった
- 10年前の本で1on1が先端的な取り組みみたいな扱われ方していて、ちょっと古い
- 部下全員と週1で15〜30分の1on1やってるみたいな人出てきてるけど、やりすぎじゃない？
- 牧歌的なことを言えば、フィードバックの仕組みが必要ないくらい自律的な人で固めたいよね
- というか一定レベル以上のソフトウェア開発チームはそうなってる気がする
- 自律的チームにおけるフィードバックは、互いに即時にされるべき。建設的なフィードバック文化の醸成ができてると良いのかな。それはどうしたらいいんだ？
- 昔いた会社だと「遠慮は悪」っていうキャッチコピーがあって、互いのフィードバックを尊重していて、それは良かった
- 人材の成長文脈で、コンフォートゾーンにいると悪いって扱われがちだけど、専門知識あって会社も容認してるんなら、コンフォートゾーン居続けるのも悪くないんじゃないかと思ったりしている。腕利きの外科医とか同じ球団に居続けるプロ野球選手とか
「情熱プログラマー」
これはもう完全に組織じゃなくて個人の話で、他の本より更に内容が古いけど、メンタルの持ち方なんかは今でも参考になる。
https://amzn.to/46ug0TP
「一番のヘタクソでいよう」はサイコーのメッセージ。
特に「今やってる仕事を毎日書き出してみて、どのくらい日々の作業にモチベ保ててるか」はホントに大事なことで、これやって悲惨になる仕事ってどれだけ給料もらえてもいい仕事じゃないんじゃないかな。所謂ブルシットジョブ。
北極星
開発組織の話に戻る。North Star Metric（北極星指標）という考えがあるようで、プロダクト開発においてはこれがいいと思った。具体的には、
Follow Your North Star
Of all KPIs, there’s one big kahuna known as the North Star Metric (NSM) that everything else ladders up to. This metric should reflect the core value you’re providing to your customers.
For example, here are some NSMs for iconic customer-focused brands:
- Airbnb: Nights Booked
- Amazon: Number of Purchases Per Month
- Facebook: Monthly Active Users (MAU)
- Medium: Total Time Spent Reading
- Netflix: Hours Watched
- Peloton: Workouts Per Month Per Member
- Plaid: Bank Accounts Linked
- Quora: Number of Questions Answered
- Robinhood: Funded Accounts
- Shopify: Revenue Per Merchant
- Spotify: Total Listening Hours
- Uber: Number of Rides
- Zoom: Weekly Hosted Meetings
のように、我々のプロダクトの一番価値はここにあって、だからこの指標を見る、というもの。
昔個人ブログにGoogle Analytics入れたとき、ユーザーの平均サイト滞在時間を気にしていたのを思い出した。
プロダクトorサービスの性質によって何を見るかは異なるし、モノによっては定義するのが難しいものもあるかもしれない。でもこれが定義できてると、プロダクトが長期的に見て、本当に正しい方向に進んでいるのかどうかが確認できる。まさに北極星。
今考えてること
以上がインプットで、こっからが個人的な考えです。開発組織はたぶんこれが上手くいくよね、と思っている内容を列挙していきます。
- ベロシティ測定は不毛なのでしない
- ソフトウェア開発の成果の質 x 量を測定するのは非常に難しい
- 仕事してない人を明らかにしたい目的であれば、普通にマージされたプルリクエスト数とかを突きつければいいのでは？
- 厳密なスクラム開発も不毛なのでしない
- スクラムを参考にしつつ、自分たちに合った会議体にアレンジしていくのが幸せそう
- 基本的なスプリントイベントは合った方が良い。プランニング、朝会、ふりかえりは固定で
- 正しい意味での心理的安全性をつくる
- 単に「安心感が高い」職場ではなく、「私の発言はきちんと受け止めてもらえる」という意味
- 間違っているかもしれない知識や「知りません」と言える雰囲気、同僚とフィードバック（表現には気をつけて）が送り合える
- たぶんプロダクトの改善に対する熱量が全員で共有できていることがポイントになる
- 「あなたが嫌いだから言っているのではなくて、ここを直してもらえればプロダクトがもっと良くなるから」という共通認識をつくれるか
- リーダーのメッセージングが大事？
- テックカルチャーを醸成して保つ
- Slackで最新トピックでワイワイしてるだけでも良い
- 記事のURL無言で貼って特に中身に触れない人が増えはじめると黄信号
- 登壇とか技術記事とかは北風と太陽の太陽的にやるべきで、会社としてノルマつくりはじめると逆効果になりがち
- ↑この2つに関しては、カルチャーブックみたいなのつくるといいんだろうな。Do List / Don’t List
- 組織レベルは大まかに下記の4段階だろうか。ティール組織とか自己組織化とか言うから、なんか理論ありそう
- ステイクホルダーとの期待値調整を行えている
- 経営、マネージャー、ユーザー、他チーム
- ユーザーだけ考えれば良いのが理想だけど、現実的には会社で仕事している以上は経営層やマネージャー陣ともちゃんと課題感の認識を合わせておく必要がある
- 適度に人が入れ替わってる方が健全
- ずっと同じ人で運営していると慣れた方法で最適化されてしまうので、技術負債が溜まりやすくなる傾向を感じる
- 結局、優秀な人をどれだけ採用できるかはコア
- でも個人の優秀さに甘えない
- 開発組織においても空気感が大事だったりするので、なるべく空気を良くする
- 褒めを増やす、チームの成果を確認してモチベ高める、ユーザーのポジティブな声を共有する、など
- これとフィードバック文化との両立が難しい。空気悪くするからネガティブなこと言えなくて、ぬるま湯になってしまうとこれもよろしくない
- 適温に保つのは難しいけども、ただそれがチーム運営の核心部分かも。プロ野球の強いチームって、和気藹々としてるんだけど、厳しいことも言い合うからなあ
- リーダーシップとフォロワーシップが大事
- アジャイル組織だと全員が主体的に動くから、その意味では全員リーダー
- とはいえロール上のリーダーがリーダーシップあるかないかは大事
- リーダーが孤立しないように、他のメンバーがフォロワーシップ発揮するのも大事
この辺りが開発組織運営について、「たぶん正解」っぽいところ。
悩んでいること
現在進行形で悩んでいることもいくつかあります。これも列挙すると。
- 組織として不毛な計測が進行していったときにどう対処すべきか？
- 「データに基づいて動く組織！」と言うと基本反対されないだろうけど、大局的に見るとムダなことをしているとき
- ダイエットしようとしている人間が、病院で精密検査受けて細かいデータを確認して綿密な計画立てるのと、食事と運動に気をつけて毎日体重計乗るのとだったらどちらが成功しそうだろうか？体組成計ぐらいは買っても良いかもしれないけど
- 空気を良くするのと、建設的なフィードバック文化の両立
- むずい
- ステイクホルダーとの議論が十分にできないときどうするか？
- たとえば経営陣がめちゃくちゃ忙しくて、あんまりコミュニケーション取れないとか。「現場でいい感じにやっちゃってよ〜」みたいなときとか
- どの程度会社としての強制力を発揮すべきか？
- 「毎日9時にはオフィスに出社していてください」とか「毎日日報を提出してください」とか、会社としての強制力を発揮する場面がある
- Web系自社開発企業だとめちゃくちゃ緩いので、強制力がほぼなかったりする
- リモートワーク環境下だと更にそう
- 組織としてやっていくために、ある程度強制力あった方がいいんだろうなと思ったりもした。「今回の全社会は対面コミュニケーションで行いたいため、原則現地参加をお願いします。組織づくりのためにご協力お願いします」みたいな
あるいは正解がない領域なのかもしれないけども。少なくとも自分の中の理想は持っておきたいところ。
（了）