こんにちは。 株式会社ラクスで先行技術検証をしたり、ビジネス部門向けに技術情報を提供する取り組みを行っている「技術推進課」という部署に所属している鈴木（@moomooya）です。
ラクスの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「技術推進プロジェクト」というプロジェクトがあります。
以前、社外の方にこの取り組みについて紹介した際に好意的な反応を得られたので、この場でも紹介してみようと思います。
取り組みの発端
ことの発端――と言っても何か目立った事件が起きたわけではないのですが、今から4年前の2017年2月に当時の開発部長（現在は開発本部長）の提案で、社内で比較的経験の長いエンジニア達が集められました。そこでラクスの開発組織として技術的なノウハウ蓄積についての課題が語られ、それらについてブレインストーミングする機会が生まれました。
かれこれ4年前の話なので、どういった議論が行われたのか詳細な内容は記憶に残っていないのですが、ビールとつまみを用意して議論していたことは覚えています 以下のような議論をしていました。
- 新サービス立ち上げ時に新しい技術を使おうとしても時間的に余裕がない
- 新サービス立ち上げ自体が高リスクなので、技術面でのリスクを取れない
- 技術刷新行っていかないとエンジニア採用滞りそう
- 古い技術だらけになったら社内のエンジニアもやめていきそう
- 個人で使った経験があってもプロダクションレベルでの利用がないとリスキーと判断されがち
- とはいえ実サービスでは問題が出ない限りコストメリットの見えない技術刷新の優先度低い
これらのことは結構どこの会社でも同じように抱えている悩みなのかな、と思います。
こういう議論を何度か繰り返した結果、「普段から少しずつ検証しておくしかない」という結論に至りました。
経営層もこういった課題感（特に人事面の課題（採用の停滞、エンジニアの流出）が強かったのではないかと1 2）を共有してくれていたということもあり、4人で週1回午後を検証に充てる（＝週5時間）取り組みが始まりました。
これまでの軌跡
- 2017年5月ごろからサービス横断で集められた3名のチームでスタート
- このときの検証テーマは「マイクロサービスの導入是非」
- 2017年10月ごろから更に2名参加
- 2018年下期の半年間は新サービス立ち上げのために一時休止
- 2019年上期から活動を再開
- 再開時の検証テーマは「あいまい検索の実現方法」だったが、検証データを用意するために副次的に「データ匿名化」が必要になり、2テーマ並行して検証することに
- これまでは1テーマずつの検証だった
- 検証チームが2つに分かれ、3人1チームで検証
- 再開時の検証テーマは「あいまい検索の実現方法」だったが、検証データを用意するために副次的に「データ匿名化」が必要になり、2テーマ並行して検証することに
【データ匿名化】
tech-blog.rakus.co.jp
・ 『全文検索の探求 Elasticsearch(1) 』: プロジェクト方針およびElasticsearch概要
・大量データを検索するサービスでElasticsearchはRDBの代替候補になりうるか？
・データ匿名化 第1回：匿名化された個人情報とは何なのか
・データ匿名化 第2回：個人情報は匿名化しても意味がないのではないか？
・データ匿名化 第3回：個人情報を匿名化するプロセス
・データ匿名化 第4回：匿名化のために行うデータ項目の一般化とは
・データ匿名化 第5回：データ匿名化の指標
・データ匿名化 第6回：実際の匿名化
【機械学習プロジェクトの進め方】
・失敗しない機械学習プロジェクトの進め方入門
- 2020年4月にプロジェクトを運営する課として組織化
- プロジェクト名も「技術推進プロジェクト」に改名
- 同時検証テーマ数が更に増え、年間で7テーマずつ検証を進行
- 検証チームの人数も2, 3人と削減
【機械学習プロジェクトの進め方 続】
tech-blog.rakus.co.jp
・機械学習をコモディティ化する AutoML ツールの評価
・機械学習モデルを組み込んだ Web アプリを Python 初心者が作ってみた
【サービス分割を見越したドメイン層設計】
・サービス分割に備えたモノリス（モジュラーモノリスとかアグリゲートとか）
【無停止リリース】
・無停止リリース実現にむけていろいろ考えてみた（途中経過）
・無停止リリースを試してみた
・サービスを止めずにアップデートを行う無停止リリース構成の検証
【モバイルクロスプラットフォーム】
・モバイルクロスプラットフォームの技術検証
【GraphQL】
・GraphQLのアプリケーションへの組み込みを考える
- 2021年も継続的に技術刷新中
【静的解析】
tech-blog.rakus.co.jp
【CSSプラットフォーム】
・PostCSSは開発標準ツールになるのか検証しました
【ユーザー認証】
・認証規格まとめ 2021年版 - OpenID Connect & FIDO と OAuth 2.0 や SAML との違い
【ドキュメントDB】
・MongoDBについて調査・検証しました
継続のための試行錯誤
検証自体は
- 時間が与えられた
- 検証に必要な予算が与えられた
- 小規模なシステムをAWS上で構築するために必要なくらいの予算
- 内部事情を把握しているエンジニア
が揃っていたので、最初こそ手探りでしたが概ね順調に進んでいました。
割り込み作業対策
しかしこの手の従来業務と並行した取り組みは「従来業務の割り込みが増えて立ち消えになっていく」という展開はよくある話です。
本取り組みでも「ある程度経験のある現場のエンジニア」が参加しているため従来業務の割り込みが発生することは懸念されていました。 対策としては（当時はオフィスにも余裕があり会議室も確保しやすかったので）午後の5時間会議室を1つ占拠して自席から離れて作業するといった対策を取りました。
こういう話で「業務に影響でないの？」と心配される方もいるかも知れませんが、有休で休んだりすることを考えれば半日いなくても業務に問題が出ることはないんですよね。最初から毎週5時間いないことがわかっていればスケジュールもそれに合わせて引くだけです。
認知度向上
各所からの協力を得るために取り組み自体を認知してもらう工夫もしました。
成果を社内に還元する都合上、検証プロジェクトが社内で動いていることを知っていてほしいのですが、当初はプロジェクト名が決まっていないため「あの件」とか言われていたり、そもそもこういった取り組みをしていることも一部のメンバーしか知らない状態でした。
とりあえず取り組みに名前をつけようということで付いた名前が「
やはり命名というのは大事で、名前をつけたことで社内の開発部門以外（広報や人事の方や、製品企画の方）にも「かみせんプロジェクト」として取り組みが認知され、採用活動の惹きつけの際にも紹介してもらえるようになりました。
その後、運営する部署が出来たので部署名にあわせて「技術推進プロジェクト（通称：ぎすい）」と呼ばれるようになっていきます。
取り組みのサイクル
本取り組みは実際に検証を始める8ヶ月前から準備を行っています。
まずは先数年間に渡って会社として身につける必要がありそうな技術要素を技術ロードマップとしてまとめます。これは各サービスで技術選定を担当している担当者にヒアリングを行い、その結果を元に毎年更新しています。
技術ロードマップとしてまとめられた技術要素群はサービス開発の中で採用していけるのが理想ですが、すべてを即採用するというのは難しいです。
そこで各サービスの翌年度開発計画で扱われない技術要素を、技術推進プロジェクトの検証テーマとしてピックアップしています。 ピックアップされた検証テーマに必要な人員を見積もり、翌年度の人員稼働計画に組み込みます。
もしかしたら「随分準備に時間をかけているのだな」「こんなに準備に時間をかけてはコストがかかりすぎるのでは」と思う方もいるかも知れませんが、例えば突然各サービスのエンジニアの稼働を「来月から12%ほど（＝週5時間）捻出してほしい」と相談しても無理な話です。協力したくても出来ませんし、直接的に売上に直結するわけではない活動に直近の開発計画を曲げてでも参加させるというのは良くない選択です。
そのため弊社では、翌年度の計画を立てる段階で考慮してもらい、各サービスの機能開発を妨げないようにエンジニアに参加してもらうようにしています。 期間やコストはかかるやり方かもしれませんが、このようにした方が継続的に技術刷新を行うことができると考えています。
大まかな進め方
本プロジェクトは旗振り役として「技術推進課」という組織が存在しているものの、検証を行う主なメンバーとしては各サービスのエンジニアに横断的に参加してもらい、週5時間（＝約12%の人員稼働）を確保して検証を進めています。 先述の通り前年度から計画を立てて進めているので、各サービス開発チームから提供してもらう人的リソースはおおむね確保できた状態で検証を進めることが出来ています3。
このように時間をかけてでも「各サービスのエンジニアによる検証」にこだわるのは検証した成果をサービスに還元していくためです。検証のみをフルタイムで行う検証専任チームを作れば、検証時間の確保は確実に出来ますし、突発での検証テーマの組み換えも比較的容易になります。しかし、検証チームとサービス開発エンジニアが分離することで成果の共有や、取り組みの認知に課題が生まれます。
本プロジェクトのような先行検証の取り組みは成果が出るまで非常に時間がかかる取り組みです。 開発組織内の認知度や、成果の共有により生まれる有用性の認識がなければ、いつ廃れてしまってもおかしくはありません。実際に他社のエンジニアの方と話していると「過去に有志で取り取り組んでいたけどなくなっちゃった」といった声もよく聞きます。
検証成果がまとまってから実際に活用されるまでに年単位のタイムラグがあるので「成果発表」という形式には限界があります。しかし「経験者がチーム内にいる」という状況であれば（離職しなければ）チーム内にノウハウとして残りますし、必要となったときにノウハウを引き出してもらえます。
おわりに ――この取組のつらみ
成果が出るまで時間がかかる
4年前から種を蒔き始めて、最近少しずつ芽が出てきた感じです4。
扱うテーマ数を増やしたのは去年からなので、2年後くらいにはもっと成果が活用されていくのではないかな、と思っています。どうしても目に見える成果が出るのが数年後になってしまうのがこの手の取り組みの辛いところです。自分たちが取り組みの意義を信じて、各部署に意義を理解してもらって、粘り強く取り組んでいかなければなりません。
知見がいくらあっても足りない
サービス拡大とともに検証すべき技術が増えていることもあり、取り組みの規模が大きくなっている事自体は良いのですが、旗振り役を担うメンバーが足りません。現在は旗振り役を担う技術推進課の実働メンバーは私を含めて2名（東京大阪1名ずつ）なので、東京大阪それぞれもう1人ずつ欲しいところです。
純粋に人的リソースが欲しいということもさることながら、知見の範囲が不足しています。
例えば、私の場合はこれまでのキャリアから要件定義、プロジェクトマネジメント、アーキテクト、フロントエンド、バックエンド、サービス運用とそれなりの範囲の知見はあるもののあくまでウェブアプリケーションエンジニアとしてのキャリアが主軸なので、インフラやセキュリティに関する知識や勘所といったところにはあまり自信がありません5。社内のインフラエンジニアの方々に話を聞きながらなんとかやっていますが、不自由なくコミュニケーションできるレベルの実務知識はないと効率の悪さを感じます。
なので、アプリケーションもある程度理解しているインフラエンジニア経験がある人が「技術推進課」に参画してくれると助かるなぁ、と日々思っています6。
というわけで株式会社ラクスでは一緒に働いてくれるエンジニアを募集しています。詳細はこの下の各種リンクからお願いします。カジュアル面談などで「この記事見て興味持ったよ」って言ってもらえると私のモチベーションが上がるかもしれません。
「技術推進プロジェクト」のこれまでの取り組みは、以下もご参考ください！
◆ 技術スペシャリストへのインタビュー記事
career-recruit.rakus.co.jp
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
career-recruit.rakus.co.jpイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
rakus.connpass.com
- 採用コストは直接的なコストでも1人あたり数百万かかりますし、ノウハウの蓄積という意味でも長くいてもらった方が効率が良くなるはず。↩
- マザーズに上場して1年ちょっと経って開発メンバーもちらほら入れ替わっていたというのもあるのかも。↩
- 実際には障害対応であったり、サービスの開発プロジェクトが佳境を迎えていたりすると参加できない週があったりはしますが、多少は「仕方のないこと」として割り切っています。↩
- 計測できていないものも含めれば「この技術は使わない」と判断する材料として成果を活用している事例もあるので結構ありそうですが。「当面の間はマイクロサービス化しない」とか。↩
- 自宅でESXiサーバー運用したり、壁内LAN工事したりといったことはしているものの本職のインフラエンジニアのような実務に即した知識はたりません……。セキュリティ知識もテクニカルエンジニア（情報セキュリティ）（現 情報セキュリティスペシャリスト）くらいは持っていますが本職の方がいてほしい……。↩
- 知見の不足という意味ではモバイルアプリの知識や、AIとかブロックチェーンの知識なども足りていないのですが、現状ではインフラ知識不足が一番の課題領域。↩
