エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。
前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。
エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力を必要としない体制へ切り替えるサービスといった仕分けをしています。主要サービスの多くは開発体制の規模が小さかったため、内製化が進んでいる状況です。後編では、主要サービスであるが開発体制が大きいためほぼ内製化の進んでいなかった「カイポケ」の内製化をどう進めたのかと、そこからの学びを中心に取り上げます。
1. 主要サービスの改革に挑む
当時の「カイポケ」は、どのような状況だったのでしょうか？
田辺 カイポケは、2014年にサービスのコンセプトを変更して、従来から提供していた介護保険請求の機能に加えて、経営管理・ファクタリングなど介護事業者の経営改善に役立つ機能をワンストップで提供するサービスにリニューアルしていました。
このリニューアルはその先のビジネス展開で非常に重要なものでしたが、一方でサービスの機能を急速に増やしたことで開発するソフトウェアの複雑さが増したことや、利用者の増加による負荷の増大など新たに解決しなければならない課題が見えてきている状況でした。
開発体制は、どうだったのでしょうか？
田辺 開発の拡大にあわせて開発組織の規模も大きくなり、当時は開発者とテストエンジニアを合わせると総勢100名を超え、それとは別にオフショアの開発チームがいるという大所帯になっていました。これだけで通常のサービスの1社分くらいの大きさの開発体制です。
最初はどのようなことから始めたのでしょうか？
田辺 ここでも最初にやったことは状況の把握です。私はこれまでにも自身として初めての開発現場に入っていき、課題解決をしていくという機会を何度か経験しています。そうしたときによく最初にチェックしにいくいくつかの要素というのがあります。このときもそこから状況を見に行きました。
見に行った点というのは次のようなものです。「要求の流れはどのようになっているのか」「起きている問題とそこへの対処の方針はどのようなものか」「構成管理はどこまでできているか」
なるほど。それぞれどのような内容なのでしょうか？
田辺 「要求の流れはどのようになっているのか」から説明します。要求というやや古めかしい言葉を使いました。これは少し広義にサービスとしてのカイポケへ求められる期待全般を指しています。カイポケのようなSaaSには、利用しているユーザーからの要望という形の期待もあれば、社内のセールスやカスタマーサクセスといったサービスを一緒に支えている人たちからの依頼という期待もあります。
こういったバックログをつくる一歩手前くらいの要望や意見、依頼といったものが、どこからどのように来ているのか、それを誰が知っているのか、それをどのように評価しているのか、「やると決めたこと」となるまでにどのような意思決定のプロセスがあるのか。そういったことを理解するのが、最初の「要求の流れはどのようになっているのか」というものです。
次に「起きている問題とそこへの対処の方針はどのようなものか」です。組織で起きている問題を理解しにいくには、起きている問題を具体的に見てみるのが一番です。そのときに見るのは、なにが起きているのかということ自体よりも、「それをどのように扱っているか」というプロセスのほうへ注目します。起きている問題をどのように評価しているか、そのときにどういった点を考慮しているか、解決すべき点をどこに置いて、どのようなアクションをしているか、その過程の意思決定ではどういうロジックで考えているか。こういった一連の流れを「自分だったら同じ問題をどう扱うのか」と比較して評価します。こうすることで、その現場の癖や制限といったものが見えてきます。
最後に「構成管理はどこまでできているか」です。これは単純にバージョン管理ツールが使われているかということも見るのですが、もう少し広い範囲を見に行きます。本番へデプロイしてユーザーがさわれる環境をつくるために、なにをどこまでどうやって管理しているのかを見るのが基本です。管理されている資源から環境を構築できるのかというのが次に見ている点で、構築された環境で変更が本番へ適用されるまでにどういう段階があり、それぞれでどういう品質が実現されているのかというところまでを見に行きます。ここは改善活動の基礎になるため、最初に見に行くことにしています。
見に行った結果、どんなことが分かったのでしょうか？
田辺 知りたいことを見に行った過程では、当然、実際に働いている人たちからはいくつもの課題や不安の声が挙がっていました。こういった場面で、リーダーシップを発揮する役割の人がするべきことは問題に構造を与えて、そこに優先順序をつけることです。なにを問題とみなして、それがなぜ起きているのかを解き明かして説明することが最初のステップになります。
このときに私たちが重要な問題だとみなしたのは次のものでした。「要求の管理があいまい」「問合せ対応やそれにまつわる作業が多く日々が消耗戦になっている」「内部品質向上のための組織能力が不足している」「ドメインである介護保険請求がそもそも難しい」
「問合せ対応やそれにまつわる作業が多く日々が消耗戦になっている」というのは新しい話ですね。これはどういう点で問題だったのでしょうか？
田辺 消耗戦というのは大量の人や時間を投入しながら、そこから未来へつながる価値が得られない活動の比喩として使っています。カイポケでは介護保険請求という非常に複雑な計算を伴う業務を扱っていて、この使い方や挙動についての問合せへの対応を開発チームでも行っていました。カイポケには充実したコールセンターの専任チームもあるのですが、問合せの内容によっては、コードを読み解いてプロダクトの詳細な仕様を調べなければわからないことや、バグなのか正しい挙動なのかを判別してお客さんへ回答をする必要があり、介護保険請求の業務の締日までに対応をしないとお客さんの業務が止まってしまう*1ような問合せもありました。とくに月次の請求業務の締日間近の期間では、こういった問合せの頻度が高く、開発者が緊急度高く対応する必要がありました。
そうした状況の中で、日々のユーザーの困りごとを解消していくためにアドホックな対処をしていくこともたびたび起きており、それによってマニュアルオペレーションでの定常作業が増えていくといったことが起きていました。
利用してくれるユーザーに迷惑をかけたくないという一心で日々を回していくことへ強いコミットメントを持っている組織でしたが、そうした状況に疲弊している人も増えてきていました。
ここで問題視したのは「問合せへ対応していること」ではなく、「問合せ対応とそれにまつわる作業によって、そういった作業が発生する状況の根本解決へ時間を使えていない」という点です。結果的に個人の熱意を燃料にして日々はどうにかなっているものの、将来に向けての問題解消の見込みはないという状況が生まれていました。
これは問題を抱えながらもコミットメントが高い組織が無自覚に陥りがちな罠で、あちこちで見かけることがあるため、「消耗戦の悪魔のループ」という呼び方で説明をしています。
2. 混乱する現場でよく見られる、消耗戦の悪魔のループ
「消耗戦の悪魔のループ」とは恐ろしげな響きですね。どういうものなのでしょうか？
田辺 このループは、まず品質が悪いソフトウェアがあるというところからスタートします。ソフトウェアの品質が悪いと、デグレードが起きたり、必要な機能が不足したりします。すると、それを解決するために割り込みの作業が発生します。バグがあればその調査や修正の対応が必要ですし、機能不足のときにはそれに伴うオペレーションの作業が発生したりします。その割り込み作業がゆとりを奪って、さらに品質が悪くなるというループです。品質の悪さに対して個人の頑張りと労働量で支えているのですが、何か手を打たないと、時間とともにつらさが増していきます。構造としてジリ貧になるんです。日々が忙しくてつらいと言っている現場は、大体こうなっています。
「消耗戦の悪魔のループ」はどうやって抜け出せばいいのでしょう。抜け出し方はあるのでしょうか？
田辺 抜け出すためにはループを逆に回す必要があります。どこを起点にループを逆に回していくのかですが、まず、無理やりゆとりを作り出すことから始めます。よくやるのは、「固定の時間をゆとりのための時間として確保して守る」「理解を求めて依頼を断る」「チームを分けて割込から守る」といった手段です。こうして作ったゆとりの時間を品質の向上へ投資をしていきます。大事なのは品質へ時間を投資するというときにどこへ投資するかです。
カイポケではどこへ時間を投資することにしたのでしょうか？
田辺 この時点で決めていた投資対象は主に2つです。一つ目はインフラの体制強化とオンプレミスからAWSへの移行です。内部品質の向上が一朝一夕ではできないことがわかっていたため、地道な改善をしていくための時間を稼ぐ魔法を考える必要がありました。そこで強力な外部のインフラエンジニアを頼って一気に体制強化をして、アプリケーションを改善するまでの間の安定運用を実現することにしました。偶然そのタイミングで前職の優秀なエンジニアがELASTIC INFRA というインフラの総合支援サービスを始めるということを聞いていたため、事情を話して協力してもらうことにしました。
二つ目の時間を投資する対象は、カイポケのコアのドメインである介護保険請求の改善です。Vertical SaaS であるカイポケは機能が多いため、全面的に改善に取り組むよりも、難度が高いところを局地戦にして戦力を集中させていくという方針を立てました。
3. 開発現場再生の 3 ステップで改善を進める
消耗戦に脱線しましたね。状況把握を進めた結果、いくつかの重要な問題を設定したという話でした。そこからどのように開発体制を立て直したのでしょうか？
田辺 ここでは次の3つに取り組みました。
まずは、全体の流量コントロールです。それまではさまざまなレイヤーの個人間での依頼や交渉で決まっていることもあった要求を、一元管理するようにしました。私は「やりたいことを全部並べて一覧に見えるようにして、今なにが一番大事か順番をつけて意思決定する」というのはとてもパワフルなツールだと考えています。期日ではなく重要さを評価して順序をつけるというのは大きな発明です。最初はなによりもこの実現に取り組みました。なぜなら、ゆとりをつくるために「やらないこと」を決めたいからです。順序がないと「やらないこと」を決めるために個々の依頼や相談に対してそのたびの交渉をすることになります。
二つ目は、消耗戦の解消です。これには消耗戦が起きている原因を理解して直していく必要があります。日々の問合せややっている作業が発生している理由について、理解を正しくそろえます。問合せや作業が低品質や機能不足によって発生するというのは、毎日の目の前のことを進めているときには気づきにくいものです。目の前のことを進めることも緊急度が高く大事ですが、同時に起きている現象について理由を正しく理解して、理由の解決にも一定の時間を費やしていくことが重要です。
そして三つ目に、内部品質の向上です。構成管理とユニットテストと自動化といった基礎の整備*2を進めること。そして、本番にリリース可能なソフトウェアの品質基準を適切に置くこと。それを設計とレビューによってコードを通して共通理解としていくこと。チームやプロセスによってソフトウェアの内部品質を担保していきます。
この内容を「開発現場再生の 3 ステップ」と呼んで進めていました。
進めていく中で思うようにいかなかった部分はあったりしましたか？
田辺 たくさんありました。今でも起きていたこととそこへの解消の道筋というのは大筋で外していなかったと思います。ただ、それでも過程では思ってもいないような形の苦労というのは多かったです。失敗もたくさんしています。 その中でも最大のものは、介護保険請求というドメインの難易度が高いこととそれにまつわるアプリケーションの改善が想像より何倍も大変だということです。
正直、技術的な課題だけであればもっと短期で課題の解消をしていけたと思うのですが、それが複雑なドメインとからんでいることで、技術の課題を単体で解消することができないということも多いです。ドメインに根ざしたところの難度を適切に見積もるというのは方針を考える上で重要だなと何度も学びました。
カイポケの改革は 3 年を超える長期戦ですよね。そうした中で苦戦や失敗をしているとビジネスや経営からの重圧というのは強くなったりしないんですか？
田辺 もちろん早く解決をしていきたいよねという話はするのですが、実は苦戦や失敗に対しての非難や重圧というものは取り組んでいる期間を通じて一度もなかったのです。これは他の会社ではあまりないことかもしれません。
エス・エム・エスという会社は仮説検証を非常に大事にしている会社です。そして、思考することも大切にするのですが、ある程度から先はやってみないとわからないという実践から学ぶ会社でもあります。それが建前でなく徹底しています。たとえばこうした改善をしていく場合にも、アプローチの良し悪しがわからない程度に様子を見ながらやって無難な変化になるよりも、ある程度結果がはっきりと出るくらい試しきることを良しとするという文化があります。もちろん、試すということは失敗するということもあるのですが、それは「仮説の検証が進んだ」としてプラスにとらえるのです。
そのため、私はこのカイポケの変化を進める過程で失敗に対して謝ることを求められたということがありません。プロフェッショナルとしての仕事が前提にはなるのですが、その信頼の上で働けるというのはやりやすい環境だと感謝しています。
4.エス・エム・エスにとって、技術活用のあるべき姿を実現するために
あらためて、時間を戻せるなら、やり直したいことはありますか？
田辺 小さく試すという話とは矛盾しますが、文化や組織など仕組みを大きく変えにいくタイミングというのは別の選択肢があったなと思います。今振り返ると、もっと全体に対して大きく変えにいくことで、変化が早まった可能性があります。状況の変化を把握して、そのときに合ったやり方に変えるタイミングが大事なんだと思います。
内製化の場合もそうですが、変化に適応できる人とできない人が出てきます。でも、最初のうちは、変化を起こす人は少数派です。小さな変化が蓄積していくことで、それが多数派になってくる。そういう変化のフェーズに合わせて、やり方を変えるということです。
理解が進んでおらず変化が起きていないときに、一気にいくとぼろぼろになります。だから、初期の段階では、戦力を集中させて個別に進めていく。そのため、どうしても時間のかかる場面が出てきてしまいます。
一方、理解が進んできたフェーズでは、総量を増やして一気にいったほうが、全体の変化は早くなると思います。
組織の文化や制度・教育・採用などを含めて、次回やるなら、一気に変えるタイミングをもうちょっと早くしてもよかったかもしれないですね。
今後、エンジニア組織について、どんなことに取り組んでいきますか？
田辺 内製化が進み、サービスの成長やお客さんに向けてプロダクトをどう良くしていこうかというフェーズに来ています。ようやくエス・エム・エスの戦略のよさを活かしたうえでプロダクトによるさらなる成長を求められる段階に来たと思っています。
ここからは、技術によってプロダクトがより大きなインパクトを残せるようにしていきたいと考えています。エス・エム・エスのやっているプロダクトは社会に直結しているため、私たちが良い仕事をするとそれが世の中を良くすることに自然とつながっていくのが良いところです。これまでに培った技術でこれからの社会を良くしたい人にはぜひ一緒に取り組んでほしいと思います。
最後までご覧いただきありがとうございました。
内製化という難儀な仕事に向き合う技術組織の責任者の方の一助になればと思い前後編とまとめましたがいかがでしたでしょうか。
田辺が最後にも触れていましたがエス・エム・エスは実践からの学習を徹底している仮説検証を非常に重視している会社です。開発の一つ一つの現場もそうですが、組織の大きな変革においてもこの思想で長期目線で取り組んでいます。
もしこの記事を読んでいただき、このようなエス・エム・エスに興味をもっていただければ、ぜひカジュアルにお話しできれば幸いです。
