## RFQとは（RFPやRFIとの関係など）

RFQは正式名称「Request For Quotation」の略語で、日本語では「見積依頼書」と呼ばれており、後述するRFI（情報提供依頼書）やRFP（提案依頼書）とセットで用いられるのが一般的です。RFIやRFQを提示した後にシステム要件が明確になると、システム化に要する費用の情報が必要となります。**その費用を把握するための文書がRFQ、すなわち「見積依頼書」です。**

発出される際は、RFI「情報提供依頼書」→RFP「提案依頼書」→RFQ「見積依頼書」の順番が一般的ですが、「RFQ」が「RFP」と一体で発出される場合もあります。

RFIは正式名称「Request For Information」の略語です。RFIは「情報提供依頼書」と訳されているように、**ITベンダーに対して会社情報・事業内容・技術情報・サービス情報などの提供を依頼する文書です。**

求める情報はホームページに載っているような公知の情報というよりは、ベンダー選定に当たって必要となるより詳しい情報であり、求めるのは製品やサービスなどの導入先・導入事例・得意分野・製品スペックなどです。RFIには取引検討の意思を示す意味もあり、RFPの前に位置する依頼書と言えます。

RFPとは正式名称「Request For Proposal」の略語で、日本語では「提案要請書」や「提案依頼書」と訳されています。**RFPは、システム導入や業務委託を進める際、発注先の候補となるSIerやベンダーに提案を依頼するためのもの**で、システム化の狙い・目標・システムの要件などが記された文書のことです。

RFPの作成はシステム開発や導入の実質的なスタートです。RFPの出来栄えがシステムの成否を左右します。ITエンジニアとしてはシステム概要書や要件定義書と同様に重要なドキュメントだと認識しましょう。

混同されやすい「要求仕様書」との違いは、RFPにはプロジェクトの要件や見積もり条件を含みますが、要求仕様書にはそれらを含みません。要求仕様書は機能要件や非機能要件が記載されます。

**RFQ・RFI・RFPの3つをまとめて「RFx」と称します。**RFxは元々、自動車業界を中心に調達・購買業務において用いられた手法で、IT分野でも用いられるようになりました。従来の経験や勘に頼らない、合理的・科学的な調達や購買を実現するために利用されています。

では、*RFQはどのタイミングでどのような内容で発出するのでしょうか？*これから、その流れ・文書の内容・注意点などを『Webサイトの構築』を例にして解説します。クライアント企業でコーポレートサイトの再構築が決まったという前提からスタートします。

1.社内でコーポレートサイトの再構築が決まる
2.ベンダーの選定条件を決定する
3.*選定条件に合致すると思われる数社のベンダーにRFIを送付*
4.数社からRFIの回答を貰い、候補ベンダーを3社に絞り込む
5.*候補ベンダー3社にRFPを発出*
6.候補ベンダー3社から提案書を受け取る
7.提案内容を検討し、提案内容が経営陣から高い評価を得たA社に内定、B社を次点とする
8.**詳細見積もりの提示を求めるため、A社とB社にRFQを発出**（あいみつ）
9.A社、B社から見積もり提示。A社の提示額がややB社を上回ったため、A社と価格交渉を行う。
10.交渉の結果、A社の提示額がB社を下回ったため、A社に正式決定。

以上ベンダー選定の一例として紹介しました。

RFQに記載するフォーマットについて、特に決まりはありません。業種・求める製品・サービスなどによって多少異なりますが、**取引条件・支払い条件・支払い方法・納期・納品方法・明細・単価・数量・金額などは明記してもらう必要があります。**

例えば、請負契約であれば成果物が納品され検収が済んだ後に費用を支払うのが一般的ですが、プロジェクトが長期の場合は前金を支払うこともありますので、支払いが一括なのか・分割なのかといった点も確認しておく必要があります。

*▪RFQを発出する側*
　RFQを用いてベンダーに見積もりを依頼する場合、RFIやRFPに対する回答をベンダーから受け取っていることが前提です。基本的にはベンダーからの提案を検討し、納品物に関する価格見積もりを受けるという流れになるので、RFIやRFPを抜かしていきなりRFQを発出するというケースは稀です。

*▪RFQを受取って回答する側*
　RFQを受け取ったベンダーは、RFPに対して回答した提案内容に基づいて見積もりを行い、RFQを発行したクライアントに見積回答書（見積書）を提出します。

RFPやRFQを依頼されて発行しても必ずしもクライアントに選ばれる訳ではありません。

他のベンダーが選ばれてしまうのはそう珍しいことではないため、「せっかく時間をかけて作成したのに選ばれない」「損ではないか？」とマイナスな感情になってしまうこともあります。RFPやRFQにはどのようなメリットがあるのでしょうか。

**RFI・RFP・RFQをきちんと丁寧に作成することで、自社がどのようなベンダーなのかをクライアントへアピールすることができます。**反対に、クライアント側が丁寧に作成してくれなかったと感じてしまうと信頼されにくく、受注に繋げることが難しくなります。

ビジネスは人対人なので、細かい部分で誠実さやベンダーとしての質が問われるため、RFI・RFP・RFQをきちんと作成することで信頼されやすくなります。

### 小規模サイトでもRFP・RFQは作った方がいい

RFQを要求するのはシステム開発や大規模なサイト開設に活用するイメージですが、実は小規模のサイト作りでもベンダーにRFPやRFQを依頼した方がメリットがあります。どういったサイト作りがしたいのか具体的に明示することで、より精度の高いサイト作りが可能です。

また、*RFQを依頼することでより多くのベンダーと関わり、積極的にコミュニケーションを取っていくことで自社に合う優秀なベンダーと出会えることが可能です。*さらに、プロジェクトマネジメントが容易になったり、ナレッジの共有ができたりなど、さまざまなメリットがあります。

**見積書は契約書ではありませんが、正式契約に至るための重要な書類**です。RFQを受けて見積（回答）書を策作成・提出する上で注意すべきことがあります。

*1.契約内容の確認*
見積書の目的の1つは、契約内容の事前確認です。見積書作成によって契約内容が具体化され、金額や納品物、納品期日などが示され、契約の前工程として重要な位置を占めます。

*2.価格や内容の比較*
商品やサービスなどの購入検討の際、納品内容や価格を比較する上で見積書は重要です。特に複数社に対して同一条件で見積書作成を依頼し、価格や内容を比較することを「相見積もり」（略語：あいみつ）と呼びますが、実質的な購入や取引決定の要素となる見積書は大変重要な文書です。

### 見積書に明記すべき項目その1

続いて、見積書の書き方について簡単に紹介します。ITエンジニアの方が直接見積書を作成するケースは稀だと思いますが、営業SEやフリーランスになれば見積書の作成は仕事の1つになります。また、見積書作成をSEが手伝うケースもありますので、ここで覚えておきましょう。

*1.タイトル*
見積書用紙の最上部中央に「見積書」「御見積書」「お見積書」と表記します。

*2.発注者側情報*
誰に対する見積書なのかが分かるよう、見積依頼をした側の企業名・部署・役職・個人名（様）を記入します。

*3.見積書発行日*
右上に発行日を記入します。

*4.見積書番号*
社内に規定があれば、規定に従って番号を記入します。

*5.受注側情報*
右側の発注側の宛名より下の位置に、受注側の「企業名」「住所」「電話番号」「氏名」の4点を記入します。

*6.社印*
受注者側情報の会社名と住所に重なる位置の右寄りに押印します。社印は会社として正式に提示した見積書だということを示すためのものです。

*7.見積書有効期限*
クライアント側に発注を促す意味と、原価変動に備える意味で期限を明示します。

*8.納期*
発注から〇週以内、〇ヶ月以内というような書き方で記入します。

### 見積書に明記すべき項目その2

*9.見積金額*
見積提示額を記入します。小計・消費税額・合計金額を明確に記入します。出精値引きなどがあれば、値引き額を差し引いた額が合計金額になります。金額の記入ミスはトラブルの元になるので十分に注意しましょう。

*10.商品やサービスなどの詳細*
商品名・サービス名・項目名・数量・単価に間違えがないよう、またクライアントにも分かりやすく記入します。補足説明が必要な場合は備考欄に記入しましょう。

*11.備考欄*
全体に関する注意書き、個別の項目について補足説明が必要であれば備考欄に記入します。

以上、見積書に必要な項目を説明しましたが、**頻繁に見積書を作成するのであればテンプレート化も検討しましょう。**さらに、見積書作成システムをWebで構築し、プロジェクト管理や売掛管理システムなどと連動させるようにしておくとさらに効率的な管理が行えます。

ベンダー側が見積書をクライアントに提示した後、クライアントが注文書（発注書）を作成しますが、この手間を省くためにベンダー側が予め注文書を作成しているケースがあります。注文書があらかじめ用意されていると、発注者側は社印・役職印の押印・発注日の記入だけで済み、手間が省けるので大変効率的です。

**注文書には法的拘束力はなく、法的拘束力を得るには双方で契約書を交わすか、ベンダー側が発注に対する注文請書を発行する必要があります。**この一連の手続きを簡略化するために、見積書・注文書・注文請書をセットで用意しておくのも手です。

## RFxを活用できるエンジニアに

見積依頼書の意味を持つRFQについて解説しました。また、RFQを含めた「RFx」の3点セットであるRFIやRFPについても、概要・違い・活用場面などについて述べてきました。

RFxは最適な調達や購買を進める上で必須のツールであり、ITの開発などにおいても大変有効な手法です。ITのプロジェクトは実質的にシステム化構想や検討の段階からスタートしますが、最初からRFxを活用することでシステム開発が円滑に進むでしょう。

効率的なシステム開発を阻害する主な要因として、クライアント側とベンダー側の理解や認識の食い違いがあります。この事で仕様変更が頻繁に起きたり、手戻りが発生したりします。**RFQを含めたRFxは、こうした齟齬や頻繁な使用変更を最小限にするために極めて有効です。**

ITエンジニアの皆さんは最適なシステム開発を進められるよう、まずはRFQをうまく活用しましょう。

RFQはRFIやRFPと並ぶ、最適な調達や購買の有効なツールであるRFxの1つです。RFIとRFPからRFIが生まれ、取引契約や受発注へとつながります。有能なITエンジニアを目指す方は、RFIやRFPと併せてRFQを学び、ぜひシステム開発に活用しましょう。

調達や購買の重要なツールであるRFxは、RFI・RFP・RFQの3点から構成される

RFQは取引検討企業から取引に必要な情報である「見積書」の提示を求めるための重要な文書

RFQに対する正しい見積書の目的や作成方法を知り、ITエンジニアとしての活用方法を学ぶ

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

**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によって得た具体的な提案に対する詳細な見積を依頼する

これまでに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」と呼ばれることもあります。*ユーザー機能駆動開発は、アジャイル開発とウォーターフォール開発の中間的なモデルともいえます。*

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