**「スクラムマスター」とは、スクラム開発の理解と実践を推進し、チームメンバーがプロジェクトを円滑に進められることに責任を持つ人です。**いわゆる「プロジェクトマネージャー」や「プロジェクトリーダー」とは別の職種として区別されています。本記事では、スクラム開発とは何かについて解説した後に、スクラムマスターとして働くためのスキル・知識を得られる資格を3つ紹介します。

「スクラム開発に興味があり、個人的に作法を勉強したい」「参画中のプロジェクトでスクラムマスターを担当することになったが、何を勉強すれば良いか分からない」といった方向けの記事となっています。

## そもそもスクラム開発とは？

スクラム開発は、アプリやソフトウェア開発の手法の1つです。*チーム内でのコミュニケーションを重視し、迅速にプロダクト開発を進めていきます。*

ラグビーの試合でボールを奪い合うために、チームメンバーが体を交差させて塊を作り相手に向かっていくことを「スクラム」と呼びます。ソフトウェアにおける「スクラム開発」という名前は、1つの目標に向かってチームが一丸となって働くところがラグビーのスクラムに似ているところから名付けられました。

スクラム開発とは？エンジニアが知っておきたい情報をまとめました！

### アジャイル開発の思想が根底にある

スクラム開発ではウォーターフォール開発とは異なり、設計〜テスト〜リリースまでの期間を短く区切り、何度もサイクルを回すことでプロダクト開発を進めます。

**この開発手法はアジャイル開発の「開発途中に仕様・設計の変更があるのは当然である」という思想を元にしています。**

アジャイル開発は、2001年に17人の技術者によって表明された「アジャイルソフトウェア開発宣言」という文書をきっかけに広まった、開発方針の1つです。「チーム内の対話」「動くソフトウェア」「顧客との協調」「変化への対応」を重視する価値観として、今も多くの企業に取り入れられています。

【参考】：[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)

DX時代に脚光を浴びる「アジャイル開発」の本命「スクラム」とは？

スクラム開発を行うチームには、大きく分けて3つの役割が必要です。それぞれ、以下で紹介します。

*・プロダクトオーナー*
プロダクトオーナーは、プロダクト価値の最大化に責任を持つ職種です。プロダクトの開発に必要なタスクを「プロダクトバックログ」として整理し、その優先度を決めます。また、ビジネス感覚が鋭いことが重要な素質の1つに挙げられます。市場が求めるプロダクトへのニーズをしっかりと把握しなければなりません。必要な場合はプロダクト仕様の変更や削除を行うなど、重要な意思決定を行う職種でもあります。

*・スクラムマスター*
スクラムマスターは、チームがスクラムとは何かを理解した上で、スクラムのやり方に沿って開発を進められているか、常にチェックする役割です。スクラムという開発手法に最も詳しい必要があります。また、チームの目的達成の妨げになりうる障害が発生した場合には、スクラムマスターが率先してそれを取り除きます。

*・開発チーム*
プロダクトオーナーやスクラムマスターと協力しながら、実際の開発タスクをこなしていく役割です。データベースの管理やアプリケーションの開発、テストの作成など、プロダクト開発に必要なことは一通り行える必要があります。

## スクラムマスター関連の資格は３つある

では、スクラムマスターとしての経験や知識を保証するための資格にはどういったものがあるのでしょうか。

*認定スクラムマスター（Certified Scrum Master、以下CSM）は3つある資格のうち、最もメジャーと言われている資格です。*Scrum Alliance社認定の研修を受けた後に初めて受験資格が与えられ、さらに試験に合格して資格取得者として認定されます。

*・研修*
研修は座学とケーススタディを組み合わせたもので、「スクラムマスターとして振る舞うにはどうすれば良いのか」が実践形式で身につくものになっています。研修のほとんどは英語もしくは通訳ありで行われます。CSM受講のための研修を行える「スクラムトレーナー」にはScrum Alliance社の認定が必要ですが、その認定を受けている日本人が少ないためです。英語に自信がない方は通訳ありの研修を選択しましょう。

また、**CSMは研修受講のための金銭的負担が大きいのが特徴です。**2022年3月時点での各社の研修期間と研修料金をまとめます。

*「Scrum Alliance」*
受講期間...2日
受講費用...161,139円(税込)
言語....英語、通訳あり

*「Odd-e Japan」*
受講期間...5日
受講費用...3,200ドル(税込)
言語....日本語

*「Agile Business Institute」*
受講期間...2日
受講費用...161,139円(税込)
言語....英語、通訳あり

以下に各社の研修受講の申込サイトを添付しますので、参考にしてみてください。

【参考】：[Course Search - Scrum Alliance](https://www.scrumalliance.org/courses-events/search?ctyp=Csm&vo=true&rad=30&tz=my&last=cr&pg=1)
【参考】：[Scrum Alliance® 認定研修](https://www.odd-e.jp/training/?category=1)
【参考】：[認定スクラムマスター日程](https://www.abi-agile.com/%e8%aa%8d%e5%ae%9a%e3%82%b9%e3%82%af%e3%83%a9%e3%83%a0%e3%83%9e%e3%82%b9%e3%82%bf%e3%83%bc%e6%97%a5%e7%a8%8b/)

*・試験*
研修は複数の団体が主催しているのに対し、試験問題はScrum Alliance社が監修している1種類しかありません。問題文の言語について、英語か日本語のうち好きな方を選ぶことができます。試験時間は60分間で50問あり、37問正解が合格条件です。内容としては研修の内容に加えて、前述の「アジャイルソフトウェア宣言」と「スクラムガイド」を理解しておけば解ける問題です。

【参考】：[スクラムガイド](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)

**Licesnced Scrum Master（以下LSM）は、Scrum Inc社が認定しているスクラムマスター資格です。**受験のためには専用の研修受講が必要になっており、その研修はスクラムの共同考案者であるジェフ・サザーランド博士によって監修されています。

*・研修*
LSMの研修もCSMと同様、体験型のワークショップ形式となっており、スクラム経験の有無に関係なく受講することができます。基本的には日本語で研修が行われるので、CSMの研修と比べて受講しやすいです。受講費用は1人当たり税込22万円と高額になっています。

【参考】：[Licensed Scrum Master Training - Scrum Inc. Japan](https://scruminc.jp/training/master/)

*・試験*
試験は4択問題となっており、全部で30問あります。試験合格には75%以上の正解が必要です。CSMと同じく、試験そのものの難易度はそれほど高くないという声が多いようです。研修の内容を正しく理解できていれば、問題なく合格できるでしょう。

Professional Scrum Master（以下PSM）はScrum.org社が認定しているスクラムマスター資格です。**上記の2つの資格とは異なり、受験のために研修を受ける必要はありません。**

*・研修*
試験受験のために研修受講が必須ではないものの、研修自体は用意されています。2022年3月時点では、日本語で行われる講義は存在せず、通訳もありません。英語での会話に抵抗がない方で、スクラムマスターとしての知識・経験を体系的に得たい方は受講を検討してみてください。

【参考】：[Scrum Master Certification From the Home of Scrum](https://www.scrum.org/classes?languages[]=en&type[]=104&delivery_method=VirtualClassroom)

*・試験*
研修受講が必須でない代わりに、試験問題の難易度は他の資格より難しめに設定されています。また合格基準も高く、CSMの合格率が75%程度なのに対し、PSMは85%以上正解しないと合格できません。

下記の公式サイトに「Reading the Scrum Guide and taking the Open Assessments alone isn't typically enough preparation」とあるように、スクラムガイドを読んでおくだけでは準備不足です。Udemyの対策コースで勉強するなどして、さらに知識を深める必要があります。また、**PSM受験のために必要な費用は150ドルとなっており、他の資格よりリーズナブルに受験することができます。**

【参考】：[Scrum Master Certification From the Home of Scrum](https://www.scrum.org/classes?languages[]=en&type[]=104&delivery_method=VirtualClassroom)
【参考】：[Scrum for Beginners + Scrum Master Certification Preparation | Udemy](https://www.udemy.com/course/agile-scrum-for-beginners-scrum-master-certification-preparation/)

## スクラムマスターとしての実力を付けるために資格を取ろう

本記事では、スクラムマスターとしてのスキルや知識を体系的に得られる資格を3つ紹介しました。**これらの資格を取得することで、スクラムマスターとして良い働き方ができるようになるだけでなく、昇進や転職の際にも有利になります。**費用が高額になりやすいため、身に付くスキルが実用的なものなのかしっかり検討した上で受験するようにしましょう。

スクラムマスターとは、スクラム開発における役割の1つです。スクラム開発の理解と実践を推進し、チームメンバーの開発サポートを率先して行います。スクラムマスターとしてのスキルアップにつながる資格には「認定スクラムマスター」「LSM」「PSM」の3つがあります。

スクラム開発とは、アジャイル開発の思想を元にした開発手法の1つであり、プロダクトオーナー・スクラムマスター・開発メンバーという3つの役割でチームを組みます

スクラムマスターとは、スクラム開発において開発メンバーが円滑にスクラムを進められるように障害を取り除く役割です

スクラムマスターとしての知識を体系的に身につけられる資格に、「認定スクラムマスター」「LSM」「PSM」の3つがあります

スクラムマスターのおすすめ資格3選！研修内容や勉強方法も解説

「アジャイル開発宣言（アジャイルマニフェスト）」はいつ発表されたのでしょうか。それは2001年に17人のソフトウェア開発者のグループが発表しました。内容は従来型の開発手法に対するアンチテーゼ（反対表明）です。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

### 従来型の開発手法に対する開発者たちに共通の問題意識

米国ユタ州のソルトレイクシティの郊外に集まった開発者たちは、ソフトウェアの開発手法に対する考え方はそれぞれ異なっていましたが、誰もが開発の現状には不満を抱いていました。

**開発者たちに共通した問題意識は、企業の論理やプロセスとソフトウェア開発のいわば「反りの悪さ」です。**

ソフトウェア開発が大規模になり、大きなプロジェクトが長期間かけて開発に取り組むようになるほど、この反りの悪さが目立つようになってきたと彼らは感じていました。具体的に言うと、「契約」と「計画・管理」を前提にする従来のビジネスプロセスは、時としてソフトウェア開発の障害になると感じたのです。

### アジャイル開発宣言を読んでみる

アジャイル開発宣言は、正式には「アジャイルソフトウェア開発宣言」で、下記のような全文223字（英文68word）の簡潔な「マニフェスト」です。

*アジャイルソフトウェア開発宣言*

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。


プロセスやツールよりも*個人と対話を*、
包括的なドキュメントよりも*動くソフトウェアを*、
契約交渉よりも*顧客との協調を*、
計画に従うことよりも*変化への対応を*、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

大規模なソフトウェア開発で重視されてきたプロセス・ドキュメント・契約・計画よりも、**チームの対話・ソフトウェアを動かしてみること・顧客満足・変化への対応という4つの価値をより重視すべきだというのです。**

【参考】[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)

## アジャイル開発宣言が提唱する開発姿勢

この「宣言」には、「アジャイル開発宣言の背景にある原則」という文書が付属していて、そこには彼らがソフトウェア開発において重要だと考える12の原則（開発姿勢）が列挙されています。

### ソフトウェア開発に求められる12の原則　

「アジャイル開発宣言の背景にある原則」を要約すると次のようになります。

1.*顧客満足を最優先*し、ソフトウェアを迅速・継続的に提供する
2.開発後期であっても*変更を歓迎*し、それによってクライアントの競争力を高める
3.動くソフトウェアをできるだけ*短い間隔でリリースする*
4.営業と開発は、*プロジェクト内で*日々一緒に働くべきである
5.意欲のある人を集めて*良い環境を提供し、プロジェクト終了まで支援*する
6.*フェイス・トゥ・フェイス*で話をし、情報を伝える
7.*動くソフトウェアこそが進捗の尺度*である
8.一定のペースを継続的に維持できる、*持続可能な開発プロセス*が求められる
9.技術的卓越性と優れた設計に対する*注意を怠らず、機敏に対応する*
10.*ムダなく作るシンプルさ*が開発の本質である
11.*自己組織的なチーム*から最良のアーキテクチャ（設計への発想）が生みだされる
12.*チームの効率を定期的に振り返り*、やり方を調整する

これらの原則を読んでまずイメージされるのは、革新的な製品を世に送り出したスタートアップ企業の少人数によるプロジェクトの生き生きとした開発の様子です。

この原則や開発姿勢を否定的にとらえる人はいないでしょうが、問題は**企業とベンダーが関わる（大規模）ソフトウェア開発で、この柔軟性・創造性・効率性が発揮できるのかということです。**

### 流行語としてのアジャイル開発　

IТエンジニアでアジャイル開発について聞いたことがない人はいないくらい、この言葉は大流行しています。しかし、日々のプロジェクトの業務でアジャイル開発の原則が取り入れられていると感じているエンジニアはごく少数派に留まるでしょう。

IТ企業もアジャイル開発の価値と原則に賛同するところは少なくありませんが、**それをソフトウェア開発戦略の中心に据えて本気で取り組んでいる企業は、大企業ではほとんど見当たらないと言ってもよい状況です。**

誰しもがアジャイル開発の原則を「ソフトウェア開発の1つの理想形」として受け入れますが、それを現在進行しているプロジェクトにどう結び付けていけばよいのか分からないのです。

### アジャイル開発は「ソリューション」ではない　

アジャイル開発が流行語の域をなかなか抜けられない理由は、**アジャイル開発を従来のプロジェクトに存在する問題点のソリューションと捉える間違いにあります。**

例えば、クライアント企業とベンダー企業が、プロジェクトにアジャイル開発の手法を取り入れようと話し合ってプロジェクトマネージャーに指示したとしても、それが上手くいくとは考えられません。

なぜなら、アジャイル開発は「契約」のあり方から考え直さないと機能しないからです。アジャイル開発の原則がソフトウェア開発に携わる人々の「マインドセット」であることは確かですが、*従来の契約・計画・管理の枠組みでエンジニアたちにマインドセットを求めても難しく、理不尽なダブルバインドになるだけです。*

そもそも**「ソフトウェア開発に携わる人々」の枠をプロジェクト内部に限定したのでは、アジャイル開発の原則は維持できません。**企業戦略を策定する経営トップ・営業部門・システム運営部門・ベンダー企業のトップなど、あらゆるステークホルダーを巻き込んだ検討や支援が必要となります。

### ダークアジャイルを生む土壌とは

アジャイル開発が流行することで、というよりアジャイル開発という「言葉」が流行することで出現したのが「ダークアジャイル」と呼ばれるものです。これは、**手っ取り早いアジャイル開発のマニュアルやそれをコーチする人たちを指し、それによって苦しめられたエンジニアたちは少なくありません。**

このようなダークアジャイルを生むのも、アジャイル開発をソリューションあるいは特効薬と考える管理サイドの誤解です。よく言われるような「大規模プロジェクトはウォーターフォール開発で、小規模プジェクトはアジャイル開発で」という考えは、*ソフトウェア開発に内在する問題の矮小化あるいはすり替え*に過ぎない場合があります。

## 開発関係者のすべてが「アジャイル開発の哲学」を理解する必要がある

アジャイル開発の原則を受け入れ、その良き成果を手に入れるには、広い意味での開発関係者のすべてが*アジャイル開発の原則を貫く哲学を理解する必要があります。*

*「宣言」で太字で強調されている個人と対話は「個人と対話する」という意味ではなく、「個人＆対話」です。*「プロセスやツールよりも個人が重要であり、対話が重要である」と述べられています。個人（Individuals）は、分割できない全人格としての人というニュアンスで、その個人間の相互作用（interactions）つまり対話が重要だというのです。

これは、**エンジニアをプロセスの中の「駒」として捉えるのではなく、あくまで「人」として捉えようということです。**それを示しているのが、12の原則にある次の言葉です。*「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」*

「このプロセスに従え」「このツールを使え」というのは管理には好都合ですが、そういう硬直した姿勢が、意欲に満ちた人々の創造性を棄損する恐れがあります。また、大規模プロジェクトの多重請負構造と「IТ土方」と呼ばれる単純作業の現状を、個人と対話の尊重の哲学にどう調和させるかは難しい問題ですが、アジャイル開発の実をあげるには目を背けるわけにはいかないテーマです。

### ドキュメントを揃えるよりも動くソフトウェアを

「要件定義書」「詳細設計書」「運用マニュアル」などのドキュメントをプロセスに従って作成・提出するのはシステム開発の常道であり、「仕事が進捗している」アリバイでもあります。

しかし、プロジェクトの目的は「ちゃんと動作するソフトウェアを作ること」で、ドキュメントを揃えることではなく、まして炎上したときのためのアリバイ作りでもありません。「宣言の背景にある原則」で述べられているように*「動くソフトウェアこそが進捗の最も重要な尺度」なのです。*

プロセスに従ってドキュメントを作成することに注意を払うあまりに、**ドキュメントの作り直しが必要なアイディアを無視するようなことがあっては本末転倒になります。**

### プロジェクトには計画の変化、契約の見直しがつきものであることを了解しよう

「宣言」にある「契約交渉よりも顧客との協調を」と「計画に従うことよりも変化への対応を」は密接に関係している、というより同じことの言い換えです。*「開発」に未知数があるのは自明で、初めの契約や計画の絶対化や固執は、実り多い成果への障害というしかありません。*

しかし、一方でシステム開発も企業の論理の外にあるものではなく、お金が絡む問題なので、契約・計画・管理を軽視することはできません。**「契約」「計画」「柔軟な対応」のトレードオフ関係を解決する簡単な処方箋はありませんが、アジャイル開発の原則が述べている次の言葉が解決への道を示唆しているのではないでしょうか。**

・ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
・要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

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

ここでは、アジャイル開発のメリットとデメリットについて解説します。プロジェクトによってはアジャイル開発に向いていない場合があるため、すべてにアジャイル開発を取り入れるのは危険です。*メリットとデメリットを理解し、担当するプロジェクトに合わせて計画を立ててください。*

**アジャイル開発のメリットは、開発のスピードが早いことと臨機応変な対応が可能なことです。**従来の開発方法であるウォーターフォール開発の場合、あらかじめ決まっている計画や設計に沿って開発を進めます。そのため、スケジュールの後半で発生したトラブルが開発の前半での不備が原因の場合、大きな後戻りが発生します。

一方アジャイル開発の場合、機能単位で細かいスケジュールを組んでいるためトラブルが発生しても後戻りが少なく、すぐに修正が可能です。また、開発の途中で要件や仕様の変更があっても柔軟に対応できるため、顧客の要望に沿った開発ができます。

*さらに、アジャイル開発は最近注目されているDX（デジタルトランスフォーメーション）との相性も良いです。*DXとは日々変化するテクノロジーや人々の生活が変化するのに合わせて、ビジネスの形を変えていくこと。アジャイル開発では開発の途中での仕様・要求の変更を受け入れることができるため、顧客のニーズに合った開発方法とDXの組み合わせは最適だといえます。

**アジャイル開発は臨機応変な対応ができることがメリットですが、その分進捗状況の管理やリスケジュールの対応が困難な場合があります。**顧客の要望や開発途中で出てきた課題に細かく対応し過ぎて、納期に間に合わないといったことになっては本末転倒です。

*全体のスケジュールや納期も意識しつつ、その都度出てくる要望や課題に対応することが大事です。*また、顧客ニーズを何でも取り入れようとすると開発の方向性がブレてしまうこともあります。最終的な完成物のイメージを開発者や関係者と共有し、全員が同じ目標に向かって開発することを意識しましょう。

アジャイル開発には2つの手法があります。ここでは、アジャイル開発の手法である「スクラム」と「エクストリーム・プログラミング（XP）」について解説します。

**スクラムとはチームで開発をする上で効率の高さを重視したフレームワークのことです。**チームでプロジェクトに取り組む姿勢から、ラグビーのスクラムが名前の由来となっています。スクラム開発ではメンバーそれぞれがイテレーションの計画を立て、設計から実行までを担当します。イテレーションごとに進捗確認・成果物の動作テストなどをチームで共有する必要があり、チームのコミュニケーションが重要となります。

そのため、*コミュニケーション不足はスケジュールの遅れ・バグの見落としなどに繋がります。*小さなミスやバグを放置するとあとから大きな問題に発展することもあるため、その都度柔軟に対応することが大切です。

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

**エクストリーム・プログラミング（XP）とはスクラムよりもプログラマー中心の開発技法で、顧客の要望や開発段階での課題を柔軟に取り入れることができます。**開発途中で仕様を変更できるため、より顧客の要望に沿った開発が可能です。

主な手法として2人1組でプログラミングを行うペアプログラミングや、ソースコードや用語のメンバー共有、コードの改善、機能の実装の前にテストを作成するテストファーストといったものがあります。これらはプログラマーにとってプログラミングのしやすさにアプローチした方法と言われており、失敗やバグの防止につながります。

## ダークアジャイルに踊らされず悩まされないシステム開発を

ここまで述べてきたように、「アジャイル開発宣言」の原則・精神をプロジェクトに活かすのは、そう簡単なことではありません。エンジニアとしては、スクラム開発などのアジャイル開発の手法に取り組む前に「宣言」を読み返して、その原則と哲学を確認してみる必要がありそうです。

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

ウォーターフォール型のソフトウェアの開発の諸問題が提起される中で、再認識が必要とされているのが「アジャイル開発宣言」です。この記事ではその内容を解説し、それを現代の開発プロジェクトに活かす道筋を、現状のシステム開発の問題点を踏まえながら探ります。

アジャイル開発宣言は、開発者たちによる従来の開発手法に対するアンチテーゼ

プロジェクトは、契約・計画・プロセスよりも、個人・対話・変化への対応が重要

アジャイル開発はソリューションや処方箋ではなく開発哲学である

アジャイル開発宣言の内容を解説！開発に活かす道筋を探る

「お金の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メディアです。

アンドエンジニア編集部

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

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

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

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

FP法とは「ファンクションポイント法」の略で、1979年に米国IBMのAllan Albrecht氏により考案されました。**FP法の目的は誰が見積もりの計測を行っても同じ結果が得られ、見積もり作業のばらつきを抑えることです。**そのため、ソフトウェア開発の生産性を測定するためのユーザー要件を、ファンクションとして定義しカテゴリー化することで、*見積もりの平準化を行います。*

### FP法で定量化できるのは機能要件

**FP法では機能要件とその他の要件を分類して計算することで、正確な見積もりを出すことができます。**FP法はデータ構造によって規模を見積もっているため、システムのデータやファイルが明確である機能要件が見積もりの対象です。*機能規模では、非機能要件や技術者要件を含みません。*

FP法ではシステムの機能を「ファンクション」と呼び、そのファンクションごとに点数を定めています。そのため*誰が見積もりをしても、ファンクションの数を数えるだけでシステム規模の見積もりが同等に実施できます。*そのファンクションはシステムの実装形式による違いがなく、従来のオンプレミス（所有型）でもクラウド（利用型）でも同じスコアとなります。

同様にシステム開発の形式にも依存しないので、新規開発でもパッケージ利用でも同等の結果となります。さらに開発手法においても、従来型のウォータフォールモデルでもアジャイル型でもスコアに差がありません。もちろん、開発言語にも依存しません。

### FP法のファンクションの詳細

FP法ではファンクションをデータ処理に関する「トランザクションファンクション」と、データ格納に関する「データファンクション」に大別して集計されます。各区分のファンクションごとに点数を定めているため、*点数表に集計すると合計のスコアが簡単に求められます。*

各機能はそれぞれ、外部入力（EI）・外部出力（EO）・外部照会（EQ）・内部論理ファイル（ILF）・外部インターフェイスファイル（EIF）に分類し算出されます。

FP法の計算手順は以下のようになります。

*（1）扱うデータを5つのファンクション型に分類*

　外部入力（EI）、外部出力（EO）、外部照会（EQ）、内部論理ファイル（ILF）、外部インタフェースファイル（EIF）の5分類

*（2） 扱うデータごとに、「データ項目数」とそのデータに関連する「レコード種類数」を集計*

　データのファンクションの複雑さを3段階（低・中・高）に分類

*（3）システム全体の未調整FPの計算*

　各データに3段階のファンクションの複雑さに応じた未調整FP（調整係数）を掛けて合計

*（4） システムの特性の合計値を計算*

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