アジャイル開発に設計書は必要？バックログとの役割の違いも解説

アジャイル開発とは

アジャイル開発とは、システムやソフトウェア開発における手法のひとつです。従来のウォーターフォール開発はあらかじめ全工程にわたる計画を立ててからそれを実行する、というプロセスでした。それに対しアジャイル開発は、途中で生じる状況の変化へ適宜対応しながら開発を進めていくという手法です。 ”素早い”、”機敏な” という意味がある 「アジャイル(agile)」は、頭の回転が速いというニュアンスも含まれています。「計画・設計・実装・テスト」といった工程を機能単位の小さなサイクルで繰り返すことができるアジャイル開発は、まさに開発〜サービスインまでを素早く実行できる手法です。

アジャイル開発については、こちらの記事でより詳細にご紹介していますのであわせてご覧ください。 「アジャイル開発とは？」  

アジャイル開発に設計書は必要？

アジャイル開発において、設計書などのドキュメントは不要と考えられる傾向にあります。効率とスピード感を重視し、個人間で対話をしながら開発を進めていく場合が多いからです。 また、アジャイル開発という概念が生まれるきっかけとなった「アジャイルソフトウェア開発宣言」では、「包括的なドキュメントよりも動くソフトウェアを価値とする」という一文があります。この内容も相まって、「アジャイル開発＝設計書(ドキュメント)は不要」という認識が強くなっています。 ただし設計書をまったく用意せず、口頭でのやりとりだけで開発を進めていけばチーム内で要件に関する認識の齟齬が生じる恐れがあります。言った・言わないによる混乱で開発が滞れば、アジャイル開発の大きなメリットである「スピード感」や「効率性」を損ないかねません。 アジャイル開発における設計書作成には、メリットとデメリットのどちらも存在します。それらを理解したうえで、チームにとって適した対策を取ることが大切です。

設計書を作成するメリット

アジャイル開発で設計書を作成することのメリットとしては、以下の3つを挙げることができます。 ・要件に関する認識齟齬の防止 ・開発遅延の防止 ・運用の負担を軽減 先述の通り、設計書がまったく用意されていない中で開発を進めていくと要件に関する認識の齟齬が生じるリスクは高まります。そうなると、実装までのスピード感が失われ、アジャイル開発を採用する意味もなくなってしまいます。 また、何らかの事情があり別チームや新たなメンバーへの引継ぎが必要となった際、資料がなければ十分な引継ぎを行うことは困難です。開発者が運用をしない場合、または将来的に引継ぎの可能性が考えられる場合も設計書は作成するべきと言えます。

設計書を作成するデメリット

アジャイル開発においても設計書が役立つとはいえ、以下のようなデメリットも潜んでいるため注意しましょう。 ・設計書の作成に時間がかかる ・柔軟に内容を変更することが難しい 設計書を作成するにあたり、多少なりとも時間を割く必要があるため実装までのスピード感が失われることになります。 また、短いスパンで改変を繰り返す前提にあるシステムは、設計書を作成してもリリースの度に内容が古くなってしまいます。 上記のデメリット、そして先ほど挙げたメリットを踏まえて考えると、設計書を作成してもしなくてもスピード感が失われる懸念は拭いきれません。では、どのように対応すればチーム内におけるコミュニケーションの円滑性と開発のスピード感を両立できるのでしょうか。  

設計書とスピード感を両立させるポイント

アジャイル開発のスピード感、そして設計書のような「認識齟齬対策」を両立するには、以下のポイントを押さえることが大切です。

テキストファイルにラフな設計書を記す

APIのIF仕様書やDBテーブル設計書のように、しっかりとしたフォーマットをもとに設計書の内容を詰めても良いでしょう。しかしこれでは時間がかかるうえにハードルも高く感じやすいため、テキストファイルにラフな設計書を書き記す程度から始めてみることをおすすめします。 「設計書は詳細な内容を整えながら作るもの…」という意識は一度手放し、開発者間で作業内容をすり合わせる際のたたき台として使うメモといった感覚で作ってみましょう。それだけでも、開発のイメージを具体的にするための手助けになります。

チケット管理ツールを使う

「Redmine」や「Backlog」などのチケット管理ツールは、アジャイル開発におけるプロダクトバックログの管理に役立ちます。チケット管理ツールにてタスク単位で完了条件を記載しておけば、認識の齟齬を防ぐ対策として効果を発揮します。 しっかりと内容を詰めた設計書を作成するとなると、相応に時間がかかるものです。しかしチケット管理ツールで「メモ程度」にタスクを設定する形であれば、開発者の間で会話しながら記載できるため少ない時間でまとまります。 なお、ツールは好きなものを選んでも問題ありません。ただし「Google スプレッドシート」は導入しやすいものの、短いスパンで内容を更新する必要がある場合にはおすすめできません。更新の際に通知する機能がないため、誰かが行った追加・変更・削除などの編集を見落とす可能性があるからです。

タスクを細分化して設定する

ラフな設計書作成やチケット管理ツールの利用を試しても効果が望めなかったり、継続が難しい場合は必要な作業を細かく区切ってリストにしてみても良いでしょう。 設計書ほど内容の詰まったドキュメントは残りませんが、作業の工程をタスク名として一言でまとめておくだけでも何をすれば良いのかすぐに把握できます。ただしタスクをまとめる際、ひとつのタスク名に対して複数の作業工程を詰め込むと混乱しやすくなるため注意しましょう。

「設計書」と「プロダクトバックログ」を使い分ける

チケット管理ツールなどを用いたタスク管理は、どちらかというと「プロダクトバックログ」に分類される手段です。これだけでも開発をスムーズに進めるための効果はある程度期待できますが、設計書とはまた違う役割があり、プロダクトバックログだけではカバーしきれないケースも存在します。そのため、両者の役割を理解したうえで使い分けることが作業の効率性を上げるポイントです。 設計書とプロダクトバックログのどちらも作成すると、更新時に伴うスピード感の低下が危惧されるものです。しかし内容を変更する際、リアルタイムに更新をするのはプロダクトバックログだけで問題ありません。設計書は「長期的な保守をしやすくする」というのが主な役割なので、ある程度の仕様が固まってから反映するなど更新のタイミングを工夫するとスピード感も損なわれません。

デザインツールを使う

ブラウザ上で簡単にデザインできる「Figma」や、Webサイトやモバイルアプリ等のデザインに使用できる「Adobe XD」を利用することもおすすめです。ツールを使いワークフローを作成したり、プロトタイプを作成しながら進める方法も効果的です。  

プロダクトバックログの限界とは

プロダクトバックログは設計書よりも作成に時間がかからず、チケット管理ツールなどを上手に利用すれば更新状況もリアルタイムで把握できるという点がメリットです。しかしプロダクトバックログを用意するだけでは、将来的な運用をスムーズにするための準備が万全であるとは言えません。 プロダクトバックログでは1つのプロダクトをチケットに起票し、必要に応じてチーム内でQ&Aやディスカッションを行うことで決定した事項を概要欄に反映します。アジャイル開発は開始時点で詳細な仕様が固まっていないことが多いため、様々な関係者がプロダクト使用の設定に携わることができます。また、開発が完了したプロダクトバックログはクローズとなり内容に変更がない限りオープンされないため、開発者が現在集中するべきプロダクトも分かりやすくなるというメリットがあります。 このことから、プロダクトバックログとは開発者が作業スケジュールを立てやすくなるタスク管理法としての効果を発揮するものと言えます。 一方で、プロダクトバックログでは正しい仕様を確認したくても分かりにくいという点がデメリットです。例えば、プロダクトバックログ上で以下のような記録が残っているとします。

①a1・a2・a3という機能を含む画面Aを開発する

②「チケット1」で画面Aについての要件を起票

③開発が完了したので「チケット1」をクローズに

④画面Aの機能a1とa2を仕様変更をする

⑤「チケット2」で④の要件を起票

⑥仕様変更が完了したので「チケット2」をクローズに

⑦画面Aの機能a2を仕様変更する

⑧「チケット3」で⑦の要件を起票

⑨仕様変更が完了したので「チケット3」をクローズに

このような変更を経てから改めて画面Aの正しい仕様について確認をする場合、クローズ済みのチケット3つをシステム上から見つけ出すだけでなく、時系列に合わせて組み立てる必要があります。 その際チケット管理ツールから検索すれば該当のチケットを探し当てることができますが、検索が漏れていたり組み合わせ方を間違えると、誤った仕様を正しいものとして認識してしまいます。誤った認識を前提に新しい仕様変更を検討することになれば、より深刻な被害が及ぶリスクが高まることでしょう。 プロダクトを長期的に運用するのであれば、開発の当事者ではないメンバーが参入する可能性も十分にあります。新しいメンバーへの引継ぎをスムーズに行うためにも、正しい仕様が分かりやすく記されてある設計書は必要です。

プロダクトバックログと設計書の役割の違い

プロダクトバックログは、開発に関する作業のタスク管理をしやすくするという役割があります。すでに完了したタスクはクローズされるため、このプロダクトに関して今やるべきことはあるのか？何をやるべきなのか？が分かりやすく効率的な作業を実現できる点がメリットです。 プロダクトの開始当時から開発・運用に関わり、プロダクトの動きや正しい仕様について理解しているメンバーであればプロダクトバックログだけでも支障なく保守を続けることができるでしょう。しかし先述の通り、プロダクトが現在の形に至るまでの経緯や正しい仕様を知らないメンバーが参入する場合もあります。その際にスムーズな引継ぎを助けてくれる存在が、正しい仕様を具体的に書き記した設計書です。 プロダクトバックログと設計書の役割をまとめると、以下のような違いが見えてきます。

  両者には向き・不向きがあることが上記にてお分かりいただけたでしょうか。どちらも作成するとなれば相応の時間やモチベーションが必要ですが、設計書に関しては一度作成すればプロダクトの長期的な保守が楽になります。 アジャイル開発は最小限の体制からスタートし、リリース後の機能に対する市場からのフィードバックをもとに長期的な改善を重ねるというやり方が一般的です。だからこそプロダクトバックログで上手に計画・タスク管理を行いながら、設計書の正しい仕様に基づいた長期的な保守が重要になります。  

ハイブリッドテクノロジーズの提供サービス

ハイブリッドテクノロジーズは、高い品質管理のもと、アプリケーション開発、システム開発の設計、デザインなどの上流工程から開発、運用、保守に至る全ての工程をトータルでご提供することで、クライアント企業のデジタルトランスフォーメーション(DX）推進をサポートいたします。 お客様の要望に合わせて、アジャイル開発やウォーターフォール開発等の開発手法やラボ（ストック）型サービスや受託（フロー）型サービスを柔軟に組み合わせて対応させていただきます。

【アジャイル開発ご希望のお客様】

・アジャイル開発についてはこちら

【ウォーターフォール開発ご希望のお客様】

・ウォーターフォール開発についてはこちら

【ラボ（ストック）型開発サービスご希望のお客様】

・ラボ（ストック）型開発サービスについてはこちら

【受託（フロー）型開発サービスご希望のお客様】

・受託（フロー）型開発サービスについてはこちら

ハイブリッドテクノロジーズが選ばれる理由

01 ビジネス設計〜実装・保守までワンストップで提供できるサービス体制

既存サービスの変革や新規サービスを成功を導くための顧客体験発想による設計からプロジェクトをスタートし、MVP開発を通して顧客のビジネスグロースを一緒に共創していくサービスを提供します。

02 UCS(ユーザー中心設計）によるUI/UXデザイン

実際にそのサービスを使うユーザーを調査、分析しながら、人間中心設計を元にデザインを行なっていきます。

03 スピード感をもった開発体制の構築

要件定義で定めた機能の中から優先度の高い重要なものから、アジャイル・スクラム開発を用いて開発することでサービスインまでの期間を短縮。素早いリリースを実現し、機能の追加などのブラッシュアップを行います。 ベトナムにおける日系No1*1という知名度の高さと20,000人以上*2の候補者リスト*2を元に必要な人員リソースの確保が可能なため、スピード感をもった開発の実行が可能です。

04 累計290社の顧客のプロダクト開発実績

当社が創業以来、豊富なシステム開発・アプリ制作の実績があり、それらを通じて蓄積した知見やノウハウを持ち合わせています。企画段階から要件定義・デザイン・開発まで担当し、プロジェクトを成功に導きます。

05 低コストかつ自由度の高い開発

フルスクラッチ開発とパッケージ開発のいいところどりを実現。　フルスクラッチ開発だとコストが上がる傾向にありますが、当社はベトナムのリソースを活用することでコストを抑えられます。 また、パッケージ開発だと自由度が失われる傾向がありますが、当社はスクラッチ開発で顧客予算に合わせて、スコープを見定めながら、進めることができるので、低コストで自由度の高い開発が実現できます。

06 国際標準規格に則った品質管理体制

情報セキュリティマネジメントシステムの国際規格「ISO9001」、「ISMS（ISO/IEC270001）」、ソフトウェア・テストの国際規「ISTQB Platinum Partner」の認証を取得しており、国際標準規格に則った品質管理体制を提供しています。

1. 株式会社マイナビが運営するベトナムITエンジニア専門の求人サイトITviecは、給与・教育・マネージメント・企業文化・オフィス環境の観点から、Best Companyを選定。Hbrid technologies Vietnam Co., Ltdは、2019年と2020年に、日系企業で最高位に選出されました。
2. 過去の当社へ応募頂いた開発候補者のリストです。応募のタイミングでリクルートシステムに登録し、常にそのリストから候補者へのリサーチできる体制を持っています。

システム開発の成功事例

システム開発での成功事例をご紹介します。

外国人の方の利用に特化した就職・進学ポータルサイト(株式会社GIG)

詳しい情報は開発実績ページへ

サービス内容

外国人の方の利用に特化した就職・進学ポータルサイト

サービス上の課題/目指したいサービス

課題
今まで運用していたサイトが古く、メンテナンスが困難な状況だったことに加え、手作業で行っている部分が多くあるという背景からフルリニューアルで刷新することが課題であった。

目指したいサービス
今回開発する外国人向け就職・進学ポータルサイトにより、管理側および利用ユーザーにおいて以下の価値の提供を可能にすること。
・管理側は、アカウント情報の管理をシステム化し業務効率化を図ることができること。
・利用ユーザーは、多言語に対応した的確な情報をもとに就職・進学の手厚いサポートが受けられること。

クライアントの課題/要望

・開発部分のリソースが不足している
・予算やスケジュールに柔軟に対応していきたい

当社を選択していただいた理由

当社の幅広いリソースとスピード感を持った開発体制を評価いただいたこと

当社ご提案内容

外国人向け就職・進学ポータルサイトの開発
デザインや設計といった上流部分は、GIG社を中心に担当し、実装フェーズに移った際、円滑なスタートができるよう要件定義フェーズの一部において、日本人PMをアサインし、サポートしました。
実装フェーズではGIG社のライブラリを活用しつつ、ベトナムBrSEを中心にバックエンド、フロントエンドの開発を行いました。

まぐまぐ！リーダーアプリ (株式会社まぐまぐ)

https://www.mag2.com/app/reader/

詳しい情報は開発実績ページへ

サービス内容

まぐまぐ!で登録したメルマガコンテンツとまぐまぐ社が運営するメディアを手軽かつシームレスに閲覧できるスマートフォンアプリ「まぐまぐリーダー」

サービス上の課題/目指したいサービス

課題
メルマガはメールのみ、メディアもそれぞれ独自のWebを持っているためユーザービリティが良くない点

目指したいサービス
まぐまぐ!で登録したメルマガコンテンツとまぐまぐ社が提供する4つのニュースメディアを横断して手軽かつシームレスに閲覧できるサービス

クライアントの課題/要望

・新規アプリ開発リソースの不足

当社を選択していただいた理由

内製での開発リソースを保持されていないことと、当社の幅広いリソースとスピード感を持った開発体制が、まぐまぐ様の開発ニーズに合致したため、当社を選ばれました。

当社ご提案内容

ラボ型（ストック）開発＋保守にて提案
1.メルマガやニュースメディアといった多様なユースケースに、細やかに対応する開発体制

メールマガジン配信プラットフォーム事業の理解と学習から始まり、要件定義・設計・開発までをアジャイルスクラム開発で担当し、1週間ごとにクライアント様と成果物のレビュー会を行うことで、フィードバックを早いサイクルで受けることで、ユーザーの期待を超える価値体験を追求いたしました。 記事を読むという観点ではニュースサイトなどのメディアに分類されるサービスではありますが、既存の媒体がメールであるためにユースケースには多様性がありました。

2.毎日読む情報収集アプリとしてのファインダビリティとユーザービリティを考慮したUX・UI設計

メールアプリで閲覧するものだったメルマガをスマートフォンアプリで軽快に閲覧できる機能と、まぐまぐ社が提供する4つのニュースメディアを横断して閲覧できる機能を両立しつつ、スムーズに情報収集を行えるUX・UI設計を行いました。メインペルソナである多忙なサラリーマンの方の情報収集アプリとして、短時間での閲覧でも読みやすい視認性や可読性を重視した白基調の配色とタイポグラフィの設定を行い、ボタン類のアクション要素は見落とされない配色設計や、押しやすいサイズ設計、リアルタイムデータベースを使用した同期的な処理、まとめ読みや読み返しが快適にできるようにローカルデータベースを使用したオフラインファーストな設計をすることで既存サービスのユーザー体験をスマートフォンアプリでも損なわないように配慮しました。

Fimple Credit (H.I.F.株式会社)

https://www.hifcorp.co.jp/fimple-credit/

詳しい情報は開発実績ページへ

サービス内容

与信における企業信頼度を可視化するWEBサービス

サービス上の課題/目指したいサービス

課題
難解な債権回収リスクの与信判断を、AIを活用して効率化・高精度化できるかという点

目指したいサービス
H.I.F社が独自に収集したデータを元に各企業の与信における信頼度をスコア化し、Web上で手軽に検索・確認することを可能にするサービスを目指しました。

クライアントの課題/要望

・開発リソースの不足

当社を選択していただいた理由

別案件での提案の際のデザイン案が非常に良かったことがあり、短納期の中でも充分に任せられるスピードとクオリティと判断頂き、当社を選ばれました。

当社ご提案内容

ラボ型（ストック）開発にて提案
密なコミニケーションで最適な上流設計を提案
デザイン作成と合わせて画面遷移図と、各画面の要件定義資料の作成を実施。開発フェーズを担当するベンダーへの詳細説明まで弊社が行うことでお客様のシステム開発全体が滞りなく進むよう配慮いたしました。 また短納期ということもあり、お客様からフィードバックをいただく機会を通常以上に密に設けました。早い段階での問題発見・方向修正を心がけ、最適なユーザー体験をクライアント企業様と一緒に、練り上げることができました。

Web 相談予約システムの新規構築(大手物流会社)

詳しい情報は開発実績ページへ

サービス内容

窓口相談を事前に予約できるWebアプリ
窓口での相談日時を利用者が事前に予約できるようにし、企業と顧客双方にとって利便性を向上するWebアプリの開発案件です。

サービス上の課題/目指したいサービス

課題
利用者からの問い合わせは、常に窓口で対応している背景があり、
窓口で順に受け付けていたが、待ち時間が長く、顧客から不満の声が上がっていた。

目指したいサービス
・顧客の利便性（満足度）を向上すること。
・システム導入の周知により金融相談業務の認知度を向上させること
・システム導入による効率的な要員配置を目的として、顧客がWeb 上で事前に金融商品に関する相談日時を予約できるシステムを新たに構築すること

クライアントの課題/要望

・社内で開発体制を保持していないこと
・Salesforceを業務の基幹システムとして利用されているため、Saleforceでの機能開発が必須
・金額をミニマムに抑えながら安定的な運用を実現したい

当社を選択していただいた理由

・日本国内での開発より大きな価格メリットがあったこと

当社ご提案内容

受託型開発（フロー）にて提案
1.Salesforceを活用し、ミニマムコストでスピード感を持った機能開発

Salesforceを活用することで0からインフラを構築せずに素早く開発環境を作成することが出来ます。Salesforceの標準機能を基に必要な機能をカスタマイズして開発することで、スピーディな開発〜実装を可能としました。

2.プログラム実装前にプロトタイプ作成し、スピードを保ちつつ認識ギャップを防止

プログラム実装前にプロトタイプを作成することで、リリースというゴールまでスピード感を保ち、的確にコミュニケーションをおこないながら、認識ずれが生じないよう努めました。

3.Salesforce準拠のセキュリティ基準を担保

開発と合わせ、Salesforce準拠のテストコードを作成し、テストを実施することで、リリース後の不具合が発生しにくく、運用保守コストも抑えることができます。またすでにクライアント様が使用されているSalesforceの機能拡張のため、セキュリティー面は今までと同様のものが担保されます。安心感を持ってシステムをご使用いただき、クライアント様、エンドユーザー様双方からご好評いただいています。

まとめ

アジャイル開発とは、あらかじめ具体的な計画を立ててから開発を行う従来の手法とは異なり、途中で生じる様々な変化へ臨機応変に対応していくという手法です。だからといって手ぶらの状態でスタートしても良いという訳ではなく、長期的な保守を見据えて設計書を作成し、正しい仕様について記しておく必要があります。また、チケット管理ツールを利用すれば関係者を交えた仕様の策定やタスク管理もスムーズに行えることでしょう。