業務委託との長く続く良い関係性

こんにちは。トレタでVPoEをしている北川です。

この度、クレスウェア株式会社の奥野賢太郎氏がトレタの技術顧問に就任しました。

corp.toreta.in

トレタに在籍している人にとっては奥野さんが技術顧問になったという話は「今更！？」と感じる人もいるかもしれません。

それだけ奥野さんはトレタで業務委託として長く携わってもらっていますし、実務以上に技術面の啓発や開発カルチャー作りに今までも貢献していただいていました。

今回のことで奥野さんとの関わりが大きく変わることもありませんが、これからトレタの開発組織を強化し、発信を活発にしてく上で、奥野さんとの協力をより一層強くするために今回の発表をさせていただきました。

---

自分と奥野さんとの関わりも5年以上経つので積もる話もたくさんありますが、あまり内輪話を記事にしても仕方がないので、もう少し一般化して「長く活躍いただいている業務委託の特徴」について、自分なりに思う事をこの記事に書こうと思います。

Noを言ってくれる

業務委託と社員の間にはどうしても委託先と委託元という関係性が発生するので、意識しないようにしても接し方に影響がでてしまいます。社員の中でも上司と部下であれば起きますが、業務委託の場合はより色濃い気がします。

その中でも対等の立場で議論が行えて、場合によっては指摘したりNoと言ってくれる方はとても貴重な存在です。 年をとると怒ってくれる人がいなくなる、という話に近い感じがします。

例えば、複雑な設計をしすぎた仕様を提示すると「それYAGNIじゃないですか？」とよく言われます。 将来的な事を詰め込んだり欲張った設計を自分はしがちですが、「パフォーマンス悪くなりますよ」「QAに負担かかりすぎますよ」だったりと論理的、多角的な視点で現実的な指摘をいただけます。

総じて言うと、強い「オピニオン」を持っているという特徴があると思います。それは経験に裏づけされたものかと思いますが、確固たる思想をもち思想が合わない場合には率直に意見をしてくれます。

細かいことでいうと、先日もコードベース上でシングルクオートにするかダブルクオートにするかでプチ議論になりました。 些細なことに見えますがこれは意外と大事な事で、一般会話においても質問に対して「なんでもいいよ」と答える人とは議論が成り立たないわけです（夫婦間でよく怒られるやつ）。 細かいことでも一貫して自らの意見を持ちぶつけてくれる、というのがプロの特徴の一つなのかと思います。

創造性と情熱

対等な議論ができる、というのは関係性がしっかり構築されていないと実際のところ難しいです。 そのため関係性が浅い業務委託の方の場合は、どうしても依頼したことのみを動く人になってしまいがちです。

「世界最高のチーム」 *1 という本の中に、仕事において人に求められる能力の段階として「能力のピラミッド」*2が紹介されており、レベル4の主体性より上に引き上げるためには「心理的安全性」が必要と書かれています。

社内で活躍しているメンバーは社員や業務委託であるか問わず、主体性（課題を見つけすぐに行動する）や創造性（より良いアーキテクチャー、ライブラリへの意識を常に持ち取り入れる）を持ち合わせています。情熱を持ちあわせた強強の人までいくと、経営視点でのサービスの発展性やプロダクト成長の方向性についていっしょに議論ができます。

直近でも今後やりたいプロダクト成長を踏まてNext.jsでPagesRouterからAppRouterへ切り替えたり、デザインシステムの導入を見越してTailwindCSSの導入を行いました。どちらも最初にメンバーから提案をいただき、迅速に対応いただきました。

新しく入るメンバー含め全員が同じような主体性や創造力をもって仕事するために「心理的安全性」を作れるかは、開発文化の醸成を行なっていくVPoEになった自分のこれからの任務だと考えています。そしてそれをサポートいただく強力なパートナーとして、今回の技術顧問の発表を行なったという背景です。

さいごに

トレタではエンジニア採用を積極的に行なっています。

奥野さんとガッツリとモブプロしたり、手厳しいレビューを受けて揉まれたいエンジニアはぜひ応募してみてください！ hrmos.co

*1:「世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法」 ピョートル・フェリークス・グジバ (著)

*2:「経営は何をすべきか」ゲイリー・ハメル(著)

開発組織の新しいコアバリューを定めました

こんにちは、トレタ VPoEの北川です。

先日VPoEに就任したご報告をしましたが、あわせて開発組織内のコアバリューを新しくしました。 この記事ではその新しいコアバリューについて書こうと思います。

tech.toreta.in

新しいコアバリュー

「短く速く作り出そう。遠いゴールを目指して飛び込もう。(Dash & Dive)」

トレタの会社全体のビジョンやミッション、行動指針などはありますが、その中でも現時点での開発組織としての重心としたい要素をこの言葉にまとめました。 盛り込みたい要素はいろいろとありましたが、なるべく短い言葉にしたかったのでそこに込めた背景を説明していきます。

短距離走ではなく長距離走でもなく、短距離走の連続

トレタはベンチャー企業である以上、短期間での開発＆リリースが求められるプロジェクトは少なくないです。 新規プロダクトを2ヶ月で作り上げてリリースする等、ユーザーに早く価値を届けることを目標にスピードを重視した短距離走的な進め方をする場面はよくあります。

一度プロダクトをローンチした後は、運用面も意識する必要があるため長期的な視点が必要になってきます。 ただし、初回リリースのスコープから外した機能のエンハンスや、手が回らなかった部分はリリース後にゆっくりやっていくか、といったらそうはいきません。 そこからエンハンスの新しい短距離走が始まるからです。

短距離を走り切ったらまたすぐ次の短距離を走る、それが今の開発現場の状況です。

最優先される価値は「スピード」

荒ぶる四天王があらわれた！*1

そんな限られた期間内での開発状況においてどうリリースまでもっていくか。プロジェクトを調整する要素は「時間」「予算」「品質」「スコープ」の4つがある、と「アジャイルサムライ」の本にはあります。

「時間」については、定められた短い期間でやるのが前提でありリリース日を延期するのは最終手段です。

「予算」について、「人月の神話」にもある通り人を２倍の数にしても開発速度が２倍になることはありません。人が増えることで発生するコミュニケーションコストは開発工数の中でも大きく占める要因の一つと考えています。最速で行うには少人数の方が向いています。

「品質」については@t_wadaさんの「質とスピード」*2の話が社内ではよく挙げられます。質(保守性)とスピードはトレードオフの関係ではなく、高速なデリバリーをし続けるためには高い品質を保ち続けることが必要と考えています。

最後の「スコープ」が「アジャイルサムライ」の本にもある通り調整が一番しやすい部分です。スコープをいかに小さくし、その中で最速で開発を行うか、という重要性をコアバリューの「短く速く作り出そう」という言葉をに入れました。

常に全速力を続けるために、コンディション(質)を保ち続ける

上記の通り「品質」は常に高く保ち続ける必要がありますが、じっくりとリファクタリングする余裕もありません。

そこで必要なのは開発をしながら品質も同時に保つ、というやり方を意識することです。それは負債になりづらい設計や実装に心がけたり、TDDの様に実装とテストコードを対で実装していくやり方かもしれません。

ただし、高い品質を求め過ぎて開発速度が下がってもいけません。盲目的にテストコードのカバレッジを80％以上に保つというルールを設けるのではなく、テストコードで得られる安全性とそこにかける時間のバランスを常に意識することを心がけます。

場合によって、納期を優先して一時的に負債を許容する場面もあるかもしれません。ただし、それは解消する目処がある場合にのみ良しとします。 次のフェーズで同じところを触るからその時に改善する、そのうち使われなくなるから今は見逃すなど、負債が残り続けないかという観点も意識します。

---

次に「遠いゴールを目指して飛び込もう(Dive)」の部分について、「短く速く作り出そう。(Dash)」の部分が短期の目線を表しているのに対し、こちらは長期の目線を表すために入れました。

始める前には必ず一歩立ち止まる

走り始める前にゴールまでのルートを計画してから飛び込む必要があります。重要なのは短期のゴールと長期のゴールの２つを意識することです。

よく行うアプローチとして、小さく絞った「スコープ」を積み上げていくのではなく、先に最後のゴール像を設計しきってからそこまでの登り方を分解していきます。 特にデータ設計など後付けしづらい部分などは、最初に詳細まで詰めきっておきます。 ゴールまでの道筋を描き切ったら、一旦頭の中から放念して今度は直近のゴールへの道筋を設計します。

この様な短いスパンの視野と長いスパンの視野を行き来することが重要です。

近道はない。あるのはトレードオフのみ。

設計を進める上で、どちらの設計を選択すべきか迷う場面は往々にしてあります。肝に銘じないといけないのは、近道や銀の弾丸はないということです。 すべてはトレードオフがあるのみです。

一見簡単そうな道があったとしても、何がトレードオフになっているかを考えることが重要です。 どの道を選ぶべきかの判断軸は、前述のとおりどちらが速くゴールに辿り着けるか、です。 険しい道だとしても結果的に最後にゴールするのが早い道を選ぶための勇気を持つために「Dive」という言葉を入れました。

長く潜り過ぎてはいけない

遠いゴールを目指す時の注意点として、そのゴールを過信しすぎてはいけません。 常に状況は変わります。 当初のゴールは途中で目指していたものから変わっている場合があります。

たとえば、システムリプレイスなど期間が長く大きいプロジェクトがリリース直前になって頓挫することは今までトレタの歴史でも多々ありました。 一年かけて開発していた間にユーザーが求めていたものが変わっていたり、外部環境が変わっていたりします(パンデミックなんて予想できない！)。 ビッグバンリリースはなるべく避けなければならず、最初の言葉にもある短く細かくリリースしていくことが重要です。

常に状況を見て現在地を確認していれば軌道修正は可能です。 途中で意思決定や設計を間違えることがあれば、その時も軌道修正すればよいのです。 失敗を恐れずに「Dive」です。

さいごに

いかがだったでしょうか。 このような開発文化でトレタでは日々の開発を行なっていきます。 エンジニア採用を積極的に行なっていますので、興味がある方がいればぜひ声をかけてみてください。

hrmos.co

*1:「アジャイルサムライ」著者Jonathan Rasmusson

*2:質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition - Speaker Deck

VPoEとしてやっていくこと

こんにちは、この度VPoEになりました北川です。

ついこの間まではPdMとしてプロダクトをみていましたが、少し範囲が広がり開発組織全体も見ていくことになりました。

せっかくなので、VPoEとしてこれから何を考えどうやっていくのか、今日時点での所信表明をこの記事に書こうと思います。

corp.toreta.in

VPoEとは

あらためて、VPoEとは「Vice President of Engineering」の略です。日本語でいうと開発部長です。

とはいえ一言でVPoEといっても広義であり、各社ごとにその定義や役割は違うと思います。

そんな中で自分の中で気に入っている定義は、VPoE handbookにある「Executionに責任をもつ人」という定義です。

note.com

こちらによると、VPoEの一番の責務は「Execution = 実行」 であると書かれています。具体的に言うと、CEOやCOOが意思決定した戦略に対し、「確実に・最適に実行する責任」を持つことです。

振り返ってみると今までの自分のキャリアでは比較的に一人エンジニアとして動くことが多かったです。トレタでも入社後には新規プロジェクトの立ち上げとしてエンジニアは自分のみで、プロダクトオーナーやセールス、CSと二人三脚のように事業を進めていく動きをしていました。

フロントエンド/バックエンド/インフラなど開発領域に垣根なく必要な開発は全てやるし、運用に必要な仕組みを作ったり各所とのコミュニケーションや調整など、事業を進めていく上で必要なことは何でも行なっていく、というのが自分の性に合っていたようです。

PdMになってからも範囲は広くなりましたが基本的に動き方は変わりませんでした。今度はVPoEとして開発部の各チームを束ねながら事業を推進するために必要なことはなんであれ着実に実行していく、ということを変わらずやっていきます。

CTO vs VPoE

トレタではVPoEがいる時期といない時期があります。CTOは技術領域の責任者、VPoEが組織面での責任者といった区分けです。

今回においては前CTOが退任となり、自分がVPoEとなりました。なので現時点において弊社のCTOは不在です。

自分はCTOという肩書きは選ばずにあえてVPoEという肩書きを選びました。

理由としては、前CTOほど自分は技術に長けているわけではなくその器でもないと感じていること。CTOとして相応しい人が現れたら二人で肩を並べるためにCTOの席は空席にしておきました。

それが社内のメンバーから頭角を表してくれれば大変喜ばしいし、これから良い出会いがあるかもしれません。その時までCTOの穴を補いつつ組織力を高めようと思います。

事業成長の遂行

さて、VPoEの役割は「実行に責任を持つこと」と書きましたが具体的に何をやっていくのか、という部分に入ります。

トレタの会社のビジョンは「食の未来をアップデートする」です。このビジョンを実行に移していくわけですが、直近だと注力事業のモバイルオーダーシステムである「トレタO/X」の事業計画を遂行していくことになります。

toreta.in

「トレタO/X」はプロトタイプの時期から数えると4年くらい経っているプロダクトになります。０→ 1 のフェーズはとっくに過ぎましたが、そこから事業スケールがなかなかうまく行かず現在は1→ 5くらいの達成度の感覚です。

今年に入りブレイクスルーが見えてきてやっと1→ 10のフェーズを超える兆しが見えてきたところです。まずはそこを確実に遂行するのが今年の目標です。

そこから次は10→100のフェーズに入っていきます。それには組織のスケールが必要になってくるので、ロードマップを作りプロダクトや組織のスケールの計画を作り遂行していきます。

チームビルディング

チームビルディングは一朝一夕ではできないので、今から少しずつ中〜長期を見据えたチーム体制へ徐々に移行していく準備をしていきます。

今のチーム体制の課題の一つとしては、リリーススピードの鈍化が挙げられます。

モバイルオーダーのシステムはエンドユーザーが使う注文アプリ以外にも、飲食店スタッフが使うハンディアプリやバックオフィス向けの管理アプリや売上管理アプリなど利用するアクターに合わせて複数存在しており、アプリケーションが増える度にフットワークが重くなってきています。

ドメインにあわせたマイクロサービスごとのバックエンドチームと、アプリケーションごとのフロントエンドチームに分かれていますが、この縦割りの体制であることが結果的に一つの機能改修に対して複数のチームでの改修が必要になる、という場面が多くなってしまいました。

この反省から、既存の縦軸のチーム分割とあわせて機能改修を１つのチームで完結できる横軸の横断チームを構成しようと考えています。

チームトポロジーでいうところの「ストリームアラインドアラインドチーム」にあたります。他の本では「デリバリーチーム」と表されていたりもします。

www.atlassian.com

エンドユーザーと直接面しているセールスやCSチームと開発チームが一緒になり、フィードバックから企画、開発、結果検証までのフィードバックループが行えるチーム体制を目指していきます。

採用の強化やオープンポジションもこれから広げていきますので、興味のある方はぜひお声がけください。

hrmos.co

カルチャー作り

チーム作りとあわせて組織の文化形成の強化も必要になってきます。

現在のエンジニア組織のコアバリューは「良質なプロダクトを産むために、トレタとしての技術資産を生み出す」です。

いわゆる「顧客が本当に必要なもの」を正しく定義し、技術的に正しい状態を目指していく、という意味が込められています。

このバリューは大切にしつつ、さらにアップデートしようと思っていますが、それについてはまた別の記事を書こうと思います。

やらないこと

最後に、余談程度にやることの反対でやらないことを挙げておこうかと思います。

「無理しない」です。

今月に入ってVPoEとしての動きに変わってから、ストレスなのかわかりませんがニキビが増えたのが最近の悩みです。 責任あるポジションになり体やメンタルを崩す人を見ることは今までにもありました。無理はせずにやれる範囲でやれることをやっていこうと思います。

「紅の豚」というジブリ作品のセリフに「徹夜はするな、睡眠不足はいい仕事の敵だ」というのがあります。

常にベストのコンディションを保ち、いい仕事をしていきたいと思います。