DXあんとれ　備忘録　No.3

＜過去分＞

⑦Power Platform

何度か講義を見たけど、いまいち理解が追いついていません。おそらくアプリの必要性≒自分の困り事を十分に認識できていない事が原因だと思います。

業種柄、業務データを個々に持ち出す行為について無意識にストップがかかっている気がします。

まさに先入観。

「エクセルでいいんじゃない？」とかいう考えを一旦捨てて、ゼロベースで考える必要がありそうです。

現時点でこの講義を理解する為のいわゆる「フラグ」が立っていない状況だと思いますので、他の講義を聞いて、自分の発想を柔軟にし、再度ここに戻ってくる必要がありそうです。

⑧アジャイル

わからないものを作るための開発手法。開発→リリース→検証→修正のサイクルをとにかく小さくする。目的は「手戻りを最小にする」こと。
「わからないものを作る」ということは「ゴールが日々変わる可能性がある」ということですので、当然手戻りは多くなります。効率的に進める為には手戻りを最小にしないといけないので、その為の手法です。

対義的な手法がウォーターフォール。どっちが優れているというものではなく手法の採用はケースバイケース。ただ、わからないものを作る時はアジャイルで対応した方が効率的という事です。

アジャイル手法を採用するときの前提条件としては「開発チーム内のメンバー全員に計画を修正できる柔軟さが必要」。
柔軟さを生む為には、全員が開発開始時点で「わからないもの」「答えのないもの」を作っているという共通認識を持つことが大事です。

サイクルを小さくするということは、当然ながら雑にすることではなく、むしろ工程を丁寧に分割し、その中で一番重要と思われるものから開発していくということです。

車に例えると、「車輪」「ハンドル」「エンジン」「屋根」「エアコン」「音響」等に分解し「何が一番重要か？」を考えるということ。
ここの作業を雑にやった場合、全員で一生懸命「屋根」を作って高品質の「音響」や高性能な「エアコン」等も完成させた中で、最後に車輪を作ったとすれば、「重すぎて動かない」という根本的な問題が発生する可能性があったりします。
その問題に対して必死に軽量化などで対応した後に、実は一人で乗るので車じゃなくてバイクでいい等となったら、今までの作業が全て手戻りになってしまうリスクがあります。

誰もがイメージできる車なので笑い話に聞こえるかもしれないですが、最初にある「わからないものを作る」という事になった際に笑えない話になります。

⑨スプリント

アジャイル手法では「わからないものを作っている」ので、完成形というものは中々出しづらくなるので、「スプリント」という考えによって「小さく完成させていく」必要があります。

スプリントの考え方
①2週間程度の期間で成果物を完成させる。
②短い期間だけどあくまで完成させる。
③成果物は「価値」でなければならない。

上のアジャイルの例で言えば、作るのは車輪だけだとしても車輪としては完成させなければならないということですね。
あくまで「小さく作る」だけで「雑に作る」ではない所がポイントかなと思います。

この辺は実は銀行業務とも非常に関連している部分だと思います。
融資等の案件を進める際に「金額」「期間」「金利」「担保」「保証」等、融資を構成する条件が様々ある中で、貸せるか貸せないかも分からないうちに金利交渉だけ詰めてもまったく意味がないのです。
本来なら金利の前に担保を交渉するべきだったかもしれないし、そもそも条件交渉をせず、即お断りするべき案件かもしれません。

難しい融資になればなるほど手戻りは致命的で、状況によっては手戻りでは済まない（＝手戻りが許されない）場合もあります。
どういう状況かと言えば、断るべきタイミングで断っていないが為に、間違いとわかって融資実行せざるを得なくなるような状況です。

銀行組織は非常に硬直的な組織でありますが、そういった組織こそアジャイル的・スプリント的手法が必要なのかもしれません。