この記事は、クラウドワークス Advent Calendar 2024 シリーズ4の23日目の記事です。

こんにちは、のむらです。
2024年12月20日をもって、長らく務めさせていただきました取締役を退任しました。せっかくなのでこの13年をふりかえり、自分が得た学びを少しでも世の中に還元すべく、したためてみます。

まずはふりかえり

創業〜プロダクトリリース

クラウドワークスは2011年11月に創業し、2012年3月にプロダクトの初期リリースをしました。

この間の4ヶ月は、起きている時間はほぼプログラミングをしているような生活でしたが、自分の人生の中で最上級に幸せな時間でした。いわゆるフロー体験がずっと続いているような感覚です。

ただ、今ふりかえるとそれは、社会やユーザーと接続されていないが故の居心地の良さであり、決して手放しで賞賛されるべきものでもないようにも思います。

プロダクトリリース〜組織拡大

1度のリリーススケジュール延期を経て、クラウドワークスは無事リリースされ、時流の波に乗って成長を続けました。

サービスの成長とともに開発組織も拡大しますが、自分はここで暗黒時代を迎えます。

そもそもマネジメントという概念がない（言葉としては知っているが、根本的に何も理解していない）
現場の課題解決（プログラミング含む）という「楽しい」仕事を手放せない利己心
自分が「うまくやっていた（つもりの）」仕事を他者に渡すことへの不安

これらの要因により、「個々人のスキルはしっかりしているがマネジメントのなされていない開発組織」が爆誕。結果として「人数の割にはリリース速度が遅い」などの課題が顕在化し、当時現場の責任者兼開発担当取締役だった自分は経営会議等でもずいぶん詰められた記憶がありますw

この頃は、「何かがうまくいっていないが、何が課題なのかがわからない」という状況でしたが、『「何が課題なのかがわからない」という状況であることが認知できていない』という「メタ解らない」状態でした。やばい。

自分が苦しかったのは自己責任なので諦めもつきますが、当時の開発メンバーには自分の至らなさで色々と不本意な思いをさせてしまったであろうことはいまだに悔やまれます。

この問題は結局当時の自分にはどうすることもできず、上場後に入社した某氏のおかげで改善に向かいました。その後は既存メンバーの成長に加えて外部からも継続的に優秀な人材を採用することができ、紆余曲折はありつつも組織としては継続的に成長できているのではないかと思います。

自分もようやく組織マネジメントという概念を得て、その後の仕事にはそれなりに活かせています（と思いたい）。

上場〜管理部門へ

その後、東証マザーズ市場（現：グロース市場）上場を経て、諸般の事情により2018年5月に管理部門へと異動。未経験のバックオフィスを管掌する「管理担当取締役」になります。決算短信や有価証券報告書に責任者として自分の名前が載ったことは、一生の記念ですw

コーポレート編

コーポレート部門では主に管理体制の立て直しと、某事業（お察しください）のBSの精査を行いました。前者は現在の管理担当取締役（当時は本部長）が主導して行なってくれましたが、後者はそもそもの問題が自分の開発したシステムに起因することもあり、自分自身で手を動かすことも含めて取り組みました。

この時期は未経験の領域だったためとにかく学びが多かったのですが、特に後者のプロジェクトではソフトウェアエンジニアとしてめちゃくちゃ重要な学びがありました。その内容についてはさわりの部分だけ以下のエントリに記載していますが、正直なところこれを読んだだけではなかなか伝わらない気はします。

あえて一言で言えば「そのソフトウェアのしていることを会計的な視点から眺め、それを実装する」ということです。少なくとも自分の触れてきたソフトウェアはどれも、「事業的な視点」からのみ実装されており、「会計的な視点」は組み込まれていませんでした。結果として、それらのうち一定規模に達したものは、例外なく会計的な問題をはらんでいました（同業のランサーズさんも例外ではないようです）。

この問題はおそらく今後も多くのサービスで顕在化していくものと思われますので、自分の得た知見を何かしらの形で世の中に還元したいお気持ちがかなりあります。

社長室編

その後は「社長室」という組織を管掌し、「ミッション・ビジョン・バリュー」に代表される、企業カルチャーの言語化や浸透施策を担当しました。クラウドワークスのミッションが「働くを通して人々に笑顔を」から「個のためのインフラになる」にアップデートされたのもこの時期です。

この役割での最大の学びは、人を突き動かすのは「ミッション・ビジョン」であり、リーダーの最大の仕事はそれらを描くことである、ということです。この記事の後半に「リーダーの仕事は課題設定」ということを記述していますが、「課題」＝「目指す状態（≒ビジョン）と現状の差分」ですので、まあ要はそういうことです。

新規事業チャレンジ

直近では、主にPARKという新規事業を担当していました。

事業としては最初からPMFしていたクラウドワークスと異なり、最初は全くの鳴かず飛ばずでした。その中でとにかく潜在ユーザーにSNSなどでコンタクトを取り、精一杯のサポートをすることでまずはサービスを使っていただき、フィードバックをもらって機能を改善し、可能な場合は別の潜在ユーザーも紹介していただく、ということを100件以上繰り返して突破口を見出してきた過程には大きな学びがありました。

今ではGMVも大きく成長し、アンジャッシュ渡部さんなど各界隈の著名人が利用されたり、サービスに満足されたユーザーさんが友人・知人に勝手に紹介してくださったりと、世の中に対して一定の価値提供ができるプロダクトにはなってきました。

13年間の学び（一部抜粋）

大切なのは「現実を直視すること」

上には書かなかったうまくいかなかった新規事業や、クラウドワークスで実装したが全く使われなかった数々の機能群、あるいはPARKでのうまくいかなかった初期の経験、あるいはうまくいったきっかけ、それらを一歩引いた視点で眺めると、事業において一番大切なことは「現実を直視すること」であると感じます。

一言で「現実」といっても色々ありますが、最も重要な現実は、「顧客は誰なのか？」「その顧客は何に困っているのか？」です。振り返ると、自分が失敗してきたパターンは、「そもそも顧客（≠ペルソナ）が特定できていない」あるいは「顧客が何に困っているが見えていない」状態で、自分たちの頭の中で「妄想」した顧客のためのプロダクトを作ってしまうパターンです。

同様に、自社サービス内のユーザー動向といった「客観的ではある（＝妄想ではない）が、解像度の粗い情報」を元に立案した施策も、打率はそれほど高くありませんでした。これもまた、「解像度が低すぎる」という意味で現実が見えていない状況でした。

自分が主に扱っていたtoCのプロダクトは人を介さずに売ることが基本で、人によるセールスで売っていくことが多いtoBのプロダクトよりも上記の罠にハマりやすい構造があります。成功するtoCプロダクトを作るには「それってあなたの妄想ですよね？」という空気を読まないコメントあるいは自問自答が必要であると思います。

課題解決はエンタメ、リーダーの仕事は課題設定

エンジニアという職業は、本質的には「課題解決」する役割であると考えています。それと対比すると、マネジメントという役割は「課題設定」、すなわちメンバーが解くべき課題（＝この課題を解けば、目的・目標が達成できるという課題）を設定する役割です。

そして、より「楽しい」のは前者の「課題解決」です。人によるといえば人によるのかもしれませんが、世の中に「課題を設定する」というゲームがないことからも、楽しいのは基本的には「課題解決」であることがわかります。おそらく、「課題を解く」ということは「獲物を捉える」ことに似ていて、脳内麻薬的なものが出るような仕組みなのだと思います。

プレイヤーからマネージャーになって最初に越えなければいけない壁は、「課題解決」というエンタメを手放すことです。多くの人が「自分でやった方が早い（あるいは成果が出る）」を言い訳に、この壁を越えるのに苦労するように感じます（私自分も例外ではありません）。

こんなことを今更改めて書いているのは、今後AIの進歩により、「課題解決」はそもそも人間の仕事としては減っていくと思われるためです。ありたい姿・あるべき姿を描くことの価値は、今後ますます大きくなっていくはずです。

技術的負債はなぜ生まれるのか

　　エンジニアのスキル不足　　開発方針の不在　　　開発者の妄想
　　　　　　　　　　　↘︎　　　　　　↓　　　　　↙︎
　　　　　　　　　　　　　＿人人人人人人人＿
　　PMFまでの道のり　→　＞　技術的負債　＜　　← 　PM・POの妄想
　　　　　　　　　　　　　￣Y^Y^Y^Y^Y^Y^￣
　　　　　　　　　　　↗︎ 　　　　　　↑　　　　　↖
　　　　マーケットの変化　　　　資本主義　　　　　技術の進歩

その名前からも「技術的な問題」であると思われがちな「技術的負債」ですが、起きたことの結果だけ点で捉えればもちろん技術的な問題ですが、それが生まれた原因は上の図のように多岐に渡り、技術的な要因はごく一部に過ぎないというのが現時点での私の結論です。

技術的負債をコントロールするには（「解消」できないというのはおそらくもはやコンセンサス）、技術的な観点だけでなく、プロダクトマネジメントの観点、事業戦略の観点、さらには経営の観点が必須であり、その意味において当社は技術的負債への対処として「正しい」道を歩んでいると思います（公開記事につきボヤッとした書き方ですみませんw）。

法人と個人は似ている

「株式会社クラウドワークス」という、会社（＝法人格）の中で13年間過ごしてきて、「法人と個人はとても似ている」というのが大きな一つの学びです。

どの会社にも「キャラ」あるいは「芸風」みたいなものがあり、会社としてそれに合わないことをしようとしても、なかなかうまくいきません。

また、その「キャラ」みたいなものは、その「中の人」、特に創業者、CEOをはじめとする経営陣といった相対的に大きな影響を持つ人たち、それからもちろんそこにいる従業員や関わる人たちの総体であり、それらの人々の成長や、会社自身のおかれる環境によって変化していきます。

会社の「成長」は基本的には直線的あるいは連続的であり、当社の業績の推移を見てもおおよそそのようになっています（そのことの良し悪しはさておき）。一方、個人と同じように会社にも「発達」とでもいうべき進歩があり、これは最近で言えば「生産性向上」に取り組む前後や、それよりも以前では「CWカルチャー」を定める前後など、会社として「質的に」大きく変わる局面もありました。

現在クラウドワークスは14年目、人間で言えば中学生くらいです。今の会社としてのステージ・成熟度は、「世の中の仕組みを一通り理解し、自己認知も進んできたが、まだまだ未完成」という中学生のイメージに、不思議と一致しているような印象を持っています。これからも会社として様々な「発達」があるであろうことを想像すると、このタイミングで退任するのは勿体無いという気持ちも否めません。

仕事は目的・人生はプロセス

前項で「法人と個人は似ている」と書きましたが、決定的に異なる点が一点あります。

それは、法人には「事業という目的」があり、個人の人生にはそれにあたる唯一の「目的」がないということです。

法人には「目的」がある以上、その構成員であるところの我々の「仕事」にも「目的」が必然的に存在します。一方、個人の人生を考えると、最終的にはみんな何も持たずに死んでいくわけですので、「日々を充実して、幸せに過ごす」というプロセスが大切であると考えています。

これらを混同して、会社的な「目的・目標」を柱とする価値観を個人の人生に（無意識的に）持ち込んだり、逆にプロセス重視の価値観を仕事に持ち込んでしまい、なんだか働きづらい、あるいは生きづらい感じになってしまうケースがままあるように思いますので、最後に書き留めてみました。