【講演資料】「巨大なDXの潮流の中で、開発現場からできることはあるか」

川沼 大輝　　日本IBM　アソシエート・アーキテクト
ーー
昨今のDXの流行は特筆するまでもなく明らかです。
ですが、多くの論説でDXの問題と位置付けられているのは組織構造や雇用形態といった社会の大きな仕組みであることが多く、開発現場から起こせるアクションは微々たるもののように思えます。しかし本当にそうでしょうか？
実際にシステムのアーキテクチャやソースコードと向き合っている現場だからこそ進められるDXもあるはずです。
本セッションではエンタープライズシステムの開発に携わった自身の経験を元に、実際の開発現場で起こりがちな課題は何なのか、現場からできるDXはどんなことなのかを考察します。

Transcript

1. 1 巨⼤なDXの潮流の中で、 開発現場にできることはあるか IBM Japan, Ltd. Daiki Kawanuma March 4th, 2021 CNBF Meetup #4
2. 2 本セッションは私⾃⾝の⾒解であり、 所属組織の⽴場、戦略、意⾒を代表するものではありません。 また、技術的な内容にも⾔及しますが、正確性を保証するものではありません。 免責事項
3. 3 昨今のDXの潮流は明らか https://www.nikkei.com/article/DGXZQODF235CP0T21C20A2000000 https://www.publickey1.jp/blog/20/cloud_native_computing_foundation.html https://www.meti.go.jp/shingikai/mono_info_service/digi tal_transformation/20180907_report.html 2018年に経産省が発表した『DXレポート』を⽪切りに、各企業でDX推進の動きが盛んになっている
4. 4 ⽇本におけるDXの定義 【DXシナリオ】 2025年までの間に、 複雑化・ブラックボックス化した既存システムについて、 廃棄や塩漬けにするもの等を仕分けしながら、必要 なものについて刷新しつつ、 DXを実現することにより、2030年実質GDP130兆円超の押上げを実現。 DXレポートのインパクトが⼤きすぎて『DX=レガシーシステム刷新』という局所的な解釈が主流になってしまった 「DXレポート」から抜粋 「DXレポート 2 中間取りまとめ」から抜粋 「DX＝レガシーシステム刷新」など、本質でない解釈を ⽣んでしまった
5. 5 本セッションで取り上げるDXの定義 本セッションではDXを「デジタルを活⽤したプラグマティズム」と定義する プラグマティズム • 「実⽤主義」「実際主義」「⾏為主義」 • 物事の真理を「理論や信念からではなく、⾏動の結果によって判断しよう」という思想 【DXらしいフレーズ】 いくつもの新しいサービスを世に出していく必要がある。 １００個ローンチして１個生き残る感覚。 by 某企業エグゼクティブ 「とりあえず、やってみる。出来たら、うれしい。 出来なかったら、忘れる。また、やってみる。この繰り返しです」 by 宮崎駿 「最小限の実用的な成果物」を目的とし、進化させ続ける。 by ガートナー 「素早く」変革「し続ける」能力を身につける。 by 経産省 プラグマティズム 日本的思考 真理 異なる意見にも耳を傾け、仮説の検証に よる探究のプロセスを共同で行う 「個」の主張が弱く、意見をぶつけるよりも 空気を読んで同調する 事象 目の前の事象に対して、その場で考えう る上手くいく方法を選択する 事象に対したときに、責任を自身ではなく他 者や組織に転嫁できる選択を取る 対立 対立しているものの中から「相互作用」を 見出し、解決していく 調和を求める傾向が強い一方で、和を乱す ものを排除する風潮が強い 失敗 マイナスではなく、すべてを人生の糧と考 える 禊をするなど、失敗は取り払うべきと捉える 超大国アメリカを支える思想「プラグマティズム」入門 ( https://president.jp/articles/-/20609 ) MVP アジャイル Cloud Native DevOps SRE デザイン思考 AI プラグマティズム プラグマティズムに全て集約できる気がする DX
6. 6 本セッションでお伝えしたいこと 開発現場からできるDXはプラグマティズムを実践することではないか︖ https://digital-shift.jp/digital_hr/200326 https://comemo.nikkei.com/n/n360cc11aadea DXの問題と位置付けられているもの多くは雇⽤形態や組織構造 現場レベルで出来ることは何もないのだろうか︖ DXを「デジタルを活⽤したプラグマティズム」と位置付ければ、現場からできることも⾒つかってきそう 今まで現場で悶えていたこともプラグマティズムで説明ができそう 現場からできるDX＝プラグマティズムを⽰したい
7. 7 ⾃⼰紹介 Daiki Kawanuma Associate Architect, Red Hat Certified Specialist, AWS Certified Solution Architect 所属 役割 レガシーアプリを適切にモダナイゼーションする 働き⽅ 半年から数年程度でお客様を渡り歩く “遊撃隊“ のような働き⽅ IBM Japan, Ltd. Cloud Application Services, Modernization Strategy ⾦融系 ⾦融系 保険系 運輸系 ⾦融系 プロジェクト遍歴
8. 8 プラグマティズムの具体例 現場で体験したプラグマティックではないものを集めてみた 1. プラグマティックなアーキテクチャとは何か 2. 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ 3. バリューアップとセットと考えるべきリファクタリング 4. DX=DX(Developer Experience) 5. 完全なテストをやり切るという虚無な理想
9. 9 1. プラグマティックなアーキテクチャとは何か
10. 10 プラグマティックなアーキテクチャとは何か コンテナや Microservice といった⽅法論を実践すれば DXに適合したアーテクチャになるのか︖ΜͳΘ͚ͳ͍ プラグマティズム（⾏動的・実践的）なアーキテクチャとは何か ラン・ザ・ビジネス バリューアップ 全社戦略 サービスごとの戦略 バリューアップ ラン・ザ・ビジネス どの程度変えるか どこを変えるか 画⾯ 連携 パフォーマンス 精度 システム・サービスごとに異なる これを決めるのが”プラグマティックな”アーキテクティング • Try & Error を繰り返して継続的に改善していく • システムのライフサイクルを変える • どの程度ライフサイクルを変えれば良いのか︖ • どの部分のライフサイクルを変えれば良いのか︖ システム・サービスごとに適した⽐率があるはず システム・サービスごとにバリューアップはポイントは異なる
11. 11 プラグマティックなアーキテクチャとは何か エンドユーザーとのタッチポイントであり、歴史の⻑いシステムとの接続部でもある SoE(System of Engagement) と SoR(System of Records) のはざま領域 ここでは、ユーザーとのタッチポイントである画⾯系をバリューアップのポイントと仮定する エンドユーザー バックエンドシステム ⾃部⾨サービス SoE バリューアップ SoR ラン・ザ・ビジネス ︖︖︖ ライフサイクル︓ 5年〜10年塩漬け SLO︓ 99.999%〜99.9999% 失敗より不変 ライフサイクル︓ 1週間〜1ヶ⽉でリリース SLO︓ 〜99.99% 安定より変化 アーキテクティングのサンプルケース
12. 12 プラグマティックなアーキテクチャとは何か ① 今のビジネスを変えずに⾛り続けます エンドユーザー バックエンドシステム ⾃部⾨サービス 従来のアーキテクチャを⼤きく変えることなく、コスト最適化（リホスト／リフト等）のみ実施する SoE バリューアップ SoR ラン・ザ・ビジネス
13. 13 プラグマティックなアーキテクチャとは何か ② UIの魅⼒で他社と差別化します エンドユーザー バックエンドシステム ⾃部⾨サービス GW SPA API API SPA SPA SPA APIとGWのライフサイクルは バックエンドに引きずられてしまう APIの機能に収まる範囲で 主に画⾯系の改善を早いライフサイクルで回す 主たる機能は従来のライフサイクルを踏襲しつつ、主に画⾯系の改善を早く回すことでUX向上を⽬指す SoE バリューアップ SoR ラン・ザ・ビジネス
14. 14 ③ 魅⼒的なUIと洗練された機能で他社にないUXを実現します プラグマティックなアーキテクチャとは何か エンドユーザー バックエンドシステム ⾃部⾨サービス GW SPA SPA SPA SPA 画⾯と機能の両⽅の改善を 早いライフサイクルで回していく API API API API SaaS等 機能拡充の要件に合わせて SaaS等との接続も⾏う 機能⾯でも早いライフサイクルでの改善が可能なように、⾃部⾨サービスで機能拡張できる⾃由度を設ける SoE バリューアップ SoR ラン・ザ・ビジネス
15. 15 プラグマティックなアーキテクチャとは何か ④ ⾃社サービスの洗練は勿論のこと、他社サービスとの連携も拡⼤して事業を成⻑させます エンドユーザー バックエンドシステム ⾃部⾨サービス GW SPA SPA SPA SPA BFF BFF BFF BFF 他サービス API API SaaS等 API公開によるラン・ザ・ビジネス拡⼤と、ライフサイクルを早めたバリューアップの両⽅を実現する SoE バリューアップ SoR ラン・ザ・ビジネス
16. 16 2. 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅
17. 17 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ ある要件に応じてシステムの変更を⾏うとき、要件が明確ではないものについて変更するか 現⾏の設計・実装を踏襲するかは⼀つの判断となるが、現⾏踏襲という判断をしている場合が少なからずある HW更改 画⾯刷新 UX向上 機能追加 リリース改善 • マネジメント⼿法 • ドキュメンテーション⼿法 • 開発標準 • システムアーキテクチャー • 使⽤ソフトウェア • コンポーネント設計 • クラス設計 • テスト標準 • リリースフロー etc 変更するか現⾏踏襲するか 判断が問われる 必要な変更 任意の変更 システム変更時の判断
18. 18 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ 現⾏踏襲は⾒かけ上はメリットが⼤きいように⾒えるが、それは現⾏設計・実装を直視していない場合が多い プラグマティズムの観点に⽴てば、盲⽬的な現⾏踏襲はメリットどころかリスクを⽣むことがわかる 現⾏踏襲の誘惑 プラグマティズムの観点 元々動いているものを再利⽤するので信頼性が⾼い 現⾏の設計・実装は絶対ではない 運⽤の知⾒が貯まっている（はず） • 現⾏の設計・実装は完全ではない • 運⽤の過程で少なからず課題が出てきているはず 既存のものがあるので⼀から設計・実装する必要がないので簡単 合理的でない現⾏踏襲は負債を⽣む 周辺環境／技術が変わっている • 以前とは前提・制約が変わっている場合も多い • 新しい技術の登場で出来ることも増えている 変更すること／変更による失敗へのプレッシャー 変更しないことによるリスクをより重く⾒る 要件が変わっている • その要件は今でも必要なものか • 今となっては不要な要件に縛られていることはないか 盲⽬的な現⾏踏襲の例 現⾏踏襲の誘惑とプラグマティズムの観点 1.10.2 現⾏ではリリースしたモジュールが 不整合を起こしていないか1ヶ⽉に ⼀回チェックしています。 今回のシステム変更でもこれを 踏襲するようにします。 モジュールをチェックするのが要件なんだっけ…︖ Dev Prod Release entry dcd293ff Enter the hash of 1.10.2 不整合する余地がないようにCI/CD の仕組みの中で解決する Prod
19. 19 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ 現⾏踏襲の誘惑に打ち勝ち、プラグマティズムを実践するには問題の捉え⽅を変える必要がある 昨今のテクノロジーの進化により、昔は受容するしかなかったことが解決できることに変わっている 現⾏の固定観念からのパラダイムシフト 現⾏の設計・実装 プラグマティックな解決法 ⽅針 許容できないことを補填するように設計・実装する 許容できないことを根本的に発⽣しないようにする 背景 テクノロジーが未発達だったため、 許容できないことを受容し、補填するしかなかった テクノロジーの進化で昔は仕⽅がなかったことが 解決できるようになってきている 10年前のテクノロジーで仕⽅がなく⼿でやっていた作業を踏襲することに意味は無い 盲⽬的に現⾏踏襲するのではなく、テクノロジーの進化を適切に使いましょう
20. 20 3. バリューアップとセットと考えるべきリファクタリング
21. 21 バリューアップとセットと考えるべきリファクタリング イケてなさ これやってみたら 解決するんじゃない︖ でも、実際は… リファクタリングされていないコードを前に諦めることも多い ⼼理的負担 ⼤きな変更は不安・⾟い ͔ͤͬ͘ͷϞνϕʔγϣϯΛ୆ແ͠ʹͯ͠͠·͏ 1ヶ⽉間の負債 → 3⽇間 10ヶ⽉間の負債 → 30⽇間︖ リファクタリングに 30⼈⽉当てたいと思います それだけで 30⼈⽉︕︖ リファクタリングに 10%当てたいと思います そういう活動 ⼤事だよね バリューアップの種は⼩さなモチベーション 作業的負担 コストが⾼過ぎてとてもやりきれない （誰しもがこういう場⾯を体験しているはず） より現実的な⾯でも早期のリファクタリング着⼿が重要 リファクタリング⼯数の増加は線形ではない マネジメント側との同意も厳しくなる
22. 22 バリューアップとセットと考えるべきリファクタリング 従来のアプローチ システム全体のリファクタリングを頑張るのは（たぶん）無理 頑張ったところで効果も薄い 1年に1回しか変更しないような箇所に 多⼤な⼯数を掛けますか︖ 頑張るべき箇所はやはりバリューアップ・ポイント 画⾯ 連携 パフォーマンス 精度 進化させ続けたい箇所こそ注⼒してリファクタリングを⾏う どこのリファクタリングに注⼒するか 最初に全体のリファクタリングを⾏うが、 全部は到底直し切れない リファクタリングされきらないまま 無理やり進む 開発完了 その後は直されない 初期状態（負債が溜まっている） 1. すべてを対象にリファクタリングしようとしている 2. ⻑期間にわたって負債を溜めすぎている
23. 23 ⼩さなリファクタリング ⼤きなリファクタリング 実装作業と並⾏してリファクタリングを⾏う • コードリーディング時に理解のためにリファクタリングする • 機能追加時にリファクタリングする • コードレビューの時にリファクタリングする • バグフィックス時にリファクタリングする ⻑期休み（夏休み・冬休み）前などにリファクタリングを⾏う バリューアップとセットと考えるべきリファクタリング ⼀連の実装過程で⾃然に⾏うのが良い ⼯数の⾒積もり・割り当て⽅ A機能 実装 R B機能 実装 R C機能 実装 R タスクごとにリファクタリング⼯数を積むと ⾒積もりが肥⼤化してしまう A R B R C R 個⼈ごとにリファクタリングバジェットを割り当てる → ⾜りない分は⼤きなリファクタリングに積む 1 2 3 4 5 6 7 8 9 10 11 12 R R 実際のリファクタリング・サンプルケース バックログに積むなどして管理・可視化できると良い
24. 24 • 新任者が着任してくる • 新任者には現⾏の固定概念を覆す改善を期待できる • 新任者が理解しやすいドキュメント整理が重要になる バリューアップとセットと考えるべきリファクタリング 新任者が理解しやすいドキュメント整理 M:¥庶務¥座席表¥PC管理台帳.xlsx 放置するとドキュメントも腐る 1. 構成管理が時間経過によって崩れている 探すとき”座席表”配下は おそらく⾒ない 3. 内容が複雑化・劣化・消失 2. 情報が散在している ⼒こそパワー「使い勝⼿の良い SaaS を使う」 Confluence - Atlassian • 作成／編集が楽しい • フィードバックがしやすい（コメント機能） • 検索がしやすい Box • 配置場所を変えてもリンクが切れない • ファイル名での検索可能 • コメント機能あり Fess - CodeLibs Project • 全⽂検索サーバー • Java 実⾏環境があればどのOSでも実⾏可能 • Apache ライセンスで提供され、無料で利⽤可能 ドキュメントが腐るのはある程度 仕⽅がないので検索⼒でカバーです ドキュメントのリファクタリング • 前提が複雑化・暗黙化し過ぎて理解困難 • ⻑い間放置され更新されていない • そもそもドキュメントが存在しない ドキュメントのリファクタリング⽅法論 構成管理⾒直していこうぜ 情報の所在も整理していこうぜ 中⾝もしっかり更新していこうぜ • ちゃんとやれる⼈とやれない⼈がいる • とりあえず…という誘惑があることは否めない • そこまでマネジメントし切れない 解決策︓ Alfresco - Alfresco Software • コンテンツ管理システム • WindowsとUnix系OSで動作 • コミュニティ版はLGPで利⽤可能 ドキュメントが腐るを受け⼊れる
25. 25 4. DX=DX(Developer Experience)
26. 26 DX=DX(Developer Experience) バリューアップの種はメインのタスクを進める道中で芽⽣える これを開花させられるか、 それとも芽のままで枯らせてしまうのか 重要なのは鮮度とワクワク感 その場で必須ではないもの だが、中⻑期的な成⻑には必要なもの 1. ツールが⽴ち上がらない・⽴ち上げるのに数分掛かる 2. ツールの使い⽅にそぐわない運⽤ 3. 社内プロキシー・NAT Docker⽴ち上げるとPCフリーズする Eclipseがなかなか⽴ち上がらない → 余裕ができたらでいいや イケてなさ これやってみたら 解決するんじゃない︖ バリューアップの種は⼩さなモチベーション（再掲） ※ 感覚的には7割くらいは枯らしてしまっているイメージ （それだけ潜在的なバリューアップの芽は存在する） 芽の開花を阻む様々な要因 オフラインで使おうとすると依存関係を⾃分で 解決して全てのモジュールを⼿で持ち込み → ⼿間が掛かるし、持ち込み申請が通る1週間〜2週間後には やりたかったことなど忘れている 技術難度が跳ね上がることが稀に良くある これを解決することだけに数⽇を費やすことも → ワクワクすることがいつの間にか⾟いことに変わっている
27. 27 DX=DX(Developer Experience) シャドー・エンジニアリング マネジメント側はいかに開発者を縛るかを考え、 開発者はその抜け道を探すことに労⼒を掛ける 守りたいものの守り⽅ 縛るのではなく、啓蒙する・検知する 秘匿情報すべき情報を検知 OSS研修 道具（ツールやサービス等）を利用することは「人」であることを理解し、常にリテラシーの 向上や教育を実施し、「人」に起因するセキュリティ事故をなくす（最小限にする）ようにする。 弊社の例 DockerCon EU 2015 より引用・改変 重⼤な脅威でない限り、縛るのではなく検知で⼗分な場合も多い まず第⼀に啓蒙する
28. 28 5. 完全なテストをやり切るという虚無な理想
29. 29 完全なテストをやり切るという虚無な理想 更改 リリース ⼤規模に⼈員投⼊ ⻑期間テスト実施 打鍵 パッチ 影響範囲調査 テスト要項書作成 打鍵 本番適用 完全な品質担保は可能なのか︖ 完全な影響範囲調査は可能なのか︖ 従来のテストに対するアプローチ
30. 30 完全なテストをやり切るという虚無な理想 コスト 品質 完全な品質担保が不可能なのは 直感的に分かるはず が、コストの範囲で 限りなく完全な品質担保を求められる • そもそも完全な品質担保は無理なのと、 • テストを追求すればするほどコスパが悪くなっていくので、 荒いバグは無くした上で 10%のユーザーに限定公開 (カナリアリリース) 駄⽬だったら瞬時に切り戻し (B/Gデプロイメント) 7.x → 8.x 1.19.x → 1.20.x • 完全な影響範囲調査は不可能という前提の元、 • リリースノートとは別の影響調査を講じる そもそもリリースノートを全て洗い出せば影響範囲調査できるのか︖ リリースノートに基づく ホワイトボックステスト CIによる無影響確認 完全なテストは可能なのか︖ 完全な影響範囲調査は可能なのか︖
31. 31 どこのテストに注⼒するか（再掲） 完全なテストをやり切るという虚無な理想 システム全体のテストを頑張るのは（たぶん）無理 頑張ったところで効果も薄い 1年に1回しか変更しないような箇所に 多⼤な⼯数を掛けますか︖ 頑張るべき箇所はやはりバリューアップ・ポイント 画⾯ 連携 パフォーマンス 精度 進化させ続けたい箇所こそ注⼒してテストを⾏う プラグマティックなテスト・影響調査 この場合、APIの廃⽌や特定パラメーターの挙動変更もしくはバグ混⼊ などでない限り、”基本的に” 既存のコンテナは動く「はず」 でも万⼀があって困る機能は⼯数と時間を掛けてでも確認する 1.19.x → 1.20.x まさか乗っているコンテナ全部テストしませんよね︖ 論理的にはここを確認すれば⼤丈夫な「はず」 ＋ サービス影響が⼤きい箇所 プラグマティック できる限り「全部」 ＋ どの機能も同じ⽐率の⼯数・時間 盲⽬的 上記に加えて、 もし、テスト⾃動化・CI が⼗分に⾏われていれば、 安価なコストで “⼤丈夫な「はず」” をより担保できる おそらく影響は無い「はず」だけど、 主要なコンテナはテスト流しておくかー ポチッ
32. 32 完全なテストをやり切るという虚無な理想 https://www.slideshare.net/brikis98/how-to-test-infrastructure-code-automated-testing-for-terraform-kubernetes- docker-packer-and-more コスト ⾃動化 容易性 更改(5年毎) 継続的なリリース(1ヶ⽉毎) できるか︖ CI はあったら良いものから 絶対に必要なものに変わる ⾃動化に掛けた⼯数は ペイするの︖ CI 当然やるよね︖ テストのピラミッドを意識する 下位の⾃動化されたテストの結果が担保された上で、より上位の複雑なテストを必要な箇所に⾏う CIの重要性・必要性 効果的なCI戦略
33. 33 完全なテストをやり切るという虚無な理想 1. ⼿動テストは無くならない 全てを⾃動化しようとしてはいけない e2eテストは結合テストは⾃動化のコストが⾼いので、 ⼿動テストを効率化する補助的な⾃動化に留める 逆に、静的解析や単体テストは出来る限り完全な⾃動化を⼼掛ける (周辺ツールが整っており⾃動化が⽐較的容易) ⾃動化のコストが⾼い ⾃動化のコストが低い 2. CIは常に実⾏し続けることに意味がある テストを書いてCIパイプラインを作ったら終わりではない そこがスタートになる 誰も結果を⾒ていなくて放置されているCIでは意味がない 3. テストコードを保守する覚悟が必要 テストは保守しないと腐っていく テストコードそのものを保守していく（＝⼯数に含める）覚悟が必要 CIを推すからこそ分かっていてほしいこと
34. 34 まとめ DXを”デジタルを活⽤したプラグマティズム”と捉えれば、今の環境でも出来ることはあるはず。 ⾃分たちの置かれた環境で実践できるプラグマティズムをまずは始めませんか︖ 今までも、こうしたほうが良い・こうあるべきだったことが、いよいよなくてはならないものに変わってきた。 DXという⾔葉がビジネスと開発を繋ぐ。プラグマティズムの意識が全社的に浸透する。 今こそ、これまで変えられなかったことを変えるチャンスかもしれない。 • ⾃分たちはどの程度バリューアップを⽬指すのか︖ • どこがバリューアップ・ポイントなのか︖ • 今やっていることは意味があるのか︖ • 掛けたコストに⾒合っているのか︖ • そこに何の価値があるのか︖
35. 35 それ、プラグマティックですか？
36. 36 Special Thanks • Satoshi Doi • Takuya Kojima ご清聴ありがとうございました。