自社の開発組織の強みを定義する

ようやく涼しくなってきましたね。もう少し漸進的に気温が下がってほしい。プロダクト開発部部長の塚本@hihats です。

前置き

この二、三年くらいは個人的にシステム思考への傾倒があり、以前ここに書いた変化に適応するソフトウェアアーキテクチャと組織構造への道程も、Qiitaに書いたソシオテクニカルアーキテクチャ概要もその系譜の記事だった。今回は、エレガントパズルという書籍を読んでいて、そこかしこにドネラ・メドウズ公の話が出てくるので改めて私もシステム思考について記事を書こうと考えていた。

そんな折、他社のCTOと話す機会があってそこで「自社の開発組織や開発力にそこまで特別さを感じていないんですよね」という話を聞いた。実は過去にもそれはあって、自社のWebプロダクトで会社の利益を上げているにも関わらず、開発の責任者がそう思っているケースは少なくないのかもしれない。

一定の市場シェアを獲得していて、今生き残っている時点で何らかの競合優位性があるはずではあるが、それは先行者利益なのか、次々と生まれる革新的なアイデアなのか、顧客体験の良さなのか、外部環境の変化なのか、要因は様々である。

いずれにしても、「開発組織として可視化しやすいスループット力（一般的に技術力と呼ばれやすいもの）を強みとするのが本当に正しいのか、それが本当に事業貢献をしているのか」あたりの疑問は常について回っているといった様相がある。

開発生産性がやたら取り上げられる昨今、なおのこと向き合うことから逃れることはできない命題であるし、それについて書くことにした。

突きつけられている課題

• ソフトウェア開発者をやっていると、ソフトウェアで問題解決をしたり価値提供をするのが当たり前であり、それを疑いもせずエンジニアをやってきていることは特段珍しいことではない
• 一方で、ソフトウェア開発をせずに問題解決をしたり価値提供できるのであれば、リードタイムは短く、技術的負債も発生せずで、そのほうが嬉しかったりする

この矛盾はありつつ、手札としてソフトウェア開発力を備えていない企業が生き残るとは思えないし、いざ地上戦になったときに製品開発力がないことによる「戦う前からの敗戦」を避けることはできる。そもそも新規開発に限らず、長期的に製品を保守運用するだけでも相当の技術力は必要である。

事業会社における技術戦略とはそういうものであるという解釈のもと、では自社の開発組織の強みとはなんなのかを抽出してみる。

自社の開発組織の強みの抽出

How to

定量的には例えばFour Keysの指標が他社と比較して高いなどが上げられるかもしれない。それらで言えば部分的には平均よりは高いらしく（Findyさん調べ）、一定強みといっても過言ではないとは言えそうだった。がしかし、それと事業収益性との相関がまだ見えていない状況で強みとするのは時期尚早という判断で除外した。

ではそれ以外だとなんだろうというところで、結果としては複数人から一定共通して上がる我々ならではの定性的な強みがいくつか上げられた。

複数プロダクトによる技術の多様性

クラウドワークスでは複数プロダクトを運用しているが、技術選定に関してはハッキリ言ってバラバラである。

各プロダクトの利用技術（ごく一部）

統一しようと思えばできなくもないが、今後もM&Aによる子会社が増えることを考えると、統一することはどのみち現実的な選択肢ではない。

であれば、それぞれが好きな（つまり状況に適した）技術を採用するほうに舵を切りつつ、横断的関心事や、専門性＆学習コストが高い技術領域に関してはプラットフォームチーム化するのが妥当という方向性になる。

結果として

• 技術に限らず、SaaSやプラットフォーム、Embed AIプロダクトといったプロダクトの型も多様
• マッチング領域から工数管理領域までドメインも広い
• 開発プロセスも基本現場任せであり、チームの特性や成熟度にあったやり方を選択している（英語を使う部もある）
• 異動によって必然的に新しい技術を学ぶ環境にはなっている

これらは強みと言えるが、特異性と言ったほうが近く、見方を変えると一方で

• 人材の流動性という面では異動してすぐ活躍できるかという点での不安などがある
• 局所的に技術を突き詰めたスペシャリストは生まれにくい土壌になりつつある

これらのデメリットは、それでいいのかという課題はつきまとう

テクノロジーカンパニーである

ここでいうテクノロジーカンパニーとは

「技術を正しく使える」

という意味で、開発者一人ひとりにその意識があることを指す。

言い換えると、新しい技術への関心はもちつつ、決してそれを使うことが目的にはならない集団とも言える。

※もちろんテクノロジーカンパニーには「経営が技術を理解して適切な技術投資をできる」という文脈もあり、それはそれで必要ではあるもののここでは一旦脇に置く

自社の開発組織の強みとしては基本的にはこれに尽きるが、シンプル過ぎるのでこれに従属した強みも列挙していく

健全性、持続性、信頼性への責任

数年後まで持続的に運用する前提で品質を考慮して設計するのが当然の考えとなっている

• ポストモーテム文化
• 内部品質と外部品質両面からSLIを定めて運用（整備中）

• 不正利用への厳正さ

  ※ここで言う不正利用とは、利用規約に違反した利用のこと

  ※※日々多種多様に発生しているので、不正に対応しきれているとは言えない

• 技術的負債を解消していく文化

  • 技術的負債に対する向き合い方がチームを超えて共通してある

その他の特性

• 課題内在性認知負荷に対する耐性が強い
  • 複雑で難解なドメイン知識に立ち向かえる
• 越境を厭わない

• アジャイル

  ここではアジャイルの定義の正誤については議論の対象にしない

• 適切なリーダーシップ

  • 分からない人がいれば手を差し伸べるのが当然で、優しさというよりあくまでコミットメントのためにそうしている
  • 育成も同様
• 刺激と成長
  • 技術と知識に優れた人が積極的に継承の姿勢を見せることで、それに続くことが自明の態度である
• わからないことは聞く
  • 真面目な仕事人は自分でなんとかする方向に寄りがちなので、あえて即白旗を上げる方向に寄せて助けを求める心理的ハードルを下げる（白旗文化）
• OSSや社外への貢献

エンジニアに限定しなければ

• POなど開発職以外のメンバーも上記特性への理解があり、部分的にエンジニアリングをしている

これらはマネジメントからのフィードバックによって奨励されてきた行動もあるが、会社全体のカルチャーとも相まって、意図せずして生態系としてそうなっている側面もある。 ここまで書いて、結局システム思考の話に戻ってくるんじゃない？と気付いた。はい、長くなるので今回はここまで。

まとめ

自社の開発組織の強み

• 技術の多様性
• テクノロジー（を正しく使える）カンパニー
  • 健全性、持続性、信頼性への責任
  • 変化に対応する特性

といったところになった

何をもって「強み」とするかは、どうしても相対的な見方が入ってきてしまうので、私含め数人が他社と比較して自社が優れていると思う点になった。 上記に挙げたいずれも、そう容易に組織に身につくものではないと考えていて、先人も含めた全員の積み上げにより作り上げられてきたという自負がある。 （逆に積み上げられた負債もあるが、それに立ち向かっているという点では強さと表裏一体である）

そして、こうやって言語化することで改めて見えてくることがあり、内外に発信することによってより強固になっていくのだろうという仮説があるので、これから検証していく。

We are hiring!

上記のような強みをもつ開発組織で働いていきたい方、こちらからお待ちしてます！ herp.careers