![見出し画像](https://assets.st-note.com/production/uploads/images/73901517/rectangle_large_type_2_61b7754ca6273718e207f9c64ad1a514.png?width=1200)
「銀行」×「アジャイル」の必要性を考える vol.1 内製開発
ふくおかフィナンシャルグループ ビジネス開発部 ながお です。
今回も、
「※この発言は個人の見解であり、所属する組織の公式見解ではありません」
のスタイルを貫きます。
※筆者はこんな人です
本題に入る前に!!
ところで、ふくおかフィナンシャルグループのブランドスローガンをご存知ですか?
正解しなくて当然なので、ジャジャーンと答えです!!
●ブランドスローガン
![](https://assets.st-note.com/img/1646822953929-pwQNtFnjbQ.png)
あの手この手で「あなたのいちばんに。」を実現して世界を良くしようというのが企業の目指すところなんです。
それでは・・・ガラにもなく・・・長めの真面目な記事を書いていきます!!
なぜ内製開発が必要なのか?
市場への柔軟性を確保するため、技術やシステムの「手の内化」を図るためです。
変化が必要なタイミングに手元で修正が可能な状態が必要です。
変化が必要なタイミングで、変化に必要な決断が可能な技術知識が必要です。
今までの銀行に起きていたこと
●「メガを見ろ」「他行に並べ」
今までの銀行は、変化の起こしにくい環境で、かつ、法律により守られた環境にありました。(たぶん)
ある程度の市場での戦略の取り方が限られていたため、リスクをとるよりも、他社事例や他社の実績の適用が合理的でした。
それはつまり
メガバンクがやっていることを適応する
他行との足並みをそろえる
どの業界でも起こることです。銀行は、銀行法だったりのルール上、差別化できる余地が少ない業界でした。差別化要素が少ない中、変化を起こすリスクに対するリターンが見込めなければ、変化を起こすことは合理的ではありません。フリーライダーとして利益を享受できるなら、経済合理性としても最善です。
●ベンダーに発注
変化が起きづらいことにより、一刻を争うようなスピード感がないことはそこまで致命的ではなかったのかもしれません。
そのため、ある程度の見通しに対して要件を固めていく事が可能でした。そこにある程度の期間がかかったとしても、問題が顕在化することはありませんでした。
もしくは、他社で既に実現されている機能を再現してサービスを提供していければよかったのかもしれません。既知の機能を自社製にカスタマイズする作業は0→1を経験するよりもリードタイムは短かったのかもしれません。
このように、IT投資として想定されるシステムは想像しやすい状態です。
つまり、既存で技術的知見や業務経験があるベンダーに発注してベンダーの能力や経験を転用してもらうことがより合理的でした。
今、課題となっていること
私たち銀行組織は今、複雑性の高いマーケット環境にいます。
その複雑性により、従来型の成功体験や学習の棄却(アンラーン)が必要になりました。構造自体の再構築も必要になります。
複雑性の高いマーケットに対して、サービスやプロダクトを必要なタイミングで届ける必要があります。顧客ニーズに対応できる十分な柔軟性が必要です。
今までは既知の課題、解決策が明確な課題に対してシステム構築を行っていました。しかし、今は解決策が不明確です。さらに、ある時点での正解も次の時点では不正解であることが多くなりました。
既知の知見を転用し続けるよりも、未知の課題に対してそれぞれの解決策を検証し続けなければいけない市場になりました。
そのためには、サービスやプロダクトの提供を頻繁に行い、カイゼンが必要です。
そうなるために、具体的には以下の点が課題だと私は感じています。
●思考の課題
考え方における課題です。
実績のない解決策に対してリスクを取りづらく、実戦経験を作りづらい
業務が最適化され分業制になっているので、部分最適に陥りがち
サービスやプロダクトの価値向上よりも、プロジェクトの完遂を優先してしまう
●構造の課題
組織構造における課題です。
整理された分業構造になっているため、他部門の業務がわからない
部門を跨ぐ作業にたいするコストが自部門を大きく超える
部門間での優先項目が違う
●手順の課題
物事を進めるプロセス上の課題です。
専門部署を使って情報や権限を集約しているので、部門をまたぐ意思決定に時間がかかる
階層構造で承認作業を行うため、同じ部門内でも決裁や意思決定に時間と人数がかかる
整理・成熟した組織なので、手順を変えることにも労力が必要
今、私たちが取り組んでいること
●思考の変革
契約や仕様、納期を中心とした思考の優先度を下げる必要があります。
これはいわゆるプロジェクト思考からの脱却になります。
納期やKPIに重きを置くことで、価値よりも成果物の量が大事にされてしまうからです。
私たちは、顧客を中心に、プロダクト(サービス)がどうよくなるかを考えカイゼン・向上できるようになる必要があります。これはプロダクト思考です。
私たちは顧客に価値があるサービスをJust In Timeで提供できるように、顧客を中心に価値提供を考えるプロダクト思考になっていきたいのです。
●構造の変革
内製開発が一概に解決策ではないとは思います・・・。外部に発注しようとも、顧客価値を見据えて共同開発をできる体制であれば問題は少ないと思います。
しかし、ベンダー発注の場合に顧客価値優先にすると、お互いの契約上不利益につながる選択を迫られることもあります。その不利益をのんででも価値提供をできるくらいにお互いの関係性を構築することはさらに難しいのではないでしょうか?同じ企業内だろうと、部門間での優先度が違うことで問題が発生するので、他社ともなればさらに難しいことが想像できます。
ベンダーでなければいいのでしょうか?内部だろうとも、企画部門からの要求に応えることが合理的な関係になってしまっては意味がありません。
●手順の変革
考え方や構造が変わるだけでは、柔軟性が足りません。
なぜならば、各種のワークフローなどの手順が簡略化されなければ、進め方としての柔軟性が向上しないからです。
縦・横の垣根を越えて、市場への適応のプロセスを簡略化する必要があります。
チームが権限を持つのか、権限を持つ人がチームに入ってくるのか・・・。
提供のためのプロセスを簡略化することが重要です。
今後、起こること
課題に対してカイゼンしていくので、私は以下の要素における変化を起こす必要があります。
マインドセット
組織構造
プロセス
一部の先端部署だけの導入でなく、企業全体のマインドセットとして顧客中心に価値提供をする考えに変わっていく必要があります。手段の目的かをしてはいけません。
「なぜ」を探求し顧客に価値提供できる組織が増えていかなくてはいけません。
組織構造は、より単純にして市場のニーズを反映しやすくする必要があります。縦や横にとらわれずに、より全体最適を考えやすい組織構造が重要です。マインドセットだけではなく、構造上の正義として顧客価値を最大化することが正義となることがよりよいはずです。
プロセスにおいても、従来の枠組みだけで考える状態からのカイゼンが必要です。プロセスにはその存在理由(課題)があります。その課題解決のための最少最短のもので運用されることがよりよいはずです。開発だけが素早く柔軟に行えるだけでは不十分です。開発したプロダクトをより早く市場に提供できる段階まで含めてカイゼンする必要があります。
つまり、私たちは
さらに内製開発でアジャイルな"状態"になる必要があるのです!!
アジャイルという手法を実践することが目的ではなく
つまりアジャイルと言われる状態になることが「あなたのいちばんに。」につながると信じています(私が)
宣伝
ふくおかフィナンシャルグループはまだまだ仲間を募集しております!!
https://www.fukuoka-fg.com/recruit_career/requirements/
※効果検証のために「このブログを見た」って言ってもらえると喜びます