業務改善原則を使った企画の重要性

Transcript

1. 私の考えた最 強????の アーキテクチャ 業務改善原則を使った企画 の重要性
2. わらわの 自己紹介  氏名:工藤 由美  所属:2月よりYumemiビジネスアーキテクトチーム  特技:抽象化、モデリング  趣味:音楽聴くor編曲、方法論構築  好き:ベビパンが⿁好き
3. 対象者 システム要件を満たすアーキテクチャを構築しているのにもかか わらず、ユーザーに実際に使われないなど、導入後の効果が いまいちと感じている方
4. 目的の方向性
5. 今日話すこと システム導入 案件の実情 ECRS原則 の説明 アジャイル文脈に おけるECRS事例 実際の使い方 の流れ
6. システム導入案件の実情
7. 企画・要求開発段階で検討不足 炎上しやすい案件では企画フェーズなど、 そもそもシステム要件定義前で躓いている。 例) システム化スコープの検討不足など そもそもシステム導入の目的は? →企業や組織の業務を効率化し、競争力を高めること。 決してシステム導入自体が目的ではないはず。 効率化できていなかったらシステム導入は逆効果。
8. 一貫性のない状態のDDD アプリケーションアーキテクチャは、たしかにDDDで 開発されているものの、ビジネスアーキテクチャはDDDで業務設計されてない。 つまり、ビジネスアーキテクチャと相似形でない。 その結果、業務を変えたいときに ・システム内部のどこを変えたらいいのか? ・そこを変えたときに業務のどこに影響が起こるのか? それらの追跡が非常に行いにくい。 システムスコープ以外の改善が行いにくい。
9. わたしの主張 最強のアーキなんてないです。 業務改善もせずに リファクタリングやらリアーキやら やることなかれ。
10. ベン図で表現したらこんな感じ
11. 注意事項 所々、前提すっ飛ばした用語あります。 わたしの愛嬌に免じて許してくどさい。 イベントストーミングとかの説明とかはがっつり端折ります。 用語とか聞きたい人は懇親会とかで聞いてください。
12. ECRS原則 の紹介
13. ECRSの 概要説明  業務プロセス改善のための4原則  DXなどの文脈では必須なもの  要件定義前で検討した上でシステム化範囲を決めるもの ※これらはモデル図などで可視化した上で行うこと。 業務フローをアクティビティ図で データの流れをDFDなどで描くなどして適用する。
14. 原則適用の順番の重要性
15. Eliminate （排除） 【概要】 不要な作業、ステップ、手順、リソースを排除することで、無駄を減ら し、プロセスを効率化する。 【目的】 作業の効率化と時間の節約を目指し、価値を提供しない活動を取 り除くこと。 無駄を排除することで、リソース(時間、エネルギー、資 金)を最も重要な部分に集中させることができる。 【具体例】 ・過剰なドキュメント作成を排除 ・無駄な会議の排除 ・不要な機能の削減(←戦術的フォークと呼ばれている)
16. ※でも排除できない理由がある、、、 ・普段は使わないユースケースで極まれに使用されるプロセスである。 ・利用頻度は低いものの、ビジネスインパクトが大きい。 だからこそのビジネスアーキの重要性 どの程度の頻度で、どのくらいの損失を生むのかなどのデータで検証。
17. Combine (統合or分割) 【概要】 蜜結合であるべき複数の作業・プロセスを結合 or 疎結合であるべきものを分割 することで無駄を省き、業務の効率を高める。 【目的】 重複する作業や相互に関連する作業を統合、または関連の薄い作業を分割 することで、リソースを有効に活用し、全体の時間やコストを削減すること。 【具体例】 ・ペアプログラミング ・BizDevOps ・大きくなり過ぎたコンポーネントやinterfaceの分割
18. Rearrange （再配置） 【概要】 作業やプロセスの順序を変更することで、効率や成果を向上さ せる。 【目的】 適切な順番でタスクを実行することにより、プロセスのスムーズな 進行を促し、無駄な待機時間や遅延を減らす。 順序を変えることで、作業のフローがよりスムーズになり、時間の 浪費やエラーの発生を最小限に抑えられる。 【具体例】 ・ユーザーストーリーの順番を再配置 ・事務作業の並べ替え
19. Simplify （簡素化） 【概要】 プロセスや作業を簡素化することで、効率的でわかりやすい方法で 作業を進める。企画段階ではここでシステム化スコープを検討。 【目的】 複雑さを減らし、作業の実行を簡単でスムーズにし、エラーを減らし て効率的に進めることです。シンプルで直感的な方法を取ることで、 チームの生産性を高め、問題解決が容易になります。(KISS原則) 【具体例】 ・デプロイメントプロセスの自動化 ・ユーザーが迷わず直感的に操作できるよう、シンプルなUIデザイン ・複雑なコードをシンプルにする
20. この一連の考え何かに似てませんか? クイズタイムです。 何に似てますか? 、、、、 ひらめきましたか? →リファクタリングの流れそのもの ECRSは業務リファクタリングの原則といっていい
21. 実はECRSは アジャイルの様々 な場面で使われ ている! TDD E+Sの事例 テスト自動化 ペアプロ C+Sの事例
22. テスト駆動開発(TDD) E無駄なコードの排除: テストが通るために必要最小限のコードの実装を重視する。 これにより、冗⾧なコードや不必要な機能を排除できる。 無駄なコードを事前に排除でき、コードの可読性と保守性が向上。 Cテストと実装の結合: テストと実装を密接に結びついて、テストを実装と共に進めることで、 コードの整合性を保ちつつ進めることができます。 R開発の順序を最適化: まず失敗するテストを書く(Red)、その後に最小限の実装を行い(Green)、リファクタリングを行うという順番で進めます。 Sコードの簡素化: TDDでは、リファクタリングを通じてコードを簡素化する。最小限の実装とシンプルなコード構造を維持することが重要であ り、これにより複雑なコードや不要なロジックを削減することができます。
23. テスト自動化 E 不要な手動テストの排除: 手動での反復的なテストや不要なテストプロセスを排除することで、 余計なテストコストを削減する。 C テストケースの統合: 複数の単体テストシナリオを1つの統合テストに。 R テスト実行順序の最適化: 最も重要なテストケースや頻繁に変更される機能のテストを優先して実行 S テストプロセスの簡素化: 自動化されたテストフレームワークを使用することで、テストの設定、実行、報告の手順を簡素化
24. CI/CD E 冗⾧なビルド・テストの排除: 同じテストやビルドを何度も繰り返すことを排除し、 変更部分のみをビルド・テストすることで、無駄なリソース消費を削減。 C 複数のプロセスの統合: CI/CDパイプラインは、コードのビルド、テスト、デプロイなどのプロセスを一連の流れとして統合。これにより、変更を加えた コードの品質を早期に検出できます。 R プロセスの順序変更: 最初に静的解析や単体テストを実行し、問題なければ次に統合テスト、最終的にデプロイメントを行う。 S プロセスの簡素化: CI/CDによって複雑なビルド・デプロイの手順を自動化し、簡素化できます。これにより、開発者や運用チームが手動で 行っていた作業を減らし、ミスを防ぎます。
25. ペアプログラミング E無駄なコミュニケーションの排除: 二人の開発者が密にコミュニケーションを取りながら進めるため、 理解のズレや無駄な修正を減らすことができます。 最初からコードに対する合意形成ができるため、後で発生する無駄なやり直しを排除できます。 C知識の共有と統合: 二人の開発者が同じコードを同時に作成するため、コードやアイデアを即座に統合できます。 R作業フローの最適化: コードを2人で交代で書きながら進めるため、作業のフローが柔軟に再配置できる。 Sコードの簡素化: 2人の開発者が常にコードの品質をチェックしながら進めるため、コードがシンプルで直感的になることで、保守性が向上し、将来的な変更も容易になります。 他にもいろいろな文脈で使われてる。
26. 具体的な 業務改善の流れ 【流れの概要】 何でもECRSを適用すればいいわけではない。 ボトルネック部分に対しての解決策として、 ECRSを適用し、効果測定をして、 成功事例を積み上げていく。
27. 前提条件 システム導入前に業務モニタリング基盤を整える →まずはDDD業務モデリング →制約部分をみつける →そこにECRSを適用
28. ①イベントストーミングで全体像把握 イベントストーミングで業務プロセス全体をマクロに把握する。 ※各イベントの抽象度は必ず揃うように。(SLAP原則守る) もしわからなかったら一段階詳細化して、また前提の抽象に戻って検証。 【理由】 おおよそのボトルネック特定したい&関心が分離されたモデリング手法だから。 →ボトルネック部分をさらに詳細化(プロセス構造を抽象度揃えて)
29. ②AsIsの業務フロー可視化 ①で出したマクロなイベントのボトルネック 周りの現状の業務をモデル図で可視化。 オススメは図のようにアクティビティ図で。 注意) どの抽象度のフローでも 事前条件、事後条件、不変条件 は必ずマストで定義しておかないと、 後工程で手戻るので要注意。 →理由は次
30. 【契約による設計】 最初の•に事前条件 最後の•に事後条件 このフロー中で常に満た すべき条件を不変条件 として定義! この定義を忘れると、 interface定義が アンポンタンなものになる。
31. ③モニタリングツールで現状測定 現状の業務プロセスの指標を BPMツールなどを用いて計測する。 図のような代表的な指標は、 テンプレートとしてツールにあるので、 お好みのものを自分たちで選ぶ。 (引用元: 上級SEのためのビジネスモデリングテクニック) ※起動タイミング&頻度あたりの指標は、 業務の可用性という感じで、ビジネスから品質を考慮しておくと、システムに求められる重要品質特性が浮き彫りになりやすい。
32. ※モニタリング基盤 システムの要件定義には、システム構築後に確実に業務改善できるようにするため、 KPI(プロセスの指標)のモニタリングの仕組みが埋め込まれている状態を目指す。 (理由) 構築後にモニタリング基盤埋め込んでも、 システム導入による定量的効果は見えないため。 システム構築後は、効果獲得とKPI改善に集中できるようにする。
33. ④ボトルネックの発見 指標を見ながらどこがボトルネックか? を定量的に判断しましょう。 ・想定以上にコストがかかっている箇所 ・想定以上にパフォーマンスが遅い箇所 など、 全体的に見て想定をはるかにズレた 指標が必ずあります。
34. ⑤ToBeモデルを作成 ボトルネック解消後にどうなっていてほしいのか 仮説ベースのモデルを作成。 (データと機能両方の静的動的モデルで) & ざっくりした数値でいいから 「このくらいになってほしい」という定量化。 (③のモデル値というところ) 注)ToBeを先かAsIs先なのかは状況による。 自律してる組織とかはAsIsベースがベター。
35. ⑥ボトルネック部分にECRS適用&効果測定 ボトルネック部分にターゲットを絞って、 ECRS原則を適用して、業務改善を行う。 一気にECRSをやるのでなく、 実験的に小さいプロセスに対して、 指標を常に見ながら段階的に ECRSを適用し、都度効果を定量チェックする。 (そのためにも各プロセスの抽象度合わせた構造化がマスト) ※EやCからできない時には、Sから始めてみる。その後Eを行う。
36. ※ビジネス層で品質を明らかに 想定していない状況をあえて再現とか、 あえて負荷をかけるなどの実験も行ってみることで、 かなり前段階のビジネスにおいて重要な品質が判明する。
37. 参考書籍 ビジネスモデリングやログデータ どの組織に対して責務を持たせるのか? といったことが網羅されている古書。 RDRAなどとセットで用いると効果大。 今日持ってきたよ♪
38. まとめ ECRS原則はあらゆるフローに対して有効。 このプロセス毎回めんどいな～ 毎回ここでつまるな という部分があれば、 いきなり自動化せずに、まずはECRSの順でやってみてください。 【俳句】 ビジネスの カイゼンしないと 冬が来る(いろんな意味で)
39. ありがとうございました X:アジャイルアーキテクト Qiita:せやかて駆動 Kudo_panda