“働く⼈のライフスタイルを豊かにする”をミッション・ステートメントに社会課題の解決に取り組む株式会社OKAN。外資系企業Microsoft Development Ltd.やポーターズ株式会社CTOを経て、2020年1月同社CTOへ就任した川口氏に、これまでのキャリアや成長期のエンジニア組織構築についてお話を伺いました。
中央大学法学部法律学科卒業後、1995年4月株式会社オービックビジネスコンサルタントへ入社。財務会計パッケージソフトの開発を担当。2001年7月よりMicrosoft Development Ltd.入社。Microsoft IME開発、はがきスタジオ開発、Surface Tableの開発に携わる。2009年10月、株式会社セカンドファクトリーへ入社。UX開発コンサルティングを経験。2011年4月ポーターズ株式会社へ入社後、技術戦略の策定と実行を担当。2014年執行役員CTOへ就任。2020年1月より株式会社OKANへCTOとして入社。現在は、エンジニア組織構築、技術戦略に携わっている。
株式会社OKANについて
弊社は、“働く人のライフスタイルを豊かにする”をミッション・ステートメントにリテンションマネジメントカンパニーとして、日本における企業課題と社会課題の解決に取り組んでいます。
現在のメイン事業は、従業員の健康をサポートするプチ社食サービス「オフィスおかん」です。導入企業の従業員は、オフィスに設置された健康的で旬なお惣菜を全品100円で購入いただけます。現在、全国累計2,000社以上に導入いただいており、従業員3名の企業から50,000名を超える企業まで規模や業種も様々です。
新規事業としては、昨年7月に人材定着を支援する組織改善サービス「ハイジ」の提供をはじめました。このサービスは、従業員アンケートと結果レポートによって、人材定着と関連の深い組織の課題を可視化できます。他社が提供している組織改善サービスの多くは、従業員のモチベーションを上げ生産性を高めるという所にポイントを置いていますが、我々はさらにその土台となっている従業員の「ハイジーンファクタ(衛生要因)」に着目し、定量的な分析・改善のサイクルを生み出すことで、働きつづけられる組織へ導くことを目標にしています。まだリリースして1年強ではありますが、既に約100社以上の企業、約1万人の従業員にご利用いただいており急成長しております。
コンピューター少年から一転、法学部へ進学
私が小学生の時、NECからPC-6001が発売されました。まだインターネットも普及しておらずコンピューターも珍しい時代だったので、近くの電気屋さんに行っては毎日のようPC-6001を触ってました。
その頃は、すがやみつる著の漫画『こんにちはマイコン』をボロボロになるまで読んだり、『マイコンBASICマガジン』という雑誌を買っては、電気屋に持っていき掲載されていたベーシックで書かれたプログラミングを打ち込んでプログラムを動かすといった幼少期を過ごしていました。
それから中学生になり、親に懇願して富士通のFM-77を買ってもらいましたね。ソフトを買うお金はなかったので、レンタル店でソフトが入ったカセットテープを借りてきて、コピーしてゲームをやっていました。
※当時のプログラムはカセットテープに録音されており、その音をデジタルへ変換して読み込んでいた
中学生の頃までは所謂コンピューター少年でしたが、高校生になってからはコンピューターへ興味がなくなり、全く触らなくなっていました。そのため大学は、勉強内容や仕事のイメージがつきやすかった法学部へ進学することにしました。
私が就職活動した頃は、MicrosoftがWindows 3.1日本語版を発売するなど世間的にもコンピューターが流行り始めていました。そのような背景があり、開発系にいけたらよいな、と思いながら就職先を選びました。新卒で入社した株式会社オービックビジネスコンサルタントでは、運よく開発部に配属されたので、そこから本格的にプログラミングの勉強を始めました。基本的な技術はそこで学びましたが、他の会社がどのような開発をしているのか、そこで学んだ開発手法がどれくらい優れているのか、正直分かりませんでした。6年程在籍した中で、社内では技術力が高い部類に入ってきたので、もっと自身のレベルを高められる環境に身を置こうと決め、Microsoft Development Ltd.（以下、マイクロソフト）の選考を受け、転職しました。
マイクロソフトのレベルに驚愕。外資と日系の違い
死ぬかと思うほどレベルが高かったです（笑）技術的なレベルもそうですが、ビジネスの進め方なども全く異なり、最初はついていくのに必死でしたね。
外資系企業なので、いわゆるロジカルシンキング的なやり方も当たり前のように取り入れていました。物事をあいまいに語らず事実ベースで徹底的に議論する姿勢や、数字ベースで語れることは数字で語る、分からないところに関しては仮説を立てて進めていくいくなど、慣れるのに半年くらいかかりました。今では日系企業でも普通に取り入れられているやり方だと思いますが、当時の日本はまだ阿吽の呼吸で進めていくような場面が多かったので、衝撃が大きかったことは覚えています。
マイクロソフト退社後は、株式会社セカンドファクトリー（以下、セカンドファクトリー）へ転職しました。セカンドファクトリーは、UX/UIを強みに人間中心設計を軸にした受注型開発を行っている会社でした。当時の業務システムは、UXが考慮されることは少なく、「使う人が覚えれば良い」という考え方で作られているものが多かったのですが、セカンドファクトリーは「人間の行動や思考パターンをもとに設計されたUX」とシステムの開発を組み合わせて提供していくということに価値を見出していました。当時のデザイン会社としては比較的珍しい進め方でしたし、私自身UXの知識を深めること興味があったため、この会社へ転職をしました。
それからしばらくの間、セカンドファクトリーで仕事をしていましたが、受注開発よりも自社開発の方が自分たちの作った価値をより多くのお客様に使ってもらえる点において良いな、と思い始めました。
そうして自社開発を行っている会社を探し始めたところ、ポーターズに出会いました。当時のポーターズは、国内シェアNo.1の人材ビジネスに特化したASP型マッチングシステムを提供しており、ちょうど新しい世代のシステムを開発しようとしているところでした。マッチングアルゴリズム(今で言うAI)の開発の話なども出ていたので、技術の力で採用の決定率を上げていくことは、非常にやりがいがありそうな仕事だと感じ入社を決めました。
ポーターズでは、0からの開発組織構築を経てCTOへ就任
入社当初は、マネージャーとして入りました。まずは、「開発できる状態に持っていくこと」が最初のミッションでした。
どんなものを作るのかまだはっきりと決まっていなかったため、社長と一緒に要件を整理し、仕様に落とし込んでいきましたね。社長からは「半年後にはリリースしたい」と言われていましたが、当時在籍していたエンジニア5名は、既存サービスの運用・保守を行っており、新規の開発をできる状態ではなかったので、急いでエンジニア採用を行いました。
採用業務に関しては、以前から携わっていたのでそこまで困りませんでした。例えば、当時のマイクロソフトの面接時では、ホワイトボードにプログラミングを書いてもらい技術的な質問を候補者へするのですが、それをそのまま踏襲していました。おかげでレベルの高いエンジニアを集めることができました。
社員が少ない頃から役員と一緒に仕事を進めていたこともあり、ほぼボードメンバーという感覚だったので、CTOに就任したところで関係性に変わりはなかったです。
しかし、業務内容はサービスが成長するにつれて大きく変わりました。入社からの3年間は、新製品を開発しなければいけない状況だったので、とにかくサービス開発を進めることが最優先でしたが、一方、それ以降は数値の話ができる状態にまで整ったので、経営的なことにも入ってくようになりましたね。
ドラッカーの本や組織論の本を読んだりと、色々本を読んで勉強しました。ファイナンスにおいては、前職のオービックビジネスコンサルタントで会計システムを開発していたので、簿記も取りましたし、帳簿もどういうものか分かっていたので基本的な知識はもともとあったのだと思います。
ちなみに、私はCTOにもファイナンスの知識はある程度必要だと感じています。ボードメンバーと経営の話をする際、ファイナンスの知識がないと会話を理解できないので、最低限、簿記の知識と財務諸表くらいは読めるようになったほうがいいと思います。
前職では、組織的に成果を上げるためスクラム開発の促進など色々なことに取り組んでおり非常にやりがいはありましたが、なによりも働いているエンジニアの幸福度を高めることこそがエンジニアリングの高い生産性につながると思っておりました。いつかそんな未来を実現したいな、と思っていた矢先、「働く人のライフスタイルを豊かにする」をミッションに掲げたOKANに出会い、OKANでチャレンジすることに決めました。OKANのミッションと私がもともと実現したいことが丁度重なったタイミングだったように思います。
サービス開発の観点では、まだまだできることがあったな、という思いもありますので、満足いく形までできたかというと物足りない気がしますが、エンジニア組織構築の観点でいうと、エンジニアの人数は約30名以上に増え、私がいなくても開発を進められるレベルまで体制を整えることができました。
入社当時、社長は自分の会社はIT企業だと思っていなかったそうですが、私が入社して1年くらい経った時、「うちもIT企業って言おうか？」と言い出し始めましたね（笑）そのくらいポーターズでは、エンジニアの存在価値を大きくすることができたんだと思います。
OKAN入社後は、スタートアップでありがちな俗人的組織をスクラム型組織へ変革
私が入社する以前のOKANは、スタートアップだということもあり、開発プロセス云々より、取り敢えずリリースすることを最優先にするような状況で、それによる弊害が様々な場所に出始めていました。例えば、口頭で仕様のやりとり行っていたために、後から「なんでこうなっているんだろう？」と何が正しいのかわからなくなってしまったり、案件ごとに個々のエンジニアが個別対応していたため、問題が起こった時、当事者しか対応できないということが発生していました。いわゆる属人化というものです。
私自身、絶対スクラム開発が正しいというような考え方ではなく、スクラムを導入するか否かは現場の様子を見てから決めることにしていました。これまでのやり方の方がスムーズに物事が進んでいたり、スピードが速かったりするのであれば、従来の方法を尊重すべきかなとも思っていました。しかし、結果としては、やり直しが発生する無駄やエンジニアが交代した時のリスク等を比較した時に、従来のやり方よりもスクラムでのチーム開発の方がメリットがあるという結論に達したので、スクラムを導入することにしました。
スクラム開発自体に不満を持つメンバーはいませんでした。ただ、同じタイミングでそれまで１つだったチームをシステムごとに2つのチームに分けたので、それに対して不安に思うメンバーはいました。以前なら各々が全てのシステムを幅広く経験できたのですが、チーム分けて分担したことによって、手をつけられる範囲が限定されてしまったからです。
メンバーにはチームを分ける目的をきちんと説明しました。「もともと俗人性が高い組織は会社としてはリスクがある状態でそれを改善したい」、「チーム体制にすることで誰かが倒れても大丈夫な組織にしていくんだよ」というような話をして納得してもらいましたね。
現在は「Solution Team」「Innovation Team」「ハイジ開発チーム」の3グループに分かれています。
- Solution Team（4名）
OKANの根底を支えるシステムを開発しているチームです。主に、サプライチェーンマネジメントのシステムや、顧客用のポータルサイトの開発、運用を行っています。オフィスおかんやおかん便などをお客様に安心してお届けできるよう、お惣菜の数量を算出したり、配送のスケジュールを決めたりするシステムです。 - Innovation Team（3名）
オフィスおかん事業に対して非連続的な価値提供を生み出すために新しい領域の開発をしているチームです。キャッシュレス決済や、画像認識、ビッグデータを使ったお客様の利用状況分析などを試みています。 - ハイジ開発チーム（3名）
組織改善サービス「ハイジ」のシステムの開発、運用を行っているチームです。
きちんと仕組みづくりをすることで、ある程度上手くスクラムを回すことはできます。スクラムの考え方として「守・破・離」というものがありますが、そのうちの「守」、つまり型を徹底的に実践できるようにすることです。
例えば、スプリントバックログでは、タスクの粒度を厳密に行っています。「なんとなくこんな感じでタスク置いておけばよいよね」とあいまいさを残したタスクをなくし、粒度と完了の定義を厳しく設定しています。同様に、完了の判定も厳密に行っています。例えば、エンジニアが「終わりました」と言っても、完了の定義と異なる場合はやり直しになったり、「未完了」と見なすよう徹底しています。
また、タスクが予定通りに進められなかった場合は、「何故できなかったのか？」を本質まで突き詰めるようにしています。単に「〇〇が出来なかった。じゃぁ、次回は気を付けよう」で終わりにするのではなく、「出来なかったのは何故なのか」を、トヨタ生産方式のカイゼンプロセスのように”Why”を5回繰り返して根本原因を解決するということを行っています。特に解決方法が精神論になった場合は間違いなく突っ込みますね。
スクラムを回し始めて半年程経ちますが、チームによって差はあれど、成長は実感しています。
技術負債やハイジの開発との向き合い方
現時点では、技術的負債を解消するための明確なルールは決めていませんが、新機能の開発の時には、疎結合であるとか、将来への拡張性などを踏まえて開発しています。既存部分に関しては、コードを変更するタイミングがあれば、可能な限り整理していくというのを状況に応じて行っています。もう少しチームのキャパシティが出てきたら、一定の時間は技術負債に取り組む時間に割り当てて、継続して取り組める形にしていきたいな、と思ってます。基幹システムや「ハイジ」もそうですがローンチに向けて急いで作ったものなので、これからサービスを拡大していく時にボトルネックになりそうなところは優先してリファクタリングやマイクロサービス化をして改善しようと計画しています。
現実問題、技術的負債の為に全て作り直すということは考えていないです。作り直した時に、前と同じ品質レベルを保った状態でリリースできるのかというと結構そこは難しいんですよね。
ユーザーからすると、内部の構造が変わろうとも、以前と同じ機能が使えることが担保されていないといけないのですが、そもそもエンジニアが前の状態を完全に把握しているかというと、なかなかそうはいかない。そうすると、無理に進めてプログラムは綺麗になったとしても、必ず抜け漏れが発生することになります。ユーザーから見たら前のシステムの方がよかったと言われかねません。もし、全ての状態を把握していない中で、作り直したいという声が上がったとしたら、それは単にそのエンジニアが既存のプログラムを把握するのが面倒臭いというだけだと捉えますね（笑）
とは言っても「今あるコードを綺麗にしよう」というリファクタリングだけでは、あまりモチベーションは上がらないと思いますので、マイクロサービス化していき、切り離していこうと思っています。このやり方では影響範囲も限定されてきますので、リスクも抑えた状態で、エンジニアの興味が持てる開発に繋げていくことができると思います。
「正解がない」ところが難しいですね。もしかしたら、なんらかのロジックがあるかもしれませんが、「これだ」というのが決まっているわけではないので。
しかし、「正解がない」というのはポジティブな意味で、「いかようにもやり方はある」ということです。そのため、短期間でPDCAを回して、仮説検証しながらサービスを煮詰めていくという研究開発的な面白さもあります。このプロセスに関われることにエンジニアとしてはやりがいがあるのではないかと思います。
CTOが目指すのは、OKANが掲げるミッションの実現
現在は、採用が30%、スクラムマスターが40%、CTOとしての役割が30%くらいですかね。CTOとしての役割は、経営会議の参加とそれに伴う意思決定、経営側への技術的説明、中長期的なプランの作成、世の中の情報収集（IT、技術）して乗り遅れないようにすることです。
OKANのミッション「働く人のライフスタイルを豊かにする」を達成することが最重要課題で、それを実現するために、テクノロジーをどう使っていくかが私の使命だと思っています。
現在、「オフィスおかん」と「ハイジ」というサービスを運営していますが、ミッションを達成するためにこの２つの手段しか用いないかというとそういうわけでもありません。ミッションを達成するためにどんな事業を新しく作っていくのかも、１つの楽しみですね。
個人的には、弊社エンジニア全員が楽しそうに開発してくれて、成果がでるような組織を作ることにやりがいを感じるので、これからも組織改善には全力を注いでいきたいです。
