開発責任者がやるべきことの気づきと"Think Like a CTO"

1年をふりかえる

年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長の@hihatsです。 本記事はクラウドワークスAdvent Calendar 2023 シリーズ2の25日目の記事です。

今回は、プロダクト開発部として今年取り組んできたことと、その中での気づき、「Think Like a CTO」という書籍の話にも触れていきます。

今年やってきたこと

技術的負債解消への取り組み

昨年のアドベントカレンダーでも書きましたが、2023年も技術的負債の解消に取り組んで参りました。

結果としては、フロントエンドでの注力の割合が大きかった一年でした。詳しくは@okuto_oyamaさんの1日目の記事をご覧ください。 記事にもありますが、Vue.js化をフロントエンドを触る全チームが行える体制に整えることで加速させていきます。

またバックエンド側でも、不要な機能の削除、不要なデータの削除、不要なライブラリの削除を地道に行い、現在はコアとなるドメインの再設計にも着手しています。

インボイス制度への対応本格化とともに、組織強化に重点を置いた取り組み

今年の10月から施行されたインボイス制度への対応の複雑さという点での難しさはチャンタマ氏の19日目の記事 にて詳しく書いてくれています。加えてもう一つ「制度そのものに対する反対世論も多い中、プロダクトの提供価値として設計、実装にいつどの程度舵を切るかどうか」の判断の難しさもありました。他にもやりたいことが山程ありましたからね。

私自身は細かい指示を出すことはほぼなく、それぞれ自分たちで考え抜いて進められた経験をもって学習してもらえた手応えはありました。とはいえやはり余裕をもたせることで細かい失敗を許容しやすくするほうが、より健全な学習体験だったろうなという反省があります。

並行して組織マネジメントの強化に取り組み、結果としてエンジニアリングマネージャー（以下EM）の増員によって強固な体制に。日々の運用の中でペインとなっている業務に対して、なかなか本腰を入れて改善に取り組めていない領域が複数あり、その領域をチーム化することでまずは動き出せるようにしました。

具体的には例えば、ユーザーサポートのメンバーは日常的にユーザーと接しながら感じている課題をプロダクトとして根本から改善する手立てが無い構造になってしまっていました。 そこにユーザーサポート専任の開発チームを設置、ユーザーサポートメンバーからプロダクトオーナーになっていただいて元々いるシニアのPOがサポートすることで軌道にのせていくことができています。

個別の領域以外にも、（少なくとも私が入社してから1年半ほどは）目の前の短期的なKPI達成に追われ、中長期について考える時間を取れていないことに危機意識がありました。”何がユーザー満足度に繋がるのか設計し直したり、2〜3年後に何を目指すのかといった戦略を考える”専任のチームを作ることができたのもこの時期でした。

プロダクトマネジメントにおける取り組み

プロダクト開発の現場において、「非エンジニアのグループが考える人たち、エンジニアが作る人」という構図になっていた部分が一部ありました。以前は違ったとしても、ちょっとしたことで陥りやすく、そっち側に最適化される何かがあるということです。この構図自体が悪いわけではないけれど、エンジニアとしては「社内受託のようだし、成果を感じにくい」という声がありました。またエンジニア側がリソース効率100％に近い（もしくは超えてる）状態だと、傍から見て相談しづらく、（よかれと思って）なるべく開発チームに余計な情報を入れないようにという配慮による悪循環もありました。結果としてエンジニアが知らないところで施策が進んで、あとからパフォーマンス劣化に気づくといったことも起きました。上記は一例ですが、類する事例を抽象化すると根本としては仕組み不足であったので、解消のために施策が「生煮え」の段階でも事業横断で共有する会議を設けました。一見すると出席者の多い会議が増え、コスト的にはオーバーヘッドにも見えますが、未然に知ることで得た恩恵のほうが大きかったというふりかえりができています。

また、スクラムチーム化というチャレンジにおいて着々と進化しているチームもあり、成果に繋げることでモデル化できるようにしたいところです。

note.com

機械学習による不正な仕事依頼の検知

ちょうど一年前ほどから、特徴的な不正仕事依頼が検知されるようになり、対策として機械学習モデルで検知できないか試験運用してみようとなりました。以前もベイズ推定による不正利用の検知は行っていましたが、運用継続がうまくいかず止まってしまっていた状態でした。

ここ最近でエコシステムがさらに一段階整備されたこともあり、比較的少人数で実装とMLOps周りを進めていけています。

データ分析チーム

データアナリストの入社に伴い、よりバイアスを取り除いた手法での分析ができる体制になりました。詳しくは以下をご参照ください。

note.com

全社横断技術のカバー ＆ 経営との接続

ここまではcrowdworks.jpというプロダクト開発における取り組みでしたが、弊社における複数の事業のプロダクト開発に共通した課題を見出し、現場と経営の接続をする役割も明確に（意識的に）今年は遂行するようになりました。

端的に言うと「多角化するプロダクトポートフォリオの変化に対応するための技術部門が存在せず、事業単体での局所最適化だけでは、ブリコラージュにしかならない」というAs Is。

個別のアプリケーション開発においては、認知負荷におけるドメイン知識の占有率が高いので、まだそれでも良い。しかしより専門性の高いデータエンジニアリングやプラットフォームエンジニアリング寄りの技術に関しては横断的な有効活用が必要だと感じ、新たなグループを創設しました。もう一つの狙いとして、横断的にまたがる技術課題の相談先が無いことへの打ち手でもあります。

私がこれまで所属したりお手伝いしてきた会社組織と同様、開発組織の課題は開発組織単体で生まれているわけではないものが多く、単に表面的な事象として現場に顕在化しているだけだったりします。「よいプロダクト開発をするためには結局、開発組織だけを見ていればよいわけではない」という考えの確信が高まっていく中で、現場と経営との接続に取り組むのは避けては通れない道でした。

と、ここまでの書きっぷりから伝わるように、当初あまり気乗りしてなかったこの動きを続けていくことで実は想定よりもかなり大きい気づきを得ました。

これまでの気づき

主な気づきについて、数が多いですが、以下に列挙していきます

人数が増えると容易に分断を生むことは社会人類学的に回避が難しい

• ダンバー数について知識としては持っていても、実感を得れる機会はあまりなかった
• 何か悪意があってそうなるわけではなく、そうに違いないという思い込みが増えるのも要因

現場の課題感や専門的な解決法の提示内容は経営に浸透するまで時間がかかる

• 厳密に言うと伝わってはいるが、膨大な量の意思決定をしている人たちにはあっという間に忘れられやすい
• 何回かしつこく言い続けるくらいがちょうどいい
• 課題を伝達するだけではスピードが足りない
• 我々が技術進化の速度を感じ、それに適応しようと工夫するのと同じように、ビジネスの変化や経営判断の速度に合わせないといけない

開発への投資は回収期間が長くなりがちでわかりづらい

ごく当然のことですが、その違いを前提に置いて話していく必要があります。 またひと口に開発への投資といっても、何種類か存在します。

• 比較的回収期間が短めな、（例えば）SEO対策やCPA改善の施策などはあるが、プロダクトのUXを向上させるものではない
• 社内の業務改善の開発も一定効果が見込みやすい施策ではあるが、これもプロダクトのUXの向上に直接的には繋がらない（間接的には繋がる）
• プロダクトそのものの品質向上は、関わるみんながやりたいことであるが、成果に対する不確実性は高く、即効性が高くないことが多い
• 「toilを減らすこと」はエンジニアが創造的なタスクに集中できることに繋がり、理論的には効果も高い
  • だが現場の献身によって表面的には回っているように見えると、toilを減らす必要性も伝わりにくい

これらのバランスはタイミングごとに異なるので、見極めが重要かつ、どういった状況においても、極端な偏りがないかを可視化する必要があります。

その上でケイパビリティを高める

• 会社がどの数字を重点的に追っていくかは、市場の動向や会社の状況によって変わってくるため、あらゆる場面で利益を生んだり、資産を作ったりできる力が開発が備えておくべき力
• それらをユーザーへ価値を届けるのもプロダクトの役目

プロダクトを使ってもらうことで価値交換システムを形成している以上、開発組織のアウトプットの総量を増やしただけで価値が生めるとは言えないわけですが、技術部長の職務の枠から飛び出すと嫌でもそれには直面しました。

Think Like a CTO

Think Like a CTO

私はちょっと前まで「ソフトウェア工学やテクノロジーにまつわるトレードオフを理解した上で意思決定を行う」という専門的な仕事をしていたわけで、簡単なシフトチェンジではないなと感じていました。

その頃、Tech Lead Journalを聴いていたときに、Alan Williamsonの書籍「Think Like a CTO」が紹介され、そこで話された内容が自分の動きと近かったので、書籍を読んでみました。

CTOの役割

経験上知っていたことは「CTOの役割は会社によっても異なるし、またその会社内のフェーズによっても変わってくる」ということ。知ってはいたものの、自分がビジネスやテクノロジー環境の狭間で変化に合わせた動きをすることで、ああこういうことねと非常に腹落ちしました。

それ以外にも書籍には開発責任者がとるべき態度について分かりやすく言語化されており、以下に紹介していきます

最も賢い人であってはならない

• そうでなければCTOがチームの蓋をしてしまうことになる
• Noと言える人を常に近くにおいておくこと

ビジョンを示す

• 眼の前の課題について語ることは極論、誰にでもできること
• 誰かが技術戦略やビジョンを指し示してくれるのか？という問いをしてみよう
• ビジョンが示されていないエンジニアリングチームにマイクロマネジメントしたいのか？

テクノロジーがもっとも重要だとは限らない

• テクノロジーは必要不可欠ではあるが、最重要だとは限らないという意味
• 例えば半導体メーカーのように、技術力がそのまま強い相関でビジネスに直結する会社であれば別

CEOと経営の言葉で話すこと

• CEOが特定の技術に興味が無いと決めつけるのは尚早であるかもしれない
• 知りたいことを引き出そう

偶然にも、春先からCEOと定期的に会話する時間を設けてもらっており、幸運なことにCEOが成し遂げたい世界に共感できています。いつも生意気な発言をしていますが、抽象化スキルが試されるフィードバックが返ってきます。

マイクロアグレッションは許されない

技術者同士でときに無意識のうちに無知を貶めるような会話が行われたことは、経験が長い人ほど目にしてきたのではないかと思います。ただ新しい技術の名前を覚えたから使ってみたかっただけだとしても、経営の中での会話でそれは一発アウトです。伝わる言葉で話すこと。

インポスター症候群への対処

• CTOになると皆インポスター症候群に罹る

インポスター症候群に罹る人というのは、一定自分への期待値が高く、そこと現実とのギャップに苦しむということだと解釈していますが、私は結構前から「自分がすべてを学べるわけではない」という事実を受け入れているため、インポスター症候群を感じることは記憶の限り無かったです。

一方で「新しい技術についてのキャッチアップを諦めてよい」と言ってるわけではないので、開き直りにならないちょうどよいスイートスポットがあるんだろうなと思います。

品質の責任者

• 日常的にテクノロジーから遠ざかろうとも、自分が品質に責任をもつ人物であることを忘れてはいけない

これは私のエンジニアとしての根底にあるもので強く同意しました。

まとめ

一年を振り返ると色々やったなあと感慨深くなりますね。私がやっていることは他の人からは見えづらいことが多いという自覚はあるので、透明性の維持をサボらないよう気をつけたいと思います。

We're Hiring !

来年以降も目白押しの開発施策を一緒に推し進めてくれるエンジニアの皆さんお待ちしております。 herp.careers