エンジニアリングGの井口です。WEBリサーチビジネス事業グループのエンジニアチームリーダをしています。
当グループは主に、「会員の皆様にアンケートにご協力いただき、集まった情報を元に、クライアントの課題を解決していく」というサービスを提供しています。
少し前に、グループの経営メンバーで相談し、
「ここ数年業務プロセスが大きく変わってない」→「今までのやり方じゃダメだ」→「やり方を変えて抜本的な業務プロセス・システム改革を進めよう」
という感じで、開発方針を転換したので、その取り組みについて紹介させていただきます。
業務プロセス・システム改革の進め方
大きな改革は、小さな改善を積み重ねても起こすのが難しく、「長期的なビジョン（と長期的なLTVを考慮したROI）に基づいて計画的に実施していく必要がある」という結論に至りました。ここでは、実際にどんな感じで進めているかについて、紹介したいと思います。
この結論に至った経緯は下の方に書いてあります。
1) トップレベルのミッションを明確にする
まずは、「WEBリサーチビジネスの業務プロセス」を最上位レベルで捉えました。
これをどうしたいのかを改めて考えたたところ、我々のミッションはシンプルに、
「このプロセスを少しでも早く、精度高くできるようにすること 」
だと結論付けました。
2) 具体的なゴールを描く
次に上記の１つの業務プロセスの箱の中に、役割ごとにモジュールを定義しました。
このモジュールごとに責務が分かれており、システム的にも基本的には独立するイメージです。
これに対して、2020年度末までに、システムで何をやるべきかを、ミッションに立ち返りながら整理しました。
xxxxxxの部分は各システムで本当にやりたいことを1〜2行でまとめた内容です。
後続の開発フェーズで自由なアイデアが出るの阻害しないように、このフェーズではあまり細かいことは書かないようにしました。
実際にシステムを作る際にやりたいことに対してフラットな状態で情報を収集し、最適なものを選択していくほうが良い結果が出そうです。
3) 経営メンバーでゴールを共有する
上記内容をベースに具体的な実現例を口頭補足しながらビジネスサイドに共有し、方向性が間違ってないことを確認しました。
あわせて、システム毎に
- 工数（○人月、半年、一年ぐらいの粒度）
- 定量効果（◎、○、△ぐらいの粒度）
- 定性効果（ここは結構しっかり記載）
などの情報を整理し、とりあえず最初の１システム目着手を合意、今後３年間のだいたいのスケジュールイメージも共有しました。
4) 個別のシステム開発を進める
四月後半から１システム目に着手しています。基本個別のシステム開発は、担当エンジニアに基本リードしてもらう方針です。
自分が気にしているのは、
- 外部仕様をざっくり把握。過去案件をピックアップし、設計段階で成り立つかを検証してもらう
- レアケースなど新システムで出来ないことがあった場合の代替方法があるか
- 意味のある単位でなるべくこまめにリリースして、段階的に導入すること
ぐらいです。
要は「作ったけど使われないリスク」だけを避けていければ、担当エンジニアが良いものを作ってくれるだろう！という考えです。
着手中の「アンケート回答の集計・見える化システム」の技術スタック
結論、「フロントエンドはReact.js、バックエンドはGo」で行きます。
今後作っていくシステムも、特別な理由がなければこの構成で行く予定です。
技術選定は結構チーム内でも意見が別れました。
フロントエンドは、Vue.jsと迷っていたのですが、先行して開発を進めているGUIアンケートシステムでReact.jsを採用しており、コンポーネントの使い回しなどを優先し（車輪の再発明を避けたい）、React.jsを採用することになりました。
バックエンドAPIサーバは、最初は固く「Java＋Spring Boot」で行くべきか？と考えていましたが、新しくチームにJoinしたメンバーから非常に強くGoを勧められ、最終的にGoで行くことになりました。
採用理由は、
- Goはシンプルな言語で学習コストが低い（優秀なエンジニアならすぐキャッチアップできる）
- システム開発上の関心事（ルーティング、例外ハンドリング、DBアクセスなど）をサンプルアプリを作ってくれて、実装イメージが湧いた
- フレームワークの機能が薄く、最悪別フレームワークに切り替える様なことになっても、比較的工数がかからなそう
- Javaでこれだ！と言い切れるフレームワークがない。Spring Frameworkもハマることが多く学習コストが高くて、閉塞感を感じていた
などです。
あと、自分が意識したのは、浅い理解で変に全てをコントロールしようとせず、自分が重視/不安視している最低限の部分だけを明らかにする努力をした上で、詳細はメンバーの総意に従うようにしました。
最初迷いはありましたが、決まってしまえば「Goで開発」することに、すごくワクワクしてます！
みんなで進めていきます
まるで全て自分でやってるかのように書いてきましたが、たまたま私がブログを書いているだけで、実際には、
- 強力に上記プロセスを推進してくれるシステム企画責任者の相原さん
- チームにJoinしたばかりで技術面を協力にリードしてくれる滝安さん、冨岡さん
- GUIアンケートシステム構築を推進、フロントエンド技術をリードしてくれる岩本さん
- 現行システムの保守、PDCA、改善をきっちり進めてくれるチームメンバー
- 進め方に理解を示し、協力してくれる経営メンバー
チームみんなで進めているプロジェクトです。
今後も皆で協力して進めていきたいと思ってます！！
[参考] 開発方針変更の経緯
そもそもなぜ業務プロセス・システム改革を始めることになったのか、についても参考までに記載しておきたいと思います。 興味なければ、読み飛ばしてください。
1) 問題点
ビジネス側に目標達成に対するボトルネックをヒアリングした際に、「社内作業が雑多で営業活動になかなか時間を割けていない」という声が上がりました。
自分たちとしてはこれまでもきちんと業務ヒアリングをして、改善を積み重ねてきたつもりだったので、結構心外な感じでした。
しかし、ちゃんと振り返ってみると、「一連の業務システムは昔と同じことを効率的にやっているだけで、根本的には変わっておらず、システムに依存する業務プロセスも当然大きな改善はできていない」ということに気が付きました。
2) 原因
そもそもこれまで、業務プロセス・システムを今後どうしていきたいか、長期的なビジョンを定義したことがありませんでした。 その結果、エムスリーの文化でもある「ROIを計算して、ROIの高いものから優先順位を付けて対応する」を実現しやすい、眼の前すぐに効果が出るような施策や改善ばかりを採用し、根本的な変化を起こすような改革が進みにくかったのだと思います。
3) 対策
対策は普通のことかもしれませんが、「小さな改善はこれまで通りのROI優先のプロセスで進める一方で、大きな改革は長期的なビジョン（と長期的なLTVを考慮したROI）に基づいて計画的に実施していくこと」だと判断しました。
まとめ
- 大きな改革は、長期ビジョンをうまく整理して、経営レベルで合意した上で進めていくのがよさそう（今のところは破綻なし）
- WEBリサーチビジネス事業グループは基本的に「React.js＋Go」を採用することにした
- 今後、業務プロセス・システム改革を皆で進めていきます！
エンジニアを募集しています！
WEBリサーチビジネス事業グループでは「React.js＋Go」を使って、一緒に業務プロセス・システム改革を進めてくれるエンジニアの仲間を募集中です！勉強会の見学やカジュアル面談も随時受け付けてますのでご興味があれば是非ご応募ください！
