狠狠撸

狠狠撸Share a Scribd company logo
Elementum Consulting
础滨プロジェクトを成功に导くゴール设定
2018年7月12日
エレメンタムコンサルティングLLC
増田和紀
SORとSOE
SoR(System of Record) とは、高い品質と安定稼働が前提の従来型の
基幹業務システム全般のことを示します。基幹業務を担う、会計システムや販売
管理システムが、このカテゴリーに属します。
一方、SoE (System of Engagement) とは、ユーザとの接点や利便性の
向上を目的とするもので、SNS等の様にユーザの動向を的確に捉え、常に更新
が行われています。
SoR(System of Record) SoE (System of Engagement)
重要な要素 堅牢性、信頼性、機密性 柔軟性、俊敏性
開発のアプローチ ウォータフォール アジャイル?トライアンドエラー
コードの主体 スクラッチ?パッケージ APIの組み合わせ
システム運用 開発とは別のプロセス DevOps
改良のサイクル 組織主体で計画的 状況に合わせて適宜
SORとSOE
SORは、ERPのパッケージを利用したり、DBの設計から始めスクラッチでプロ
ジェクトを立ち上げる形態をとります。
一方、SOEでは、用意されたAPIの機能群を組み合わせ、短期間で開発し、
ユーザからのフィードバックを重視して、課題を明確にし、優先順位を再検討し
ながら継続的な開発と運用を行います。
Continuous
client experience
Partner value
chain
Systems of EngagementSystems of Record
CRM HR
DB ERP
短期的、フィードバックを重視長期的、計画的
ウォータフォール型 痴-モデル
SORいわゆる基幹業務の開発は、ウォータフォール型で、システムの切り替え
まで、数年間かかるプロジェクトも珍しくはありません。要求定義段階で明確に
なった機能について、外部設計、内部設計、プログラミング、単体、結合、シス
テム、受入テストを行い、本番稼働に至ります。
この開発モデルは、ユーザ接点のSOEには適合しません。
要件定義
外部設計
内部設計
プログラミング
単体テスト
システムテスト
結合テスト
計画 受入テストウォータフォール型 痴-モデル
Cloud上のAIと開発?運用プロセス
アジャイル開発のプロジェクトでは、要求事項は、バックログに纏められます。
バックログの一部が、スプリント(イテレーション)の単位になり、設計?開発?テスト
を繰り返して、リリースを繰り返します。
※スクラム プロセスの例
フィードバックループ
「何かを変えよう => どうなったか調べよう => そこから学ぼう => また何かを変えよう。一
般的に言えば、あなたにはできるだけ短期のフィードバックループが必要です。そうすることで、
プロセスを素早く適応させることができるのです。Kniberg and Skarin」
クラウド上のAIに投入したナレッジベースは、非構造化データであり、そこからユーザの意
図を抽出します。ところが、事前に用意したFAQ等のデータは、静的なもので、必ずしも動
的な生きたユーザの意図を代表しているわけではありません。実際に使われてみて、ユーザ
の傾向が分かり、それを測定することによって、次の課題が明らかになります。
引用:https://www.infoq.com/news/2011/03/agile-feedback-loops
フィードバックループ
まず、APIを組み合わせて、短期間に構築(Build)してリリースするとします。そこ
でのユーザの反応を測定(Measure)することなしに、学び(Learn)はなく、次の
課題は明確になりません。
全体の中の利用率、利用者の満足度を測る仕組みも同時に考えて置きましょ
う。これは、自動的に把握されるわけではないので、自ら用意しておく必要がありま
す。
引用:https://www.infoq.com/news/2011/03/agile-feedback-loops
ゴールの設定
8
過去のAIプロジェクトを見てみると、物珍しさが先に立ち、経営層が夢を見てい
ることもあって、「ともかくAIをやってみました。」というプロジェクトが多く見られます。
この場合は、基本的にはAIをやってみたということがゴールになっています。
GOAL
AIをやってみた
?クラウドを利用する。
?AIをAPIで利用する。
?APIを組合せて提供する。
AIプロジェクトを成功に導くゴールの設定
各種の報道や事例発表でも、そのほとんどが、「AIをやってみた。」というものであり、その結果
として、定量的にどのような効果があったかを示しているものは多くありません。
AIを社内のシステムに利用し、例えば、パイロットシステムを開発するとして、何が達成できて
いれば、目標を達成できているのかを、事前に明確に示し、関係者、経営層と合意を得てから
進めることが重要です。
GOAL
社員全体の何%が利用し、
問合せ件数は、現在のx
件からy件に削減される。
?クラウドを利用する。
?AIをAPIで利用する。
?APIを組合せて提供する。
柔軟に俊敏に、
状況に対応するための手段
AIプロジェクトを成功に導くゴールの設定
非構造化データを取り扱う以上、予め用意したナレッジベースだけで、目標を
達成できるとは限りません。リリースし、ユーザの利用した結果を測定し、それを
次のリリースの改善に生かして、ステップアップを繰り返し、予め定めた期間内で
ゴールが達成できるかどうかを判定することになります。
GOAL
Release 1
Release 2
Release 3
開発プロセスと非機能要求
11
情報システム部門が行う、一般的なウォータフォール型の開発プロセスにおいては、その
要求定義段階で、機能要求だけではなく、非機能要求について、定義しておくことが求め
られます。
IPA(情報処理推進機構)では、可用性、性能?拡張性、運用?保守性、移行性、情報
セキュリティ、環境?エコロジーの6つに整理しています。
機能要求 非機能要求
? 可用性
? 性能?拡張性
? 運用?保守性
? 移行性
? 情報セキュリティ
? 環境?エコロジー
※IPA
搭載する機能
?マスター管理
?トランザクション登録
?計算?表示
開発プロセスと非機能要求
つまり、システムの持つ情報セキュリティや運用?保守性、性能?拡張性などの非
機能要求についても、要求定義の段階で、機能要求とバランスをとって、定義し、
後の外部設計、内部設計、プログラミングして実装し、テストの各段階で、検証さ
れてリリースを迎えます。
要件定義
外部設計
内部設計
プログラミング
単体テスト
システムテスト
結合テスト
計画 受入テスト機能要求
非機能要求
開発プロセスと非機能要求
13
情報システム部門が行う、一般的なウォータフォール型の開発プロセスにおいて
は、その要求定義段階で、機能要求だけではなく、非機能要求について、定義
しておくことが求められます。
IPA(情報処理推進機構)では、可用性、性能?拡張性、運用?保守性、移
行性、情報セキュリティ、環境?エコロジーの6つに整理しています。
機能要求 非機能要求
? 可用性
? 性能?拡張性
? 運用?保守性
? 移行性
? 情報セキュリティ
? 環境?エコロジー
※IPA
搭載する機能
?マスター管理
?トランザクション登録
?計算?表示
アジャイル開発のプロジェクトでは、機能要求は、バックログに纏められます。ところ
が、短期に、ユーザのフィードバックを受け、リリースを繰り返すことのみを焦点に充
てると、非機能要求がすっぽり抜けてしまうプロジェクトが多く見られます。
※スクラム プロセスの例
アジャイル開発と非機能要求
AIを用いるプロジェクトが、短期間にフィードバックを重視して設計、開発、テストを
繰り返すアジャイル型の開発?運用のプロセスであったとしても、非機能要求を無視
して良いものではありません。例えば、後から会社の規程に反して、重要な機密を
国外に出してしまったことが分かったとすれば、大きな問題になってしまうでしょう。
※スクラム プロセスの例
アジャイル開発と非機能要求
アジャイル型の開発?運用プロセスにおいては、非機能要求をどこに組み込めばよ
いのでしょうか。それは、要求事項を明確にしたプロダクト?バックログです。プロダクト?
バックログをユーザの機能要求だけで、実装してはなりません。出来れば、リスク分析
をした結果を元に、機能要求のグレードに合わせた非機能要求のグレードを定義し
たものを事前に持って置き、それを適用させることが望ましいと考えられます。
※スクラム プロセスの例
機能要求
非機能要求
機能要求
非機能要求
アジャイル開発と非機能要求

More Related Content

础滨プロジェクトを成功に导くゴール设定