こんにちは、キカガク CTO の祖父江です。キカガクは AI・機械学習の会社と面接で言われることも多いのですが、「あるべき教育で人の力を解放する」ために 3 本の事業（後述）を軸にしている組織となっています。
教育事業部や fwywd などの他事業からは他媒体でアウトプットされているにも関わらず、開発事業部として技術の話をアウトプットしてきませんでした。エンジニアが急増してきた面白いフェーズの今を知ってほしいという目的でテックブログを開設しようとなりました。これから週 1 持ち回りでメンバーが記事を投稿していきますのでぜひご覧ください。
少しでも興味を持っていただけたなら正社員 / 業務委託の関わり方は問いませんので、一度カジュアルにお話させていただけると幸いです。
www.wantedly.com www.wantedly.com www.wantedly.com
キカガクの事業
キカガクは AI / 機械学習など先端技術の研修事業、e ラーニング事業、DX 推進事業（技術開発/コンサルティング）をおこなう組織です。
それぞれの事業が単独で動くのではなく、3 つの事業が相互に良い影響を与え合う事業体制になっています。例えば、研修事業では法人様が求めるゴールをコミュニケーションを取りながら研修案に落とし込む必要があります。その際先方が求めるゴールに対して明確な学びの道筋を作れるのは DX 推進事業が活用現場を知っており、幅が広い AI / 機械学習 / データサイエンス領域においてギャップを埋めるための最善策を提案できるためです。
そして活用現場と教育現場の両面を知っているからこそ、最適な学びの道筋、コンテンツを提供できると考えています。
キカガクが考える教育
キカガクが考えるあるべき教育については 弊社副社長の西沢の記事 がありますので詳しくはそちらをご覧ください。
上記の記事で大切なキーワードが「学びの評価方法の基準を『活躍』に変える」です。これまでの教育は暗記力の評価やテストの点数で学生時代から評価されてきました。もちろんある一定の効果があることは私自身も実感していながら、それが社会で活躍できるかどうかと直結しないということも実感しています。
キカガクではこれまでの「知識力」に加えて、活躍から逆算された「実践力」を試すことが重要になると考えています。現在は Step1: 学習に着目してサービスを提供していますが Step2: 証明、Step3: 活躍に紐づく機能も提供できるように開発を進めており、学習から活躍まで一気通貫して提供できるプラットフォームにアップデートした姿を皆様にお披露目できるのを楽しみにしています。
開発組織について
詳しくは別ブログで書く予定ですが、弊社の開発チームについて少し書いておきたいと思います。2022 年 Q2 から開発組織体制と開発方法を刷新しました。
マイクロチーム×横断チーム
前提として弊社のチームはまだまだ小さいのですが採用が回りだし、人数が急増することになりました。2021 年末に 4 名でしたが 5 月現在 9 名体制（業務委託含）になりました。そこでこれまではプロジェクト毎で全員に役割を分担してきたところを、プロダクト毎に少数チームを設立し、プロダクト毎のクオリティコントロールのために Tech Lead をプラットフォームチームとして据えることにしました。
今後人数が増えるとチームを職能別に分割することも考えていますが、現状は Designer と Data Engineer もプラットフォームチームに属しています。
弊社では目標管理手法として OKR を導入しているのですが今期からチーム毎に OKR をおくことでそれぞれの目標が明確になり、責任範囲も鮮明になることで迷うことなく進められています。その結果私が細かくマネジメントする必要がなくなり、組織横断的なインフラの課題やプロダクトの未来のことに注力できるようになりました。
現状は上手く回りだしているのですが、まだまだやりたいことに対して人数が足りていませんので引き続き採用に注力していきます。
スクラム開発の導入
これまではプロジェクト毎に 2~3 ヶ月の大きなプロジェクトをビックバンリリースすることが多かったのですが、チームの生産性が見えづらく改善がしづらかったことと社内にアジャイル経験者が入社したことを契機にキカガクでもスクラム開発を導入することにしました。まずはチームで共通ルールを持つことが目的です。
Jira などのプロジェクト管理ツールを導入している会社も多いのですがまずはスモールスタートとしてエンジニアの手に馴染む GitHub だけで進められないかを検討しました。そして Tech Lead の方が GitHub Project beta × Milestone × Label をかけ合わせると最低限できる案を提案してくださいましたので採用しました。
- Milestone でスプリントを区切り、Issue を紐付ける
- Issue 毎に point を付与し、5point/人として振り分ける
まずは細かい PDCA を回すためにスプリントを 1 週間に設定しています。毎週月曜日のキックオフで先週の振り返りを実施し、チームの進捗確認と生産性の可視化をおこない、今週の Issue を振り分けています。これまでは感覚的だったのが徐々にチームの生産性として蓄積してきています。
課題としては GitHub Project beta ではベロシティやスプリントキックオフで決めた目標の達成率などを簡単に計測ができないので、パフォーマンス最大化のための改善の流れが作りにくいです。今後はチームで生産性を数値で可視化できるようにし、チーム内で継続的な改善が進む組織体制を作っていきたいです。
おわりに
開発組織も人数増加により、これでこれまでやりたいけどやれなかったことをやれるようになるぞ！と飛び跳ねていましたが、逆にやりたいことが溢れていて『あれ？』と毎日頭を抱えております。人数を増やせているときはそれ以上にやりたいことが増えていきますね。
というわけでまだまだやりたいことがあるのに人が足りません。少しでも興味を持っていただいた方はお気軽にカジュアル面談からお話させてくれませんか？
ではまたの機会にお会いしましょう。
