SA Night #2 FinatextのSA思想/SA Night #2 Finatext session

https://finatext.connpass.com/event/341924/

Finatextのソリューションアーキテクトとして、多種多様な要件の金融サービスの開発プロジェクトに携わってきた経験をもとに、普段どのような思想をもって業務にあたっているかをお話しします。上流工程に携わっているSEの方やPM寄りのバックグラウンドを持つ方、あるいは「スクラム」や「Unified Process」に興味をお持ちの方にとって、ソリューションアーキテクトとしてのマインドセットの参考になれば幸いです。

Transcript

1. © 2013 - 2025 Finatext Ltd. CONFIDENTIAL FinatextのSA思想 Finatext, Fintech Shift team, Architect Satoshi Imai SA Night #2 0
2. © 2013 - 2025 Finatext Ltd. 1 Speaker • 筑波大学理学部数学科卒業後，総務省統計局で統計集計シス テムのシステムアーキテクトおよび統計調査企画実施を担当． 国連欧州経済委員会（UNECE）CPI専門家会合および物価指数 に関するオタワグループ会合に政府代表として参加するなど した． • 2015年に株式会社ナウキャストに参画． ナウキャストの創業プロダクトである日経 CPINow に新たにS 指数を加えて世に送り出す．その後データアーキテクトとし て投資家向けPOSデータソリューションの構築を担当． • 2020年より株式会社 Finatext に移籍し，Fintech SHIFT 事業に てアーキテクトとして活動中． • 三菱ＵＦＪ銀行の資産形成総合サポートサービス Money Canvas プロジ ェクトの総責任者 • 証券業，保険業におけるデータ活用を軸にしたシステム化コンサルタ ント
3. © 2013 - 2025 Finatext Ltd. 2 FinatextのSAの位置 • クライアントが実現したいシステムの方向性から，実現の要件化までが主たる責任範囲 • システムはクライアントのビジネスに貢献するものであるため，ビジネス及び業務に対する責 任的 contribution が必要 • ソフトウェアに対しては設計意図が反映されているかの総合的 supervise が必要 • 図表引用 • 室谷隆，「ソフトウェア開発の標準プロセス」，IPA SEC セミナー，2011-07-22，p25-28 • IPA SEC，「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」，2006 Supervise Contribute Drive Drive
4. © 2013 - 2025 Finatext Ltd. 3 ＳＡの責任範囲，Drive と Contribute が要するもの １：The only thing that is clear is that things change. • 「利害関係者」は具体的なシステム（結果）をみるまで，自分が何を求めているのかを完全には思い 描けない（ 「みればわかるんだけど」作用 [Barry Boehm, 1988]） • 統制適切に管理され，詳細化された精密な仕様は，ほとんどの「利害関係者」にとって心理的および 組織的に達成の難しい難問である [Kruchten, 2000] ２：Work expands so as to fill the time available for its completion • 作業は，完了までに使える時間を埋めるように延びていく[Parkinson 1958] すなわち， • 真に存在しないものはその時点では捉えられない • また，真に存在するものも常に動き続ける • 「クライアントの実現したいコト」をソフトウェアを介して実現することを Drive/Contribute するため， いかにクライアントの「思い描くコト」を 引き出せるか／見える化 できるか
5. © 2013 - 2025 Finatext Ltd. 4 ＳＡの責任範囲に技術力／技術背景がどう活きるか １：「知らないものは探さない」 • 候補としての実現手段の選択肢が事前に用意できていなければ，その実現手段を提案することはでき ない • 目に見えない，ましてや変わりゆく「クライアントの実現したいコト」を実現化するには，知ってい るコトの幅が必要になる ２：「車輪の再発明」 • 既にそこにあるモノが取り出せるものに多大な労力をかける必要はない • 「再発明」する価値がある／「再発明」する必要があるコトを見極める必要がある ３：「どんなに問題が巨大だとしても通せるパスは細くシンプルなパス」 • 大量のリソースを投入しようが何をしようが，breakthrough するのはA4 n 枚程度の情報量 • 弾幕の情報量は結局到達点には寄与しない • SAの根源的必要能力は，言語的能力であったり，共感力，巻き込み力であったりする が • 取りうる手段の豊富さとしての技術力／技術背景がなければ目的を達成できない • 取りうるパスの中で部分最適解にできるだけ短時間で到達し，これを反復する
6. © 2013 - 2025 Finatext Ltd. 5 思想背景と出発点 • 目的共有が優先，手段共有は次点 • 「名前をつけること」の effect/side-effect • 定義すること，論述することの発露と限界 • 手段・技術は用の術であって，目的最適化が必要 • 目的最適化（記述できないことへの対抗）と 変更耐性「あそび」（未来予知への対抗）の最適均衡点を探すのが仕事 真に存在しないものは その時点では捉えられ ない また，真に存在するも のも常に動き続ける 手段・技術は用 の術であって，目 的最適化が必要 目的共有が優先 手段共有は次点 「◦◦定義」 「〇〇設計書」 は手段であって 目的ではない 「名前をつけること」 の effect / side-effect 定義すること，論 述することの発 露と限界 反復のアウトプットは，テスト され，統合され，実行可能な 状態になったシステム（プロ トタイプではない） 動く，総体としてのシステムを 高速に反復改善していけばいい
7. © 2013 - 2025 Finatext Ltd. 6 思想背景と出発点 • 単一の遺伝子で構成された生命体は単一のウィルスで全滅する • 同一装備の２マンセル vs それぞれ専用装備の２マンセル • 専門性に根差した専業化・先鋭化 vs Specialty を活かした任務遂行 • できるかなじゃねぇ やるんだよ 真に存在しないものは その時点では捉えられ ない また，真に存在するも のも常に動き続ける 単一の遺伝子で構 成された生命体は 単一のウィルスで 全滅する 目的共有が優先 手段共有は次点 専門性に根差した 専業化・先鋭化 vs Specialty を活かした 任務遂行 同一装備の２マンセル vs それぞれ専用装備の ２マンセル 目的ではない ものはすべて 差し替え可能 目的に向かって動く セルの集合体としてのチーム できるかなじゃねぇ やるんだよ
8. © 2013 - 2025 Finatext Ltd. 7 Unified Process とスクラム • クライアントが実現したいシステムの方向性から，実現の要件化までが主たる責任範囲 • 真に存在しないものはその時点では捉えられないまた，真に存在するものも常に動き続ける • 取りうるパスの中で部分最適解にできるだけ短時間で到達し，これを反復する これらを所与の前提とすると • SAが依って立つのはスクラムでは手段に寄りすぎている • より上流も含めて視界を確保するという点で Unified Process の再発見が必要になる • その上で反復，アジャイルの Agility を高める手段がスクラムであるのは最適
9. © 2013 - 2025 Finatext Ltd. 8 Unified Process （参考） • UP • OOA/D (Object-oriented analysis and design) を実施するための古典的ソフトウェア開発プロセス． [Jacobson, etc., 1999] • UPを製品化したRUP(Rational Unified Process) [Kruchten, 2000] が代表的 • UMLはUPが提唱する視覚的ドキュメント化を実現する言語 • UPのコンセプト 反復的開発 • 開発を，短い固定した長さの連続するサブプロジェクトで編成する • 反復のアウトプットは，テストされ，統合され，実行可能な状態になったシステム（プロトタイプではない） • 変更を抑え込むのではなく，変更は避けられず，むしろ重要な開発進行要因であるとして許容，取り込む
10. © 2013 - 2025 Finatext Ltd. 9 UPのベストプラクティス（参考） • リスクが高く，重要度の高い箇所には早い時点の反復で取り組む • 利害関係者に，継続的に評価，フィードバック，要件定義に関与させる • 中核に位置するアーキテクチャを早い時期の反復で構築する • 継続的に品質を検査し，現実的なテストを早い時点から行う • ユースケースを適用する • ソフトウェアを視覚的にモデリングする（UML） • 要件を慎重に管理する [Backlog] • 変更要求管理と構成管理を実施する [Backlog and Git]
11. © 2013 - 2025 Finatext Ltd. 10 スクラムの原則（参考） • 経験的プロセスを管理する． スクラムでは透明性，検査力，適応力が重視されます． • 自己組織化する． スクラム開発には役割やルールがありますが，すべてのスクラムメンバーにタスクや 仕事の責任が課されます．スクラムでは，責任を共有することによってチームがよりクリエイティブで ダイナミックになると考えます． • コラボレーションする．スクラムスプリント中や終了後に協力し合うことで最大限の結果が得られます． • 価値観に基づいて優先順位を付ける． スクラムスプリントのゴールは，最高のビジネス価値を提供する ことです．そのためには，スクラムプロセスの最初から作業に優先順位を付ける必要があります． • 時間を区切る． スクラムプロセスにはスプリントそのものやデイリースタンドアップ，振り返りなど， 時間ベースのアクティビティが多数あります．スクラムは継続的な改善という信念を基に成り立ってい るため，次のタスクへと進み，仕事を改善していくために，仕事の時間を区切ることが重要です． • 反復的に開発する． スクラムでは，最初の製品は完璧なものではありません．しかし，反復的に開発を 行うことで，チームは顧客のニーズにうまく対応し，価値観に基づく優先順位に従って製品やアウトプ ットを変更できます．
12. © 2013 - 2025 Finatext Ltd. 11 「我々の間には，チームプレーなどという 都合のよい言い訳は存在せん． 有るとすればスタンドプレーから生じる チームワークだけだ．」 荒巻大輔
13. © 2013 - 2025 Finatext Ltd. 12 Finatextのアーキテクト職のポジションはこちらです！ •アーキテクト（フィンテックシフト事業） https://herp.careers/v1/finatexthd/oBmVDYz2BifB まずは話を聞いてみたい、という方はカジュアル面談からどうぞ！ •【共通】カジュアル面談 https://herp.careers/v1/finatexthd/vZWzSlI_B-qk アーキテクト募集中！