プロジェクトマネジメントは、「プロジェクトの進め方」のことです。
ウォーターフォールとアジャイルは、いずれもプロジェクトの代表的な進め方です。
プロジェクトマネジメントの基本は、
順番が、立ち上げ、計画、実行、監視・コントロール、となるところですが、ウォーターフォールはこれをこのまま実行します。
アジャイルの場合は、規模の小さな形でこれを何度も回して、完成度を高めて行きます。
問題解決の手順 にQCストーリーやDMAICがあります。 これらは、見た目にはウォーターフォールと似ていますし、最終的なプロジェクトのまとめは、あたかもウォーターフォールで進めたようなまとめ方をします。
ウォーターフォールのようにして厳格にこの順番を進めるケースもありますが、 実際の進め方は、アジャイル的です。何度も回して行きます。 何度も回してわかったこと、できたことについて、人にわかりやすく説明したり、論理に飛躍がないのかをチェックするために、ウォーターフォールで進めたようなまとめ方をします。
ウォーターフォールの短所として、 物が完成してから、それを見て、「こうすれば良かった」、「こうしなければ良かった」となることがあります。 ひどい場合は、せっかく作ったものが、まったく使われないこともあります。
一般的にアジャイルの説明がされる時には、ウォーターフォールの短所への対策になっています。 しかし、アジャイルにはアジャイルの短所があります。 また、ウォーターフォールとアジャイルは、かなり異なるため、簡単に変更できるものでもないです。
ところで、ウォーターフォールの短所への対策は、アジャイルだけではないです。 他にも対策が考えられていて、こうした方法は、アジャイルへの変更よりも進めやすいです。
アジャイル以外の対策には、「要件定義の精度を高める」、「試作段階を追加する」、「PDPC」があります。
ウォーターフォールへの直接的な対策として、 要件定義 の改善があります。 ユーザの要求をそのままシステムにするのではなく、適切なシステムのあり方を検討します。
プロジェクトが終わってから出て来る、「こうすれば良かった」、「こうしなければ良かった」という事への直接的な対策になります。
本格的に物を作り始める前に、試作段階をいれることがあります。
試作段階というのは、PoCの実施、模型の制作、試作品の制作、仮想空間の制作(シミュレーション)、等です。 PoCは、Proof of Concept(概念実証)の略で、人工知能(AI) 関係でよく使われています。
ちなみに、試作段階を何度も繰り返すような進め方の場合、アジャイルと似ています。
PDPCは、Process Decision Program Chartの略です。 新QC7つ道具 のひとつになっています。
場合によっては進め方を変える必要がある時に、あらかじめそれを想定しておく方法です。 プロジェクトをある程度進めてみて、途中でわかった情報を使って、プロジェクトの中止や、成果物の内容を変えます。
この方法の難しい点として、「場合によっては進め方を変える必要がある」というのが、事前にわかっていなければいけない点があります。 経験的に想定できることもありますが、そうでない場合は難しいです。
PDPCの「とりあえず進めてから判断する」という考え方は、アジャイルと似ています。
プロジェクトマネジメントの対象は、立場によって、いろいろあります。 そのため、「プロジェクトマネジメント」と書かれている文献が含んでんいる範囲も、いろいろです。
「広い」には、何かを作るようなプロジェクトは、何でも入って来ます。
「一番広い」には何かを作る訳ではないプロジェクトも入ってきます。
例えば、
小集団活動
や
シックスシグマ
の活動があります。
問題解決の手順 や、 意思決定論 の議論の中では、「ベストな進め方は選択肢を広く考えてから、決めていこう」という考え方をすることが多いです。 広い視点のプロジェクトをする時に、このような考え方は大事です。
広い視点のプロジェクトでは、いくつかの選択肢がある中で、「ITシステムを作ろう」ということが選ばれることがあります。
一方、議論がスタートした時に念頭にあることや、最初から「ITシステムを作ろう」となっているプロジェクトも世の中にはあります。
立場によっては、もっと早く安い選択肢が選べることもありますが、 立場上の制約などによって、選択の余地がないこともあります。
問題解決の手順 や 課題達成の手順 は、プロジェクトになります。
問題解決や課題達成の中では、対策が決まる段階があります。 ややこしいのですが、対策が決まると、対策の実行の部分だけがプロジェクトになることがあります。 つまり、大きなプロジェクトの中に、小さなプロジェクトが入っている形になります。
世の中には、「AI・機械学習・データ分析のプロジェクト」というものもあります。 以下の特徴があります。
「会社の問題解決や課題達成のためには、 AI・機械学習・データ分析のプロジェクトを立ち上げて、システムを作る」という話は、 世の中では、よく解説されています。
しかし、AI・機械学習・データ分析のプロジェクトには、独特の難しさがあります。 難しさの原因としては、PoCやメンテナンスがあることよりも、以下の事情の方が多いようです。
ちなみに、 データの利活用の進め方 に似た話があります。
筆者の経験の範囲ですが、 会社の中の問題や課題に対して、プロジェクトを立ち上げて進める場合は、 問題解決の手順 や 課題達成の手順 をベースとした進め方が基本です。
まず、データ分析ですが、 問題解決と課題達成のためのデータサイエンス のページにあるように 、 問題解決の手順 や 課題達成の手順 の中で、適材適所で実行すると効果的です。 それなりに大変なデータ分析になるのなら、 この部分だけを、プロジェクトの中のプロジェクトとして進めた方が良いことがあります。
対策や方策を検討する中で、ひとつのアイディアとして、「AIや機械学習を使う」というのが出て来ることがあります。 ここまで進んだ場合に、プロジェクトの中のプロジェクトとして、AIや機械学習を使ったシステムのプロジェクトを立ち上げると良いです。
なお、実際には、「AI・機械学習・データ分析をやってみたい」ということが先に来て、 その目的として問題解決・課題達成の題材が選ばれることもあります。 そのような経緯だとしても、順番を入れ替えてロジックを考えるのが、一番良いようです。 世の中の成功例も、この入れ替えがうまくできたものが多いような気がしています。
何かを作るプロジェクトのプロジェクトマネジメントについては、 システムズエンジニアリング の分野でも扱われています。
「PMBOK Guide Seventh Edition」 Project Management Institute 著 2021
日本語版もありますが、筆者が読んだのは英語版です。
元の表現を知りたかったこともありますが、一番の理由は価格です。英語版は時価で販売されているようです。
第6版は、前半が、BOK(Body Of Knowledge)で、プロジェクトマネジメントをする中で必要な観点がまとまっていました。
後半が、プロジェクトマネジメントの標準として、プロジェクトの基本的な進め方が書かれています。
第7版は、前半がプロジェクトマネジメントの標準というタイトルですが、第6版とは違って、ここに書かれているのは
、原理です。
原理として、プロジェクトを進める時の考え方が書かれています。
プロジェクトマネジメントは、価値を届けるものであることを説明して、後半の内容につなげています。
後半がBoKで、原理で書かれていることが、より具体的に書かれています。
アプローチの違いは、2.3のところでまとまっています。
アプローチは、プロジェクトによって使い分けるものとしています。
ウォーターフォールやアジャイル以外のものもあります。
ウォーターフォールは、「ウォーターフォール」という名前よりも、「予測型(predictive)アプローチ」という表現になっています。
アジャイルは、「アジャイル」という名前よりも、「適応型(adaptive)アプローチ」という表現になっています。
予測型アプローチでは、オプションの探索のために、PoC(Proof-of-Concept)を実行することがあることも書かれています。
個々の場面向けの考え方の手順は、モデルや方法として最後の方に、列挙されています。
「よりよくわかるプロジェクトマネジメント」 日本プロジェクトマネジメント協会 編 オーム社 2019
プロジェクトマネジメントの本は、抽象的な表現が多くなりがちですが、この本は、
家づくりプロジェクトを通して、わかりやすく解説しています。
「プロジェクトマネジメント・ツールボックス」 ドラガン・ミロセビッチ 著 鹿島出版会 2007
プロジェクトの選定、計画、実行の各段階で使うツールについて、体系的に詳しく解説しています。
「プロジェクトマネジメントのトリセツ」 西村克己 著 日本実業出版社 2007
会話形式の部分も含めながら解説しています。
「よくわかる最新PMBOKの基本と要点」 鈴木安而 著 秀和システム 2012
PMBOKの第4版までの内容が、コンパクトにまとまっています。
「よくわかる最新プロジェクトマネジメントの基本と要点」 鈴木安而 著 秀和システム 2013
PMBOKと比べると、コミュニケーション、チームワーク、リスク管理、といった、漠然としているけれども重要な項目についての説明が多いです。
「遅延ゼロのプロジェクト・マネジメント講座 納期に追われるプロマネとリーダーが読む本」 木村哲 著 技術評論社 2021
プロジェクトを実行する中で起きる様々な問題とその対策を、著者の豊富な経験を元にしてまとめられています。
さまざまな事が書かれていますが、会議、計画、メール作成、等に対して、
時間のロスが起きないようにすることと、常に先のことを考えて準備を進め、それぞれの行動が始まるまでにも時間のロスがないようにしておくことが共通しているようでした。
著者は、プロジェクトの4つの基本原則は、ゼロベース発想、変化柔軟性、コンピテンス基盤(利害関係者とうまくやって行けるようにする)、価値評価を挙げているのですが、筆者としては、たいていのプロジェクトはこの原則が成り立ってないように思っています。
WBS(スケジュールの作成)は、工程設計と似ている。作業項目の洗い出しではない。
「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法」 市谷聡啓・新井剛・小田中育生 著 インプレス 2020
アジャイル開発について、チームのあり方、等も含めてまとまっています。
「誰も教えてくれなかったアジャイル開発」 堀哲也 他 著 日経BP 2022
教科書通りにアジャイル開発を進めようとして、うまく行かない時の話が、豊富に紹介されています。
アジャイル開発が扱う不確実さに対して、計画、報告、契約、成功基準といったもの厳格に定めることを対策にすることで、
本来やるべきことよりも、そちらの対応の方が大変になるような話が多い印象でした。
「データ×AI人材キャリア大全 職種・業務別に見る必要なスキルとキャリア設計」」 村上智之 著 翔泳社 2022
データ×AI活用プロジェクトと、「データ×AIの人材になるには」といった内容の本です。
「データ×AI活用」と「データ×AI活用プロジェクト」として、それぞれ3つを挙げて、対応関係がありました。
・「機械学習による自動化」:「機械学習システム構築プロジェクト」
・「データに基づいたインサイトの発見」:「データ分析プロジェクト」(データを根拠にした施策案がアウトプット)
・「データに基づいた経営判断」:「データ可視化・BI構築プロジェクト」
「データ分析プロジェクト実践トレーニング ケーススタディで学ぶ現場の問題解決」 下山輝昌・川又良夫・佐藤百子 著 秀和システム 2022
アイディア創出、やりたいことに対する現状の精査、強みの再発見、おおまかな将来像づくり、ユーザーごとの「つくるもの群」の設定、
試行錯誤(「つくってみる」ユーザーに「あててみる」)、運用へのインストールの7つの項目を「地図」と読んでいます。
プロジェクトの進め方の一般的な説明は、こうした項目は「プロセス」として説明されるので、まずここから違っています。
この本では、地図のどこから始めても良いし、同時でも良い、としています。
常に自分たちが地図のどの位置を進めているのかを念頭に置いて、地図の中の情報をどんどん更新していく進め方になっています。
正解がない、正解がわからない、何をしたら良いのかがわからない、といったスタートの中で、進めながら答えを見つけて行く、
答えを高めて行く、という考え方です。
このページで、QCストーリーやDAMICの順番は最終形態であって、実際の進め方ではないことを書いていますが、それと同じ考え方をされています。
「データ分析人材になる。 目指すは「ビジネストランスレーター」」 木田浩理 他 著 日経BP 2020
Demand、Design、Data、Develop、Deployの5段階でデータ分析のプロジェクトが進みます。
料理人が、要望を聞いて、食材を集め、調理、食べてもらう、といった順で進むことを例にしています。
「ビジネストランスレーター データ分析を成果につなげる最強のビジネス思考術」 木田浩理 他 著 日経BP 2023
三井住友海上火災保険 経営企画部 CXマーケティングチームの皆さんによる共著となっています。
ビジネストランスレーターのスキルとして、ビジネススキーマ活用力、プロジェクト遂行力、ビジネス背景理解力、データ解釈基礎力を示し、
ビジネストランスレーターの役割を明確にしています。
「いちばんやさしい機械学習プロジェクトの教本 人気講師が教える仕事にAIを導入する方法」 韮原祐介 著 インプレス 2018
企業内へのシステムの導入に従事してきた著者が、
機械学習を組み込んだシステムの導入について、体系的にまとめています。
通常(従来)のシステムは演繹的。機械学習のシステムは帰納的であり、データから推論して結論を出す。
機械学習のシステムを作るには、質の良いデータが大量に必要。そのため、実際のデータを使ったテストが大事。
「人工知能システムのプロジェクトがわかる本 企画・開発から運用・保守まで」 本橋洋介 著 翔泳社 2018
人工知能システムの開発に特有なのは、データ分析、テストの実施、モデルのメンテナンスがあること。
モデル作成では、異常値やデータの偏りに気を付ける。
的中率が70%だったとして、それが良い悪いかは、人がやる場合と比較する。
すべてを人工知能に任せるのでさなく、人と協調していく。
「データ分析プロジェクトの手引 データの前処理から予測モデルの運用までを俯瞰する20章」 David Nettleton 著 共立出版 2017
マーケティング、保険の加入者、テレビの視聴率といった、社内から社外の動きを見るデータ分析が題材になっています。
実際に検討されたデータの項目も、かなり具体的です。
目的のためなら、何でも使う感じで、
決定木
、
回帰分析
、
ネットワーク分析
などがありました。
分析で実際に大変な事の話は、ありませんでした。
システム開発やプロジェクトの話は少しで、ほとんどが分析の話です。
データ分析は、データからの知識発見と、モデリングのためにしています。
(
因果推論
のためではないです。)
モデリングはシステム開発につなげている。
「AIエンジニアの実務と知識がこれ1冊でしっかりわかる教科書」 AIエンジニア研究会 著 技術評論社 2021
AIの入ったシステムの開発の手順として、要件定義の前に、アセスメントとPoCの段階が入っています。
アセスメントとは、どんなデータで何をするAIなのかを決める段階です。
PoCは、AIを試しに作ってみる段階です。
「AI・データ分析プロジェクトのすべて ビジネス力×技術力=価値創出」 大城信晃 他 著 技術評論社 2021
データサイエンティストという立場の人が、プロジェクトとして、AIを作るスタイルが想定されています。
「仕事ではじめる機械学習」 有賀康顕・中山心太・西林孝 著 オライリー・ジャパン 2018
プロジェクトとして
機械学習
を使うことを想定していますが、
プロジェクト特有の話は少しです。
代表的な機械学習の手法を紹介。
効果検証として、
検定
や
因果推論
。
機械学習を使わない分析として、Kickstarterを使ったExcelベースやのデータ分析。
順路
次は
業務フロー