教育系企業に開発部門をつくる5年間の取り組み
長い間、教育系企業を教育×インターネットベンチャーするため、社内に開発部門をつくる取り組みを模索しながら進めてきました。この5年間の取り組みで知見も溜まってきたのでまとめてみることにしました。
前置きとして、これらの取り組みは僕ひとりで進めてきたわけではなく、会社全体のチームで取り組んで来たものです。ご留意いただければ幸いです。
少し長くなるのでアウトラインまとめておきます。
- 業務委託
- 学生エンジニア育成講座
- 外国人社員エンジニア育成
- CTO就任&エンジニア採用
- 組織体系の変更
- 1 on 1 の導入
- HackDayの取り組み
- ３人目のエンジニア採用
- 組織化への取り組みへ
1.業務委託
およそ5年前の2012年に、社長から作りたいモノの構想を聞きました。当時、駆け出しのフリーランスのエンジニアをしていた私は二つ返事で受け、日々のレッスンを提供するための仕組みを改善するシステムの設計・開発をしました。
組織としてシステム発注の経験があった企業ではないので、（HPの制作やマーケティングは協力企業と連携をして実施してました）要件定義などは厳密にすることはできませんでしたが、もともと僕自身がディレクターをやっていた経験とフリーランスの経験で培いつつあったヒアリングテクニックを駆使しながら、システムは無事リリースできました。
合わせて、システムを作るだけではなくハードウェアを用意したり、充電や社内ネットワークの整備など複合的な問題解決能力が培われました。意識したことは、できないと言わないことです。できる、ただし、これこれが必要ですみたいな形で進めていきました。
インターネットサービス開発の時は、リリースしても鳴かず飛ばずということを多く経験していたのですが、リリースした瞬間から目の前で使われはじめるというのは凄く興奮した記憶があります。いまでも、この経験ができることは、「×インターネット」の様なハイブリッド企業の醍醐味だと思っています。
思い返すと、この時期は社長が中心的なエンジンとなって組織を動かしつつ、開発について1人で奮闘していた時期です。（アドバイスに乗っていただく方はいましたが）何事においてもローンチすることが最優先課題でした。
2.エンジニア育成講座
引き続き1人で、保守や改善を続けていたのですが、社長からエンジニアを組織化する構想を聞かされ始めます。たまたま、別の仕事でプログラミングのスクールをやっていたこともあり、エンジニアを育成してみてはどうか、という提案を受けて実際に動き始めます。
この取り組みはいまでもやっていて、今年で5期目になります。主にアルバイトの学生さんを対象に無料でプログラミングの授業を実施しています。この講座についても改善を続けて、かなり良くなりました。
一方で、エンジニア育成といってもそんなに簡単ではなく、一人前になるまでは時間がかかります。開発をしながら講座をするというのは両立の面では大変でしたが、また後で書きますが、長きに渡る取り組みを諦めずにやり続けたことは良かったと思っています。
やり続けるために意識していたこととしては、エンジニア育成講座の成果は時間がかかるというコンセンサスをしっかり取っていたことです。
3.外国人社員エンジニア育成
同じく即効性のありそうな取り組みとして社長から提案を受けます。同じく会社内に別組織として別の事業部があり、そこに外国人の先生がいました。彼はもともと、それなりにバックグラウンドがあるので、彼であれば育成できるのではと。もちろん、彼も職種（教師→エンジニア）の変更を希望していました。
組織としてはCakePHPからRuby on Railsに移行していた時期でもあり、Railsの新規開発（学習目的のプロトタイピングを含む）を進めていきます。苦労したこととしては言葉の問題や、地理的な問題（オフィス場所が異なり顔を毎日合わせない）、などがありましたが、無事リリースまで漕ぎ着けることが出来ました。
これらの課題に対して、（いまでも正しいのかわからないのですが）続けたことは、作るシステムに対する自分の熱意を伝え続けることです。業務委託の時代にシステムをつくる孤独感のようなものを理解していたのが良かったと思います。
残念なことに、（半分は嬉しくもあるのですが）彼はエンジニア能力を身に着けたことをきっかけにフリーランスに挑戦したいということで、また組織としても事業を集中するための組織変更があり、いまは一緒には働いていません。
いま、組織は日本語を中心としていることもあるのですが、もしグローバルなチームを作るのであれば、また声をかけたいと思っています。やはり長く一緒にやってきたメンバーと離れるのは辛くもあります。
大きな学びとしては、マネジメントの難しさと、事業成長の重要さです。開発タスクは当時はRedmineでチケット化してましたが、モチベーション・マネジメントがうまく出来てなかったと思います。理想像としてのセルフモチベートされる仕組みがなかった。もし、これができていれば離れるということはなかったかもしれない。
また、それよりも大事なこと事業が成長していることです。事業が成長していないと継続はできません。このシビアさについて、骨身にしみる経験になりました。
4.CTO就任&エンジニア採用
上記の出来事と平行している部分もあるのですが、4年くらい前の2013年の4月に取締役になる提案を受けます。合わせて、エンジニアの採用が決まっていました。そこで、開発を続けつつも、開発組織をつくることを本格的にやることがミッションになります。
僕の状況としては上記の事柄を進めていくなかで、面白みを感じつつあり、また時間が足りなくなり、ほぼほぼフルコミットになっていました。なのでフリーランスを辞めてフルコミットすることの抵抗感はありませんでした。
やはり一人でできることの限界と、チームでやることのダイナミズムと、すでにリアル事業があることのメリットと、就任先のミッション・ビジョンへの共感と、などなど、チームに入ることの理由は上げればきりがありません。
（フリーランスか組織で働くかについては、結局のところ個人に於ける価値観やスタイルに依るところが大きいのですが、僕は組織の方が良いと思っています）
この時は、組織づくりということを明確にミッションに対し、経験もなく何をして良いのか分からないというのが正直な思いでした。一方で、これまでの経験から、未経験のことでもやってみることで前に進むということを学んでいたので、失敗や軋轢を恐れずにやってみることを大事にしていました。
5.組織体系の変更
そこで初めに取り掛かり始めたことが、エンジニアがなるべく開発に専念できるような組織体制の変更です。いまでも、組織はそこまで大きくはないので、またいろいろな業務を知ることのメリットはあるので、エンジニアは多くの業務を経験することはあります。しかし、定常的にやる業務は開発業務に集中させるための組織変更をしました。
ちょうど組織も大きくなり始めていていたので、エンジニアだけでなく、ほかのチームも全体野球からのシフトを、ということでルール変更をしました。結果としては、まだまだな部分があるし、継続的な改善が必要なことではありますが、組織体系としてはちゃんとしたと思います。
IT企業では当たり前ではありますが、エンジニアという職種の特性などを考え、業務が中断されにくい環境づくりなどを進めました。
ここでも反省があります。ひとつはスピード感が足りなかったこと。もう一つは制度先行で進めてしまったことです。スピード感については、新サービス立ち上げを含む開発をしながらの作業だったので、サブプロジェクト的なニュアンスでいました。しかし、当事者たちとしては毎日の業務で実感することです。ココらへんの温度感に差があったと思います。
また、この移行期に、制度先行ではなく文化先行で進めて欲しいとの指摘を受けました。制度いきなり作るのではなく、その文化を先に浸透させて、それから制度を作る。既成事実を先に作っちゃう。その方がうまくいくことが多いんですよね。このことを知らないことによって無駄な軋轢を生みました。
6.1 on 1の導入
これらの反省をする上で導入したのがヒアリングをする機会を設ける１ on １です。上記のことで悩みまくっていた時に、ちょうど１on１がネット界隈で話題 になりはじめていて、すがる思いで実施を決めます。
合わせて、エンジニアレベルを中級レベルから上級レベルへの上げることが個人的にやりたかったことでもあります。結果として、かなり効果的な実感があります。実施を悩んでいる方がいれば、やってみることをおすすめします。合わなければやめればいいだけなので、マイナスは殆どないと思います。
別途で個人的にプラスになったのが、１on１を繰り返す中で、聞き方などの勉強になりました。何より大事なことは、答えは相手の中にある、ということが実感として理解できたことです。このことによってミーティングなどの仕切りなども、以前より効率的に回す事ができるようになったのではと思っています。
反省としては、これと合わせて最後に書く組織化の取り組みをすべきだったと思っています。
7.HackDayの取り組み
組織化の前に、１on１の成果物のひとつ。HackDay。１on１をやるなかで提案を受けます。エンジニアは日々の業務を重要視して、棚卸しをする機会がないと。
副次的にも、個人的に課題と思っていたエンジニアレベルの向上にも狙えると思いました。そこで、月１回、８時間くらい時間をとって全員でブレストからはじめて、棚卸業務のHackathonをする取り組みを始めることになりました。
これは現在まで続いていて、１on１とも連動する形にもなっています。
8.３人目のエンジニア採用
もう一つ差し込みで。エンジニア育成講座からの採用が2016年7月に実を結びました。時間がかかり過ぎかもしれませんが、それまで長くやってきたこともあり、すでにメンバー間で信頼関係ができているので、ベストな採用になりました。
この時に個人としては採用は自分の仕事である、とういうことを強く認識しました。プロダクトを作るということを任されているな中で、どういう人と働きたいか決めて、それに必要な環境を用意することも、当然ミッションなのだと思いました。
いまでは４人目以降のメンバーを募集しています。まずは、僕が話を聞きますので、ご興味があればご遠慮なく下記から連絡してください。
日本の英語教育を変える✨サービスを作れるエンジニア募集！ by 株式会社キャタル _Career at 株式会社キャタル. キャタルでは日本の英語教育の問題を解決したいエンジニアを募集しています。 エンジニアチームは現在3人ですので、機動的に動くことが求められます。企画や要件定義もエンジニアの業務範囲に入ります。チ…_www.wantedly.com
インターネット❌教育サービスのプロダクトマネージャー募集！ by 株式会社キャタル _Career at 株式会社キャタル. 教育❌インターネットサービスのプロダクトマネージャー募集！ PM職の方にはどのような問題を解決するの定義すること、またその改善を指数化して計測可能にすることが求めれれます。また、実際に物を作る…_www.wantedly.com
プロトタイプ制作からUI/UXデザインまで幅広く活躍するデザイナー募集！ by 株式会社キャタル _Career at 株式会社キャタル. プロトタイプかUIデザインまで幅広く活躍するデザイナー募集！ エンジニアと一体となってサービスの改善を行っていただきます。また、新しく機能を開発する際のプロタイプの製作なども行っていただきたい…_www.wantedly.com
9.組織化への取り組みへ
こうしてチームを作ってきたのですが、組織について日々悩んでいました。（プロダクトや戦略についても、日々悩んでいるのですが）果たして、チームはやるべきことに集中しているか、パフォーマンスの最大化はできているのか、といったことです。
１on１の成功体験もあって、チームが機能するとはどういうこととか、心理的安全性とか、モチベーション3.0とかを勉強し実行していました。がんばってはいるものの、上手く行っているのか自信が持てないでいました。
しかし、最近気づいたのですが、そんなことをやる前にやることがあったのです。各種プロジェクトの進捗状況をしっかりと把握できる仕組みとつくること、また期待する役割とそこで期待されるアウトプットを定義することです。
（大事なことは、プロジェクトを把握することではなく、プロジェクトを把握できる仕組みをつくること）
結局は、プロダクトに向かうことが大事なのに、人の問題から出ることが出来ず、当たり前にすべきことが出来ていなかったのです。
こういったことから出る問題の例を上げると、例えば新しいメンバーが入った時に、何を任せるのかという話にならず、どこのチームに入れるかが話になることです。どこのチームに入れることは大事なのですが、何をやるかの方が、もっと大事なはずです。
その話にならない原因としては、期待する役割とアウトプットの定義がないからです。定義があれば、参加するチームは必然的に決まるので、何をやるかの話にダイレクトにいけるはずです。
もっと早く気付けですね。はい。
。。というわけで、、最近はこんなことを模索してます。ひょっとしていま、上手く行っていることも上手く行かなくなるかもしれません。
こんな四苦八苦している毎日ですが、一緒に仕組みづくりとサービスづくりに協力してくれるメンバーを募集してます。自分にあった環境を探すより作っちゃったほうが早いかもしれません。何より楽しいです。ご興味のあるかは、ぜひ、お願いします！