Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイルとユースケース駆動開発を統合したプロセスを実践してみた

 アジャイルとユースケース駆動開発を統合したプロセスを実践してみた

2022/11/16(水)にDLLABにて登壇した「エンタープライズAIとモダンアプリケーション開発の実践~ISID✕Microsoft~ #2」の発表スライドです

AITC - DENTSU SOKEN

November 17, 2022
Tweet

More Decks by AITC - DENTSU SOKEN

Other Decks in Technology

Transcript

  1. 2 自己紹介 所属: 電通国際情報サービス クロスイノベーション本部 AIトランスフォーメーションセンター 経歴: 2015年3月:大学卒業(学部 2015年4月:新卒でとあるSIerへ入社し、 Azureベースの機械学習システム導入案件を推進

    2020年2月:ISIDへ中途入社 現在は、顧客支援と並行してAIを使った自社サービス開発に尽力中 業務: 機械学習システム開発・導入、自社のAIソフトウェアの開発、主にAzureによる アーキテクチャ設計 Qiita : https://qiita.com/tamitarai 趣味: コーヒー、ウィスキーなど 御手洗 拓真
  2. 6 宣伝 自分が所属する製品開発グループのメンバーと 『アジャイルとスクラムによる開発手法: Azure DevOpsによるプロフェショナルスクラムの実践』 という書籍を翻訳出版。Azure DevOpsを使うなら必読、それ以外の方にも良い本。 ◼ 基本的なコンセプト

    ➢ スクラムの原理原則だけではなく、実践的なプラクティス を押し付けない形で紹介している(意外と無い) ➢ Azure DevOpsの単なる使い方ではなく DevOpsへの批判 も込みで「スクラムで使うならこうなら、ここをこう使え。 これは使うな。」という内容を紹介 ◼ 学べる内容は、以下のとおり ➢ スクラムの実践的なプラクティスと取捨選択の基準と、体 系と紐づけて理解できる ➢ Azure DevOpsのとても便利な使い方がよくわかる
  3. 11 大事な前提 こ の 物 語 は フ ィ ク

    シ ョ ン で あ る 。 全て、架空のAI製品開発チームのお話
  4. 14 書籍との違い 書籍の前提 現実の制約 PO 専任 案件で6割以上稼働 十分な権限 開発する機能の決定にはPOの上司やマネジメント会議で の合意が必要

    スクラムマス ター 専任 不在(開発メンバーが兼任) 開発チーム 基本、自律して動けるエンジニア 完全に自律して動けるのは2/3 良し悪しは別にして書籍で置かれている前提とは以下のような違いがあった
  5. 16 生じていた問題たち 以下のような問題がなかなか解消しなかった バックログの管理が しきれない 頭のなかだけにある 詳細な製品仕様 開発メンバーを増や しづらい状況 問題

    バックログの管理コストが高く、かつPOも専任ではなかったこと から、メンテナンスされないまま数百も積み上げられ、どこから どう手をつけるべきか分からない状況 とにかく動くものを作ることを優先していた結果、ドキュメント が断片的にしか存在しておらず、製品の全体像から細かい仕様ま で開発メンバーに聞かないとわからない。 上の二つから帰結するが、設計や実装方針などが整備されていな いため、新規メンバーのキャッチアップコストがあまりにも高い 概要
  6. 17 なぜ解消が難しかったのか? スクラムの条件を満たしていなかったため、スクラムの枠組みで解決が難しかった バックログの管理 がしきれない 頭のなかだけにあ る詳細な製品仕様 開発メンバーを増 やしづらい状況 問題

    • POがメンテナンスする 時間を取れない • どうメンテナンスすべ きか分からない • インクリメントの開発 を優先しドキュメント を作成しなかった • 設計書や開発方針のド キュメントが無いため新 メンバーがジョインしづ らい 原因 • 様々な前提が全て頭の中にある ため対話でカバーしきれない • POは6割以上案件で稼働 • 若手なためHowToがわからな い • メンバーごとにスキル差が大き く、対話だけでは差を埋められ ない • 「必要」なタイミングを判断す るスクラムマスターの不在 現実 • POが責任をもってメンテ ナンスする • 自律した開発者が対話を 繰り返して同期せよ • 必要に応じてドキュメン トを作れ • 自律した開発者が対話を 繰り返して同期せよ 書籍の教え
  7. 20 基本の方針 ① プロセスを重たく or きっちり しすぎない 手間がかって結局やりきれなかったり、キチキチで変更に対応できない状態は避ける ② メンテナンス性を考慮した最低限の設計をする

    「とりあえず動くものを作ってから考えよう!」という過激な現物主義は避ける ③ 新加入メンバーが頭を悩ませない開発体制 これから成長していく若手が、進め方の面で迷子にならずに開発に入れて、 比較的チームがスケールしやすい状況にしたかった。 アジャイル×ユースケース定義のプロセスを考える際、念頭においた基本方針
  8. 22 作ったプロセスの全体像がこちら ※ このあと観点を絞って、もう少し説明 バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを

    増やしづらい状 況 問題 ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度
  9. 23 問題への打ち手とプロセスの対応関係 ※ 問題への効果については次のセクションで一つ一つ説明します バックログの管理 がしきれない 頭のなかだけにあ る詳細な製品仕様 開発メンバーを増 やしづらい状況

    問題 ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲しい」 「ここ直したい」というバックログを緩い秩序で 雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どういう時、 どういう気持ちで、どういう機能を求めるか少 しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユースケース 定義書など最低限必要なドキュメントを作成して 整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進めるために 日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 責任もつ人
  10. 24 プロセスのおおまかな情報の流れ 情報のおおまかな流れは以下のようなイメージ。 このようなプロセスを次頁のようにアジャイルに回していく。 ※ 一つ一つのステップついては、この後で触れます ゆる秩序バックログ管 理 日々、新たに産まれる「こういう機能欲しい」 「ここ直したい」というバックログを緩い秩序で

    雑に溜める場所 お気持ち&要求分析 バックログをインプットに、誰が、どういう時、ど ういう気持ちで、どういう機能を求めるか少しだけ 整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユースケース定義 書など最低限必要なドキュメントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進めるために 日々の作業を同期する ツール 概要 Azure DevOpsの Boads Azure DevOpsの Boads Confluence Confluence 責任もつ人 PO PO 開発者 開発者 情報の流れ
  11. 25 アジャイルに回すと お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理 お気持ち& 要求分析

    要件定義& 設計 日々のタスク チケット管理 お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理 アジャイル 開発 イテレーション2 イテレーション1 イテレーション3 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 実際にはこんなに美しく回ってはいないが、 イメージはこのような形 気付いたら やる
  12. 26 アジャイルに回すと アイディアは顧客やコンサルから貰ったタイミングで貯めておいて 忘れないように&タイミングによって差し込み検討できるようにし、 お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理

    お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理 お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理 アジャイル 開発 イテレーション2 イテレーション1 イテレーション3 気付いたら やる ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理
  13. 27 アジャイルに回すと 日々の開発では、イテレーションのなかで ドキュメント作成ができるようプロセス化する お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理

    お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理 お気持ち& 要求分析 要件定義& 設計 日々のタスク チケット管理 アジャイル 開発 イテレーション2 イテレーション1 イテレーション3 気付いたら やる ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理 ゆる秩序バック ログ管理
  14. 29 全部部まとめると バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況

    問題 ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度
  15. 31 バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況 問題

    ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度 全体像の再掲
  16. 32 バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況 問題

    ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度 ゆる秩序バックログ管理
  17. 38 ポイント③:とはいえ最低限の秩序はキープ とはいえ、油断すると無秩序になるため、以下のような軽めの工夫で、最低限の秩序を維持。 大事なことは「いきなり重たいルールを作らず、できる範囲を見定める」こと。 ただしタグを作りすぎると管理しきれ なくなるので、「セットで実装するも のないかな~?」を探すのに最低限な タグにするとよい。 30分/週のメンテナンスを定例化 バグ、PBI、作業を

    一目で分かるようにする 大きな機能分類用にタグを用意 POと開発者のうち一人が、最低週に30 分は定例でバックログを並び替える作 業をする 組織にもよるが、現在はバグ、PBI、 Work Itemの3種類を利用。分け方の観 点は「クエリで抽出したい or 除外した い」のはどれか?と言う点。
  18. 39 バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況 問題

    ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度 お気持ち&要求分析
  19. 46 バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況 問題

    ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度 要件定義&設計
  20. 48 要件定義&設計:概要 開発において必要最小限となるドキュメントを作成する。 製品開発チームの場合は試行錯誤の結果、以下のドキュメントを作成している。 概念クラス図 ・ドメンモデル図に登場する各クラスの属性を記載する 画面定義書 ・画面の紙芝居を作成し、画面上の項目を定義する ・バックエンド開発時のヌケモレを減らす ユースケース定義書

    ・システムがユーザーに提供する機能をユースケースとして漏れなく洗い出し、 図にまとめる ・基本シナリオと代替シナリオをシステム利用ユーザーとシステムとの対話形式 で記載する(細かいロジックは書かない。) ドメインモデル図 ・アクターがシステムで操作する「モノ」の概念と関係性をモデル化する。 ・チーム内で使う用語と、システムを使う業務の全体像の認識をあわせる。 コンテキストモデル ・アクター(システム利用者と、外部システム)を具体化する。 ・具体化することでユースケースの主語がブレなくなる。 要件定義(POレビュー必須) 設計(開発者内レビュー)
  21. 50 ポイント①:POレビューをしっかり入れる 特に要件定義系ドキュメントは「作るべきもの(What)」の正体を明らかにするためのもの。その ため、Whatに責務を持つPOからのレビューを必ず受ける。 さらに、レビューは作成者が実際に声を出して読む方が効果が高いので推奨。 概念クラス図 ・ドメンモデル図に登場する各クラスの属性を記載する 画面定義書 ・画面の紙芝居を作成し、画面上の項目を定義する ・バックエンド開発時のヌケモレを減らす

    ユースケース定義書 ・システムがユーザーに提供する機能をユースケースとして漏れなく洗い出し、図にまと める ・基本シナリオと代替シナリオをシステム利用ユーザーとシステムとの対話形式で記載す る(細かいロジックは書かない。) ドメインモデル図 ・アクターがシステムで操作する「モノ」の概念と関係性をモデル化する。 ・チーム内で使う用語と、システムを使う業務の全体像の認識をあわせる。 コンテキストモデル ・アクター(システム利用者と、外部システム)を具体化する。 ・具体化することでユースケースの主語がブレなくなる。 ↑ 要件定義(POレビュー必須) 設計(開発者内レビュー)
  22. 54 (参考)ユースケース駆動開発とは ソフトウェア開発のための最小限のUMLモデリング手法 紙芝居 ユースケース モデル ロバストネス図 シーケンス図 ドメインモデル クラス図

    実装コード 単体テスト 静的 動的 イテレーティブ テスト計画 UMLを活用し、ユーザーのやりたいこと(ユースケース)からソフトウェアの実装コードにもっていくまでを 最小限の成果物で目指す手法(UMLとは、記号と表記法やその意味が定義されたモデリングのための言語)
  23. 56 (参考)ドメインモデル図 目的: 以下について認識をあわせる • チームや関係者どうしで使う言葉の定義 • システムが実現する世界の全体像 書くこと: •

    システムで扱う「モノ」の概念と関係性のモデル化。 • 関係性は、is-a関係(汎化)と、has-a関係(集約)だけに した方が良い。 • この時点ではフィールドは書かない。「モノ」だけを書く。 ※ 具体的な書き方は専門の書籍をご参考ください [引用元] ダグ・ローゼンバーグ, マットステファン 『ユースケース駆動開発実践ガイド』P.44 図2.7
  24. 57 (参考)ユースケース定義書 目的: • ユースケースのヌケモレを防ぐ。 • アクターがシステムを理由する際に、システムとユー ザーがそれぞれどのような順番で相互作用するのかを明 確にする。 書くこと:

    • ユースケース図(上の画像)。ユースケースとアクター を漏れなく洗い出すことが大事。 • ユースケースのシナリオ(下の画像)。基本シナリオと 代替シナリオを作成することが重要。 ※ 具体的な書き方は専門の書籍をご参考ください [引用元] ダグ・ローゼンバーグ, マットステファン 『ユースケース駆動開発実践ガイド』P.72 図3.8 [引用元] ダグ・ローゼンバーグ, マットステファン 『ユースケース駆動開発実践ガイド』P.89
  25. 58 (参考)画面定義書 目的: • ユースケース定義書に書くと細かくなりすぎるUIに関し て共通認識をもつ。 書くこと: • 画面のワイヤーフレーム or

    紙芝居。(画像の上部) • 画面の項目、UIの制約など(画像の下部) ※ 具体的な書き方は専門の書籍をご参考ください [引用元] 株式会社モンスターラボ「仕様書とは?開発事例をもとに成功する仕様書 の書き方を解説」https://monstar-lab.com/dx/solution/howto-specification/
  26. 60 バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況 問題

    ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する プロセスのステップたち Azure DevOps のBoads Confluence ツール Azure DevOps のBoads Confluence PO PO 開発者 開発者 激ゆる ややゆる きっちり ややゆる 責任もつ人 きっちり度 日々の作業チケット管理
  27. 65 プロセスのステップたち バックログの管 理がしきれない 頭のなかだけに ある詳細な製品 仕様 開発メンバーを 増やしづらい状 況

    問題 ゆる秩序バックロ グ管理 日々、新たに産まれる「こういう機能欲 しい」「ここ直したい」というバックロ グを緩い秩序で雑に溜める場所 お気持ち&要求分 析 バックログをインプットに、誰が、どう いう時、どういう気持ちで、どういう機 能を求めるか少しだけ整理して書く場所 要件定義&設計 要求をもとに、ドメインモデル図やユー スケース定義書など最低限必要なドキュ メントを作成して整理する 日々のタスク チケット管理 要件をタスク分解してアジャイルに進め るために日々の作業を同期する ポイントだけまとめ ① 楽をする ② 順番付けは超ざっくり ③ 最低限の秩序をキープ 紹介したポイント ① お気持ちと機能を両方かく ② きっちりな構造化はしない ③ 「あると嬉しいゾーン」で柔軟に ① POレビューをしっかい入れる ② イテレーティブに作成する ① DevOps本の第6章を読む
  28. 67 問題に対してどうだったか そもそも解きたかった問題に対しては、一定の効果を実感できた バックログの管理 がしきれない 頭のなかだけにあ る詳細な製品仕様 開発メンバーを増 やしづらい状況 問題

    ゆる秩序バックログ管 理 お気持ち&要求分析 要件定義&設計 日々のタスク チケット管理 関係するプロセス 問題に対する効果 半分程度は解決。 優先度が高いものについてはそれなりに並び替えが機能するよう になった。 ほぼ解決。 要件と設計が可視化され、誰とでもすぐに共有でき、認識合わせ が可能な状態となった。 ほぼ解決。 ドキュメントが理解できるレベルの開発者であれば1週間以内に 完全に自律的判断でコーディングが可能になった。
  29. 69 残っている課題 以下のような課題はまだ残っているため、継続的に改善を続けたい • 未整理の古いバックログ ➢過去の整理されていないバックログが、ざっくり優先度整理もされないまま、別のエリアに 半分くらい放置されている。 • 要求分析は少し乱雑になりがち ➢要求分析は「手軽に書ける」ことをすこし優先しすぎて、リストがやや乱雑になっている嫌

    いがある。(それでも今までよりはだいぶ改善された) • 要求分析が開発に追いつかない状況 ➢開発がスピードアップしたことと、POが専任ではないことにより(POの責務自体は軽くなっ たが)要件定義や開発に、要求分析が追いつかないケースがある。そのため、一番最初認識 あわせに時間を要している。
  30. 70 まとめ ⚫ スクラムに関する書籍を翻訳してスクラムに挑戦したが3つの問題に直面した ① バックログの管理がしきれない ② 頭のなかだけにある詳細な製品仕様 ③ 開発メンバーを増やしづらい

    ⚫ アジャイル×ユースケース駆動のプロセスで問題にアプローチし、以下のような結果に ① バックログの管理がしきれない→ 半分くらい解決 ② 頭のなかだけにある詳細な製品仕様 → ほぼ解決 ③ 開発メンバーを増やしづらい → ほぼ解決 さらに副次効果として、開発効率化、負荷の平準化、コーディングスキル向上などが得られた ⚫ ただし、まだ以下の課題もあるので、継続的に改善していきたい ➢ 古いバックログがまだいくつか未整理 ➢ 要求分析ドキュメント内の要求事項がちょっと乱雑になりぎみ
  31. 74 ISID AITCでは新しい仲間を募集しています また、右側の職種への応募用ページからご応募頂いても大丈夫です。 コンサルティング系 AIコンサルタント https://groupcareers.isid.c o.jp/pgisid/u/job.phtml?jo b_code=591&company_co de=1

    AIビジネスプロジェクトマネージャー https://groupcareers.isid.c o.jp/pgisid/u/sp/job.phtml ?job_code=532 製品開発系 AIエンジニア(製品開発) https://groupcareers.isid.c o.jp/pgisid/u/job.phtml?jo b_code=647&company_co de=1 AIプロダクトマネージャー https://groupcareers.isid.c o.jp/pgisid/u/job.phtml?jo b_code=693&company_co de=1 職種ごと応募ページ
  32. 76 AI製品開発グループ ISIDのAI製品開発グループでは、機械学習とアプリケーション開発両方の知識を活かしながら、 AI製品の研究開発を行っています フロントエンド バックエンド コンテナ・仮想化 クラウド&インフラ AI/ML アジャイル開発(スクラム)

    (AIスキルだけじゃない!) AI × IT × Biz AIはシステムの一部、フルスタックなIT実装力 UVP ・機械学習 アルゴリズム ・統計解析 ・機械学習工学 ・ディープラーニング ・Webシステム構築 ・MLOps ・データ分析基盤構築 ・IoTシステム構築 ・PM、PdM ・デザイン思考(UX/UI) ・ビジネスクリエーション (リーン, ジョブ理論, etc.) ・業界や分野の専門知識 IT技術 Biz AI/データサイエンス
  33. 77 コンサルティンググループ 顧客とのコミュニケーションを 通じて、問題を実際に解ける課 題にまで切り分ける • ヒアリング • 顧客業務の理解 •

    問題の把握 • 解くべき課題の特定 企画 データを集めてAIモデルを構 築し、切り分けた課題をAIで解 けることを検証する • データ収集 • モデル作成 • モデル評価 • レポーティング PoC(概念検証) 顧客内のAIリテラシーを高め、 顧客内のAI活用文化醸成を支 援する • レクチャー資料作成 • レクチャーの実施 • フィードバック 教育 実運時の課題を洗い出すため のプロトを構築し、業務適用を 検討、検証する • 業務フローの作成 • プロト開発 • 顧客レクチャー • 仮運用時の 課題整理 プロト開発 顧客業務に組み込むAIシステ ムの設計・開発・テストを実施。 コンサルタントはPMとしての アサインが多い • 要件定義 • 設計 • 開発・テスト • 運用 システム開発 ISIDのAITC コンサルティンググループでは、 顧客が抱える「AI/データをうまく活用できないだろうか」という課題を、 「こうすればAI/データ分析で解決できる」という整理を行い、 AI/データ分析の社会実装/運用を実現しています