事業化準備ステージ ― 新規事業運営の体制作りとサービス開発

はじめに

ここでは、新規事業立ち上げのプロセス「ステージ・ゲートプロセス」における「事業化準備ステージ」を解説します。

※上図の各ステージをクリックすることで対応記事にジャンプできます。

新規事業立ち上げの全体概要を掴みたい方は、まず新規事業開発 ― ステージ・ゲートプロセスによる新規事業立ち上げを一読頂くことをお勧めします。

事業化準備ステージとは

事業化準備とは、事業を運営するための体制作りやサービス開発等、事業化に向けた準備をし、リリース判断を行います。

JV設立・事業部化

概要

事業化後の最適な推進体制と資本政策を検討するステップです。「事業計画策定」の中で検討した出口を改めて検討/具体化します。
事業の特性によって、どのような推進体制が望ましいのかを検討し、事業の管理や拡大にとって重要な資本政策を策定します。

実施手順

1. 事業の特性を整理する

下記のような事業の特性によって、適した推進体制が異なります。まずは検討中の事業の特性を整理しましょう。

• 事業領域における自社アセットの優位性
  • 自社のアセットがその事業領域で勝ち残るための重要な鍵になるか
  • 他社のアセットへの依存度が大きいか
• 事業が自社に及ぼすリスクの大きさ
  • ブランドイメージのダウンにつながる可能性が高いか
  • 不確実性が高く、事業の失敗が自社の既存事業や企業評価低下につながる可能性が高いか
  • 既存事業や取引先と顧客を奪い合うような事業で、反発が生まれる可能性が高いか
• 事業推進に求められる自由度やスピード
  • 既存事業部での進め方やスピードだとチャンスを逃す可能性が高いか

2. 適した推進体制を選定する

以下の図は、適切な推進体制を検討するために単純化した条件分岐です。1で整理した特性をもとに最適な推進体制を選定しましょう。

推進体制の検討観点

3. 資本政策を検討する

資本政策とは、事業資金を調達するために立てる計画のことを指します。策定した事業計画をもとに、将来的に必要になる資金を見積り、計画的に確保していきます。ただし、必要以上に株式を発行してしまうと、経営権を奪われたりするリスクがあるため、計画的な資本政策が重要となります。

資本政策のゴールを定める

最初に資本政策のゴールを設定します。例えば、株式公開を目指すのか、上場せず事業運営で獲得した自己資金や銀行からの借入金で事業を運営していくのかを定めます。株式公開を目指す場合、JPX(日本取引所グループ)が定めている上場審査基準があり、その数値が目標値となります。

財務数値を予測する

これまでの実績や類似上場企業の財務数値を参考にし、将来的な予想損益計算書、予測貸借対照表、予想キャッシュフロー計算書を作成します。

「誰に」「いつ」「どんな方法」で資金を得るのかを検討する

予測した財務数値と目標値を比較することで、現状と目標のギャップが把握できます。そのギャップを埋めるために、「誰に」「いつ」「どんな方法」で資金を調達するのかを検討します。

• 「誰に」
  • 投資家、ベンチャーキャピタル、取引先、役員、従業員等
• 「いつ」
  • シード、アーリー、シリーズA、シリーズB、シリーズC等
• 「どうやって」
  • ストックオプション、従業員持株会、第三者割当増資等

資本政策表を作成する

上記で検討したゴールや資金調達の計画をもとに、資本政策表を作成します。

資本政策表

コツ/注意点

出口戦略はなるべく早く検討すべき

事業化直前で初めて出口戦略を検討してしまうと、立ち上げに時間がかかってしまいます。事業の特性自体は初期段階でも整理できるため、出口の選択肢を確保しておき、事業化が近づいたときにスムーズに移行できるよう、準備を整えましょう。

資本政策で攻めるタイミングを見極める

資金は多ければ安心できますし、資金の利用用途は沢山思い浮かぶでしょう。しかし、資金政策に失敗すると、会社や事業をコントロールできなくなります。市場の動向を踏まえて、いつ資金を投入して勝負に出るのかを見極めることが大切です。

オペレーション・人員設計

概要

オペレーションの流れと必要な人員を設計するステップです。商品・サービスを提供するために必要な業務を洗い出し、必要な人数を算出します。

実施手順

オペレーション設計および人員設計は、一般的に以下の5つの手順があります。

1. 「何」のオペレーションを設計するのかを決定する

利用申し込み時があった際のオペレーションや問い合わせがあった時のオペレーション等、切り取る対象によって、オペレーション内容は異なります。まずは設計する対象を選定しましょう。

2. 事業に関わる主要な関係者を洗い出す

オペレーション設計の対象が決まれば、次にその業務に必要な関係者を洗い出します。

例）

• 事業企画
• カスタマーサポート
• セールス
• 契約・法務確認
• アフターサービス
• 請求

3. 関係者のオペレーションフローを記載する

以下の図は問い合わせがきた際のオペレーション図の一例です。作業が発生する条件やアウトプットを明確化することで、わかりやすいオペレーション図を書くことができます。

• インプットが何か
• どのようなプロセシング(処理)をするか
• アウトプットは何か

オペレーション・人員設計

4. 関係者毎に対応に要する時間を設定する

• 関係者毎に1つの問い合わせを完了させるまでに要する時間を設定する
• 関係者毎に1日で対応可能な問い合わせ数を算出する

5. 必要な人員を算出する

収支計画で算出した顧客数から問い合わせ数を試算し、関係者毎に必要な人員数を算出する。

コツ/注意点

業務の開始と終了のタイミングを押さえる

作業がいつ始まるのか、いつ終わるのかがわからないと、流れが把握できず、間違ったタイミングで作業を設計してしまう可能性があります。担当者に確認をとり、明らかにしておきましょう。

条件分岐がある場合、分岐した場合の作業を明確にする

業務フローに意思決定など条件分岐がある場合、どのような条件によって分岐するのかを明確にします。

サービス開発

概要

事業の開始に向けて、本格的にサービス開発を行うステップです。
システム開発の場合は、何を作るのかを大まかに決めてから、どう作っていくのか具体的に設計し、開発していきます。

システム開発以外のサービスの設計においては、前述した『オペレーション/人員設計』を参考に設計し、実際にオペレーションが問題なく回るかどうか、求められる水準に達しているかどうかを繰り返しテストしてください。

実施手順

具体的な進め方については、後述の開発プロセスを参照してください。

コツ/注意点

スケジュールを決め、進捗管理を徹底する

開発する要件が決定した後、具体的な開発スケジュールを作成し、進捗管理を行います。特に関係者の確認/レビューが必要な部分は、いつまでに確認結果が欲しいのか等のスケジュールを明確にできていないと、進捗に遅れが生じてしまうことが多くあります。「いつまでにどのような状態になっている必要があるのか」「誰が今、どのような業務を担当しているのか」等を明確にして進めましょう。

開発プロセス

概念実証(SPF)ステージを通過した事業では、実証された事業仮説と収益の得られる事業計画が手元にあります。
一方で、MVPでは成立したはずの仮説が、プロダクトをリリースしてみたら間違っているということも新規事業開発においては起こり得ます。

開発に多大な時間とお金をかけてリリースしたものの、仮説が外れていたために売上を確保できなかった場合、
損失も大きく事業継続が困難になる可能性があります。

そのため、短いスパンで製品をリリースし、ユーザーに使ってもらい手応えを掴みながら改善を繰り返し、より良いものを目指しましょう。
顧客の要求や市場の変化に素早く柔軟に対応し、改善を重ねながら開発を進められるのがアジャイル形式です。我々は、その実践手法としてスクラムを使います。

アジャイル・スクラム

概念実証(SPF)ステージでもスクラムを利用していましたが、本ステージでは開発チームの規模も大きくなります。
開発を円滑に進めようと思うと、まずはアジャイルの基本となる考え方を関係者全員が理解し、開発をチームで自律的に推進できるようになる必要があります。

まずは、チームの中でロールを決めましょう。
基本的なロールの考え方を図示します。

スクラムで進める場合の理想の体制

それぞれの役割の概要については、スクラム現場ガイド¹より引用した以下の表を参照ください。

デザイナー、アプリ、インフラといった形でチームを分けること、職能で壁を作ることはやめましょう。
チームとしての一体感がスクラムを進める上での重要なファクターとなります。

事業オーナーには夢を語ってもらい、チームで共感を持ち自分ごととして考えられるようにします。そうしたうえで、自分たちで「必要な事柄」(要件)を考えられるようになれば、自律・自走ができるチームになっていきます。

プロダクトオーナーは、一見事業色が強く見えますが、エンジニアリングを理解していることも求められます。メンバーのスキルセット次第ですが、エンジニアがプロダクトオーナーを担うことも検討してもよいでしょう。

スクラムの基本となる考え方、開始準備、開発における特徴については、Fintanで公開されている以下のコンテンツを参照してください。特に、スプリント開始条件チェックリストで開始できる状態にあるかをチェックしてください。

見落とされがちですが、スプリント期間およびスクラムイベントの設定は重要です。
スクラムガイドではスプリント期間は1ヶ月以内であると明記されていますが、1週間あるいは2週間がおすすめです。スプリント期間が短くなるほど、スプリントイベントに費やす時間割合が大きくなり相対的に開発時間が短くなってしまいます。しかし、その分だけチームの改善は進み、計画の精度も高くなります。
一般に、スクラムに不慣れなチームほど、一週間スプリントの方が望ましいとされています。以下も合わせてご参照ください。

• Q. 初めてのスクラムでは、スプリント期間はどれくらいがおすすめですか？スプリント期間を決める上でのポイントはありますか？

以下に、スプリントイベントそれぞれの目的と、2週間スプリントの所要時間の目安について記載します。
なお、目的はスクラムガイドから抜粋しました。

プロダクトバックログアイテムのライフサイクル

プロダクトバックログに取り組むには、優先度順に並んでいるだけでなく、スプリントで実施するプロダクトバックログアイテムがReady(準備完了)になっている必要があります。
Ready(準備完了)の状態とは、以下のような項目があげられます。

• 目指す価値が明確であること
• 受け入れ条件が定義されていること
• 開発を進める上で大きな疑問が残っておらず、スクラムチーム全員が何を行えば良いかを理解できていること
• 開発チームによって開発のサイズが見積もられており、かつ、進行を妨げる依存関係がないこと

ここで定義している内容が全てではないですが、基準となるベースラインを合意しておくことでプロダクトバックログアイテムの品質を保つことができます。
また、プロダクトバックログアイテムは各スプリント毎等で定期的に見直しを掛け、優先度や状態を確認してください。

記述すべきドキュメント

事業計画立案ステージでは、
目指すプロダクト像を言語化し認識を共有するためにいくつかのドキュメントを作成しました。
これらのドキュメントは本ステージ以降でも継続的に更新が必要です。
それに加え、本ステージではそれらで検討した内容をベースとして、円滑に開発を進めるために必要なドキュメントを整備していきます。

次項からは、上記の成果物フローの図中に記載したものの中から、
この事業化準備ステージで言語化しておくことが望ましい主要なドキュメントについて説明します。
これらのドキュメントについてもシステム同様「継続的に」更新し、一貫性を持たせ、システムの状態を常に反映させるようにしましょう。
継続的なメンテナンスを行うためには、後述する「Doneの定義」に、ドキュメントの更新を含めておくと良いでしょう。

ドメイン知識

新規事業を成功させるためには、提供したい価値をプロダクトを通じてユーザーに理解してもらい、確かにその価値があると納得してもらうことが重要です。
この時、提供したい価値をうまくユーザーへ伝えるためにはドメイン知識が必要になることがしばしばあります。
開発者にドメイン知識が不足していると、ユーザーにわかりやすく価値を伝えるプロダクトを開発することが難しくなります。

ドメイン知識をどのようなドキュメントとして表現するかは、形式は問いません。
市場環境や競合製品については、事業計画書においてまとめられているでしょう。
事業の全体像は、既に顧客向け営業資料としてわかりやすくまとめられているかもしれません。
対象業界特有の用語や自分たちが新たに定義した用語は、用語集としてまとめるのが良いでしょう。
プロダクト内で用いる用語とその意味を統一しておくことは、画面デザインの観点からも重要です。

ドメイン知識は最初から全てを網羅してドキュメント化する必要はありません。
事業において重要な概念や、チームメンバーや顧客から質問を受けた内容を中心に順次言語化していくのが良いでしょう。

ER図

事業計画立案ステージでは概念データモデルを作成しました。
本ステージでは概念データモデルをベースに、システム開発に必要となる論理・物理データモデルをER図上で表現します。
新規事業開発においてはプロダクトのリリース後も継続的に開発が続き、求められる要件の変化に伴うデータモデルの変更がしばしば発生します。
なるべく変更に強いデータモデルを設計するように心がけましょう。

画面デザイン

画面デザインは、プロダクトの顔となりユーザーからの第一印象に大きな影響を与える重要な要素です。
このプロダクトではどのような価値を提供できるのかを、画面を通じてユーザーに分かりやすく伝える必要があります。
先のステージで整理した業務フローやプロダクトバックログをインプットに、ユーザー体験に配慮した画面デザインを心がけましょう。
UIデザイン・画面遷移図ともに一度作成して終わりではなく常に更新し続けていく必要があるため、
UIデザインツール(Figma等)で描画することを推奨します。

画面デザインの成果物はユーザー体験に配慮したデザインが行われているだけでなく、デザインの意図が開発者に伝わるものであることが望ましいです。
なぜそのようなデザインにしたのかという意図についてもなるべく記載しておくと、開発時の認識齟齬が減らせるでしょう。

1st. リリースまでの全体像

新規事業開発における開発の全体像は下図で示す形になります。スクラムだからといって全体の計画が無くて良いわけではなく、この後、説明していくスプリント0も含めて全体計画をきちんと立てることが重要です。

また、全体計画を踏まえて、見積もりも精緻にし直した方が良いでしょう。初期予算との乖離がこの時点である場合は、予算・意思決定者やマネジメント層にその事実を伝えましょう。

1st. リリースまでの全体像

スプリント0

スプリント0は、本格的な開発を始める前の準備期間になります。ここでしっかりと準備ができない場合、後続となるスプリントが空回りしてしまいます。
準備すべき内容については以下の図を参照してください。ここまでの工程ですでに準備できているものもあると思いますが、改めて確認しましょう。

スプリント0でやるべきこと

各項目の具体的な進め方については、以下の表、およびScrumプロジェクト開始のベストプラクティス #RSGT2018を参考にしてください。

全体テスト計画

限られたリソースの中で効果的・効率的にプロダクトの品質を担保するためには、テスト全体としての計画を立案し、「各テストで確認すべき品質の明確化」と「各テストでの品質の積み上げ」を行わなければなりません。

前章のスプリント構成で進める場合、どのテスト観点を各スプリントで担保するのか、どのテスト観点をテストスプリントで担保するのかを明確にしましょう。
各スプリントで担保するテスト観点を多くするほど各スプリントのインクリメントの品質が担保されますが、
テスト時間(自動化したとしても、そのテスト整備の時間)が増えていきます。

まず、アジャイルなプロジェクトにおけるテストは、「開発支援」「プロダクト評価」「ビジネス観点」「技術観点」の4象限で整理した「アジャイルテストの4象限」²で表現できます。

アジャイルテストの4象限

「開発支援」に該当する左側の象限のテストは、スプリント内で実施し品質を担保しましょう。
「プロダクト評価」に該当するものについては、プロダクトの全体像がある程度見えた段階でテストを実施します。ここでのテストは「テストスプリント」まで持ち越すのではなく、できるだけ早い段階で露払いを行いましょう。最後までこれらを実施しないままの場合、リリース直前まで大きなリスクを内在したままになってしまいます。

基本的な方針として以下を定めます。

DoneとUndoneの定義

リリースするためにしなければならないことのうち、スプリントで何を行い、何を行わないのかを示すものがDoneの定義とUndoneの定義です。
例えば全体テスト計画で定義する、スプリント内で実施するテストをパスすることがDoneの定義の1つになります。
スプリントを開始する前にこれらを作成し、スクラムチームで合意しましょう。
Doneの定義の目的や意義についてはDoneの定義 | アジャイル・スクラム | Fintanを参照ください。

具体的に我々が利用しているDoneの定義とUndoneの定義の例は以下のようなものです。

• Doneの定義
  • 開発・修正した対象機能について、単機能観点での動作が保証できていること
  • 品質分析するための諸元が記録されていること
  • 以下の条件を満たす自動テストを記述できており、全ケースパスできていること
    • 自動テストのC1カバレッジが、自動生成コードを除き原則として100％であること
  • CIがGreenであること
  • チームリーダー、あるいはチームリーダーの指名したレビュアーがapproveしていること
  • 記述すべきドキュメントが更新されていること
• Undoneの定義
  • セキュリティテスト
  • 性能テスト
  • ストレステスト
  • ボリュームテスト
  • ロングランテスト

スプリント

決定したタイムボックスのスプリントを重ねていきましょう。

スクラムのスクラムイベントは、それぞれが確固とした目的を持っています。
忙しくなってくると各イベント開催の負荷が気になり省略したくなることもあるかもしれませんが、目的をしっかり理解し、粘り強く開催しましょう。徐々にチームがその開発に適応してくるはずです。

また、開発を続ける限り、プロダクトバックログを更新していきましょう。開発中のプロダクトがある限り、プロダクトバックログの変更が止まることはあり得ません。新たなアイテムの追加や既存アイテムの変更に応じ、見積もりを行い優先度を設定し直しましょう。

各スプリントで開発した成果物(インクリメント)は、スプリントレビューにてプロダクトオーナーやステークホルダーに確認してもらいましょう。
プロダクトのゴールを達成するのに十分に価値を感じるものになっているのかというフィードバックをもらい、より価値のあるプロダクトへと昇華させます。

スプリント

テストスプリント

理想的なスクラムにおいては、各スプリントで「出荷可能」なプロダクトが構築されているのが理想です。
しかし毎スプリントで「出荷可能」と判断できるだけの品質を確認するためには、チームに相応の負荷がかかり、
開発が思うように進まないことも多いです。

そこで、アプリケーションの総合的な品質を確認するため、リリース前にテストスプリントを配置します。
このスプリントにて、「出荷可能」なプロダクトになっていることを担保します。

注意していただきたいのは、テストスプリントがあるからといって通常のスプリントで品質担保を疎かにすべきというわけではないことです。スプリント単位で、おおよそ問題ないと言える程度の品質を担保しなければ、テストスプリントで大量の不具合が発覚することになります。

進捗管理

本章の記述は、エッセンシャルスクラム³を参考に、いくつかのカスタマイズを行なって記述したものです。

スクラムで進める開発であっても、「いつリリースできるのか」という問いには答える必要があります。そのためには、ある程度の長期にわたる計画を立て、その進捗状況をトラックしなければなりません。
本書では、長期にわたる計画の立案を「リリースプランニング」と呼びます。

リリースプランニングではリリースの制約を明らかにする必要があります。一般に主な制約となるのはスコープ、期日、予算の3つであり、リリースごとに制約の組み合わせが以下のどちらになるのかを検討します。

この判断は、継続的に行う必要があります。後述する進捗の可視化で進捗上の問題が検知された場合に、見直しを行いましょう。

固定スコープのリリースプランニングと進捗管理

スコープが固定の場合のリリースプランニングは以下の手順になります。

1. スコープに含まれるプロダクトバックログアイテムを詳細化し、そのサイズを見積もる
2. スコープに含まれるプロダクトバックログアイテムの見積もりについて、合計サイズを計算する
3. チームのベロシティの範囲を決める
4. 合計サイズを最も遅い場合のベロシティで割り、端数を切り上げる。これがリリースに最低限必要なスプリント数となる
5. 合計サイズを最も早い場合のベロシティで割り、端数を切り上げる。これがリリースに必要となるかもしれない最大のスプリント数となる

このリリースプランニングにより、「対象スコープの開発を完了させるためには○回から○回のスプリントが必要になる」という答えが得られます。回答が範囲になっている通り、ここに不確かさが残ることは避けられません。
しかし前述した不確実性コーンが示す通り、時間が経つにつれてその不確実性は下がっていき、次第に信頼性の高いものになっていくはずです。

不確実性コーン

開発の進捗状況を掴むためには、バーンダウンチャートを使います。
固定スコープの場合のバーンダウンチャートは、現在のリリースのゴールに達するまでの残作業の量をスプリントごとに示す、右肩下がりのグラフになります。
以下が、エッセンシャルスクラム⁴から引用したバーンダウンチャートの例となります。これを事業オーナーやステークホルダーの常に見える場所に配置し、進捗状況を共有しましょう。

チャート

固定期日のリリースプランニングと進捗管理

期日が固定の場合のリリースプランニングは以下の手順になります。

1. リリースまでのスプリント回数を計算する
2. プロダクトバックログを適切な詳細度まで分割し、優先順位を決める
3. チームのベロシティの範囲を決める
4. 最も遅い場合のベロシティと1.のスプリント回数を乗じ、そのポイント分のプロダクトバックアイテムを選択する。これが「完成するであろう」ラインになる
5. 最も早い場合のベロシティと1.のスプリント回数を乗じ、そのポイント分のプロダクトバックログアイテムを選択する。これが「完成するかもしれない」ラインになる

固定期日の場合のプロダクトバックログ

これにより、期日までにどこまでできあがるのかの答えがある程度わかります。ここでも不確実さは排除できませんが、不確実さの程度は次第に小さくなっていくはずです。

アーキテクチャ設計・方式設計

アーキテクチャ設計は、非機能要件と業務要件に左右されるため、どうしても事業ごとの設計が必要になります。
このため、本書でもアーキテクチャ設計のテンプレートを示すことはできません。
以下では、システムのアーキテクチャを設計する上で押さえておかなければならないポイントを説明します。

最終的なソリューション像を描いた上で設計を実施する

アーキテクチャ設計で重要なのは、ビジネスにどのような機能要件・非機能要件が求められるのかを正確に把握し、それをアーキテクチャに落とし込むことです。
この「アーキテクチャに落とし込むべき要件」は、1st. リリースで必要になる要件ではなく、サービスの将来像を見越した要件であることに注意しましょう。
これはアーキテクチャに落とし込むときの判断は時に「不可逆」な判断となり、あとで修正が効かない、あるいは修正するのに多大なコストがかかるためです。

アーキテクチャ設計の際は、事業オーナーと「最終的なソリューション」がどうあるべきかを議論し、システムの変化する方向性を認識しておきましょう。
例えば、将来的にどのような機能を入れていきたいのかを議論するだけでも、アーキテクチャ上のどこに拡張ポイントを用意しておくべきなのかの勘所がつかめます。

保守性を強く意識する

受託開発においては機能適合性やセキュリティが重視されがちですが、自ら運用し素早く成長させていく新規事業においては、保守性を強く意識しなければなりません。
なぜなら、保守性こそがアジリティの根源であるためです。
ぜひt-wadaさんが公開されている以下の資料をご一読ください。

保守性の高いソフトウェアアーキテクチャを設計するためには、「保守性」の品質副特性を把握しておく必要があります。
以下の図はソフトウェア品質モデルSQuaREに関するつながる世界のソフトウェア品質ガイド～あたらしい価値提供のための品質モデル活用のすすめ～からの引用ですが、保守性の品質副特性は以下となっています。

• モジュール性 (Modulability)
• 再利用性 (Reusability)
• 解析性 (Analyzability)
• 修正性 (Modifiability)
• 試験性 (Testability)

システム/ソフトウェア製品品質

これらは一般的なソフトウェアアーキテクチャでも作り込みが必要なものであり、本書での言語化は控えますが、新規事業開発ではこれらを強く意識したアーキテクチャ設計が必要な点を理解してください。

新規事業開発では、短いスパンで製品をリリースすることが求められるため、これらの品質(内部品質)を犠牲にしてスピードを優先するといった判断が行われることは少なくありません。
しかし、これらの品質を犠牲にすることでシステムの保守性も犠牲になるため、短期的なスピードが得られようとも、中長期的には逆効果になります。この損益分岐点は数週間だとされている⁵ため、内部品質を下げるという判断が行われないようにしましょう。

環境を明確に分離する

本番環境とそれ以外の環境は、明確に分離する必要があります。
開発環境の変更が本番環境へ影響することはあってはなりませんし、同様にステージング環境の脆弱性によって本番環境で情報漏洩につながることも避けなければなりません。
また、多数の開発者が本番環境上の個人情報にアクセスできるのは望ましくなく、厳密なアクセスコントロールも必要になるでしょう。

これらを防ぐため、アプリケーションが動作する環境(開発環境や本番環境等)に対してそれぞれ異なるAWSアカウントを用意する形で環境を分離することを基本形とします。なお、本書ではこの「アプリケーションが動作する環境」のことをRuntime環境と呼びます。
サービス開発当初、Runtime環境については開発環境と本番環境の2環境とし、オンデマンドで増やしていくのが良いでしょう。
DevOps環境構築キットEponaでも同様の構成をとるため、必要に応じてご利用ください。

アプリケーション方式設計

サービスを開発する上では、
開発者が開発時にどのような方式で実装すればよいのか、ある程度ルールを定めておく必要があります。主目的は以下となります。

• 保守性の高いプロダクトを作るための開発者間の意識合わせ
• 後から入った開発者に対して開発方針を示す

方式設計はスプリント0での実施を推奨します。実際に開発へ入る前にルールを制定しておくと、スムーズに開発を始められます。
方式設計書についてはサンプルがあります。こちらのサンプルをすべて網羅する必要はありませんが、参考にしてください。

• アプリケーション方式設計書サンプル | Nablarch | Fintan

アーキテクチャ・方式設計の管理

アジャイルで進めるプロダクトにおいては、システムのアーキテクチャが一度で決まるわけではありません。そういったとき問題になるのは、以下の点があります。

• アーキテクチャ上重要な意思決定が特定の開発者だけで行われ、他の開発者が設計の動機や目的、経緯を理解できない
• アーキテクチャ変更を変更する際に、すでに解決されている課題が後の変更で再発してしまう
• 新規アサインメンバーへの情報の共有に時間がかかる

このような問題の結果、設計当時と事業のコンテキストが変わっていたとしても既存のアーキテクチャを変更すべきかという判断もできなくなり、事業の変化に追随できなくなってしまいます。

このような課題を、我々はADR(Architecture Decision Records)を導入して解決します。
ADRとは、「アーキテクチャ上重要な意思決定」を、そのコンテキストや結果とともに記載した文書になります。
Architecture Decision Recordsの導入例・効果・運用については以下をご参照ください。
Architecture Decision Records導入事例

ADRのフォーマットは種々ありますが、ADRを作成・運用するコストを最小限に抑えるため、我々はMichael Nygardのフォーマットを利用します。
長いADRを書いても運用の負担になるため、1-2ページで収まる程度の分量を目安とします⁶。

# タイトル

## ステータス

提案中、受理、拒否、非推奨、等のステータスを記載する。

## コンテキスト

ADRが対象とする技術的・政治的・組織的な問題を記載する。
本記述内容は、中立的に事実のみを記載すること。

## 決定事項

ADRで提案する変更・実施事項を記載する。

## 結果

ADRの内容をプロジェクトに適用した際の結果を、良い面・悪い面の双方について記載する。

開発

ここでは、開発にあたっての開発プロセス上のプラクティスを記載します。

ブランチ戦略

我々が利用するのはGitLab Flowです。

GitLab Flowでは、環境ごとに対応するbranchを用意します。
下図の例では、開発環境にdevelop branch、本番環境用にproduction branchを用意しています。
develop branchの内容が開発環境に反映され、production branchの内容が本番環境に反映されます。

GitLab Flow

新機能を開発する開発者はdevelop branchから機能開発用branch(feature branch)を作成し、当該branchにて開発します。
テストとレビューを通過したら、develop branchにマージできます。開発環境に反映し、そこで実環境でのテストを行いましょう。
開発環境でテストし正しい振る舞いを行うことが確認できれば、production branchにマージし、本番環境に反映します。

このようにGitLab Flowでは、環境に対応するリリースブランチが存在すること、mergeが単方向で行われることに特徴があります。
これにより、各環境にデプロイするバージョンをコントロールできるとともに、本番環境にデプロイされるコードはそれ以前の環境でテスト済みであることが担保できます。

ピアレビュー・プルリクエスト駆動開発

システムを開発する際は、アプリケーションやインフラを何度も変更することになります。
その変更はチーム内のピアレビューにてその品質を担保しましょう。ピアレビューは、変更の品質を向上させるだけでなく、相互訓練、ピアラーニング、スキル向上の効果を持っています⁷。

ピアレビューを確実に行うために、開発チームではプルリクエスト駆動開発を行ってください。
「The DevOpsハンドブック　理論・原則・実践のすべて」の記述を参考にすると、おおよそ以下のような開発スタイルになります。

1. 何か新しく作業を始める際、エンジニアはわかりやすい名前（たとえば、“newoauth2scopes”）をつけたブランチを分岐させる
2. エンジニアはローカルのそのブランチに修正をコミットし、定期的にサーバーの同名のブランチに作業内容をプッシュする
3. フィードバックや支援が必要なとき、あるいはブランチをマージする準備が整ったと思ったときに、エンジニアはプルリクエストを送る
4. ほしいと思っていたレビューが送られ、マージのために必要な承認が得られると、エンジニアはブランチをマージできる
5. コード変更がマージ、プッシュされると、エンジニアはそれを本番環境にデプロイする

プルリクエストの駆動開発は、以下のメリットがあります。

• 変更点や課題が見えやすいためマネジメントを行いやすくなる
• コードの書き方や注意点を学ぶことができる
• プルリクエスト送ることでコードをレビューする文化が身に付き品質が高まる
• コードについて議論することで途中段階から素早くコードの書き方や設計等のフィードバックを得ることができる

Infrastructure as Code (IaC)

我々はインフラもコードで記述し、バージョン管理、上の述べたブランチ戦略、プルリクエスト駆動開発の実践をインフラ開発でも行います。

手作業でインフラを構築する場合、最初の段階では一貫性を保ちながら構築・設定しても、時間が経つにつれて一貫性が失われ、管理も難しくなります。これが、絶えず変化が必要な新規事業開発にとって強く足枷になります。
例えば、以下のような課題が代表的です。

• 本来同じ設定であるはずのサーバー群の1台のみ誤った設定をしてしまう (構成ドリフト)
• 他のサーバーとの差異が管理されず、誰も当該サーバーに手が触れられなくなる (スノーフレークサーバー)

これを防ぎ、インフラが変化の足枷にならないためには以下のような原則を守らねばなりません⁸。これを実現することがIaC導入の目的です。

1. インフラの任意の部分を簡単に変更・再構築できること
   • 構成変更・設定変更を行う際に恐怖感がない
   • 再構築するときに各種の判断が不要
2. インフラが統一的であること
3. インフラの構築プロセス・設定変更プロセスが反復可能であること (そうしないと自動化できず人為的ミスを誘発し、結果として変更を恐れるようになってしまう)

IaCツールとしてはTerraformを利用します。DevOps環境構築キットの提供するモジュールを利用することで、IaCを利用して開発を効率化可能です。

継続的インテグレーション(CI)

複数の開発者が個別のbranchで自分の作業を進めると、それぞれの作業を統合(merge)するときに問題が発生しやすくなります。例えば、以下のような事が起こり得ます。

• 開発者Aが使う共通コンポーネントを開発者Bが修正しており、結果として開発者Aの開発した機能が正しく動作しない
• 開発者Aと開発者Bが同じコンポーネントに変更を加えてしまい、mergeしたときに整合性が取れなくなる

複数人で開発するときにはこのような問題は不可避ですが、その影響を小さくするプラクティスが継続的インテグレーション(CI)です。
変更を可能な限り頻繁にメインとなるブランチ(develop branch)にマージすることで、mergeしたソースコードに対してテストを実施し早期にフィードバックを得られます。
これによりアプリケーション全体に影響のないことが確認でき、自動化されたテストによってアプリケーションを素早く容易に高頻度で改修できます。

CIを実践する上で開発チームは以下の点を心がけてください。

1. テストコードを記述する
2. 頻繁にdevelopブランチにmergeする (変更するバッチサイズを小さくする)
3. 自動化できるレビューポイントは自動化する

頻繁にdevelopブランチにmergeすることがCIの要諦です。そのためには変更するコード量を少なくしなければなりません。
変更するコード量が少なければ、レビューのスピードと質は向上し、mergeも頻繁に行えます。
以下は「The DevOpsハンドブック　理論・原則・実践のすべて」⁹から引用した図ですが、変更量が大きいほどレビューに時間のかかることがわかります。
レビューに時間がかかるほど、mergeが遅れ、CIが有効に機能しなくなります。また、開発者にとっての待ち時間も多くなり、リソース効率を削ぐことになるでしょう。

レビューのリードタイム

本書ではVCS ProviderとしてGitLabを利用します。
このため、CIを実装するときはGitLab CI/CDを使います。

静的チェック

静的解析では、ソースコードや設定ファイルを解析し、特定のコーディングパターンに違反している箇所をチェックします。
これにより開発の極めて早い段階でエラーを検出できるとともに、優れたコーディングスタイルを推進でき、可読性や保守性も向上します。
また、機械的に指摘できるエラーを摘み取ることもできるため、ピアレビューではより高度な問題にも集中できるようになります。たとえばJavaでは、SpotBugsやCheckstyleが静的解析ツールの代表例でしょう。

具体的な実装例としては、example-chatでの適用例をご参照ください。例えば以下が参考になります。

• GitLab CI/CDでの静的解析を含むステップの定義
• Mavenを使ったtestライフサイクルの実行
• pom.xmlへのSpotBugsの組み込み

ユニットテスト

アプリケーションのコードが期待通りに振舞うことを検証する基本となるのがユニットテストです。
継続的インテグレーションがもたらす核でもある「素早いフィードバック」は、ユニットテストのカバレッジが十分にないと可能になりません。素早く実行でき、カバレッジの高いユニットテストを記述していきましょう。

具体的なサンプルについては、上述の GitLab CI/CDでの静的解析を含むステップの定義をご参照ください。

CIをパスしないコードをマージさせない

継続的インテグレーションにとっての最大の過ちは、壊れているコードをチェックインしてしまうことです。
パイプラインをパスしないコードについては、マージさせてはならず、開発者は直ちに修正しなければなりません。
これは、この状態で変更をマージしてしまうと以下のような問題が発生するからです。

• 原因を特定しコードを修正するのに時間がかかるようになる
• コードが壊れている状態にチームが慣れてしまい、常に壊れたままの状態に陥ってしまう

GitLabでは、パイプラインを通過していないコードをマージさせないようにできます。
設定方法についてはOnly allow merge requests to be merged if the pipeline succeedsをご参照ください。

継続的デリバリー(CD)

デプロイが不安定な場合、デプロイそのものがリスクになります。
結果としてデプロイ作業は重くなり、例えば半年に一度しかデプロイができないなど、事業が目指すべき素早い改善とかけ離れた状態になります。
このような状態をもたらす、デプロイのアンチパターンとして以下が知られています¹⁰。

1. ソフトウェアを手動でデプロイする
2. 開発が終わってから擬似本番環境にデプロイする
3. 本番作業について手作業で構成管理を行う

安定したデプロイを手に入れることで、本番デプロイもリスクではなくなり、高頻度なサービスの改善が可能になります。
これを行うためのプラクティスが継続的デリバリーです。

デプロイ作業は自動化し、デプロイメントパイプラインに組み込みましょう。
アプリケーションによってデプロイ作業は様々ですが、AWS CodePipelineなどを組み合わせれば、自動化は難しくありません。

以下はDevOps環境構築キット Eponaの方法ですが、Eponaを使わずとも、同様の構成でCDを実現できます。

• アプリケーションコンテナを無停止でデプロイできる
• 静的コンテンツを無停止でデプロイできる
• サーバーレスアプリケーションをデプロイできる

会議体設計

概要

事業の進捗を適切にマネジメントするために、適切な会議体を設計するステップです。事業の規模や状況によって、設定すべき会議は異なります。事業化後は、顧客からのフィードバックや問い合わせの数、事業の関係者の数等が一気に増加します。また、システム開発を通じて、商品やサービスも変化していきます。このように事業化後は、調整の必要性が高まるため、無駄な会議によって時間を浪費しないために、ここで適切な会議体設計の方法をご紹介します。

実施手順

会議体設計は以下の3つの手順で実施します。

1. 会議の目的を定義する

2. 会議体を選定する

3. 目的を踏まえて、参加が必要な関係者を洗い出し、頻度を設定する

コツ/注意点

会議が本当に必要か考える

会議は参加者を拘束することになるため、メールや書類での報告等、会議以外での手段で代替できないかを検討してみましょう。

アジェンダ(議題)を設計する

会議を効率的・効果的に運営するために、アジェンダを設計し、関係者に対して事前に展開しておきましょう。

ゴールを明確にする

その会議がなぜ開催されているのか、どうなれば会議の目的が達成するのかを明確にすることで、無意味な議題で時間を消費せず、効果的な会議運営につながります。