業務委託テックリードと技術的負債

河野と申します。2018年8月からマッハバイトで業務委託（いわゆるフリーランス）として業務に携わっており、2022年6月から、テックリード（以降、TL）という立場となりました。

TLという言葉は広く使われていますが、実際に何をするのかは、会社や環境によってさまざま。 3ヶ月の振り返りがてら、ここに一例として公開してみようと思った次第です。

TL着任以前

Join当初はRailsエンジニアとしての働きを期待されており、最初の担当はマッハバイトiOS版用に、REST APIを開発することでした。半年少しでその業務が一段落した後は、以下のことなどを担当してきました。

Rails製アプリケーションの機能追加、Ruby、RailsのUpdate
ホストOSのUpdateに伴う、deploy環境の修正や、ライブラリなどのUpdate（オンプレ環境）
マイクロサービスの中心に置きたいメッセージングサービスの選定 -> kafka / MSKになった
SpringFramework / Kotlinを使ったマイクロサービスの開発
React / Next.jsを使った管理画面の実装 & GraphQLでのAPI実装
SSO(Keycloak)導入

マッハバイト内では、これらを「基盤領域の仕事」などと呼称しておりましたが、フリーランス仲間の話を聞くと、業務委託のエンジニアにこのような基盤の仕事を任せることは稀だそうです。各々の契約内容によりますが、リブセンス社はその点柔軟なのだろうなぁと感じております。

TL着任とそれ以降

情報の収集

TL業を依頼された時、何を期待されているのかと聞いてみたところ、「優先順位付け」ということでした。優先順位を付けるには、情報が必要です。そのため、最初はとにかく情報集めに集中しました。

幸いにして先代のTLとの引き継ぎ期間があったため、知らない分野のことや先代TLがTodoとして認識していたものなどを、何度かの1 on 1を経てリストアップ。さらにその中でも大玉の案件については、個別に時間を取ってインタビューし、資料を作成。さらに、日報で私が「情報収集している」と書いているのを見た他のメンバーが、MTGの時間を取って「このような問題が生じている」と情報提供をしてくれました。

結果として、70項目以上の長いリストが作成されました。

優先順位の決定

リストを眺めてみると、技術的負債が開発効率を低下させていることが気になりました。携わっている「マッハバイト」は、創業時から10年以上続くサービスであり、古いPHPとフレームワークを使っている箇所が残っているなど、技術的負債がそれなりの量で存在しています。

しかし、開発チームのリソースは当然ながら限られており、技術的負債を解消するための施策だけでなく、「売上を向上させるための施策」「オペレーションの効率を向上させるための施策」を進めていく必要があります。

その事を念頭に、今後どのように開発チームが仕事をしていくかについて、グループリーダー（以下、GL）およびエンジニアリングマネージャ(以下、EM)と打ち合わせを実施。「技術的負債が開発速度を遅くしているよね」という共通認識に至り（というか、再確認し）、「一定のリソースを技術的負債の解消に割き続けていく」ことになりました。さらに負債の解消方針についても、「不要部分や重複部分を削除し、サービスをシンプルにする」ということで合意しました。

基本方針が決まったので、先程作ったリストの項目それぞれに、おおまかに優先順位を付けていくことにしました。ただ数字を書き込んだだけだと分かりにくいかと思い、各項目に「出血中」「痛みを伴っている」「健康診断判定E」「体脂肪率40% -> 20％」など、健康状態に例えてラベル付けをしていきました。

例えば、極めて改修頻度が低くメンテが後手に回った結果、CIが古く不安定になっているリポジトリには、改修頻度が低いほど自動でのサポートが必須だと考えたため、「出血中」というラベルを付けました。

他にも、フレームワークや言語のバージョンが古いものには「健康診断判定G」、オンプレからクラウドに移行するだけで開発が機敏になるものには「体脂肪率40% -> 20%」などとラベル付けをしました。

事業部内への情報展開

その頃社内でのイベントで、「基盤領域の業務の説明をして欲しい」という依頼が来ました。基盤領域の業務は、非エンジニア職の方々には見えにくく、「こっちはこんなに忙しいのに何をしているのだろう」などという不信にも繋がりかねません。今後の技術的負債の解消に向け、そういった不信感は致命的です。それを少しでも解消するための良いチャンスと受け止め、プレゼンでは基盤領域の仕事を、アルバイトで求人が多い飲食店チェーンに置き換えて話をしてみました。要約すると、以下のような感じになります。

揚げ物ブームが来たのででかいフライヤーを導入したが、ブームが終わったら稼働率が落ちた。これを撤去したり、新しい機材を入れたりしなければならない
包丁もコンロも、各調理器具は手入れをしなければ、継続的に使えない
こういったものを常に、現在の仕事が滞り無くできたり、新しいブームにすぐ乗れたりするように保つ必要がある
Webシステムにおいて、そういった手入れや準備、研究、調査をするのが、基盤領域の仕事

さらに「それらの仕事がどのように売上にインパクトを与えるのか」については、t_wadaさんの銀座Railsでの登壇およびデブサミ2021「アジリティを支える品質特性質」の講演を参考にさせていただき、

基盤を整備し、アーキテクチャを刷新し、技術的負債を解消するのは、すべて「アジリティ」のため
「アジリティ」があれば、トライ＆エラーによる創意工夫の高速化が実現でき、事業部が目指す非連続成長につながる

という話をしました。

プレゼン後、「あの案件、○○が原因で難しくなってるんですね。なるほど」と非エンジニアのメンバーから話しかけられたり、EM、GLをはじめ色々な人が「アジリティ」という単語を口にし始めました。それなりに効果があったのかな、と感じています。

新メンバーへの仕事の依頼

それからしばらくして、エンジニアが一人、マッハバイトの事業にJoinすることになりました。

やるべきことのリストは先述の通り、大まかな優先順位を付けた状態で作ってあったので、その中からお願いすることになりました。ただ心配だったのは、いきなり技術負債の山を見せられて、新メンバーが面食らったり怯んだりしてしまう事でした。

そこでEMと相談の上、「負債の中でも比較的独立している、オンプレミスのサーバで運用している古いサービス」について、周辺を整えつつ一気にクラウドまで持っていってもらう仕事を依頼することにしました。他の古いサービスもクラウドへの移行を計画しているため、後から続くためのモデルケースを作ってもらおう、という意図での依頼です。

またもう一人、インフラチームにJoinしたメンバーが、マッハバイトの業務にリソースを割いてくれる事となりました。やはり同じく優先順位を付けたリストを見せたところ「やっぱりこれが一番の問題ですよね」と、優先順位が高くなっていた「オンプレ上で稼働するDBのクラウドへの移行」を選択し、担当してくれることとなりました。

結果的に、お二方ともすぐに業務に着手し、パワフルに仕事を進めてくださっています。

自分が担当した作業

また並行して、リストの中で「出血中」と書いたものに着手しました。選択基準としては、今後メンバーが技術的負債を解消するタスクに携わるにあたり「これをあらかじめやっておくとスムーズに進む」であろうものを優先しました。

BitbucketからGitHubへの移行、JenkinsからGitHubActionsへの移行など

皆が慣れているGitHub上に移動し、不安定になっているJenkins CIもGitHubActionsで再構築して「古いコードに触る敷居をできるだけ下げ、負債解消の速度を上げたい」という意図がありました。 GitHub移行により、インフラチームのメンバーによって、対象サービスのコンテナ化も進むこととなりました。