巨大なDXの潮流の中で、開発現場からできることはあるか
•
1 like•276 views
CNBF Meetup #4 登壇資料 https://speakerdeck.com/foobar3173/ju-da-nadxnochao-liu-nozhong-te-kai-fa-xian-chang-karatekirukotohaaruka
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 巨大なDXの潮流の中で、開発現場からできることはあるか
Similar to 巨大なDXの潮流の中で、開発現場からできることはあるか (20)
More from Daiki Kawanuma
巨大なDXの潮流の中で、開発現場からできることはあるか
- 1. 1 巨⼤なDXの潮流の中で、 開発現場からできることはあるか IBM Japan, Ltd. Daiki Kawanuma March 4th, 2021 CNBF Meetup #4
- 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 プラグマティズム プラグマティズムに全て集約できる気がする
- 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)
- 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% 安定より変化 アーキテクティングのサンプルケース
- 17. 17 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ ある要件に応じてシステムの変更を⾏うとき、要件が明確ではないものについて変更するか 現⾏の設計・実装を踏襲するかは⼀つの判断となるが、現⾏踏襲という判断をしている場合が少なからずある HW更改 画⾯刷新 UX向上 機能追加 リリース改善 • マネジメント⼿法 • ドキュメンテーション⼿法 • 開発標準 • システムアーキテクチャー • 使⽤ソフトウェア • コンポーネント設計 • クラス設計 • テスト標準 • リリースフロー etc 変更するか現⾏踏襲するか 判断が問われる 必要な変更 任意の変更 システム変更時の判断
- 18. 18 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ 現⾏踏襲は⾒かけ上はメリットが⼤きいように⾒えるが、それは現⾏設計・実装を直視していない場合が多い プラグマティズムの観点に⽴てば、盲⽬的な現⾏踏襲はメリットどころかリスクを⽣むことがわかる 現⾏踏襲の誘惑 プラグマティズムの観点 元々動いているものを再利⽤するので信頼性が⾼い 運⽤の知⾒が貯まっている（はず） • 現⾏の設計・実装は完全ではない • 運⽤の過程で少なからず課題が出てきているはず 既存のものがあるので⼀から設計・実装する必要がないので簡単 周辺環境／技術が変わっている • 以前とは前提・制約が変わっている場合も多い • 以前の考え⽅をそのまま適⽤するとむしろ負債が増える 変更すること／変更による失敗へのプレッシャー 要件が変わっている • その要件は今でも必要なものか • 今となっては不要な要件に縛られていることはないか 現⾏踏襲の誘惑とプラグマティズムの観点 Dev Prod Release entry dcd293ff Enter the hash of 1.10.2 不整合の余地がないようにリリースの仕組みの中で解決する 盲⽬的な現⾏踏襲の例 1.10.2 現⾏ではリリースしたモジュールが 不整合を起こしていないか1ヶ⽉に ⼀回チェックしています。 今回のシステム変更でもこれを 踏襲するようにします。 モジュールをチェックするのが要件なんだっけ…︖ Prod 現⾏の設計・実装は絶対ではない 合理的でない現⾏踏襲は負債を⽣む 変更しないことがバリューアップの阻害要因になる
- 19. 19 盲⽬的な現⾏踏襲はプラグマティズムと最も遠い考え⽅ 現⾏踏襲の誘惑に打ち勝ち、プラグマティズムを実践するには問題の捉え⽅を変える必要がある 昨今のテクノロジーの進化により、昔は受容するしかなかったことが解決できることに変わっている 現⾏の固定観念からのパラダイムシフト 現⾏の設計・実装 プラグマティックな解決法 ⽅針 許容できないことを補填するように設計・実装する 許容できないことを根本的に発⽣しないようにする 背景 テクノロジーが未発達だったため、 許容できないことを受容し、補填するしかなかった テクノロジーの進化で昔は仕⽅がなかったことが 解決できるようになってきている 10年前のテクノロジーで仕⽅がなく⼿でやっていた作業を踏襲することに意味は無い 盲⽬的に現⾏踏襲するのではなく、テクノロジーの進化を適切に使いましょう
- 21. 21 バリューアップとセットと考えるべきリファクタリング イケてなさ これやってみたら 解決するんじゃない︖ バリューアップの種は⼩さなモチベーション （誰しもがこういう場⾯を体験しているはず） でも、現実は… リファクタリングされていないコードを前に諦めることも多い ⼼理的負担 ⼤きな変更は不安・⾟い せっかくのモチベーションを台無しにしてしまう 作業的負担 コストが⾼過ぎてとてもやりきれない より現実的な⾯でも早期のリファクタリング着⼿が重要 1ヶ⽉間の負債 → 3⽇間 10ヶ⽉間の負債 → 30⽇間︖ リファクタリング⼯数の増加は線形ではない リファクタリングに 50⼈⽉当てたいと思います それだけで 50⼈⽉︕︖ リファクタリングに 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. 情報が散在している • 前提が複雑化・暗黙化し過ぎて理解困難 • ⻑い間放置され更新されていない • そもそもドキュメントが存在しない ドキュメントのリファクタリング⽅法論 構成管理⾒直していこうぜ 情報の所在も整理していこうぜ 中⾝もしっかり更新していこうぜ • ちゃんとやれる⼈とやれない⼈がいる • とりあえず…という誘惑があることは否めない • そこまでマネジメントし切れない Confluence - Atlassian • 作成／編集が楽しい • フィードバックがしやすい（コメント機能） • 検索がしやすい Box • 配置場所を変えてもリンクが切れない • ファイル名での検索可能 • コメント機能あり Fess - CodeLibs Project • 全⽂検索サーバー • Java 実⾏環境があればどのOSでも実⾏可能 • Apache ライセンスで提供され、無料で利⽤可能 Alfresco - Alfresco Software • コンテンツ管理システム • WindowsとUnix系OSで動作 • コミュニティ版はLGPで利⽤可能 ⼒こそパワー「使い勝⼿の良い SaaS を使う」 ドキュメントが腐るのはある程度 仕⽅がないので検索⼒でカバーです ドキュメントが腐るを受け⼊れる 解決策︓
- 26. 26 DX=DX(Developer Experience) バリューアップの種はメインのタスクを進める道中で芽⽣える これを開花させられるか、 それとも芽のままで枯らせてしまうのか その場で必須ではないもの だが、中⻑期的な成⻑には必要なもの イケてなさ これやってみたら 解決するんじゃない︖ バリューアップの種は⼩さなモチベーション（再掲） ※ 感覚的には7割くらいは枯らしてしまっているイメージ （それだけ潜在的なバリューアップの芽は存在する） 重要なのは鮮度とワクワク感 1. ツールが⽴ち上がらない・⽴ち上げるのに数分掛かる 2. ツールの使い⽅にそぐわない運⽤ 3. 社内プロキシー・NAT Docker⽴ち上げるとPCフリーズする Eclipseがなかなか⽴ち上がらない → 余裕ができたらでいいや 芽の開花を阻む様々な要因 オフラインで使おうとすると依存関係を⾃分で 解決して全てのモジュールを⼿で持ち込み → ⼿間が掛かるし、持ち込み申請が通る1週間〜2週間後には やりたかったことなど忘れている 技術難度が跳ね上がることが稀に良くある これを解決することだけに数⽇を費やすことも → ワクワクすることがいつの間にか⾟いことに変わっている
- 27. 27 DX=DX(Developer Experience) シャドー・エンジニアリング マネジメント側はいかに開発者を縛るかを考え、 開発者はその抜け道を探すことに労⼒を掛ける DockerCon EU 2015 より引用・改変 守りたいものの守り⽅ 縛るのではなく、啓蒙する・検知する 秘匿情報すべき情報を検知 OSS研修 道具（ツールやサービス等）を利用するのは「人」であることを理解し、常にリテラシーの 向上や教育を実施し、「人」に起因するセキュリティ事故をなくす（最小限にする）ようにする。 弊社の例 重⼤な脅威でない限り、縛るのではなく検知で⼗分な場合も多い まず第⼀に啓蒙する
- 28. 34 まとめ DXを”デジタルを活⽤したプラグマティズム”と捉えれば、今の環境でも出来ることはあるはず。 ⾃分たちの置かれた環境で実践できるプラグマティズムをまずは始めませんか︖ 今までも、こうしたほうが良い・こうあるべきだったことが、いよいよなくてはならないものに変わってきた。 DXという⾔葉がビジネスと開発を繋ぐ。プラグマティズムの意識が全社的に浸透する。 今こそ、これまで変えられなかったことを変えるチャンスかもしれない。 • ⾃分たちはどの程度バリューアップを⽬指すのか︖ • どこがバリューアップ・ポイントなのか︖ • 今やっていることは意味があるのか︖ • 掛けたコストに⾒合っているのか︖ • そこに何の価値があるのか︖
- 30. 36 Special Thanks • Satoshi Doi • Takuya Kojima ご清聴ありがとうございました。