**RFI（Request For Information）とは、企業や官公庁などが業務発注や業務委託を実施する際に、発注先の候補であるベンダーの業者に情報提供を依頼する文書を指します。**ここでは、RFIの概要・目的・RFIとRFPの違いやRFQについて紹介します。

**RFIは、ベンダー先の製品やサービスなどの情報を収集するための依頼書として利用されることが多いです。**一般的にIT業界の場合、システム開発やIT関連業務の委託を実施する前にRFIは発行されます。RFIへのベンダー先の回答例として、カタログ・パンフレット・導入事例の資料などが挙げられます。

**RFIの目的は、業務委託を実施する事前準備としての情報収集です。**発注元はRFIを利用して、製品やサービスなどについて情報を収集します。*決してベンダーを選定することが目的ではありません。*

例えば、ベンダーの比較や検討を実施する際に、どのような方法で評価するのかの材料収集のためにRFIを作成することがあります。また、RFIを用いて製品やサービスなどの情報を収集したあと、ビジネスにどう活かすのかを検討する事業展開の発端となることも多いでしょう。

**RFP（Request For Proposal）とは、ベンダー先に具体的な提案依頼を実施するための書類を指します。**端的に言えば、RFPは「見積依頼」とも言えるでしょう。作業の流れは、RFIを利用してベンダー先の製品やサービスなどの情報収集を行い、製品やサービスを導入するための要件を詳細に整理します。次に、RFPを用いて実際にベンダーに提案依頼を実施します。

RFIの内容を検討した際、業務委託の候補から離脱するベンダーも多いです。そのため、自社のニーズに適合するベンダーのみに対して、RFPを送付します。*RFIでは情報提供を求めることが目的ですが、RFPでは自社の要望を詳しく記載するのが特徴です。*RFPへのベンダー先の回答は、具体的な提案や正確な見積金額などが記載されていることが多いでしょう。

RFPとRFIとの違いとは？エンジニアがシステム開発に活用するコツ

RFP(提案依頼書)を作成するメリット、デメリットと活用方法について

### RFQとは？RFI・RFP・RFQの関係性

RFQ（Request for Quotation）とは、日本語で見積依頼書・見積要求書と訳します。**RFQの目的は、自社が求めるサービスや商品の作成をベンダーに依頼する前に、ベンダーに詳細な金額・スケジュール等の見積を提示するよう依頼すること**です。

RFI・RFP・RFQの3つの文書は、以下の順番・内容でベンダーに提出するのが一般的です。なお、状況によっては3つの文書をすべて使わずにRFIのみ・RFQのみといった場合もあります。

1.RFIで、ベンダーから導入事例・パンフレットなどの情報を収集する
2.RFPで、RFIによって得た情報からより具体的な提案を依頼する
3.RFQで、RFPによって得た具体的な提案に対する詳細な見積を依頼する

RFQとは？システム作りに必要なRFx3点セットの1つ

これまでにRFIの詳細や、RFI・RFP・RFQの違いについて解説しました。RFIを作成することにはメリットが多いですが、デメリットもあります。ここでは、RFIのメリット・デメリットについて詳しく紹介します。

### メリット1.正当なベンダー選定を行った根拠として利用できる

**業務委託でサービス・商品の作成・提供を依頼する場合、誰が見ても「正当にベンダーを選定した」というクリアな裏付けが必要です。**RFIを利用することで、公平に情報収集した結果からベンダー先を選定したという根拠を明確にすることができます。

例えば、ベンダー先の製品・サービス・システム・ツールなどを導入後に不具合やトラブルが発生した場合、ベンダーを選択した理由をRFIで実証できれば、自社での対応も円滑に行うことができるでしょう。

### メリット2.スクリーニングを実施できる

RFIには、自社が必要としている要望を記載してベンダー先に提出します。ベンダーはRFIの記載に基づいて、製品やサービスなどの基本情報を発注元に提供します。しかし、提供された情報には自社にとって不要な機能が含まれている場合もあります。

そのため、**ベンダー先の回答をもとにスクリーニングを実施すれば、自社に必要なものと不要なものを事前に把握できるでしょう。**

### メリット3.新しい情報を収集できる

近年、ビジネスは情報戦と言われることもあります。そのため、他の企業よりも早く新しい情報や有益な情報を入手することは、ビジネスの成功のカギとも言えるでしょう。

**RFIの回答には、新しい製品やサービスの情報が含まれていることもあります。**RFIから得られた新しい情報を今後の事業展開の検討材料とすることができれば、ビジネスの拡大も期待できるでしょう。

### デメリット.RFIを作成する負担が大きい

**RFIのデメリットは、RFIを作成するための時間・労力の負担が大きいこと**です。RFIを作成するには、自社がベンダーに求める情報や、作成・提供して欲しい製品・サービスの概要、自社が抱える課題などをわかりやすく記載する必要があります。RFIを作成する時間を十分に確保する必要があるため、工数・人員が不足している場合はRFIの作成が困難です。

RFIの完成度が低いとベンダーからの回答も不明瞭となるため、RFIを作成した時間と労力が無駄になることもあります。

これまでにRFIの詳細や、メリット・デメリットについて解説しました。では、RFIを作成する際に記載する項目や内容はどのようなものでしょうか。ここでは、RFIに記載すべき項目や内容について詳しく紹介します。

RFIを作成する必要があるということは、業務委託を控えているということでもあります。そのため、**RFIを作成した理由や目的、必要な情報について詳しく記載することが大切です。**RFIを作成した理由・目的を正確に記載していない場合、ベンダーは趣旨や目的を理解できないため、RFIに対する回答も発注元が期待したものと異なる恐れがあります。

**自社に関する情報は、ベンダー先がRFIへの回答を作成する際に、提案内容や記載内容を決める参考資料となります。**また、RFIはベンダー先との最初の接触の機会です。ベンダー先に自社のことを正確に把握してもらうことで、*新しいビジネスパートナーとしての関係構築にも役立つと言えるでしょう。*

RFIは、製品やサービスの情報を収集するだけではありません。**新しいビジネスパートナーとして関係を構築したい場合、ベンダー先のことを正確に理解する必要があります。**そのため、ベンダー先の「社名」「所在地」「売上高」「従業員数」「事業内容」「グループ企業」「親会社」などの基本情報を記載してもらうことも大切です。

### ベンダー先の製品やサービスなどの基本情報

業務委託の実施を控えている場合、ベンダー先の製品やサービスなどの特徴を正確に理解することに加えて、**他社と比較した強みについて把握することも大切です。**そのため、自社が必要としている製品やサービスなどについて、比較・検討がしやすくなるような基本情報を収集しましょう。

例えば、「製品の名称」「セールスポイント」「リリース時期」「導入実績・事例」「価格プラン」「サポート体制」など、*他社と比較しやすい基本的な製品やサービスなどの情報を収集できるRFIを作成します。*

### ベンダー先の製品やサービスなどの機能要件

**企業が製品やサービスを導入する目的は、導入後に売上が向上するといった成果が期待できることです。**そのため、製品やサービスなどを導入するにあたって「どのような機能を備えているのか」「どのような成果を出すことができるのか」などがわかる項目をRFIに記載しましょう。

製品やサービスなどの機能はベンダー先によって多種多様です。そのため、*RFIを上手く活用して各社の違いを比較・検討できる項目を作成することが大切です。*

これまでにRFIの詳細・メリット・デメリット・RFIに記載すべき項目・内容について解説しました。ここでは、RFIを作成する際の注意点を説明します。RFIを初めて作成する方や、RFIを作成したが期待された回答がベンダー先から返ってこなかった方などはぜひ参考にしてください。

### ベンダー先が回答しやすいように作成する

**RFIに記載する内容は、シンプルかつ明瞭にすることが重要です。**RFIを作成する際は、ベンダーの立場になって作成しましょう。簡潔なRFIであれば、ベンダー側も回答しやすいため正確な情報を提供してくれるでしょう。一方でクリアでない回答が返ってきた場合、RFIの内容がベンダーに正しく伝わっていない可能性が高いと言えます。

### RFIは細部にこだわらず作成する

ビジネスはタイミングが重要です。理想的なビジネス設計だったとしても、タイミングを逃すと価値が低くなる可能性があります。そのため、**ベンダーが少ない時間で回答できるようにすることが大切です。**RFIはベンダー先の選定が目的ではなく、情報収集が目的であることを意識しましょう。*RFIは細部にこだわらず作成することも重要です。*

## 注意点を意識して適切なRFIを作成しよう！

これまでに、RFIの詳細・メリット・RFIを作成する際の項目・内容、注意点について解説しました。RFIとは、業務委託などを実施する際に、発注先の候補である業者に情報提供を依頼する文書のことを言います。**RFIの目的は、あくまでも業務委託などを実施するための情報収集です。**

**RFIを利用することで、正当なベンダー選定を行ったという裏付けを取ることができます。**また、ベンダー先からの回答をもとに、スクリーニングを実施することで、自社に必要なものと不要なものを事前に把握することも可能です。さらに、RFIを用いることで、ビジネスに活かすことができる新しい情報収集も行える可能性もあります。

RFIに記載する項目や内容には注意しましょう。*自社が必要としている情報を簡潔に書くことや、細かすぎる内容をRFIに記載するのは控えることが大切です。*また、ベンダー先の目線に立ってRFIを作成することで期待していた回答をもらうことができるでしょう。

RFIとは、企業や官公庁などが業務発注や業務委託を実施する際に、発注先の候補である業者に情報提供を依頼する文書を指します。当記事では、RFIの詳細やメリット・RFIを作成する際に記載すべき項目・内容・注意点などについて解説します。

RFIは業務委託などを実施する際に、発注先の候補である業者に情報提供を依頼する文書

RFIを利用することで、正当なベンダー選定を実施したという裏付けを取ることができる

RFIを作成する際は「自社が必要としている情報を簡潔に書く」「細かすぎる内容を記載するのは控える」ことが大切

RFIとは？詳細やメリット、作成する注意点について徹底解説

「お金のSNS」をテーマに掲げて**スマホアプリだけでお金の管理ができる「みんなの銀行」**は、従来の銀行と比べて使い勝手の良さ、フレンドリーさでお金との付き合い方を変えてくれるデジタルバンクです。

普通預金はお財布感覚の「ウォレット」、貯蓄預金は貯金箱のような「ボックス」に貯めていきます。スマホさえあれば自宅や街角、職場、どこからでも簡単に自分のお金を扱えます。

~~2021年度グッドデザイン賞も受賞している~~

ただ、「デジタルバンク」という言葉に馴染みがない人は、**信頼してお金を預けても大丈夫かな？**と不安に思うこともありますよね。

この記事では「みんなの銀行」のセキュリティ面、技術面について、株式会社みんなの銀行CIO・宮本昌明さんにお話を伺いました。

また、開発プロセスでも**“従来型”からの脱却**を図っているそうです。ビジネスサイド、デザイナー、エンジニアと、*それぞれの目線で行われる開発現場の舞台裏*も教えていただきます。

宮本さんには「みんなの銀行」のサービス内容・魅力についてもお話を伺っているので、以下リンクの記事もぜひご覧ください。

お金のSNSって知ってる？「みんなの銀行」が徹底的にこだわり抜いたユーザー体験とは【前編】

## フルクラウドか否かでセキュリティ面の大きな違いはない

#### balloon and-engineer left
「みんなの銀行」は“フルクラウドバンキング”という形で取り組まれています。
一般的には、情報漏洩などセキュリティ面を心配されそうですが、実際はどうなのでしょうか？

#### balloon mingin_miyamoto right
クラウドか、クラウドではないか、というのは、**セキュリティ面であまり違いはありません**。
ちゃんと設定しているか、していないかだけ。
設定が漏れてたか否かの違いでしかないんですよね。オンプレでも設定が漏れていれば穴は開きます。

#### balloon and-engineer left
セキュリティ面ではどのように力を入れていますか？

#### balloon mingin_miyamoto right
*セキュリティ診断はかなり手厚く*やっています。
環境面のセキュリティ診断、クラウド側のセキュリティ診断などです。

#### balloon mingin_miyamoto right
悪意のあるツールを使ってスマホアプリ側をハッキングできないか、といった診断もやります。
**セキュリティに対する外部の知見・診断・対応にはかなり気を遣ってリソースをかけて**いますね。

#### balloon and-engineer left
なるほど、色んな方向から診断するわけですね。

#### balloon mingin_miyamoto right
仮に設定が漏れていればそこで気づけますし、漏れていないことの確認もできます。
**セキュリティは一度強固にしたら終わりじゃないところがミソ**なんですよね。
日々進化するセキュリティの攻撃手口にどう追いついていくかが重要です。

#### balloon and-engineer left
何名がセキュリティ面に関わっているのでしょうか？

#### balloon mingin_miyamoto right
セキュリティエンジニアは現在3名います。
でも当然足りていると思っていないですし、*3名でやれることには限界があります*。
ただ、クラウドを使うと、**クラウドベンダーのセキュリティチームが何千人といる**んです。

~~[Google Cloudのサービスサイト]( https://cloud.google.com/gcp)~~

#### balloon and-engineer left
クラウドで人員不足を補える部分もあるということですね。

#### balloon mingin_miyamoto right
そうですね。
クラウドでは日々新しいセキュリティ強化機能が出てきて、新たな攻撃があったら素早く脆弱性パッチを当てたりします。

#### balloon mingin_miyamoto right
*クラウドは我々のリソースをはるかに超えた、セキュリティリソースが動いています*。
そこが**クラウドにして一層セキュアになる**という強みですね。

#### balloon and-engineer left
「クラウドだと心配」といった印象だけが先行している感もありますよね。

#### balloon mingin_miyamoto right
はい、全然**クラウドの方がセキュア**だと思いますね。

#### balloon and-engineer left
万一、クラウドに障害が起こった際の対策としておこなっていることはありますか？

#### balloon mingin_miyamoto right
重要業務は*マルチリージョン構成*にしています。
たとえ東日本が全滅したとしても、大阪のリージョンだけで問題なく動き続けられるような冗長構成です。
**銀行の業務においては、わずかな空白が生まれることも許されないので**。

※参考情報
[みんなの銀行：日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現](https://cloud.google.com/blog/ja/topics/customers/minna-no-ginko-spanner)

## エンジニアの採用数を増やしており、経験が無くても「やってみたい」と応募がくることが多い

#### balloon and-engineer left
デザインと使い勝手にこだわる「みんなの銀行」ですが、開発プロセスはどうなっているのでしょうか？

#### balloon mingin_miyamoto right
ビジネスサイドやデザイナー、エンジニアなど、**違う役割の人が集まって1つのサービスを開発**する。
そういう開発プロセスを目指しています。

#### balloon and-engineer left
みんなで意見を出し合って開発するということでしょうか？

#### balloon mingin_miyamoto right
ビジネスサイドが要件を決めて、エンジニアはただそれをつくっていればいい、という**従来型のシステム開発から脱却**しようとしています。
エンジニアも「こうしたほうがいいんじゃないか」と口が出せる、そんな世界を目指してます。

~~従来の銀行組織とは異なる、フラットな組織を目指す~~

#### balloon and-engineer left
先ほど、セキュリティエンジニアは3名ほどと伺いました。
他の開発スタッフは何名体制なのでしょうか？　

#### balloon mingin_miyamoto right
まず、*インフラ人材が15名*ほどいます。
スマホではフロントエンドとバックエンドを合わせて、*アプリ人材は20～30名ほど*です。

#### balloon and-engineer left
結構な大所帯ですね。

#### balloon mingin_miyamoto right
いえ、全然大所帯ではないです。
**人材はまだまだ足りない**ので、増やしていっています。

#### balloon and-engineer left
採用時は応募が来るのですか？
それともスカウトでしょうか？

#### balloon mingin_miyamoto right
*エンジニアは応募が多い*です。
私が必ず最初に応募書類に目を通しています。

~~[「みんなの銀行」採用ページ](https://corporate.minna-no-ginko.com/careers/) より~~

#### balloon and-engineer left
どんな業界の人からの応募が多いのでしょうか？

#### balloon mingin_miyamoto right
銀行システムを触っていた銀行員やSIer側だった人はあまりいないですね。
どちらかというとエンジニアは*銀行システムを触ったことはなくてもJavaを書いていた人*だったり、*Google Cloudを触ったことはなくてもAWS（Amazon Web Services）はよく知っている人*など様々ですね。

#### balloon and-engineer left
銀行業界というわけでもないのですね？

#### balloon mingin_miyamoto right
業界・技術において経験がなくても**「やってみたい」と応募してくれる人が多い**です。
*やる気さえあればどんどん次の選考に進んでもらってる*感じですね。基礎があれば尚好しですが。

#### balloon and-engineer left
銀行システムの開発が未経験の方に対して、社内でトレーニングの場を設けたりするのでしょうか？

#### balloon mingin_miyamoto right
今はサービスが開始したばかりというのもあって、トレーニングの場はまだそこまで充実していないです。
ただ、アプリエンジニアはペアプログラミングなど、OJTのような形で伸ばしています。

#### balloon mingin_miyamoto right
インフラエンジニアはどちらかというと自分で触って覚えてもらったり、周りの有識者に聞いたりしてもらっています。
**教える時間がなかなか取れない分、外部研修の費用は会社で工面**しています。

## 1on1をしながら一人ずつ適正を掴み、それぞれがやりたいことを重視する

#### balloon and-engineer left
社内には「新しいもの、面白いものをつくりたい！」という気持ちを持つ人が多いのでしょうか？

#### balloon mingin_miyamoto right
銀行システムに興味のある人、という前提はありますが、*新しいことをやりたいという人は多い*ですね。
Javaを書いたことがない人も、入って勉強しながらつくったりしています。
**チャレンジ精神があって頑張れる人が多い**ですね。

#### balloon and-engineer left
採用も含め、社内での役割分担で意識しているポイントはありますか？

#### balloon mingin_miyamoto right
その人の**やりたいことや思想を重視した役割分担**を意識しています。
例えば、品質を重視して高品質のアプリをつくりたい人にはガリガリと開発に入ってもらったり。
反対に、品質はそこまでやりたいわけではないというエンジニアには、試作品の開発をお願いしたり、それぞれの進みたいキャリアにマッチした仕事をお願いしたりしています。

#### balloon and-engineer left
具体的にはどのようなことですか？

#### balloon mingin_miyamoto right
ビジネス側がアイディアを持ってきた時に、画面イメージの認識を合わせるためのモックをつくってもらったり。

#### balloon and-engineer left
適材適所というわけですね。
適性はどう判断していくのでしょうか？

#### balloon mingin_miyamoto right
*1on1をしながら掴んで、判断しています*。
**エンジニアにも色んな考え方の人がいます**から、それぞれがやりたいことを重視するのが大切ですね。

#### balloon and-engineer left
適性にあった仕事の種類も色々あるわけですね？

#### balloon mingin_miyamoto right
はい、本当に仕事が山ほどありますから。
**どんなタイプの人が来てもマッチした仕事があります**。

## エンジニア起点でも「こんなものをつくろう」と発言しやすい風土

#### balloon and-engineer left
エンジニアもビジネス側、デザイナーと一緒になってサービスをつくっていく、というのは素敵だなと思います。
そのためにどのような工夫をされているのでしょうか？

#### balloon mingin_miyamoto right
もちろん、全員が全員、ビジネスに口を出したい人ばかりでもないという前提がありつつ。
ただ、中には「サービス」をつくっていきたい、一緒に考えていきたいというエンジニアも当然います。
だから、**エンジニア起点でも「こんなものをつくろう」と意見がちゃんと言えるミーティング**を持つようにしています。

#### balloon and-engineer left
意識的にそういった場を持つことは大切ですよね。

#### balloon mingin_miyamoto right
エンジニアにも「これ、どう思う？」と話を振って、**発言しやすくする風土づくり**をしています。
例えばクローズドなチャットで「もっとこうしたほうが良さそうだな」と発言する人がいたら、そういう人はぜひ上流から関わろうよと。
*エンジニアがサービスづくりに関与できるよう*に、こうした風土を社内に浸透させていきたいです。

#### balloon and-engineer left
「みんなの銀行」は、スタッフみんなでつくる銀行でもあるわけですね。

#### balloon mingin_miyamoto right
はい、これからも楽しくつくっていきたいですね。

#### balloon and-engineer left
本日は貴重なお話をありがとうございました！

「お金のSNS」をテーマに掲げてスマホアプリだけでお金の管理ができる「みんなの銀行」は、従来の銀行と比べて使い勝手の良さ、フレンドリーさでお金との付き合い方を変えてくれるデジタルバンクです。この記事では「みんなの銀行」のセキュリティ面、技術面について、前編に引き続き「株式会社みんなの銀行」CIO・宮本昌明さんにお話を伺いました。

宮本さん

「エンジニアのこと、エンジニアから。」エンジニア向けの情報をエンジニアの視点から届ける、エンジニアのエンジニアによるエンジニアのためのWebメディアです。

アンドエンジニア編集部

“フルクラウドバンキング”だからセキュリティ面で劣っているということはない

ビジネスサイドが要件を決めて、エンジニアはそれをつくる、という開発プロセスから脱却を図る。一人ひとりのやりたいことを重視した役割分担をおこなっている

「みんなの銀行」には、「新しいことをやりたい」という気持ちや、チャレンジ精神を持つ人が多い

金融系システム開発だけど「言いなり」じゃない！「みんなの銀行」が"国内初"を生み出せた理由【後編】

**アジャイル開発とは、迅速で適応的にシステム開発を行う開発手法のことです。**ここでは、アジャイル開発のメリットについて詳しく紹介します。メリットを把握することで、アジャイル開発が適しているプロジェクトの判断ができるようになります。

**アジャイル開発は、ウォーターフォール開発と比較して柔軟に仕様変更ができます。**ウォータフォール開発とは、開発手順を1つずつ確認して工程を進めていく手法のことです。開発を工程ごとに分けて進めるため、次のフェーズに進むと手戻りが難しい手法ともいえます。そのため、ウォーターフォール開発ではプロジェクトを進めていく中で、仕様変更が起きないように最初に念入りな要件定義を実施します。

*一方、機能ごとに計画・設計を実施するアジャイル開発の場合は、仕様変更にも柔軟に対応が可能です。例えば、クライアントが開発途中に仕様変更の要望があったとしても、その内容を次のイテレーションで要望を反映させることができます。*

### システムリリースまでの時間を短縮できる

**アジャイル開発では、システムをリリースするまでの時間を短縮させることができます。**システムを機能単位で、計画・設計・開発・テストの一連の工程を繰り返し行い、システム開発を進めていきます。*クライアントの要件を随時リリース計画に取り込むことで、迅速にクライアントのニーズを満たしたシステムを開発することが可能です。*

また、迅速なリリースができれば、競合他社と比較して優位に立つこともできます。そのため、アジャイル開発はリーンスタートアップと相性が良い開発モデルといえるでしょう。リーンスタートアップとは、コストをかけずに最低限の製品・サービス・機能を実装した試作品を短い期間で作成し、クライアントの要望を随時反映させて、クライアントが満足できる製品・サービスを開発していくマネジメント手法のことを指します。

### クライアントに寄り添った開発ができる

**アジャイル開発は、プロジェクトの進捗がわかりやすい特徴があります。**一方、ウォーターフォール開発ではプロジェクトの最後にシステムがリリースされるため、クライアントにとって、途中の成果はブラックボックスの状態ともいえるでしょう。

*アジャイル開発では短期間で成果物をリリースするため、クライアントは進捗状況について的確に把握でき、プロジェクトチームは随時フィードバックを得ることが可能です。次のイテレーションの際に、クライアントからの要望をシステムに反映させることで、クライアントに寄り添った開発を行うことができます。*

## アジャイル開発のデメリット

アジャイル開発はメリットだけではなく、デメリットもあります。ここでは、アジャイル開発のデメリットについて詳しく紹介します。

### スケジュール・工程管理が難しい

仕様や要件の大枠を決めて、開発を進めていくアジャイル開発では、柔軟性な仕様変更や迅速な開発ができるメリットの反面として、**スケジュール・工程管理が難しいというデメリットがあります。**クライアントの要望に応じて、随時対応しなければならないため、場当たり的なプロジェクトになる可能性があります。

*この課題を解決するためには、プロジェクトをまとめるプロジェクトマネージャーの存在が必要不可欠です。プロジェクトマネージャーは臨機応変にプロジェクトを進めていかなければならないため、高度なスキルが要求されます。*また、チームで情報伝達・共有するためのマネジメントツールを活用することも大切です。

さらに、パートナー会社を選定する際には、アジャイル開発の経験が豊富にあり、ノウハウ・リソースを充分に備えたシステム開発会社がおすすめといえます。

アジャイル開発には、クライアントの要望を取り入れやすいメリットがあります。**その一方で、仕様の変更や修正を何度も繰り返してしまうと、当初に作成した計画からプロジェクトの方向性が大きくブレてしまう可能性もあります。**

*方向性を見失ってしまうと、終着地点が見えない状態で、開発が延々と継続されることも少なくありません。*その場合、納期に遅れてしまったり、コストが多くかかったりするデメリットがあります。当初の目的を見失わないように、プロジェクトを進めていくことが重要です。

アジャイル開発には、さまざまな手法があります。ここでは代表的なアジャイル開発の手法について解説します。

**スクラム開発は、アジャイル開発の中で最もメジャーな手法で、チームで開発を進めるためのフレームワークのことを指します。**チームでプロジェクトを進めていく点から、ラグビーのスクラムをイメージさせることから名付けられました。

*スクラム開発では、プロジェクトメンバーがイテレーションごとに計画立案や設計・実装を行います。イテレーションごとに開発の進捗状況や機能の動作を確認するため、メンバー同士のコミュニケーションが重要です。*コミュニケーションが上手くいかないと、認識齟齬が生じ、機能が正しく動作しないなどの不具合やトラブルが発生する可能性があります。

### エクストリームプログラミング（Extreme Programming）

**エクストリームプログラミングは、アジャイル開発の中でも、仕様変更・要件追加に対する柔軟性を重要視した開発モデルです。**エクストリームプログラミングは、「XP」と呼ばれることもあります。*エクストリームプログラミングでは、クライアントの担当者もプロジェクトチームの1人として参画するのが特徴です。*

クライアントの担当者は、企画や計画の段階などのシステム機能を決定する工程に参加するだけではなく、システムリリースした後のレビューなども行います。固定した役割を設けるスクラム開発とは異なり、プロジェクトメンバー全員が参加するのが、エクストリームプログラミングの特徴です。また、初期計画よりも技術面を重視するため、プログラマー中心の開発手段ともいえます。

### ユーザー機能駆動開発（Feature Driven Development）

**ユーザー機能駆動開発は、クライアントのビジネスを可視化して必要な機能を洗い出し、適切な間隔でシステム開発を繰り返す手法です。**よって、ユーザー機能駆動開発は、クライアントの機能価値を重要視した開発を行います。ユーザー機能駆動開発は、英語の頭文字を取り「FDD」と呼ばれることもあります。*ユーザー機能駆動開発は、アジャイル開発とウォーターフォール開発の中間的なモデルともいえます。*

## アジャイル開発を成功させるために重要なポイント

多くのメリットがあるアジャイル開発ですが、もちろんデメリットもあります。アジャイル開発に見合ったシステム開発のプロジェクトであったとしても、目的意識を持たずにいると、プロジェクトが失敗してしまうこともあるでしょう。ここでは、アジャイル開発を成功させるために重要なポイントについて詳しく紹介します。

### システム開発プロジェクトの目的を明確にする

**アジャイル開発に限らず、プロジェクトを成功させるためには目的を明確にすることが最も重要です。**アジャイル開発では、柔軟性とスピード開発を重視するため、仕様や要件の大枠しか決定しないことが多いです。*ここで重要なのが、プロジェクトの目的まで曖昧にしてもよいと勘違いしてはいけません。あくまでも仕様・要件は大まかに決定し、システム開発プロジェクトの目的はきちんと明確化することが大切です。*

例えば、クライアントの好みに合わせて、変化が要求されるWebサービスがあったとします。その際に、ターゲットとする顧客や提供している機能を変更・修正することはあったとしても、目的は変わらないようにすることが重要です。*目的を曖昧にしていると、アジャイル開発のデメリット面が強調されることになるため、注意が必要です。*

### クライアントの担当者もプロジェクトチームの一員

スクラム開発・エクストリームプログラミング・ユーザー機能駆動開発など、採用する開発モデルによって異なることはありますが、**アジャイル開発ではクライアントの担当者がプロジェクトチームの中の一員と考えることは大切です。**PDCAサイクルを細かく回すことで、理想とするシステムに近づけていけるアジャイル開発では、クライアントの担当者が積極的にプロジェクトチームに関与して、システムをブラッシュアップしていく意識をもつことが重要といえます。

## アジャイル開発のメリット・デメリットを把握してプロジェクトを成功させよう

これまでに、アジャイル開発のメリット・デメリット、代表的な手法、アジャイル開発を成功させるための重要なポイントについて解説しました。アジャイル開発とは、システム開発におけるプロジェクト開発手法の1つで、大きな単位でシステムを区切らず、小さな単位で実装・テストを繰り返して開発を進めていきます。

**アジャイル開発のメリットは、柔軟な仕様変更ができることやシステムリリースまでの時間を短縮できることなどが挙げられます。一方、アジャイル開発のデメリットは、スケジュール管理が難しいことや開発の方向性がブレやすいことです。**

アジャイル開発の代表的な開発モデルは「スクラム開発」「エクストリームプログラミング」「ユーザー機能駆動開発」です。*アジャイル開発でプロジェクトを成功させるためにも、プロジェクトの目的を明確にすることや、クライアントの担当者もプロジェクトメンバーの一員と考えることが大切といえます。*

アジャイル開発とは、システム開発を行う開発手法の1つです。アジャイル開発のメリットを把握することはプロジェクトを成功させるためにも重要です。当記事では、アジャイル開発のメリット・デメリット、代表的な手法などについて詳しく解説します。

アジャイル開発のメリットは、柔軟な仕様変更ができることやシステムリリースまでの時間を短縮できること

アジャイル開発のデメリットは、スケジュール管理が難しいことや開発の方向性がブレやすいこと

アジャイル開発の代表的な開発モデルは、「スクラム開発」「エクストリームプログラミング」「ユーザー機能駆動開発」

アジャイル開発のメリット・デメリットや代表的な手法について解説！

**DFDとは、データフロー図とよばれることもあります。**この記事ではDFDの書き方について解説した後に、DFDの概要について説明します。まず、以下でDFDを書き方のルールやポイントについて詳しく紹介します。データフロー図の書き方として、データに関する処理と流れを「外部エンティティ」「データストア」「プロセス」「データフロー」の4種類の要素で表現することが可能です。

### プロセスには入力・出力のデータフローが必要

**プロセスは「処理」を表し、入力したデータを編集して出力を行うものです。**そのため、データの入力・出力が両方とも必要な場合があります。例えば、入力が1つで出力は複数という状況もあります。一方、入力が複数あり出力は1つという状況もあります。さらに言えば、入力が複数で出力も複数という状況もあります。

### データストアには入力・出力のデータフローが必要

**データストアは、データの永久的な保管場所を表します。**データストアには、入力と出力のデータフローが両方とも必要です。*データは利用しなければ保存する必要がありません。*

### データフローには全て名前が必要

**データフローには、「どのようなデータであるか」全てに名前をつけることが重要です。**DFDは、どのようなデータを伝達するかを表現する図ですが、*名前を付けることが難しいデータフロー*もあります。その場合は、データフローにおけるデータのまとまりとして物足りない部分があることが多いので、*データフローを分割できないか、もしくはデータフロー自体の削除を検討することが大切です。*

### データフローに処理を書きこむことは不要

**データフロー図に対して、「処理」を記載してしまうことがあります。**例えば、「購入する」「売却する」「決済する」などです。この場合、処理の流れを表現する図「フローチャート」の内容が混在している可能性もあります。*DFDは処理の流れについては記載せず、データの流れを記述する図です。*よって「購入する」のように動詞が名前になっているデータフローは誤りとなるため、データフローの修正が必要です。

### 入力と出力に関するデータ処理の内容がイメージできる名前をプロセスにつける

プロセスには、入力と出力に関するデータが1つ以上あります。**プロセスに名前をつける際には、入力と出力に関するデータの両方ともイメージできる名前にしてください。**データフロー図を確認したら、簡単にシステムをイメージできるようにすることが重要です。

### 処理の実行順序は記載しない

**データフロー図は、データの伝達を明確にするための図です。そのため、いつデータを伝達したかについては記載しません。**処理の実行順序について記述する際には、フローチャート図やシーケンス図などに書くことが推奨されます。

### DFDのコンテキストダイアグラムとレイヤー

**データフロー図を記載する際には、開発するシステムを1つのプロセスとして「どのようなデータをやり取りするか」についてから書き始めることが重要です。**システム全体を捉えた最上層のDFDは、「コンテキストダイアグラム」と言われます。*コンテキストダイアグラムを詳細化していくために、下層のDFDをステップを踏んで作成していくことが多いです。下層のDFDについては、上位のDFDのプロセスに対して1つずつ作られます。*

1つの層ごとに、プロセスは多くても7個以内にして記載するのがおすすめです。*プロセスの数が多い場合、データフロー図がわかりづらくなります。DFDをみて直感的にシステムのイメージが把握できる図にしましょう。*また層分けを実施する際には、0・1・2…のような番号をプロセスに記載します。下層のデータフロー図は上層の番号を継承させて、0.1、0.2などのように番号を記載することで、レイヤーの関係性が理解しやすくできるでしょう。

以上までが、DFDの書き方におけるルールやポイントの紹介でした。しかし、そもそもDFDについてどういうものか理解できていない方も少なくないでしょう。ここからは、DFDの概要などについて詳しく紹介します。

**DFDとは、システムのデータの流れを表現した図を指します。データの流れを記載することで、システムの機能を洗い出すことが可能です。**システムの設計・開発に使用できるだけではなく、業務フロー分析にも活用できます。*視覚的にシステムを容易に把握できるため、クライアントとシステム開発を実施するシステムエンジニアが、認識合わせとしてデータフロー図を使用することが可能です。また、システム開発のプロジェクトメンバーと、システムのイメージを共有する際に活用でき、機能の抜け・漏れ・重複を防げるので、データフロー図を用いることで、認識齟齬が起こりにくくなります。*

DFDの他の呼び方として「データフローダイアグラム」「データフローグラフ」などがあります。また、処理について丸で示すことから「バブルチャート」という呼び名もあります。

トム・デマルコによって構造化分析は考察され、1970年代後半から普及しはじめました。**データフロー図は、構造化分析ツールの1つです。**近年では、複雑で大規模なシステムが多くあるので、構造化分析手法を用いてシステムの要求を段階的に詳細化することで、頭の中を整理することが可能です。

*構造化分析とは、「DFD」「データディクショナリー」「ミニ仕様書」などのツールを利用して、構造化仕様書を作成すること定義されています。*特に、データフロー図をシステムにおけるデータの流れを直感的にとらえることが可能です。そのため、DFDは構造化分析の土台となります。

## データフロー図で使用する記号

**データフロー図で使用する記号は、「データフロー」「プロセス」「データストア」「外部実体」の4種類です。**DFDは、提唱者によって記号の表現の仕方が異なるので注意が必要です。DFDには、「Yourdon & DeMarco記法」と「Gane & Sarson記法」の2通りの記法が存在します。2つの方法の考え方について大きな違いはありません。しかし、「Gane & Sarson記法」には補足説明が必要な場合に、便利とされる識別子の付け方が定義されています。

**データフローは、データの流れを表現する矢印のことです。**プロセス・データストア・外部要素における間のデータの流れを表します。なお、矢印には名前を記載する必要があります。

**プロセスとは、データを編集するものです。「Yourdon & DeMarco記法」では円で、「Gane & Sarson記法」では角が丸い長方形で記載**し、記号の中には名前を記述します。データフロー図を確認する方が概要について簡単に理解できるような名前を設定しましょう。

**データストアは、データにおける保存場所のことです。**データストアの例として、ファイルやデータベースなどが挙げられます。例えば、「Yourdon & DeMarco記法」では二重線で表現します。データストアに名前をつける際も、容易に理解できるものが推奨されます。*また、他のシステムの名前と同じになると、将来的に問題が発生することもあるので、一意になるように通し番号を振って名前とする考え方もあります。ただし、データフロー図の「直感的で理解しやすい」という特徴を大切にするために、わかりやすい名前にしましょう。*

**外部実体は、対象とするシステムの外部の方や組織のことです。**データをシステムに渡してくるものやデータをシステムから受け取るものを表現します。例えば、「Yourdon & DeMarco記法」では長方形で表現し、その中に名前を記載します。*外部実体については、対象とするシステムとデータを伝達する外部要因のことであるため、内容については書く必要はありません。*特に、対象システムに入力されるデータに注意を払うことが重要です。外部実体については、システムに対する理解の向上のために記載しているともいえるでしょう。

## 書き方に注意してデータフロー図を作成しよう！

これまでに、データフロー図の書き方について詳しく紹介しました。また、DFDの概要やデータフロー図を作成する際に使用する記号についても解説しました。**DFDとは、システムのデータの流れをグラフィカルに表現する図のことです。データフロー図はシステム開発工程における設計などの初期段階に作成されることが多いです。**

*データフロー図で使用する記号は「データフロー」「プロセス」「データストア」「外部実体」の4種類です。*また、DFDには「Yourdon & DeMarco記法」と「Gane & Sarson記法」の2通りの記法が存在しています。データフロー図を用いてシステム開発を進めていく中で、認識合わせを適切に行うことが重要です。特に、複雑で大規模なシステムの場合にはDFDは役に立ち、工程の手戻りを防げます。**DFDには視覚的に理解しやすいというメリットがあるので、システム開発を実施する際にはぜひ活用しましょう。**

DFDはデータフロー図ともよばれ、データの流れを表現する図を指します。当記事では、DFDの書き方のルールやポイントについて詳しくご紹介します。また、DFDの概要やデータフロー図を作成する際に必要な記号についても解説します。

DFDとはシステムのデータの流れをグラフィカルに表現する図のこと

データフロー図で使用する記号は「データフロー」「プロセス」「データストア」「外部実体」の4種類

DFDには視覚的にデータの流れを理解しやすいというメリットがある

DFD（データフロー図）の書き方や詳細について徹底解説！

**「アジャイル」が「ウォーターフォール」の対極にある新しいシステム開発手法**だということは、ITエンジニアの皆さんならご存知だと思いますが、「アジャイル」開発には「*スクラム開発*」という手法もあります。今1度ここで確認し、DX時代に対応したシステム開発手法として活用しましょう。

開発の記事（3ページ目）