NCDCのマーケティング担当、播磨です。
先日、コンサルティングを行っているお客さまのご依頼を受けて、お客さまのシステム部門のメンバー向けに「デザイン思考、アジャイル開発、DevOpsについて」というテーマで勉強会を開催しました。
この勉強会で用いた資料はデザインシンキング、アジャイル開発、DevOpsそれぞれの概要を説明するものであるとともに、NCDCのプロジェクトの進め方を知っていただくためにも役立つ内容でしたので、少し内容をアレンジして公開します。
デザインシンキング、アジャイル開発、DevOpsの概要を知りたい方も、NCDCのプロジェクトの進め方に興味がある方も、ぜひご覧ください。
（NCDCに限らず、デザインシンキング、アジャイル開発などのキーワードを用いているスタートアップについて知る参考にもなると思います）
目次
デザインシンキング→（リーンスタートアップ→）アジャイル開発→DevOps
まず、テーマである「デザインシンキング」「アジャイル開発」「DevOps」の関係性についての説明ですが、世界的なIT分野のリサーチおよびアドバイザリー企業であるGartner社では下図の事業検証プロセスを提唱しています。
いきなりこの図を見てもなんだかよくわからないと思いますが（僕自身も最初はそうでした）、この段階ではそれでかまいません。
このプロセスでは、まず「デザインシンキング（DESIGN THINKING）」でアイデアを練り、アイデアがまとまったら、最低限の機能に絞ったプロトタイプでの検証を行う「リーンスタートアップ（LEAN STARTUP）」を行うかたちをとっています。プロダクト開発においても「アジャイル（AGILE）」を導入することで、迅速・柔軟な対応が可能になります。
この図には記載がありませんが、開発後、運用にも迅速・柔軟な対応を可能にする手法として「AGILE」のつづきに「DevOps」があると考えてください。
よくわからないなと思った方も、まずはデザインシンキング、リーンスタートアップ、アジャイル開発、DevOpsはまったくバラバラのものではなく、関連性をもって機能する手法であるということだけ頭に入れておいてください。
それぞれについては、この後説明していきます。
デザインシンキングとは
デザインシンキング（デザイン思考ともいいます）とは、世界的に有名なデザインファームであるIDEOが提唱した「デザインに必要な思考方法を用いて、ものごとの問題点を発見し、その問題点の解決方法を導き出す」手法です。
簡単にいうと以下の5ステップでイノベーティブなソリューションを具現化するフレームワークになっており、「観察（体験）→発見→プロトタイプ」を何度も繰り返すことで、ユーザのインサイト（ユーザ自身も認識していない事実や心の動き）を発見し、解決策を導き出すことを目的としています。
デザインシンキングの最大の特徴は、最初の「共感」です。共感とは、デザイン課題の文脈においてユーザを理解する作業を意味します。
人々が何を考えどのように行動するのか、何を求めているのかを理解するために、ユーザを観察したり、話を聞いたり、ときには自分自身が体験してみたりという作業にしっかりと時間をかけて取り組みます。
この最初の「共感」から問題点を発見し、その問題点の解決方法を、プロトタイプを用いたテストで検証していくという流れになります。
NCDCでデザインシンキングを提供した例としては、製薬卸企業の現場にて、薬を調剤薬局に運送するトラックの助手席に乗り、行動を共にして観察し続けることで課題を発見。その課題を解決するための仮説立てとその検証をしていくことで、事業全体の改善に活かした事例などがあります。
ここまでの説明でもわかると思いますが、デザインシンキング（Design Thinking）という名称であっても、ここで指すデザインとはグラフィックデザインやプロダクトデザインなどでデザイナーが担う色や形の表現を考える作業ではありません。
デザインシンキングのデザインとは、正しく問題を解決する方法を『設計する』ことを指しています。
デザインシンキングはデザイナーという職業に就いている人のための手法ではなく、むしろデザインを専門的に学んでいない人がデザインに必要な思考法を活用するために生み出されたものなのです。
上記の「5つのステップ」では、「共感」して課題を発見したら、そのあと「プロトタイプ→テスト」という工程まで含まれていますが、プロトタイプ以降についてはリーンスタートアップという考え方のほうが少し詳しい手法にまで踏み込んでいるので、次にリーンスタートアップについて説明したいと思います。
リーンスタートアップとは
リーンスタートアップを簡単に説明すると「コストをそれほどかけずに最低限の機能を持った製品やサービスを短期間で作り、顧客に提供する」そして「顧客の反応を観察して改善を繰り返す事で、成功モデルに素早く近づける」というアプローチのことです。
2011年にエリック・リースがトヨタ生産方式などを研究してサービスの新規立ち上げのフレームワークとして考えたものです。
リーンスタートアップについては、その成功事例も紹介している別の記事がありますので、詳細は下記のページをご覧ください。
新しい取り組みの成功確率を上げる「リーン・スタートアップ」
この勉強会では、リーンスタートアップについては下記の2つのポイントだけ理解しておいてほしいとお伝えしました。
MVP（Minimum Viable Product）
プロトタイプという概念を「実行可能な最低限の機能を持ったプロダクト」と定義づけし、時間をかけずにプロトタイプを作って、ユーザーの反応を計測し、改善案を考えることをリーンスタートアップの重要なポイントとしています。
Pivot
Pivotいう英語は「中心」や「旋回軸」という意味で、リーンスタートアップにおいては上記のMVPを用いた検証結果から改善案を考える際、プロダクトの目的や概要を従来のものから別のものへ転換することを指します。
イメージとしては、ある領域ではうまくいかなったとしてもそのプロダクトを無にするのでなく、片足は「旋回軸」としてその領域に残しつつもう片方の足を別の方向へ踏み出して別の成功の可能性を探ることといえます。
従来は点滴液だったものを飲料に応用にしたことで大成功したポカリスウェット（大塚製薬）がわかりやすい例として挙げられます。
（もちろん、当時はリーンスタートアップやPivotという言葉はなかったと思いますが）
次に、リーンスタートアップをソフトウェア開発の分野で実現するために欠かせないアジャイル開発について説明します。
アジャイル開発とは
アジャイル開発は、迅速かつ柔軟なソフトウェア開発を実現するための開発プロセスの総称で、従来のやり方（ウォーターフォール開発）とは対極的な手法です。
従来のシステム開発の多くは、最初に細かく要件定義をして、長い期間をかけて開発を行い、最後に最初に決めた仕様どおりになっているかを検証するという流れで行われています。
「要件定義→設計→開発→実装→テスト」と順番に進め、前の工程には戻らない前提のため、常時上流から下流へと進む水の流れにたとえてウォーターフォールと呼ばれています。
「前の工程には戻らない」ため、途中で計画を変更することが難しく、変化に対して柔軟に対応しづらい開発手法だといえます。
それに対してアジャイル開発では「要件→設計→開発→実装→テスト」といった開発工程を「機能単位の小さいサイクル」で繰り返していきます。
最初から全体の仕様を細かく決めてしまうことはなく、「プロジェクトに変化はつきものである」という前提のもとで何度も「実装→テスト」を行い、必要であれば次のサイクルですぐに仕様変更を行うので、変化に強い開発手法だといえます。
先述した通り、アジャイルとは柔軟性を持った開発プロセスの総称で、具体的な開発手法はスクラム（Scrum）、XP（eXtreme Programing, エクストリームプログラミング）が有名です。
ここでは、よく使われるアジャイル開発手法の一つ「スクラム」を例に、もう少し詳しく説明していきます。
アジャイルのメリットとしては以下の点が挙げられます
- スプリント毎に成果物を「動くシステム」として確認できる
- 変更や修正をすぐに次のスプリントに入れることができる
- 誰がどのくらい何を作っているか期間を区切って可視化されている
ウォーターフォールとアジャイルの比較
ウォーターフォールとアジャイルの特徴を比較したものが以下の表です。
先述した通り、最初から全体の仕様を細かく決めてしまうために変化に柔軟に対処できないというウォーターフォールの課題を改善するために考えられた手法がアジャイルです。そのためアジャイルは各機能を迅速に、柔軟に開発できる手法だといえますが、アジャイルも決して万能なわけではありません。
例えば、以下のようなデメリットが考えられます。
- 全体が見えずに作り始めるため、大きな方向性に関わる変更が入る可能性がある。そうなると手戻りがとても大きくなる。
- 正確な全体の開発スケジュールを立てないので、いつシステムが完成するかわからない
- ウォーターフォールと比較して、トータルで工数増・期間増になる場合が多い
お勧めはウォーターフォールとアジャイルのいいとこ取り
そこでNCDCは、ウォーターフォールとアジャイルのいいとこ取りをしたミックス手法をよくお客さまに提案しています。
“いいとこ取り”手法のポイント
- 要件定義は行う。（ウォーターフォール的）
- 最初に全開発範囲の計画は立てる。（ウォーターフォール的）
- その中でスプリントを行う。たとえば４ヶ月のプロジェクトでスプリントを２週間と設定した場合、「２週間のスプリント×8回」に区切って進捗を管理する。（アジャイル的）
- スプリントレビュー、振り返り、スプリント計画ミーティングは行う。その中で全体スケジュールの修正なども行う。（アジャイル的）
- 開発後の工程として結合テスト・総合テストは実施する。（ウォーターフォール的）
プロジェクトによって事情は違いますし、こうした手法やそれを支える技術もどんどん新しいものが出てくるので、これが唯一の正解というわけではありません。
ただ、NCDCではこれをベースにした管理手法をプロジェクト特性に合わせていくつかのケースで導入しています。そうした経験を踏まえてブラッシュアップしてきたやり方なので、現時点では比較的優れた手法ではないかと考えられます。
勉強会ではこの手法について「アジャイルというよりは都合のいいウォーターフォールというイメージではないか」というご質問が参加者から出ました。
そのような理解でも間違っていないのですが、実はNCDCではこの手法がウォーターフォールなのかアジャイルなのかということにはそれほどこだわっていません。
もっとも重視しているのは、最後のテスト工程近くまで開発の進捗がブラックボックスになりがちなウォーターフォールの進め方に対して、この方法なら進捗状況を可視化・共有できるようになるということです。
また、プロジェクトでは必ず想定外の問題が発生します。問題が発生した場合もこの方法なら素早く対応することができます。
ビジネスとしては、システムの完成時期が正確にわからずどんどん工数が増えていくかもしれない進め方はリスクが大きいので、ウォーターフォールと同様に最初に全開発範囲の計画は立てます。
ただし、どんなにしっかり事前の要件定義を行なっても、プロジェクトの途中での変更は起こりますし、開発の遅延も起こり得ます。長いプロジェクトの途中で出てくるそうした課題に対し、随時、早めに対処できるようにアジャイルの手法を取り入れています。
全体の管理はしっかりしつつ、ある程度の柔軟性を持って変化に対処できることを大切にした手法だといえます。
従来から「アジャイルは小規模・新サービスの開発には適しているが、大規模な開発には適さない」と言われてきました。そのため、大規模開発用にエンタープライズアジャイルと呼ばれるものなど、いろいろな種類も考えだされています。
要は、原理主義的にアジャイルならアジャイルのやり方にこだわる必要はなく、そのプロジェクトに適したやり方を工夫していくことが大切なのだといえます。
DevOpsとは
アジャイル開発の普及によって短期間でのリリースが増え、従来は分離されていた開発と運用の境界が曖昧になってきたため、開発と運用をうまく連携するための手法が考え出されています。
DevOps（デブオプス）とは、その手法の総称で、開発 (Development) と運用 (Operations) を組み合わせた言葉です。
この勉強会では、DevOpsを実現するためのCI/CDとよばれる仕組みと、ソースコードのブランチ戦略について説明しました。
CI/CDとは
CI/CD（Continuous Integration／Continuous Delivery）とは、テスト、パッケージ化、デプロイ、リリースを自動で行う仕組みです。
従来のデプロイプロセス（その環境でサービスが動くようにする作業のこと）は、運用者が一旦サービス全体を止めて多くの手順を手動で行っていました。作業が大変なので細めに実施することが難しく、いくつかの変更をまとめてから実施することが一般的です。そうすると、複数の変更を同時に公開することになるため確認作業も増え、一度のデプロイがどんどん大変な作業になっていくというデメリットもあります。
結果的に新機能のリリース頻度が落ちるだけでなく、新機能のリリースそのものが停滞するという悪循環にもつながります。
それに対し、CI/CDはサービスを止めずに、何か変更があるごとに自動的にデプロイする仕組みをつくるので、いちいちデプロイ作業が大変だとか考える必要もなく、毎週でも新機能をリリースすることができます。
（とはいえ、あらゆるテストを自動化するのは難しいので、事前にポリシーを決めて、自動化するもの、手動で行うものを切り分けておくことが重要になると思われます。）
ソースコードのブランチ戦略
Branch（ブランチ）は、「枝」や「支流」を意味する英語です。ソフトウェア開発においてブランチとは、既存のバージョンに追加する機能Aと機能Bの開発を同時に進めたいときに、Aの枝、Bの枝を用意し、それぞれが影響しあわずに同時に開発するということを可能にする仕組みです。
最終的にはAの枝もBの枝も本流にマージ（合体）され、最新バージョンが完成します。
昔のソフトウェア開発では管理が難しくなるためあまりブランチを切ってはいけないと言われていたのですが、管理ツールが高機能化してきたため、最近はむしろ細かくブランチを切って複数のメンバーが並行して作業を行えるようにすることが良しとされています。
機能ごとにブランチを切り、それぞれのブランチで担当エンジニアが開発を行います。動作確認、レビューが通ったらマスターブランチにマージするという流れになります。
CI/CDでは、トリガーはいろいろな設定が可能なので、何かがマスターブランチにマージされたらテスト、パッケージ化、デプロイ、リリースが自動的に行われるようにルールを決めておくことが可能になります。こうすることで開発と運用の境目はなくなり、開発からリリースまでの作業が大幅に効率化されます。
つまり、CI/CDとブランチ戦略それぞれも大切ですが、これらをセットで考えることが重要だといえます。
デザインシンキング、アジャイル開発、DevOps勉強会まとめ
いかがでしたでしょうか。
デザインシンキング、リーンスタートアップ、アジャイル開発、DevOps。職種によって関心のある部分は違うかもしれませんが、実はいずれも目指すところは「ユーザが本当に求めているものを実現するために、サービス提供者側が迅速に、柔軟に変化に対応できるようになること」なのではないかと思います。
この中のいくつかの考え方はよく知っているという方でも、あらためてサービスやプロダクトの立ち上げから、柔軟な対応を可能にするその運用まで、ひとつの流れとして見てみると、新しい気づきなどもあるかもしれません。
こうした勉強会にご興味があれば、ご連絡ください。
NCDCではデザインシンキング、リーンスタートアップ、アジャイル開発などの思想、手法を活用し、新規サービスの立ち上げやシステム、アプリの開発を支援しています。
また、こうした手法をうまく活用するための技術コンサルティングも行なっています。
何かお役に立てそうなことがあればお気軽にご相談・お問い合わせください。
