みなさんはじめまして
温泉大好き大澤です。
関東の温泉を中心に毎週のように温泉巡りをしています。
今回は入社４年目にして初めてブログの担当が回ってきましたので、
自分が担当しているecbeingの製品エンハンス開発についてお話しします。
エンハンス開発ってなに？
まずはエンハンス開発とは何かです。
IT用語辞典では以下のように定義されています。
こちらの定義通りecbeingでもパッケージ（以下、PKGと略します）の機能追加や性能向上を指しています。
イメージは以下の通りです。
PKG開発チームが製品の大枠を作ります。
ここにエンハンス開発を加えて、より完成度の高いPKGを作っていきます。
ecbeingでは製品開発の片手間でエンハンスをするのではなく、製品エンハンスだけを担当するチームが製品の価値向上に努めています。
モチベアップのためにチーム名もあり、「EnCool」というチーム名で開発しています。
Enhance + Cool の造語で「PKGをいい感じにどんどんエンハンスしていこうぜ！」みたいな意味です。
チーム全員で考えて決めたので愛着も人一倍です。
ecbeing版製品エンハンス開発の流れ
ecbeing版の製品エンハンス開発のおおまかな流れについてお話しします。
下記のイメージのように大きく分けて5つの段階を踏みます。
それぞれの詳細について続けて説明します。
要望を受け付ける
要望はいろいろな場所から出てきます。
ecbeingを利用しているお客様、お客様とやり取りしている開発部門、営業、部内などなど...
次段階ですべての要望の中から優先順位を決めて改善を進める必要があるため、Teamsに投稿してもらい管理をしています。
これまでに約1200件、毎月約30件ずつ要望が投稿されますが、投稿内容を社内どこからでも見れるようにしてあります。
投稿内容を見てもらって「これいいじゃん」「自分のお客様も同じことを言っていた」などと共感できるものには投稿に👍マークを付けてもらっています。
こうすることで要望を投稿していない人からもニーズを計測できるようになっています。
優先順位決定
部内で以下の観点から要望それぞれに得点を付けていきます。
- 3C分析
- 顧客にどれだけ利益があるか
- 競合に対する競争力となるか
- 自社にどれだけ利益があるか
- 緊急性のあるものか
- どれだけの案件に適用可能か（どれだけの案件が当該機能を利用しているか）
上記得点と投稿についた👍数を元に独自の計算式で要望の得点を決定します。
計算式の元になっているのは「WSJF」という考え方で、開発をしたい順（プロダクトアウト）ではなく、ビジネス的価値の高い順（マーケットイン）で点数が高くなります。
この点数を元にEnCoolチームが製品エンハンス開発していきます。
要件定義
要望の投稿内容から実装の方針を検討していきます。
投稿内容は具体的なものから簡潔なものまであるため、ヒアリングが必要になるものもあります。
PKGである以上、汎用的な機能・作りとしなくてはならないため投稿内容をそのまま実装するのではなく、要望の課題点や背景を考えながら方針を検討する必要もあります。
また、時には投稿内容とは違ったものを解決の手段として提供することもあります。
ここが製品エンハンス開発の楽しいところでもあり難しいところですね。。。
ここについてもう少し詳しく説明します。
ecbeingとは少し離れますが、こんな状況があったとします。
こんな状況では以下のような要望が出ることが考えられます。
- 川を渡るために港を作って船を出してほしい
- 川を渡るために橋を架けてほしい
- 川を渡りたい
それぞれのパターンで解決策を考えていきます。
パターン1の場合
このパターンは具体的です。
船であれば流れが急でも問題なく、港から誰かが運航してくれるので自分で運転する必要もありません。
港と船を作る時間と余裕さえあれば基本的には問題なさそうです。
船のデザインや１日に何本発着させるかはヒアリングして決めます。
パターン2の場合
この場合は具体的ですが、言われるがままにすると問題が発生しそうです。
流れが急な川なので橋の材料によってはすぐ壊れてしまいます。
また、川の増水での事故や橋の経年劣化なども心配です。
このような場合は目的をもう一度考えます。
今回は橋を渡りたいのではなく「川を渡って目的地に着くこと」が目的です。
目的からいくつか案を検討し、一番汎用的なものを選択します。
ヒアリングなどの結果から開発チームからは「飛行場を作って飛行機を飛ばす」「港を作って船を運行する」「トンネルを掘る」が立案されました。
今回はこの中から作るときも、作った後も最も安価で誰でも利用可能な「トンネルを掘る」を選択します。
パターン3の場合
こちらは最もざっくりとした要望です。
具体的には何も言及されていないので、まずは開発チームで実現可能な案を検討します。
検討した案を元にヒアリングを行い、今回時間的な余裕があることが分かったので「岸と岸をつなぐビルを建設する」となりました。
以上のように要望の目的やニーズ、利用者の状況などから方針を検討していきます。
上記のような検討に加えて、ecbeingはPKGの規模が大きく、連携先も多岐にわたるため、改修による影響を洗い出すのも大変な作業となります。
製造
ここまで来てやっと製造に入ることができます。
設計、製造、試験と通常の開発フローです。
規模の大きい機能の時はタスクを切り分けて複数人で同時に開発することもあります。
また、チーム内試験の後はQAチームに試験を依頼し、機能の完成度を高めます。
QAチームの試験については以下記事をご覧ください。
展開
最後に展開です。
PKGには次回リリースの最新バージョンと過去リリースしたバージョンの２パターンあります。
最新バージョンでは改善を利用してもらえるタイミングは先ですが、過去リリースのバージョンには改善をパッチとして提供となります。
そのためお客様ごとに組み込みのタイミングはそれぞれですが、改善をすぐに利用してくれるとうれしいですよね。
さいごに
いかがでしたでしょうか。
ここまでecbeingの製品エンハンス開発について説明してきました。
製品エンハンス開発は対応の優先順位と要件定義が特に重要だと感じています。
チームの目標はドラえもんのように「あんなこといいな」「できたらいいな」を叶えていくことです。
まだまだドラえもんのようにはいきませんが、寄せられる要望も日々複雑化し、規模も大きくなっているので、チームとともに成長していきたいと思います。
ecbeingではモダンを追い求めるエンジニアを募集しています！！ careers.ecbeing.tech
