この投稿は、2023年JINSのアドベントカレンダー12日目の記事です。
はじめに
8日目に引き続き、佐藤(@Takuma_Sato)が担当します。前回はシステムアーキテクチャ設計で気をつけることをテーマに書きました。よろしければご覧ください。
さて、今回は、「サービス企画やシステム開発の内製化」がテーマです。
SPAモデル(製造小売業)の事業を営んでいるJINSは、ITシステム、デジタルの企画・開発・運用を担当する部署がありますが、以前より感じている課題としては、外部のシステム開発会社やSIの力をお借りしつつも、JINS自らシステム開発を主導したビジネス貢献をもっと増やすことです。
これは、JINSのデジタル戦略の中にある「デジタルリテラシーの学習環境を整備」にも関係しまして、今回はそんなお話です。
AWS DIP(Digital Innovation Program)ってなに？
唐突ですが、AWSの提供しているサービスの一つに、DIP(Digital Innovation Program)と言うモノがあるのはご存知でしょうか？私はAWSから提案を受けるまで知りませんでした。
このサービスは、Amazonで培われたイノベーションのノウハウを一般化して、他の企業でも活用できるようにするプログラムです。Amazonの有名な考え方として「Day1」がありますが、これに関わる手法として「Working Backwards」があります。この手法を中心に組み立てられたプログラムになっていまして、具体的には、以下の手順で実施します。
なぜこれをやろうと思ったか
(1)背景
JINSはAWSを2014年から使い始めているのですが、今では事業で扱うシステムのほとんどはパブリッククラウドで稼働するようになっています。いわゆるLift & Shiftを進めてきたものの、クラウドネイティブ化の成熟度合いは満足できるものではまだありません。
また、サービス企画の活動においてもデジタルを活用した試みが十分とは言えない為、Amazonで実績のあるイノベーション手法を参考にしつつ、JINSならではの挑戦をしていこうと考えました。
(2)実現したいこと
このプログラムを有効活用するには、自社において何を成し遂げたいのかを明確にすることが重要だと考えまして、活動を開始するに際し、実現したいことを定義しました。
- Amazonのイノベーションを生み出す要素を活用し、JINSの事業変革を促進させる「文化」「仕組み」「プロセス」「ツール」をつくること
- この試みを通して、JINSの「新しい当たり前を生み出すエンジン」をつくること
- 外部に頼らずJINS社員自ら、デジタルプロダクトやサービスを生み出すことで、アジャイル開発の内製化を推し進め、テクノロジーを活用できるEyesTech企業の基礎をつくる
- JINSデジタル人材としてのスキルの開発や経験の場を社員に提供する
やってみてどうだったか
(1)進め方
まずは、DIPの活動立ち上げ準備と参加するメンバーの選定プロセスを定め社内アナウンスしました。
Step1.アイディアの公募フェーズ
・公募は、部門全体から行なう、職位等は問わず。
Step2.アイディア絞り込み、確定 フェーズ
・当活動のオーナーである執行役員を交えて実施。
Step3.DIPに正式参画してもらうメンバーの選定
・参画してもらうメンバーは、公募してくれた人の中からと、オーナーが指名した人を対象にする。
・メンバーの役割については、別途、社内のデジタル人材定義活動で進めていることを参考に定義する。
(2)チームとロール
活動の性質上、大人数の実施は適さないこともあり(AWSのツーピザチームが参考)、5~8名の規模でメンバーを選定しました。メンバーは、担当している他の業務と並行してこの活動に従事してもらうことになるので、この活動にコミットしてもらう稼働時間(20%稼働)を予め決めたのと、スクラム開発の実施を想定していたのでそれに適したロールを決めて臨みました。
| ロール | 役割 | 責任を持つ分野(例) |
|---|---|---|
| サービスプランナー UXデザイナー |
プロデュース ディレクション サービス定義 |
・サービス要件の意思決定 ・チーム取りまとめ ・スケジュール決め、など |
| システムエンジニア | システム実装 | ・ソリューション実現の手法の検討 ・アプリケーション開発、環境構築 |
| データアナリスト データエンジニア |
必要とするデータの定義 | ・サービスとして必要な情報を決める(Data) ・サービス改善に必要な情報を決める(Information) |
| テックリード スクラムマスター |
技術支援 チームファシリテーション |
・主にシステムエンジニアの壁打ち相手 ・チーム運営がスムースになるための活動全般 |
(3)企画と実装のフェーズ
Working Backwardsの考えに基づいて顧客中心のサービス企画を立てることが中心の活動になるのですが、このフェーズでは、AWS担当者のファシリテーションで進めました。どのような考え方に基づいてサービス企画を立てるのかの道案内をしてもらう形で進めます。しかし、AWS担当者との事前討議から見えてきたことは、JINS側メンバーの理解や準備が不十分であるということでした。
その為、企画フェーズが始まる前の段階として、JINS社内でのディスカッションを行う活動をしばらく設けました。(これはDIPの標準の進め方では無い)
事前の社内活動としては、まずは「Working Backwards」に対する理解を深めることから始めました。要するに「逆算して企画を考える」ということなのですが、この思考方法に慣れてないと実は難しい作業です。その為、「他のやり方で言うとこういうことかもね？」を考えてチーム内での理解を深めました。
このような下準備を実施し活動を進め、サービスのプレスリリースを作成することができました。プレスリリースを作成するというこのユニークな手法は、自分達の言葉で対外的なアナウンスを考えることなのですが、そのサービスが本当に価値があるのか？、内容は多角的に見て説得力のあるものとなっているのか？、お客さまは本当にそれを求めているのか？などを自問自答できる良い方法論でした。
(4)やってみての振り返り(現実的な課題)
全体の活動期間は、自社での準備活動を含めて10ヶ月位で、細く長く続きました。
こんなに長く続ける予定はなかったのですが、現実問題として、メンバーが本件に割ける時間がなかなか取りづらい時もあったり、予め決めた稼働割合も20%では少なかったことも要因の一つでした。
企画フェーズは、しばらくはふんわりした要求のまま議論が進んでおりましたが、方法論をきちんと理解し地道に実行したこともあり、最終的には解像度の高い企画案を作成することができました。Working Backwardsの考えに基づいたプレスリリースの作成は刺激的でした。
実装フェーズは、スクラム開発を採用しプロトタイプ開発を行い、1スプリントを2週間と設定しました。当たり前ではあるのですが、「システムエンジニア」のロールのメンバーの作業負荷が高いフェーズになりました。このロールにアサインしたメンバーの人数が少なかったり、メンバー間のシステム開発スキルのギャップや、メンバー毎の稼働割合割合のバラツキが大きく、進行がとても難しい状況ではありました。その結果ベロシティとしては良くはなかったのですが、アジャイル開発の基本的な活動(スプリントバックログの採用、デイリースクラムやレトロスペクティブでのコミュニケーション、ストーリーポイントを用いた見積もり等)を自分達で全て実施できたことはチームの経験値という意味では大きかったです。
今後に活用できること
まずは、何はともあれ要件定義が重要であるということを再認識しました。
ウォーターフォール開発であれ、アジャイル開発であれ要件定義の量と質がその後の活動プロセスの品質に大きな影響を与えるという現実があると思います。システム設計を見据えた要件定義をしていくことが重要で「サービス要件の定義」「システム要件の定義」の2つの活動プロセスの連結が肝です。また、1スプリントに押し込めるタスクは有限なのと、インプットとなる情報によりスプリントの活動カロリー量(色々考えて対応しなければいけない事を指す)が変わります。
そして何よりも、顧客中心で考えるというのは言葉で言うのは容易なのですが、出てくる課題や問題の解決を選択していく中で、自分達本位になってしまう瞬間がどうしても出てきてしまい、その判断は良いのか？を考え続けることが大変でした。逆に言うと、顧客中心を実行し続けることが自社の競争優位性を生み出す要因の一つであるとも思いました。
明日は、劉さん(@Ryu-kato)です。彼女は、今日お話ししたDIPの「サービスプランナー」のロールで活動したメンバーであり、チームをリードした事についてお話をする予定です。お楽しみに!