GMOペパボ柴田博志が教える。経営者も理解しておくべき「技術的負債」
GMOペパボ株式会社で執行役員 技術部長 兼 VPoE（VP of Engineering）を務める柴田博志（@hsbt）と申します。CTOの栗林健太郎さん（@kentaro）と共にGMOペパボのエンジニアをまとめています。
技術的負債、どこの組織にもありますよね。どうやって返済していますか？ 会社として技術的負債にどう立ち向かうべきか、そのコツは人のマネジメントにあると考えています。今回はflexy読者の皆様と技術的負債を考えていこうと思います。
目次
技術的負債に取り組むべき時期と意思決定のポイント
技術的負債には取り組むべき時期、つまり、負債を返済すべき時期にコツがあります。
技術的負債の「負債」という言葉はすごく的確な表現だと思っています。「今期は投資なので、負債が発生しても許容する」という会計上の負債がありますよね。テストコードがない、すごく読みにくいコード、などはサービスの動作には直接影響していません。会計上の負債と同じように、今のフェーズなら問題なし、と言えます。ただ、利益を優先して負債を後回しにして負債をためていくと、いつか利益にも影響を与えます。たとえば「他の会社は、エンジニアが50人100人いてもスケールするのに、うちは10人11人になっただけで、もう誰もシステムを教えることができなくて、現場が混乱している」といった話があります。または、エンジニアを投入しているのに、その人数に見合う機能やアウトプットが出てこない、リリースしたら不具合だらけ、といった具合です。
それではいつ取り組むのか。オススメは、ローンチ時期付近で会計同様、技術的負債を「監査」することです。
悪化した状況になってはじめて、経営陣が技術的負債に気づくパターンは多いもの。
実際の経理の場合だと、会計士や内部監査の際に負債の問題点が洗い出されますよね。技術的負債も、エンジニアリングマネージャーやテクニカルリード、または技術顧問などで、同様のことをすれば良いのです。内部で判断できなければ外部に診断してもらえば良いのです。
特にリソースがぎりぎりのスタートアップであれば技術顧問は検討の余地があるでしょう。時期としては最初はローンチを優先させるべきなので、技術的負債を意識すべき、ローンチが見えてきた時期やローンチ後が良いかと思います。
保守運用の鍵は技術的負債の返済
エンジニア以外の職種の方から、「エンジニアって普段何に時間を使っているんだろう」「この機能を実装するのにそんなに時間がかかるんだ」と言われることも多々あります。
保守と運用はシステムを運営していくうえで必要不可欠。しかし、「保守と運用」ではエンジニア以外の方にいまいち伝わりにくいのも事実です。
エンジニアの仕事では新規開発と保守運用というフェーズの分け方がよくなされます。新規開発はよく注目されるのですが、我々のような事業会社の場合、新規開発が終わって、ローンチしたところからが本当のスタートだと捉えています。
ローンチするまでの開発が新規開発。今までに無いものを作って世に出していくもので、新規開発という表現を用います。それに対して保守運用は、ローンチした後の開発に関するもので、新しい機能の開発と不具合の修正、日々のサービスにまつわるルーチン作業、または効率化などによって人々の動きを改善する目的があります。これらの開発をしやすくするために、共通して欠かせないものが「技術的負債の返済」です。
ローンチ後、新規開発に割く時間は必然的に減少
エンジニア以外から見えにくいものの代表例が、新規開発と保守運用にどれだけの時間を割いているか、その割合です。
一般的にはローンチまでの開発は、ローンチすることを最優先に開発していくものですので、9〜10割が新規開発にあたります。ほぼすべての時間を新しい機能を作ることに費やし、ローンチの期日までに完成を目指して頑張っていくというのが通常の開発スタイルかと思います。
新しい機能をひたすら作り続けていくのも必要ですが、ローンチ後には実際に使ってくれているユーザがいるはずです。何か不具合があった場合、それを直さないとユーザも離脱してしまいます。「ローンチした後が本当の勝負」とは、ユーザのための改善に他なりません。
サービスの場合、ローンチ後には早く売上を上げ、利益を出す必要があります。利益化までの期間は1年だったり、2年や3年だったり、用意されている資金に基づいて決まっていきます。それを満たすためには可能な限り少ない人数で最大の成果を発揮しないといけません。
ルーチンタスクを「人力で毎回がんばる」というようなことを続けていると、リソースをどんどん投入しなくてはなりません。ソフトウェア産業の場合、人とサーバインフラがコストの大部分をしめており、ルーチンタスクに対して、可能な限り人のリソースを使わないようにして、利益拡大を目指します。プログラムやテクノロジーでいかに効率化をしていくかが大事になるわけです。
「作り終わったのでリリースしました」で待っていても売上が立つことは稀なので、ローンチ後から実際に利益を出すレベルまで持っていく活動が必要です。保守開発と新規開発との違いは、機能を作るだけでなく、機能を作りつつ、「人が増えなくてもちゃんと利益が上がるように開発する。かつ新機能追加や不具合修正、コストを下げるための改善をすぐ行えるようにする」点です。ローンチ後は一般的に、新機能を開発をするための時間はどんどん減少していきます。
【GMOペパボのコツ１】担当を分割することでリソースを確保し、技術的負債に対処する
GMOペパボでは、エンジニアの時間を作り出す試みを行っています。
新規開発以外にやらなければならない多くのタスクを、人や役職、職種で分けて取り組んでいるのです。社内では「日直」と呼んでいます。エンジニアは3〜5名のチームで構成されており、毎日日替わりでその中の1〜2名のエンジニアが、日直としてお問い合わせ対応や不具合修正を全て担当します。そして、日直以外のエンジニアが新規開発を行う、というように役割を分けているのです。日直が保守運用を巻き取っている間、他のエンジニアはより前に進むための取り組みに集中できます。
技術的負債の返済のような、日直が1～2人で担当するには大変なタスクは、専門のチームが中心となり、1～2か月ほどの単位で取り組む場合が多いです。技術部の配下に4〜5人の技術基盤チームというチームがあります。そのチームが社内で技術的に負債となっているプログラムの改修や、OSのアップデートなどに集中的に取り組みます。これは、事業部に所属しているエンジニアには事業を成長させることにコミットしてもらうためでもあります。事業部としては売上を上げて利益を出さなければなりませんので、中長期に渡っての改善活動は後回しになってしまいがちです。大掛かりなOSやDBのアップデートで半年や1年単位で対応にかかる場合、「その間新規機能の開発はほぼできません」とPMや他職種のプロジェクトメンバーに伝えても「それやる意味あるの？」と言われてしまうでしょうし、納得しづらいでしょう。
事業部のエンジニアは事業開発として新規の開発やルーチン活動を改善し、利益を上げられるタスクに集中する。その他の技術的負債と呼ばれるような、ビジネス上の利益がなかなか見えない部分については、技術部のエンジニアの方で対応していくような進め方をしているのです。
事業部のエンジニアと、技術基盤チーム。最初からこの2つを分割しておくことで、技術的負債への対応がゼロになる瞬間がなく、ある程度の割合を担保することが出来ます。
技術的負債の対応もクリエイティブにモチベーションを維持
新しいものを作るエンジニアと技術的負債に対応するエンジニアでは、進め方次第ではモチベーションの差にも影響が現れます。「古いVMをコンテナ化してk8sでマルチクラウドで●●する」というような対応と、「PHPやパッケージのアップデート」では、どうしても後者を担当するエンジニアはモチベーションが上がらないでしょう。
この場合も、「いかに事故を起こさないようにアップグレードさせるか」のようにミッションを掲げて取り組んでもらうことでモチベーションをなるべく落とさないように工夫しています。
弊社には事業部が複数あるため、BtoBの事業やCtoCのEC事業、はたまたロリポップのようなホスティング事業部もあります。そのため、ある事業部でだけ使えるような方法や進め方で技術的負債に対応するのではなく、もう少し抽象度を上げて他の事業部でも使えるようなやり方や簡易なツールを用意して対応するようにしています。単純な作業で終わらせるのではなく、頭を使ってクリエイティブに課題を解決することが重要です。
技術的負債の対応でも評価される仕組み
GMOペパボの評価制度では8等級までの等級制を導入しています。3等級まではジュニアエンジニア。4等級から上はシニアエンジニアとして上位エンジニアと位置づけられています。
「アクション評価」ではビジネス的な目標をどれぐらい達成したかが、「グレード評価」ではエンジニアの等級ごとに基準が定義されています。たとえば、1等級のエンジニアであれば、
・毎日ちゃんとコードを書いてコミットしました
といった基準が定義されており、それに従った行動が取れているか評価します。等級が上がれば、
・テストコードをしっかり書いた上でビジネス側と決めた期日に間に合わせて、不具合をできるだけ出さないようにローンチできた
と基準が変わります。
「技術的負債の返済」と聞くと、「テストをどれだけ書いたか」というような話をイメージされる方もいるかもしれません。しかし、ペパボでは、会社やサービスに貢献したかというアクション評価とエンジニアとして何を行ったかというグレード評価の2つの評価を使い分けるのが重要と考えていています。テストコードを書いたことで、「何が便利になったのか」「チームがどうなったか」「サービスがどうなったか」。これが最も重要で、弊社としてはそこを評価しているのです。
エンジニアやプログラマーは、やろうと思えば何でもできる職業です。 極論を言うと、マネージャーが「Aをやってください」と言ったとしても、自分の意思で「Bをやろう」と思えばできてしまう。コードを書けるのは自分自身。つまり、自分だけで世界を動かしたり、サービスを動かしたりすることができるとも言えます。だからこそ、自分がやったことの結果が組織や社会、世界にどんな変化を与えることなのか常々意識して仕事をするようにしないといけません。
エンジニアではなくエンジニアリングをマネジメント
よくあるマネージャーのミスとしては、エンジニアリングではなくエンジニアのマネジメントしかしていないパターンがあります。最近では、EM.FMなどのPodcastでのエンジニアリングマネージャーに関する情報発信が盛んになってきました。
技術的負債にどの時期に取り組むのか、それが最終的には本当にビジネスに寄与するのか、既存のソフトウェアで対応するのかフルスクラッチで開発する必要があるのか、このようなものがエンジニアリングに関するマネジメントに該当します。このような技術的なマネジメントを誰かがやらないといけないのです。
ビジネス上の売上・利益を上げて成長するためのビジネスマネジメントは、よくマネージャーと呼ばれる人たちやディレクターと呼ばれる人が行っています。ビジネスマネジメントは今こういう業界が伸びているからこういうプロダクトを投入しよう、というような判断を行います。
同時に、技術的な視点で、投入するプロダクトをどうやって作るのか、どの時期にターゲットを決めてリリースし、そのためには何をする必要があるのか、のような部分も、エンジニアサイドでマネジメントする必要があります。そこの技術的なマネジメントが抜けていると、「こういう物を作りますよ」という話だけになったり、「理由は分からないけどエンジニアがリファクタリングしたいと言うから、させておくか」のような状態になってしまいます。そういう話が来た時には、エンジニアリングマネージャーや判断できるエンジニアが、
「今の時期はリファクタリングよりも機能の分割を優先しましょう」
と正しくリジェクトするか、
「待ってました。今の時期だからこそ、今後成長するためにちゃんとリファクタリングやりましょう」
という話を行い、実行していきます。逆にそういう話が全然出てきていない時に、ビジネス部門のマネージャーの方針も汲み取った上で、
「この先半年間これだけの物を作っていくという計画があるので、最初の2週間のうちに、後で壊れないようにちゃんと構成を見直しましょう」
だったり、
「サーバのスケールアウトしておきましょう」
といった判断をして、事前にどのようなスケジュールで取り組んでいくのかマネジメントする必要があります。
マネジメントを語るとき、「人・物・金」がよく対象にあげられますが、技術もマネジメント対象だということを忘れてはいけません。
エンジニアとエンジニア外が共通の語彙を持つ
GMOペパボでは、エンジニア以外のメンバーとの関わり方も工夫をしています。
エンジニアと他職種メンバーの間の共通の語彙を増やすことを大切にしています。今だと私は、エンジニアリングマネージャーたちと一緒に、会計の勉強をしています。他にも、法務関連の勉強や特定の業界に関する勉強などもします。その知識や、勉強しているという行為そのものが、事業部のマネージャーだったり、各部署の人たちとの共通の語彙や話題になったりします。
逆に、法務やHRなどバックオフィスのメンバーにGitやMarkdownの勉強をすすめています。文書管理をGitで行えば、わざわざファイル名を変えて履歴残さなくて良くなりますよ、と。
お互いに少しずつ歩み寄っていく感じです。
別の例ですと、セキュリティインシデントがあった際には、エンジニア以外のマネージャーにむけてITパスポートやセキュリティ関連の資格の勉強して受けよう、という取り組みをペパボ全体で行なったことがあります。セキュリティ関連の勉強をしたマネージャーに「SQLインジェクションが見つかりました」と言えば、「SQLインジェクション、分かりますよ。めっちゃやばいやつですよね」というように、エンジニアと共通の言葉で話せるようになるんです。
エンジニアがSQLインジェクションの話をするときはまずい時、逆にこういう話をしていたら嬉しい時なんだ、という理解を得られるとその後のコミュニケーションもしやすくなりますよね。
語彙の次は思考プロセスを共通化する
昨今注目されたJavaScriptループの事案。エンジニアからしたら「これは別に問題ないでしょう」というものでも、法務からNGがでることもあります。そういうときには、どのような思考プロセスでそれぞれ考えているのかをお互いに知ることが大切です。
GMOペパボは、ホスティング事業も行っております。ホスティングは、ユーザにサーバ領域を貸し出すことになる。つまり、ユーザが何をするのかコントロールできない面があります。著作権侵害をしているコンテンツの配布であったり、他のサーバに攻撃を仕掛けるプログラムが動いたり。やろうと思えば出来てしまいます。そういったものに対処するために、技術的な見方と法務的な見方では視点や語彙が異なります。
たとえば、エンジニアは法務へ「ドメインは誰でも簡単に取れるものだよ」というエンジニアからしたら常識的なことも根本理解のために伝えます。逆に法務は「これはちゃんと規制しなくて大丈夫なの？」とエンジニアが気付かない・想像もしない部分のアドバイスを行います。そうなれば、「技術的にこうだからこの部分はセーフだが、技術的にはそれ以上担保できないので契約や規約で抑止しよう」という良い着地点が見つけられます。
あらゆる事象が、立場とバックグラウンドの見方を変えると全然違うものに見えたり、はたまた全部同じように見えたりするので、それぞれがどう見えているのかというのをお互いに探っていくという活動が一番近道かと思います。
リファクタリングに関しても同様で、エンジニア以外の人からしたら何をやっているのか分からないとしたら、逆にそれをエンジニアはどう見ているのだろう、と想像を巡らすのが良いでしょう。
【GMOペパボのコツ２】リプレイスすることでパフォーマンス低下を防ぎ、技術的負債に対処する
技術的負債への対応の仕方としては、リプレイスとして全てを作り直すのもありだと思っています。
特に、ローンチまでの開発が得意なチーム、エンジニア組織だったとしたら、どんどん作り直せば良いと思います。とにかく作って出しました、半年ぐらい様子を見ました、ユーザ全くつきません、じゃあ次を作りましょう、このサイクルが重要です。しかし、そんなに簡単ではありません。コストもかかるし、そこまでに投入した経費はどうするのかという会計的な面、そして担当者の思いもありますよね。作って半年経って「いやあと1年頑張れば…」とか、2年目になって「やっと売上があがり始めたので、利益を出すためにもう1年」という光景はよく見かけます。
どんどん作り直せないんだとしたら、それを継続的に成長させていけるように技術をマネジメントしていかないといけません。弊社では、実際にエンジニアがコードを書くよりも、コードを読む時間の方が圧倒的に増えてきているという事実があります。それは技術的負債がたまればたまるほど、コードを書く時間よりも読む時間の方が増えることの表れだと思っています。コードを書いたときの影響範囲が予想できず、調査と呼ばれる、コードを読む時間、もしくは影響範囲を確認するために試行錯誤する時間がどんどん増えていってしまいます。その結果、エンジニアがコードを書いて新しいものを作り出す時間が減ってしまいます。
「3人や5人エンジニアを投入しているのに、1人分ぐらいしか機能が出来上がらないんだけど」といった問題の本質はそこにあります。
技術的負債による危険性
技術的負債が放置されたまま3年4年経つと、開発のスピードだけではなく、今度はいよいよ有償OSのサポートが切れて、セキュリティの課題が表面化する段階です。ソフトウェアが使えなくなったり、ライセンスが切れると、もうどうにもできなくなります。そこに向けてある程度新しいOSに乗せ換えたりする運用も必要になってきます。そのような乗せ換えができるならリソースを投入すれば回避できます。
これを放置すると、セキュリティの問題を放置するかしないかや、ライセンスの問題を放置するかしないか、のような社会的責任の領域になってきます。そのため、改めてそこの部分については、サービスのディレクションを決定できるマネージャーが社会的責任として、こういう状況のものをお客様に提供するのかしないのかを判断した上で、エンジニアと一緒に頑張ってしっかりとアップデートをするなり作り直すなり、リプレイスするのか、はたまた黙って放置してそういうものをユーザに提供するか、という社会的責任が伴っているということを意識する必要があります。
初期のチームでは技術的負債の返済よりもローンチを目指す
「プロダクト・マーケット・フィット」とよく言われているような、真の顧客が巡っているところを見つける、真の顧客ターゲット層を見つける、真のターゲットが使うプロダクトを見つける、という部分へのフォーカスまでは、技術的負債を考えずにとにかく作ったほうがいいと思います。
初期のローンチのチームは、専門的な領域はそれぞれが持っているが、とにかくプロダクト・マーケット・フィットを行い、ローンチするというミッションを全員が担っているはず。その中で、いろいろな試行錯誤を行います。失敗して軌道修正もあります。そのため完璧なものをじっくり目指すのではなく、「一旦やってみる」でいいと思います。
【GMOペパボのコツ３】制約を設け、モチベーション高く技術的負債の返済を行う
では、技術的負債へどう対応していけばいいのか。ここからは具体的な実践に入っていきます。
リファクタリングの時間を確保し、アウトプットを振り返る
リファクタリングやテストコードを書く際に、どこまでやれば良いのかに悩むでしょう。そんなときは、タイムボックスを切った方が絶対いいです。つまり時間割です。
開発を進めるフェーズでも、「金曜の午後はリファクタリングタイムにしましょう」と決めてしまう。それ以外の時間は開発をどんどん進めます。たくさん作ったので金曜の午後の4時間は作成した部分に対してテストコードを追加する、さらにリファクタリングする、サーバの構成を整えるといった時間にあてることができます。個人ではなく、みんなで取り組むところがポイントだと考えています。
その時間は、1週間の振り返りに近いかもしれません。1週間で作ったものを振り返ってさらに良くしていく。これを毎週繰り返していきます。そのため、この時間にはディレクターにも参加してもらい、1週間取り組んだアイデアは本当にうまくいったのかを一緒に振り返るのも有意義です。
自分たちが出してきたアウトプットの質をより高める時間を、このように明示的に区切って使ってしまうほうが、やりやすいことも多いです。
少しの制約が良いアイデアにつながる
エンジニアやデザイナーのスピードが落ちてきているような気配を感じたチームがあったとしたら、毎週この曜日のこの時間は好きなものを作っていいですよ、と割切ってしまうのも手です。
「ひたすら今後使用する予定のないデモを作るタイム」を行うと良い場合もあります。今目指しているマーケット・フィットに関係ないものでもいいので、とりあえずみんなで作ってみる。すると意外と役立つものが出てくることもあります。
また、制約によるアウトプットの向上は、結構無視できません。「何でもやっていいよ」というと、エンジニアのテンションも上がらないものですが、制約を少しでも与えると、その枠の中で成果を出そうと制約が良い方向に動いたりします。何でもやっていいとなると、ついつい昨日と同じ普通の事をやってしまうのです。
エンジニアのモチベーションを上げる
エンジニアが楽しく、そしてモチベーション高くいられることもパフォーマンス向上であったり、技術的負債への意欲に影響を与えると思います。
もちろん理想は右上の状態。いかにエンジニアをこの状態に持っていくかが組織として大切になります。
横軸の楽しいかどうかに関しては、考え方次第なところがあります。同じ業務内容であっても、上司のアドバイス一言によって、その作業の楽しさを見出すこともあると思います。
レガシーなシステムやコードのシステムがあると「エンジニアにレガシーシステムの開発ばかりをやらせたら会社を辞めちゃうよ」という話があります。正しい面はありますが、対象のシステムが何であれ「開発が楽しければ何とかなる」という文化を作っていきたいと思います。ただ、大変だが楽しい、という領域に居続けると、その結果、「自分のスキルが伸びないので辞めます」といった新しい問題も出てきます。そこで大変だが楽しい、から「楽だし楽しい」という方向に寄せつつ、再び大変だけど楽しいという次のステップへと領域をマネジメントしていきたいと思っています。
やはりエンジニアは手作業でぽちぽちやれば1時間終わる作業があれば、マクロを組みたくなる人種です。縦軸は、いかに作業を楽にこなせるかという話ですので、取り組みさえすれば上側に移行する（余力を自分で作り出す）ことはできることが多い。ただし、それには時間も必要なので、周りもそれに取り組む環境は用意してあげる必要はあるかと思います。
固定概念を捨てる
半年前か1年前ぐらいにCTOの栗林が「あらゆることは結構両立するよ」という話を、社員向けの文書で書いていました。
古いサービスと新しいサービスみたいに、すぐ対立軸を置いたり、楽しい仕事と楽しくない仕事みたいな話や、古いサービスだとエンジニアが成長しないとか、新しいサービスだとエンジニアが成長するといったように、すぐに対立軸を作ってしまいがちです。そんな時に、でもそれは全部両立することもあるよね、古いサービスのメンテナンスでもやり方次第で技術力は成長するし、はたまた新しいサービスだけど実力は成長しない場合あるから両立するよね、と考え直してみましょう。そうすれば、無駄な固定概念にとらわれず、より良い考え方、議論ができるのではないでしょうか。
