日本ソフトウェア科学会第 36 回大会 (2019 年度) 講演論文集

PoC キャンバスを用いた機械学習システムの開発プロ
セスの管理手法
土肥 拓生
近年，機械学習に関する技術に注目を集めている．機械学習を利用したシステムにおいては，その企画から開発，運用まで，様々な種類の仮説検証が必要となる．一方，従来のソフトウェア工学の技術は，原則的に計画主導であり，不確実性を徐々に減らしてくものであるため，常に仮説検証が必要な場合には，そのまま適用することが難しい場合も多い．また，近年，主流になりつつあるアジャイル型の開発は，ビジネス上の仮説検証を考慮した開発手法と考えることができるが，機械学習を利用したシステムには，他の観点における仮説検証も考慮すべきであり，単純なアジャイル開発そのままでは解決できない課題も存在する．そして，このような機械学習を利用したシステムの場合には，仮説検証をその開発プロセスの中で管理する必要があると考える．著者は，その手法として，仮説指向ソフト
ウェア開発プロセス [3] を提唱している．本稿では，仮説指向ソフトウェア開発プロセスにおいて，仮説を整理，管理するための道具として利用する PoC キャンバスを提案し，その効果について議論する．

Recently machine learning are has been very focused. We have to do hypothesis testing for software systems
with machine learning(machine learning system) in the whole process from planning to operation. Traditionally software engineering support us to make plans and reduce the uncertainty of the development.
So it is diﬃcult to apply the software engineering techniques to machine learning system. Although agile
development which has been adopted all over the world can support to verify hypothesis on business, weneed hypothesis testing of the other perspective. We have already proposed Hypothesis Oriented Software
Development Process [3]. In this paper, we propose PoC Canvas which is useful for clarifying and managing
the hypothesis.

ばかりであるが，企業における事例に基づいたノウハ

1 はじめにウや課題として，機械学習システムを開発する手法，

近年，機械学習に関する技術が注目を集めている．

プロセスについて提示 [14] [13] されてきている．しか計算資源の高速化により深層学習 (ディープラーニン

しながら，機械学習という確率的挙動を含むソフトグ) などの技術が利用しやすくなり，実用的なシステ

ウェアという一つの新しいパラダイムに対して，十分ムにおいても有益な結果が出せるようになってきたこに議論されているとは言えない．

とが大きい．近年，機械学習に関する研究は非常に多

さて，一般的に仮説検証というプロセスが重要であく，機械学習システムに特有の課題があることも報告

るということは，以前より主張 [11] されてきている．

[5] [4] されてきている．一方で，機械学習に関する研近年主流となりつつあるアジャイル開発においても，究は，新しい機械学習アルゴリズムの提案や，特定のソフトウェア開発に関わる様々な不確実性を扱うため領域において機械学習を適用したシステムの紹介がに，仮説検証の考え方がその柱の一つとなっている．

中心であり，ソフトウェア工学的見地から，いかに，

著者は，この仮説検証というプロセスを，機械学習

機械学習システムを扱うべきかという議論は始まった

システム特有の不確実性を扱うための開発手法とし

How to Manage the Development Process for Machine
Learning System using PoC Canvas
Takuo Doi, ラ イ フ マ ティック ス 株 式 会 社/国 立 情
報 学 研 究 所, Lifematics Inc./National Institute ofInformatics.

て，仮説指向ソフトウェア開発プロセス (Hypothesis

Oriented software development Process: HOP) を提唱している．本稿では，HOP においての仮説検証を扱うための仕組みとして，PoC キャンバスを提案

する．PoC キャンバスは，機械学習システムの開発することは難しく，どの要素を特徴量とした扱うか，に携わるメンバーに，機械学習特有の仮説検証プロセ

どの学習アルゴリズムを選択するか，どのように学習

スを容易に整理する手段を与えるとともに，何を仮説

パラメタを設定するかについては，仮説検証を繰り返として捉えてソフトウェア開発を実施しているのか，す必要がある．

仮説が否定された場合にどのように仮説の再構築を行うことが可能なのかを示唆することができる．

さて，そもそもなぜ仮説検証が必要となるのであろうか．著者は仮説検証は，不確実性を扱うための有用

以降，2 章で，HOP が想定している機械学習シス

な道具であることがその理由であると考える．このテムにおける特徴と，そのようなシステムの開発に必

不確実性をいかに扱うかが機械学習システムの開発・

要な開発プロセスについて考察する．次に，3 章で，運用には非常に重要である．本章では，著者が経験し機械学習システム，および，その開発の特性に基づた，あるいは，見聞きした実際の機械学習を利用した

き，独自の課題を解消するための開発プロセスである

プロジェクトの事例より抽出した機械学習システムのHOP について示す．その後，3 章で，HOP における不確実性の特徴を示す．

仮説を監理するための PoC キャンバスについて提案

2. 1. 1 プロジェクトの進捗とその不確実性

するとともに，どのように PoC キャンバスが機能す

機械学習は，学習に利用するデータ，データのどのるかを示し，5 章でまとめる．

情報を特徴量として扱うか，どの学習アルゴリズムを選択するか，学習パラメタの設定によって，その結果

2 機械学習システムとはとして生成されるモデルの性質は異なる．そのため，本章では，仮説指向ソフトウェア開発プロセスが対従来のシステム開発のように，いかに詳細に設計した象とする機械学習システムの特徴について整理する．

としても，必ずしも期待したモデルを生成できるとは限らない．そのため，一般的には，利用可能なデー

2. 1 機械学習システムの特性

タから期待するモデルを生成できるかという仮説検

機械学習システムが持つ従来のソフトウェアシステ

証から実施することが多い．そして，この課程のこと

ムにはない特性は，これまで存在していなかった「仮説検証」が求められるということである．

を，Proof of Concept(PoC) と呼ぶ．
また，PoC ですら事前に予測不可能なことが多く，

ソフトウェア工学の歴史は，より多くの仮説検証をかつ，PoC にも膨大な時間やリソースが必要となる

工学的に可能としてきた歴史である．初期のソフト場合もあり，そのリスクを低減するために，PoC のウェア工学は，いかにユーザの要求を確定させ，その事前検証のために，Pre-PoC という段階を踏むこと要求をいかに間違いなく実装するかというものであっも多い．Pre-Poc において，例えば，ごく一部のデー

た．ユーザのニーズの多様化が進むとともに，環境タで検証させたり，代表的な手法での精度を計測するの変化が加速するにつれて，全てを計画的に実施すことにより，より大規模なデータでコストをかけてるソフトウェア開発がなかなかうまく行かなくなり，

PoC に取り組んだり，よりアルゴリムのチューニン

要求に対する仮説検証を実施する顧客開発 [2] というグにリソースをかけるなどの妥当性を検証するので考え方や，それを実現するためにソフトウェア開発のある．

プロセスにおける仮説検証を可能にするアジャイル

ソフトウェアシステムとは，最終的にはユーザに対開発 [1] が利用されるようになってきている．そして，して価値を提供するものである．そのため，PoC により柔軟なシステムが求められるようになり，機械学

より何らかの判断をある程度の精度予測するだけで習システムに注目が集っているが，まだ未解決な課題は不十分である．また，その提供する価値がユーザにも多い [7]．機械学習のモデルは，学習したデータにとって本質的なものでなければ，そのソフトウェアシ

基づき確率的に決定されるため，そもそもシステム

ステムが利用されることはない．また，モデルの振るが期待したように振る舞うかを完全に論理的に保証

舞いは確率的であるが，そのシステムで利用されるモデルが確率的な挙動を示した場合に，ユーザにどのような価値を提供できるかが重要である．例えばであるが，迷惑メールを判別するモデルを使ったシステムであれば，90%の精度で予測できれば，ユーザは満足するかもしれないが，自動運転の判断をするモデルの場
合は，同じ精度で予測するシステムが搭載された自動車には誰も乗らないだろう．ここでは非常に分かりやすい例を提示したが，一般的なシステムにおいて，どのようなモデルをどのように利用すればユーザに価値を提供できるかは，非常に重要な仮説検証の対象

図1

である．

機械学習システムの構造の情報がデータに追加され，その変化したデータに基そして，全ての機械学習システムにおいて必要なづいて，学習モデルが再構築される．

訳ではないが，運用中に妥当な学習をし続けられるかというのも重要な仮説検証である．例えば，迷惑

非常に簡略化した構造ではあるが，例えば，複数のメールの例はこれがうまくいきやすいケースである．

学習モデルが組み込まれたシステムであったり，機械

実際にユーザがメールを読むという操作 (運用) の中学習を利用しない部分が非常に複雑なシステムであっで，扱うメールを学習することにより，よりユーザにたとしても，その機能ではなく，確率的な挙動を持とっての迷惑メールかどうかの判断に近づける可能つ部分とそうでない部分で分けることは可能である．

性がある．しかし，一方で，実際の運用においては，

そのため，議論に十分な汎用性を持っているはずでどのような環境でどのようなデータを学習するか分ある．
この図を，確率的な挙動をするモデルを中心に見てかない状況において，適切な学習をし続けるための仮

いくと，モデルの不確実性に誘発されることにより，説検証をいかに扱うかは非常に大事なのである．
以上，まとめると機械学習システムのプロジェクトには，3 つの不確実性を扱う必要がある．



次の課題が導かれる．



1. モジュールがモデルの不確実性を扱うこと

1. PoC の実現性に関する不確実性が可能

2. ソフトウェアにおけるモデルの不確実性

2. ソフトウェアがモデルの不確実性を吸収す

3. 運用における学習の不確実性



ることが可能

3. ユーザや環境からの情報をデータとして追2. 1. 2 ソフトウェアの構造とその不確実性
本論文では，簡単のために，機械学習システムの構造を図 1 に簡略化して議論をすすめる．

加による不確実性を扱うことが可能

最初の 2 つの課題は似ているが観点が異なる．例

この図において，モデルが学習モデルであり，確率

えば，雨の降りやすさを示すような値を提供するモデ的な挙動を示すものである．モジュールと記載した部ルがあったとしよう．学習モデルが分類モデルであれ

分が，通常のソフトウェアモジュールを表現し，確率ば想定外の結果を返すことはないが，回帰モデルであ的な挙動をせず，プログラムの通りに動作するものでれば，その値域には不確定な部分が存在する．その場ある．これらが連携して動作するものがソフトウェア

合に，モデルの結果を 2 倍したものが降水確率としシステムであり，ユーザに価値を提供するとともに，て利用していたとして，65 という値をモデルが返しその結果に対して，ユーザからフィードバックを得るてもモジュールとして整合性がとれるかというのが前ことができる．また，そのフィードバックや環境から者である．傘を持っていくべきかどうかを指示するソフトウェアだったとして，上記の 100%以上や，0 以

きないが，現時点での機械学習の効果から考えれば，下といった想定外の値だった場合に，何か問題が起き要求工学や顧客開発など，ソフトウェア工学のこれまていると判断し「不安定なので注意してください」とでの知見を十分に活用して，ユーザが求めているもの

いった情報を提供したり，他の天気予報の情報を提供を見定めた上で，それを実現するために欠けているもしたりするというシステムとしての振る舞いが考慮のを機械学習で補えないかを検討する方が妥当であされているかというのが後者である．もちろん，いずると考える．

れの場合も何が例外的な事象なのかというのは規定されている必要がある．

すなわち，ユーザにどのような価値を届けるのかを見据え，その価値を提供するために欠けている情報を機械学習で補えるという仮説を立て，その仮説を

2. 2 機械学習システムのためのプロセス要件
では，ここまでで考察した機械学習システムを開発

PoC として検証する方が望ましい．
2. 2. 3 運用における学習の不確実性することに適した開発手法とは，どのようなものであ

運用における学習を実現するためには，そのソフ

ろうか．別の言い方をすると，どのような開発手法でトウェアの重要度に応じた対策が必要となる．前章であれば，プロジェクトに関する 3 つの不確実性を適例示した迷惑メールの判別のような比較的重要度の切に扱い，ソフトウェアの構造に起因する 3 つの不小さいものであれば，数多くの学習データを収集で確実性に対する課題に対処し，機械学習システムプロ

きるような運用を検討する方が，最終的なユーザへジェクトが成功させることができるのであろうか．

提供可能な価値は大きい可能性があるが，自動運転

本章では，これらの観点から機械学習システムを開のような場合であれば，新しく学習したモデルが，少発する際に適した開発プロセスが満たすべき要件になくとも最低限の水準を満たしていることを保証す

ついて検討する．

る仕組みが必要であろう．この最低限の水準を保証す

2. 2. 1 PoC の実現性に関する不確実性

るためには，製品自身に新しい学習モデルを評価す

PoC の実現性に対しては，一般的に不確実であるる仕組みが内包させることなども考えうる．または，ことが認識されている場合が多い．しかし，プロジェ

ユーザ自身に判断を仰ぐといった設計が適している場

クトとして考えた場合に，どれだけ多くの PoC を実合もあるだろう．

施しても，どれだけ PoC で精度を上げることができいずれにせよ，新しく学習したモデルが，そのソフたとしても，製品に貢献できなければ，ユーザに対しトウェアにとって最低限の水準を満たしていることをて価値を提供できない．また，いくらリソース費やし

保証する仕組みが必要となる．

たとしても，データによっては期待するモデルを構築できない可能性は十分にある．そのため，PoC とし

2. 2. 4 モジュールがモデルの不確実性を扱うことが可能ての成功，並びに，失敗を規定することにより，無駄学習モデルがある入力に対して，どのような出力をにリソースを費してしまわないように注意を払う必

返すかは，不確実であったとしても，その結果を利用

要がある．

する側のモジュールは期待した通りに動作すること

なお，機械学習を使わない手法との比較も重要である．

を保証する必要がある．このモデルの不確実性をモ
ジュールが扱うためには，モジュールに対する自動テ

2. 2. 2 ソフトウェアにおけるモデルの不確実性

ストと組み合わせることが最も容易であると考える．

ソフトウェアにおいて，どのような不確実性が許容

なぜなら，モデルの挙動は予測不能であっても，モデできるのかを把握することが必要である．また，PoC

ルの出力に対する期待する範囲は予想可能である．そにより未知の知識を得てそれを利用した画期的なシのため，例外状態における自動テストを用意するこ

ステムを構築したいという話を聞くことが度々あるとで，モデルが想定外の結果を導き出した場合でも，が，そのようなアプローチを完全に否定することはでモジュールとしては，想定された挙動を保証することが可能になる．

2. 2. 5 ソフトウェアがモデルの不確実性を吸収することが可能
前節で述べたように，モジュールが適切にモデルの不確実性を考慮されていれば，ソフトウェアとしては，モジュールの挙動は想定内に収まるため，その際

図2

PoC フェーズの概要の挙動について検討を行えばよい．ただし，前章の例
で言えば，モデルが適切に学習できなかったために，という仮説の検証である．この仮説を，HOP におい

常に「不安定なので注意してください」という表示をては，モデル仮説と呼ぶこととする．

するようになってしまっていないかなど，継続的なソ

もう 1 つの PoC とは，ビジネス上の仮説であり，

フトウェアとして妥当な動きをしているかを確認する

HOP では価値仮説と呼ぶこととする．価値仮説とは，仕組みがある方が望ましい．

あるモデル仮説が妥当と検証されれば，その機械学習

2. 2. 6 ユーザや環境からの情報をデータとして追モデルを用いて，ユーザに対してある価値を提供する

加による不確実性を扱うことが可能

ことが可能であり，かつ，ユーザもその価値を求めてこの課題は，運用における学習の不確実性の扱いくれるであろうという仮説である．このようにビジネと共通する部分が多い．ソフトウェアの利用というス上の価値検証を並行して実施することが，HOP の観点からすると，利用において取得できたデータが特徴である．

全て有効なデータとは限らない．PoC や事前の学習であれば，エンジニアがデータ処理をすることが一

一般的には，この 2 種類の PoC を次のような反復開発により実現する．

般的であるが，運用後に取得したデータにおいては，

1. ユーザへ提供する価値仮説を策定

恣意的に欠損値を埋めたりすることができないため，

2. 価値仮説の前提となるモデル仮説を策定

そのようなデータの加工についても十分に検証する

3. 価値仮説を検証必要がある．

4. モデル仮説を検証
5. モデル仮説の検証結果に基づき，以下のいづれ

3 仮説指向ソフトウェア開発プロセス (HOP)

かを選択

本章では，2 章で考察した特性を持つ具体的なプロ(a) 新しいモデル仮説の策定し，4 に戻る

セスを提案する．著者はこのプロセスを仮説指向プ(b) 新しい価値仮説の策定し，2 に戻る

ロセス (Hypothesis Oriented software development(c) PoC フェーズ終了

Process: HOP) と呼んでいる．HOP は，大きく PoC(d) プロジェクト終了

フェーズ，プロダクトフェーズ，運用フェーズの 3 つのフェーズから構成される．

図 2 に，PoC フェーズの流れのイメージを示す．この図で示すように，価値仮説とモデル仮説は同時に進むこととなる．

3. 1 PoC フェーズ
PoC フェーズは，その名前の通り PoC(Proof of

3. 2 プロダクトフェーズ

Concept) を実施するフェーズである．HOP のおいてプロダクトフェーズでは，モデル構築とプロダクト

は，機械学習システムには，2 種類の PoC が必要で開発を実施する．このフェーズにおいては，アジャイ

あり，2 種類の PoC を反復的に実施するものである．

ルのフレームワークである Scrum [10] に基づいて開1 つ目の PoC とは，機械学習においてよく言われ発を進める．本論文では，Scrum の詳細については

る PoC である．あるデータがあり，そのデータを元省略するが，ユーザストーリと呼ばれるユーザの体験に期待する機械学習モデルを構築することができるごとに機能を実装し，スプリントと呼ばれる期間を固定した反復開発を実施するフレームワークである．
ただし，機械学習を使わないソフトウェア開発とは異なり，以下のことを考慮する．

• 直接的にユーザに価値を提供しないモデル構築のための要件もユーザストーリとして扱う• 運用フェーズを想定した学習モデルの妥当性の確認手法を確立する• 機械学習システムの性質に応じた自動テストを記述する• done の定義として，モデルが想定外の振る舞いをした場合のテストケースを記述することを規

図3

定する
特に確率的な挙動の機能に対する自動テストは手PoC キャンバス

4. 1 PoC キャンバスの定義

法を検討する必要がある．その手法は本論文の範囲で

PoC キャンバスとは，図 3 に示す 10 の領域に区分はないが，単体テストに代表される通常の自動テスト

された表を埋めながら，PoC を整理する道具である．

の考えを拡張することも考えられる．例えば，一般的

PoC キャンバスの左側には，価値仮説に関する情報

な単体テストであれば，ある入力に対して期待する出を記載し，右側にはモデル仮説に関する情報を記載力が得られるかを検証するが，ある入力群に対して，する．

期待する出力が得られた割合が一定以上あるといった検証などが必要となる場合がある．

以下，PoC キャンバスの各領域について述べるが，各領域に付記した数字の順番に埋めていくことが容易であると思われる．まず，Diﬃculty の領域を検討

3. 3 運用フェーズ

することにより，対象とするシステムにおいて，機械運用フェーズは，プロダクトごとに検討する必要が学習が必要となる課題を明確にし，それに基づいて，あり画一的な手順を設定することは現実的ではない

Performance の領域を明確にすることにより，Diﬃ-と考える．ただし，以下の点は考慮すべき点である．

culty を解消するために必要な機械学習モデルの要件• 運用中に取得できたデータにより学習をするかを規定する．そして，PoC 仮設を中心に検討し，そのを確定する

Performance を実現するための Data と Algorithm• 学習する場合は，その妥当性をどのように検証に対して仮設を立てる．一方で，価値仮設を明確にするかを確定し，妥当でない場合にどうするかもするために，Customer とその Problem を明確にし，規定する

Value を記述することで，仮設上の矛盾の有無を確認• 運用中にソフトウェアのアップデートなどの介入方法について規定しておくする．その上で，Poc 仮設と価値仮設をつなぐためのAccountability や，Maintainability，Cost を整理することで，プロジェクトとして成立しうるかを検証可

4 PoC キャンバス

能とする．

HOP の PoC フェーズにおいては，価値仮説とモ

ただし，場合によっては，機械学習の実運用の企画

デル仮説の 2 種類の PoC を実施する．この仮説を同のために，PoC 仮設から入る場合もあるだろう．その時に整理する手法が PoC キャンバスである．本章で場合には，利用可能なデータについて検討して，Data

は，この PoC キャンバスを提案するとともに，HOPの項目から記述し，Algorithm，Performance と規定

においてどのような効果があるのかを示す．

しなければならない場合もあるだろう．そして，その機械学習モデルがあれば，解決できる Diﬃculty を探索し，それを元にプロダクトの企画を構築することも可能である．

4. 1. 3 Data
この領域には，PoC 仮設としての機械学習モデル

大事なことは，最初の時点で全ての項目を記述での構築，及び，評価に利用するデータについて，取得きる必要は必ずしもないかもしれないが，この PoC

経路，データのクレンジング，特徴量選択などの手法

キャンバスの全項目を記述し，その検証を行なえていについてもこの領域に記述する．

ない場合は，そのことを認識しながら，プロジェクト

4. 1. 4 Algorithmを進める必要があるということである．検証できてこの領域には，PoC 仮設としての機械学習モデルのいないということは，将来的にその仮設に対して，否構築に利用する学習アルゴリズムについて記述する．

定的な結論に至る可能性があるということであり，そ4. 1. 5 Customerの場合は，キャンバス上の周囲の領域を中心として，この領域には，価値仮説として，提供する価値を必

変更を加えなければならないということである．

要としているであろう顧客について記述する．この領

例えば，Peformance の領域において，想定した精域の記述の粒度については，対象などにも依存する度の学習モデルの構築が難しいということが判明しが，価値仮設の検証という観点からは，ペルソナ [9]た場合には，他のデータや，前処理を工夫するなど，まで抽出できていると望ましい．

Data の領域を変更する，または，より精度が期待で

4. 1. 6 Problem

きるアルゴリズムに変更するように Algorithm の領

この領域には，価値仮説として，顧客が抱えている域を変更する，もしくは，Diﬃculty を調整して，対であろう課題を記述する．この領域は具体的であれば象とする価値仮設を変更することを検討しなければあるほど，Diﬃculty の妥当性，及び，価値仮設の検ならない．

証が現実的かつ，迅速に実現することができる．

4. 1. 1 Diﬃculty

4. 1. 7 Value

この領域には，HOP においては，価値仮説の中核

この領域には，価値仮説の概要を記述する．

をなす記述であり，顧客価値を実現するために機械学

4. 1. 8 Accountability

習により解決しようとする困難な点である．この項目

この領域には，PoC 仮説として，機械学習モデルを検討する際には，併せて，機械学習を利用しない場に求められる説明可能性について記述する．ドメイン

合には，どのような代替手段が存在しうるかを記述すによっては，そのドメインにおける説明が可能である

る．代替手段で十分だと判断された場合には，機械学ことが重要な場合がある．そのような場合には，その習を利用しないシステムとすると判断する可能性も点を明記しておくことが重要である．

存在する．

4. 1. 2 Performance
この領域には，PoC 仮説として求められる機械学

4. 1. 9 Maintainability
この領域には，PoC 仮説として，機械学習モデルに求められる保守性について記述する．

習モデルの性能を記述し，PoC 仮設の中核をなす．

4. 1. 10 Cost

ここで言う性能とは，その機械学習モデルが見たす

この領域には，価値仮説として，プロジェクトに対べき，予測精度や，計算時間などのことである．まする期間や費用に対する制約を記述する．

た，この機械学習モデルの対象外としてよい場合があれば，併せて記載しておく．PoC 仮設において，こ4. 2 PoC キャンバスの例の記載が実現できないと判断された場合には，Data，

4. 3 キャンバスについて

Algorithm の変更，あるいは，価値仮設の Diﬃculty

これまでもキャンバスという概念は提案されてきの変更が検討される．

ている．代表的なものとしては，ビジネスモデルキャンバス [8]，リーンキャンバス [6]，仮説キャンバス [12]などがある．PoC キャンバスも，これらのキャンバ

スの考え方に影響を受けているが，これらのキャンバ
スは，検討するビジネスとそれを取りまく環境を整理することを目的としてキャンバスである．PoC キャ
ンバスは，機械学習システムには，確率的な挙動をする機械学習モデルと，ビジネス上の目的とを同時に監理するものである．

5 まとめと今後の課題
本稿では，HOP で利用する価値仮設と PoC 仮設
を同時に管理するための PoC キャンバスを提案した．
機械学習システムの開発は，産業界においては，徐々にノウハウは蓄積されてきているものの，適切に開発を管理するための体系的な手法は確立されているとは言えない．その理由の 1 つは，ソフトウェア工学においてこれまで扱ってこなかった種類の不確実性を扱うためである．PoC キャンバスにより，仮設を記述し，可視化することで，より適切な管理の手助けになると信じる．
現時点では，PoC キャンバス，及び，それを利用した HOP については，概念的に検証したに過ぎない．今後は，過去の機械学習プロジェクトをケースス
タディとして，HOP，及び，PoC キャンバスの有効性をより具体的に示すとともに，その内容をより洗練させていく予定である．

参 考 文 献[ 1 ] Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning,J., Highsmith, J., Hunt, A., Jeﬀries, R., Kern, J.,
Marick, B., Martin, R. C., Mellor, S., Schwaber,K., Sutherland, J., and Thomas, D.: Manifesto for

Agile Software Development, 2001.
[ 2 ] Blank, S., Blank, S., and Dorf, B.: The
Startup Owner’s Manual: The Step-by-step Guide
for Building a Great Company, K&S Ranch, Incorporated, 2012.
[ 3 ] Doi, T.: 機械学習を利用したシステムにおける仮説
検証を考慮した開発プロセスに関する考察, 日本ソフト
ウェア科学会 第 35 回大会講演論文集, 2018.
[ 4 ] Kim, M., Zimmermann, T., DeLine, R., andBegel, A.: The Emerging Role of Data Scientists
on Software Development Teams, Proceedings of the
38th International Conference on Software Engineering, ICSE ’16, New York, NY, USA, ACM,
2016, pp. 96–107.
[ 5 ] Masuda, S., Ono, K., Yasue, T., and Hosokawa,N.:
A Survey of Software Quality for Machine Learning Applications, 2018 IEEE International Conference on Software Testing, Verification
and Validation Workshops (ICSTW), April 2018,
pp. 279–284.
[ 6 ] Maurya, A.: Running Lean: Iterate from Plan
A to a Plan That Works, O’Reilly Media, Inc., 2ndedition, 2012.
[ 7 ] Mitchell, T.: The discipline of machine learning,Technical Report CMU ML-06 108, 2006.
[ 8 ] Osterwalder, A. and Pigneur, Y.: Business
Model Generation, Feb 2013.
[ 9 ] Pruitt, J. and Grudin, J.: Personas: Practiceand Theory, Proceedings of the 2003 Conferenceon Designing for User Experiences, DUX ’03, New
York, NY, USA, ACM, 2003, pp. 1–15.
[10] Schwaber, K. and Beedle, M.: Agile Software
Development with Scrum, Prentice Hall PTR, Upper Saddle River, NJ, USA, 1st edition, 2001.
[11] 内田和成: 仮説思考 BCG 流 問題発見・解決の発想法, 東洋経済新報社, 1st edition, 2006.
[12] 新井 剛市谷 聡啓: 翔泳社, 1st edition, 2018.
[13] 本橋洋介: 人工知能システムのプロジェクトがわかる本企画・開発から運用・保守まで, 翔泳社, 1st edition,
2018.
[14] 太田満久, 井上佳, 今津義充, 中山英樹, 上総虎智, 山裕市, 薗頭隆太, 草野隆史: 失敗しないデータ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで, 森北出版, 1st edition, 2018.