プロダクト開発の2024年総括とシステム思考

2024年総括とシステム思考

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

昨年に引き続き、プロダクト開発部として今年取り組んできたことと、全社におけるプロダクト開発の動きから整理していきますが、 3ヶ月ほど前に書いた自社の開発組織の強みを定義するという記事の中でも軽く触れたシステム思考の話を中心軸に置きつつ進めていきます。 *1

engineer.crowdworks.jp

また今年はアドベントカレンダーの数も昨年より倍に増えました。 アドカレの記事もまとめつつふりかえっていきます。

今年やってきたこと

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

※我々の組織では、「技術的負債」を以下のように定義しています。

一旦それらは脇において、我々の中では「現状放置しておくと開発速度の低下を招き、やがてプロダクトの競争力を失わせる技術的要因」を指し示している。

変化に適応するソフトウェアアーキテクチャと組織構造への道程 - クラウドワークス エンジニアブログ

フロントエンド

昨年に引き続き、フロントエンドでの技術負債解消を中心にしつつ、品質改善の取り組みも何歩か前進した一年でした。詳しくはcrowdworks.jp のフロントエンド活動を振り返る 2024にありますが、フロントエンド環境の進歩が着々と進んでおり、またデザインシステムを司るデザイン基盤チームの躍進も非常に大きかった一年です。

engineer.crowdworks.jp デザインシステムのユーザーは社内のデザイナーとエンジニアおよびPOであり、ユーザーに対するスプリントレビューを定期的に行うようになったことも、開発組織としての進歩でした。 「Are we agile?」という問いに対しての答えのポイントは

いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。

アジャイル開発がうまくいっていない気がするというチームに確認すべきこと - Ryuzee.com

であり、ベンチマークです。

フロントエンドでは、これまで社内での有志内の活動に留まっていたアクセシビリティへの活動もパワーアップして社外まで展開されるようになりました。 note.com 「個のためのインフラ」を掲げる会社のプロダクトとしては、数あるユーザビリティ副特性の中でもアクセシビリティの立ち位置は上位にあるもので、引き続き注力していきたいところです。

バックエンド

バックエンド側でも、引き続き地道に不要な機能の削除、不要なデータの削除、不要なライブラリの削除を行い続けています。

今年はRuby on Railsのバージョン6がEOLを迎えたこともあり、7.0へのアップグレード作業を行いましたが、メンテナンスポリシーの変更もあり、今後もコンスタントなアップグレード作業が必要となりました。 そのため、今後のアップグレード作業コストをいかに低減させるかの重要性が増しており、必然的にRails周辺の技術的負債の解像度が高くなり、メンバーのRailsの再学習へのモチベーションも上がってくるという怪我の功名のような結果となりました。 qiita.com 一例です。

組織面での取り組み

こちらも昨年から引き続き「いかに組織設計を柔軟にしておくか」がテーマとしてありました。 このテーマがシステム思考に繋がるポイントで、組織をシステムとして機能する状態に保つには、システム思考と密接に結びつく考え方である制約理論（TOC）も有効です。

前項でもとり上げた技術的負債の解消方法を例にとると、日常の中で各チームが技術的負債への対処をしようとする場合、どうしても限られた時間の中での対症療法的解決策を取りがちという制約が発生します。開発プロセスという一種のシステムがそれを生んでいるのであれば、変化を起こして革新的に改善を起こさねばなりません。その手法の一つが合同スプリントという取り組みです。

「ゆとりが必要である＋通常では辿り着かない解決策を見出す必要がある」という2つを同時に達成できるのが合同スプリントで、合同スプリントの期間は、全てのチームの施策を止めて普段なかなか解決できずに溜まっているバックログ課題を解消することに集中します。 普段はスプリントゴールという主目的があるため腰を落ち着けて根本対策を考える時間がとれないという問題も解消し、異なるチームにいるメンバーがコラボレーションすることによって気づかなかったアイデアが生まれ解決に至ることもあります。

一つの問題を解決するとまた別の箇所で新たな問題が芽を出すということもある。それはシステム思考の中でもよく語られるパターンですが、そのパターン前提で思考しておくことで、ある程度柔軟さを維持できるという好例かと思います。もちろん変化に柔軟に対応してくれる開発チーム（POも含め）のおかげでもあります。

このような考え方はエレガントパズルの中でも出てくる話で、合同スプリント開催後に読むことによりさらに手応えを感じることができました。

エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか

フルリモートが主体となる会社が増えたことで、各人が住む地方も広く散らばるようになり、従来のような開発合宿を気軽に行うハードルも多少高くなりましたので、合宿が難しいといった環境の組織にはおすすめのやり方です。

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

私の観測範囲としては、マネジメント側から何か言われるでもなく、チームの中で自発的にプロダクトゴールや自分たちのチーム運営について話し合うチームや時間が増えました。それは短期的には開発速度の停滞を生みますが、持続的に成果を生むチームとなるためには一定必要なことではあり、好ましい傾向であると解釈しています。当然、MTGの時間量にも限度はありますが、効能としては意思決定をする頻度が高くなり、その結果としてチームの意思決定の質も高くなるという副作用もあるはずで、そういった点でも効果計測できていくとよいと考えています。 note.com

プロダクトマネジメントそのものにおいても、システム思考の観点からのアプローチが有用でした。そこの繋がりを見出したきっかけは市谷さんの記事です。 note.com プロダクトも社会システムを構成する一要素として捉えることで、「システムを開発するということは」という開発者原点に戻り（個人として）解像度が一段高くなりました。プロダクトマネジメントに携わるメンバーもこの一年での個別での飛躍と組織としてのまとまりの両方が見られ、プロダクトを将来どうしていくかの対話が増えたと感じています。

AIへの取り組み

クラウドワークスでは生成AI登場以降のAI関連の仕事の増加に伴い、「AIアノテーション」などAI関連の新たな仕事カテゴリ・職種・スキルを選べるようになりました。

AI関連の仕事の推移

またAIを活用してお仕事をしていただくにあたりAI活用に関するポリシーを定めました

その他AI関連のトピック

• AI Tech社のジョインに伴い、Crowdworks AIというプロダクトとともにCrowdworks AI for bizというプロダクトが誕生
  • 比較的短期間でRAG機能の実装まで進めており、ユーザーのAIに対する期待への対応力が高まっている
• 社内用の生成AI Chatbot開発により、社員が業務で生成AIを活用する敷居を下げること、対話型AIのユーザーインターフェースに慣れることを推進
  • → 結果として社内の半数以上が毎日使うまで利用されている qiita.com
• 昨年も紹介した不正仕事依頼検知のための機械学習モデルが正式運用され、陰性と判断された仕事は即公開されるようになることでクライアントのUX向上にも寄与

AIとシステム思考

システム思考の一派であるシステムダイナミクスにおいては、フィードバックループが中心的な役割を果たし、これによりシステムの挙動の予測を助けます。この概念はAI（特にディープラーニング）において「誤差逆伝播法を通じて、ネットワークの出力と結果との誤差をフィードバックしモデルを改善する」というループと相似しており、AIの活用はそのままシステム思考を理解することと表現しても過言ではないという（全くの）私見です。

全社横断の開発

昨年末にGmailガイドラインの変更が発表され、今年の前半はその対応に多くのリソースを投入することとなりました。 具体的な対応内容はこちらでまとめてくれていますが、この難しい局面で全社のマーケ、エンジニアがよく協力して滞り無く完了できたことは関係者全員にあらためて称賛の言葉を送りたいです。

engineer.crowdworks.jp

次に全社の営業活動の効率化などを目的としたデータ統合プロジェクトが行われました。こちらの詳細もアドベントカレンダーの記事でまとめてくれています。

engineer.crowdworks.jp

今後はこういった全社での技術的な課題に対応するケースが増えていくはずで、データエンジニアリング周りだけでなくプロジェクト管理のケイパビリティも含め強化していくことが求められます。

創業エンジニアの退任

うまく表現できませんが、ひとつの時代が終わりました。 qiita.com お世話になりました。色々文句言ってごめんなさい。

まとめ

全社横断のプロジェクトが一例ですが、これまではデータもバラバラに管理されていたり、各事業のインターフェースと系統がほぼ形式知化されていない状態でした。 要は各事業同士をシステムとして捉えられていなかったということです。 開発組織に求められるケイパビリティはさらにハイレベルになっていきますが、その期待に耐えうるためにもシステム思考を一定活用していくと役立ちそうという私なりの感覚があり、実検証していきたいと考えています。

冷静に振り返ると自分は完全にマネジメントの人になったなという感慨と驚きの両方があります。まあこれも人生のひとつ。

We're Hiring !

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

*1: 「システム思考」については紹介するだけで連載記事になるのでここでは割愛します。機を見て書く意思はある