プロダクト拡大と開発生産性

こんにちは。LayerX CTOの松本(@y_matsuwitter)です。今回は開発生産性アドベントカレンダー17日目の記事となります。

開発生産性のカレンダー | Advent Calendar 2022 - Qiita

今年のLayerXの取り組みについて書こうとも思ったのですが先日下記の記事でまとめてしまったので、今回は開発生産性に大きな影響を与える不確実性についてのポエムを書いてみようと思います。

LayerX開発組織の2022年を振り返る - LayerX エンジニアブログ

いうのも最近はプロダクト開発そのものよりも、複数の事業をより遠くからサポートしていく事が多くなりました。そのため具体的な取り組みよりも、その根底にある戦略が正しくあることをサポートすることが多くなりました。

この視点から開発生産性について書くことは多少普段と違う見方をEngineering ManagerやProduct managerの方へ提供できるのではないかと思っています。

特にプロダクト戦略面における不確実性は具体的な運用のHowより大きな影響を開発生産性に対して与える事が多いため、戦略と開発生産性ということについて触れていきます。

戦略と開発生産性

我々が開発するソフトウェアは前提として顧客に価値を継続的に届ける事業が先にあり、そのために使われるものです。そして事業とは不確実性の塊ですので、その不確実性に日々対処することが求められます。

この時、開発生産性とは、この事業の不確実性に対してソフトウェアをどれだけ追従させられるか、変化させられるか、という目線で語ることができます。目の前の事業にて新たな事実が明らかになり、それに合わせて変化しようという時に、ソフトウェアがどれだけ素早く追従し事業価値に貢献できるかが重要です。

開発生産性をあげようという時、プロダクト開発や、運用のHowをどうしようかという発想になりがちです。我々の目の前にはDevOpsやSRE、様々なEngineering Managementのノウハウ、Scrumやチームトポロジーなどなど魅力的なHowがたくさん転がっています。

しかし、ソフトウェアそのものより前段階にある戦略に方向性がない場合、ソフトウェア開発において行き当たりばったりで対応する場面が多くなり、結果的に生産性が落ちてしまいます。方向性なき最適化は早すぎる最適化につながったり、その後の柔軟性を犠牲にしていることもあります。高い開発生産性を実現するためには、明確な優先度付けの基準となる戦略がありきであると言えます。

ここで言う戦略とは、不確実性のある事業に対して、これまでの情報と経営者やプロダクトマネージャの意思を掛け合わせて作り出した取り組みの優先度付け（方向づけ）であり、また優先度高い取り組みを実現するために想定される仕組みの構築です。

この戦略による方向づけが全くの未知であったり一貫性がないものだと、ソフトウェアには度々想定していない大きな変化を求めることになり、結果として将来の開発生産性を落としていく要素となりえます。

組織もコードも戦略に従う

戦略が明確だと、そこに必要な機能群が明確になります。機能群が明確ということは、それを実現するために必要な人やシステム、プロダクトのあり方が見えてきます。

例えばLayerXのバクラク事業部では法人支出管理という市場で拡大するために埋めるべきピースを先に整理し、その中で重要な機能から順次展開していくというような考え方を取っています。すると、その機能に合わせたプロダクトやシステム、およびそれに対応する組織が見えてきます。現在ではバクラク請求書やバクラク申請といったプロダクト、そしてその背景にあるOCRチームなどの機能を、それぞれの改善速度が最大化されるよう組織とソフトウェアを一体的に構築しています。

1年半後の組織図からソフトウェアを逆算する

戦略、というより事業の行く末が見えていると、戦略を実現し開発生産性を最大化するのに必要な将来の各時点での組織とソフトウェアアーキテクチャのあり方が見えることになります。なぜなら、その時点で現実的に拡大できる組織サイズやマネジメントの人数、開発しうるものには限界があり、またスパン・オブ・コントロールや組織とソフトウェアアーキテクチャが一体であるという制約が存在しており、それほど多様な選択肢はとれないからです。

そして各時点での差分が見えているということは、起きるべき変化を予見するということにほかなりません。正確には予見することは難しいので経営上の意思表示ということになりますが。

例えば自分は1年半後の自社のあり方を常に意識するようにしています。ちなみに1年半に深い根拠があるわけではないですが、採用を開始して、チームを作り、こなれた状態にするのにそれなりの時間がかかるということ、およびおおよその想像しうる事業計画は1年くらいの期間を対象にしているため、ぼんやりとしか見えていない18ヶ月後をターゲットに置くことで強制的に長期を考えるきっかけとしています。

時点ごとに必要な能力を満たすために、どのような構造があるべきか、それは今の時点からどのような変化が必要かという大きな方向性が見えていると、これはソフトウェア設計にも跳ね返ってきます。マネージャ一人あたりのメンバー数から逆算される取りうるチーム構造の制約や、現状のデータベーススキーマやデータの量、ソフトウェアの複雑性等をふまえながら、求められる変化に追従できる設計を考えねばならないわけです。

図：開発生産性の土台には事業戦略がある

戦略とそれに必要な機能 => 組織とソフトウェア、という関係がある中で、戦略を満たし続けるソフトウェアを志向することは、開発生産性を落とさない上で前提となってきます。

万能の変化を遂げるソフトウェア設計というのは無く、常に我々はトレードオフの中でどの設計を選択するか、どのようなスキーマで、どこにどのようにデータを配置するか、どうやってソフトウェアの品質を測り、改善するかといったお題に向き合うわけです。その中でどの選択肢を取るか、この拠り所となるのが事業戦略なのだと思います。

事業に寄り添った高い開発生産性を実現するその土台に明確な戦略は欠かせないものです。

LayerXの場合

我々LayerXの開発組織では、例えばバクラクにおいて下記のような図を元に請求書処理を皮切りに爆速で複数プロダクトをリリースしていくことによる市場の拡大戦略を取っています。

そのため、例えば初期からID基盤が分離されていたり、プロダクトカットなシステム分離を志向しつつ、チームもそれに合わせて立ち上げていく、そのための採用パイプラインを作るなど取り組んできました。

特に今年は、よりプロダクトが増え、そして複雑なプロダクト間連携に向き合い、また人の増加に伴っても開発生産性を向上させ続けることを目指すべくEnabling Teamを設立しています。Enabling Teamがいることによって、例えば開発のテンプレート整備や連携に向けたプロトコルの設計・整備が進み、必要なタイミングで必要なだけアーキテクチャを変更できる世界を目指しています。

開発生産性への取り組みの一歩目として

ここまで戦略と開発生産性ということについて書いてみました。開発生産性を高める最初の一歩として、戦略を確認する・見直すといったことからまず取り組んでみることで、様々なテクニックがより効果的に活用できるようになるものと思います。

おすすめとしては、
①中長期戦略の整理
②①で確認された戦略と現状を比較したときの組織とソフトウェアアーキテクチャ中心としたフィットギャップ分析
③ギャップを埋める施策への投資
という順序で最初の一歩目の方向性を明らかにすることおおすすめします。これらの活動はマネージャとして意識して定期的に行うようにすることで、大きなズレが生まれる前にギャップを理解し埋めることに繋がり、長期的に開発生産性を高めるための基礎を築くことになります。

せっかくの年末ですので、今自分が取り組んでいる事業領域において今後どのような方向へ向かうのか、そのためにどのような能力を獲得せねばならないのか、超えるべきハードルはなにか、現状の振り返りとともに考えてみてはいかがでしょうか。

最後に

以上、抽象的な内容となってしまいましたが、私が開発生産性へ長期的に向き合うために考えていることとして事業戦略との関係性を書かせていただきました。

LayerXではこのような発想の元で長期間、健全に成長し続けられるプロダクトとソフトウェア開発組織をめざし日々良い文化や仕組みづくりに取り組んでいます。目指す先はまだまだ遠く、このチャレンジに一緒に取り組んでいただける方を絶賛募集しております。ぜひご興味ある方、カジュアル面談などでお話させてください。

LayerX採用情報