Navigation

2018年4月24日火曜日

FinTechにおけるシステム開発手法、アジャイルかウォーターフォールか

FinTechサービス開発におけるシステム開発手法はアジャイルかウォーターフォールかを考える際に、アプリケーションレベルであれば、下記でも言及されているようにまぁアジャイルよねとなるわけです。

産業・金融・IT融合に関する研究会(FinTech研究会)(第5回)‐議事要旨
http://www.meti.go.jp/committee/kenkyukai/sansei/fintech/005_giji.html

が、手法ありきではなく、どちらであってもしかるべき管理ができればいいのですが、どのような考え方をもとに、しかるべき手法と管理をすべきなのかと思いググってみましたが、参考になる記事をみつけました。

柔軟なウォーターフォールはアジャイルと見分けがつかない
http://arclamp.hatenablog.com/entry/2015/10/26/100000



上記を踏まえて、私が意識しているポイントは下記の点です。
・システム/ドメイン毎に手法を分けよう
・事前に決めなくてはいけないことで決められることは、決めよう(アーキテクチャ等)
・事前に決めなくてはいけないことで決められないことは、とりあえずイテレーションを回して段階的にきめていく
・事前に決めなくてもいいことは、イテレーションの中できめていく

スライド8ページで記載されているように、そもそも一定規模以上の会社はあらゆる面で計画を立て計画と実績の差異があった場合にその分析、説明を行うため、基本的に事前の計画を好み、変化を嫌います。その中で、変化を受け入れるアジャイルをどのように組み込んでいくがチャレンジでしょうし、うまく組み込めると、それはコピーのしずらい組織としてのコンピタンスになるのかなと思います。

一方でTechnologyの進化の影響をうけるFinTechにおいては、変化も激しいわけで長大な計画をたてサービスインに多大な時間をかけるとリリースした頃には陳腐化しているケースもあるでしょうし、まずはクイックにリリースできるものからリリースしていくアジャイルで進めざるをえないところもあるのかなと。

そうは言いましても、金融機関としてサービスを提供するならば、顧客保護、法令遵守、監査対応のためにも、計画と実績の記録、各ゲートでのしかるべき承認者の承認の証憑、文書化等、ウォーターフォール的なものは必要になるわけで、どこでバランスをとるのがいいのか考えなくてはいけないですね。

なお、同じブログ内の下記記事も参考になります。

アジャイルにおける事前合意について
http://arclamp.hatenablog.com/entry/2018/01/09/100002

アジャイル開発で行う上で便利なツールの一つとしてJIRAがあるのですが、下記ページで提供社のアトラシアンの直近の決算が説明されていて参考になります。

JIRAやTrelloで知られるアトラシアンの決算を毎回まとめる記事【NASDAQ:TEAM】
https://www.americabu.com/atlassian-earnings

競合とされているサービスナウの決算分析はこちら。ちなみに私は両方使ったことがありますが、完全にJIRAの方が好みです。

サービスナウ【NOW】ITサービスマネジメントを”超える”統合クラウドプラットフォーム
https://www.americabu.com/servicenow