目次
◆20世紀のポートフォリオマネジメント vs 20世紀のポートフォリオマネジメント
◇20世紀のポートフォリオマネジメント（伝統的なやり方）
- 伝統的なやり方で重視されているものは何か？
- それはどのような（古い）考えに基づいているのか？
- ソフトウェア開発には伝統的なマネジメントの考え方が残っている
- 伝統的なやり方の一部分だけをアジャイルにして効果があるのか？
◇21世紀のポートフォリオマネジメント（リーン・アジャイルなやり方）
- "計画"から"検証による学び"へ
- "渋滞"から"淀みのない流れ"へ
- "チームの頻繁な解散"から"継続することによる学びの蓄積"へ
◆結論
◇結論
- バックログ
- 検証による学び(validated learning)
- ポートフォリオかんばん(Portfolio Kanban Board)
- かんばんの重要さ
◇最後に
- 本当のビジネスアジリティを得るために
◆質疑応答
◇質問
ノート
◆20世紀のポートフォリオマネジメント vs 20世紀のポートフォリオマネジメント
◇20世紀のポートフォリオマネジメント（伝統的なやり方）
・伝統的なやり方で重視されているものは何か？
伝統的なPMOはガバナンスとコンプライアンスの2つに注目している。
1. ガバナンス
ビジョン・期待される結果からプロジェクトは始まり、プロジェクトタイトルに基づいて予算・リソースが配分される。そして、予算・スケジュールの中できちんと進んでいるかどうかが監視される。
→監視はしていても、価値について見落としている場合がある。
2. コンプライアンス
プロセスの方にばかり目がいっていて、パフォーマンスがおきざりにされている。
（きちんとプロセスをフォローし、コンプライアンスに対して監査することも重要）。
→こういうものを重視しすぎるために、顧客が本当に欲しいものを作る路線に乗っているのかを忘れられてしまう場合がある。
…こういったものはどういうところからきているのか？
・それはどのような（古い）考えに基づいているのか？
レフィングウェルは"古い考えに基づくものだが、いたるところにあった現象だ"と書いている。
そして、レフィングウェルはこの古い考え方について、次の指摘をしている。
1. widget engineering
ソフトは製造業のようなものだ、という意識からソフトウェア開発がなされている。図面を書き、それどうりに作れという考え方。
2. order-taker mentality
オーダーをとってから作るという考え方。作れといわれたものを作るというだけの考え方。プロダクトオーナーの考え方もこれに近い（プロダクトオーナー≠スクラムプロダクトオーナー）。
3. Maximize Utilization
そこにあるものを最大限使う。リソースが全て使われていないのであれば、開発でも全て使えないだろうという考え方。
盛りだくさんにしておけば、フィニッシュも盛りだくさんだよね？という考え方。
4. Control Through Milestones
どんなプロジェクトでもマイルストーンについては答えがもらえるという考え方で、マイルストーンについてチームメンバーが言い淀むことがあれば、そこを調べるというやり方。
（プロジェクトによってはマイルストーン自体が非常にファジィであるにも関わらず）。
5. We can plan a full year of projects
1年分のプラン考えることできるという考え方。きちんと計画すればそれをやり遂げることができるという妄想。
失敗する原因はプランニングそのものの何かが崩れているからなので、プランニングさえうまくやれば今年はうまくいくという考え方。
6. Just Get it done
なんでもいいからやれという考え方。
バリバリと推進するようなヒーローが必要で、その周りの人は残業で疲労困憊してしまう。
…非常に馴染み深いものばかりである。
ウォーターフォールメソッドが頭に焼き付いているとなかなかうまくいかない。チームレベルでガイダンスしても、そこから先が未知なので止まってしまうことがある。これを打破してアジャイルにいかないといけない。
レフィングウェルさんはウォーターフォールマインドセットという言葉を使っている。
・ソフトウェア開発には伝統的なマネジメントの考え方が残っている
テイラーは経営科学という世界で非常に有名な人である。
彼は、二人の作業員が一日にどれだけのタスクをこなすことができるかという実験をした。
これを基準値にしてベストプラクティス・標準時間を計るという考え方である。
これがガントチャートに転出され、それに基づいて労働者が働き、基準より早く作業ができればボーナスを出していた。
1900年代初期のやり方であり、馴染み深いやり方でもある。
彼の本は翻訳され日本でもベストセラーになった。WW2が始まるまでの間、日本の産業はテイラーイズムに基づいて成り立っていた。
1948年、日本でCivil Communication Section（民間通信局）による経営講座が行われ、ドラッカー・デミングなどのマネジメントモデルが入ってきた。
1979年には松下幸之助が、自分達のマネジメントが一歩進んでいるという話をするまでになった。
しかし、このような新しいマネジメントの考え方が登場した後でも、ソフトウェア開発の世界にはテイラーイズムの考え方が残っている。
何故だろうか？
もう少し違う考え方でソフトウェア開発に挑んでもよいのではないだろうか？
・伝統的なやり方の一部分だけをアジャイルにして効果があるのか？
ウォーターフォールでもうまく言っているという人がいるかもしれない。では何故そのような変化が必要なのだろうか？。
それは"Window of Stability"がどんどん小さくなっているからだ。
一昔前なら3年後の計画でよかったが、今なら3ヶ月後のことを考えないといけない。既にウォーターフォールでは追いつけないような時代に突入している。
多くの企業がアジャイルコンピューティングを導入している。
しかし最初と最後はウォーターフォールで、間だけアジャイルというのが多い(Water-Scrum-Fall)。
このやり方にビジネスアジリティがあるのだろうか？ そうではないと思う。
◇21世紀のポートフォリオマネジメント（リーン・アジャイルなやり方）
私はここで21世紀型のポートフォリオマネジメントを提案したい、
・"計画"から"検証による学び"へ
まずは詳細なビジネス計画から離脱する必要がある。これらは教養ある人が『予測しているだけに』すぎないものであり、実際の学習をベースに意思決定していくのとは全く異なる。
デミングが「知識というのはインテリジェンス（知能）とは異なる」といっている。つまりインテリジェンスを使うのはよいが、意思決定をするときは知識を使えといっている。
アジャイルではこれが重要視されていて、起きていることをさくさくと認識するやり方がとられている。何をやっているのか？その付加価値は何か？というのを認識しながら進めている。
計画にはもう1つ問題がある。
ときには計画通りに行くこともある。そうすると「計画通りだからうまくいっているに違いない」と考えてしまう。しかし、最後にエンドユーザーから「これでは使えない」といわれてしまう。
「それをするべきだろうか？」という考え方に変える必要がある。
実際に現場にいって検証することが大事である。
細かく検証することにより、ものすごく痛い間違いを回避することができる。
今まではProcess->Delivery, Process->Delivery, Process…というやり方を繰り返していた。
我々は、問題を解決したか、そこから何を学んだというサイクルに移っている。
・"滞留"から"淀みのない流れ"へ
フローではなくプロジェクトの滞留をマネジメントするというのがここでの考え方だ。
『たくさんインプットすればたくさんのアウトプットが出てくる』という考えではなく、『たくさん終わらせる = もっと沢山終わらせられる』という考え方にする必要がある。
人間はマルチタスクが下手な動物であり、グループの中でそれをやろうとするのは大変だ。
タスクがたくさんあるのもプライオリティが頻繁に移るのもよくない。
トヨタの生産システムを見れば分かる。1つ終われば次。
決してタスクがぱんぱんになっている訳ではない。
21世紀のポートフォリオマネジメントでは、優先順位を付けてことを進める。
このとき、ポリシーがあるから流れはスムーズになる。
・"チームの頻繁な解散"から"継続することによる学びの蓄積"へ
しかし、プロジェクトが大きい場合、1つ終われば次(One in one out)だけでうまくいくとは思えない。
プロジェクトの失敗は"何か広大なことを考えてしまって身動きがとれなくなる"こと。「始めてしまった、もう後戻りできない」となる。
こういう所だと、プロジェクトチームはいつの間にかバラバラにされてしまう。
しかし、我々はチームとして尊重されるべきであり、"用事があれば集まり、用事が無くなれば解散"すべきではないと考える。
学習を蓄積していったチームは、有用なメトリクスを所有する状態になる。
昔のような「わからないことはあの人が知っている」というのはよくない。チームが知っていないといけない。
◆結論
◇結論
・バックログ
バックログを使い、価値と優先順位をベースに入っていくようにする。
そうすることで自由に動けるし、軌道修正もできるようになる。
価値と優先順位について、リーンコミュニティではMVPと言っている。
実際に顧客に手に届くまで、価値があるかどうかはわからない。だから「いいね」といってもらえるかどうか、少しずつ小出しにして実験する。
アジャイルではDoneの定義と継続的インテグレーション。
間違ったものを継続的にデリバリする企業があるが、それは継続的な学習がかけているということである。
私たちがパスしなければいけないテストとは、お客が価値を感じたか、お金を出したかということである。
まずそこに行って何が欲しいかを学ぶ。そうすることによってアイデアが出てくる。
それから実験してテスト。
それを継続的にデリバリする。
そしてお客からフィードバックをもらい、学習し、そしてサイクルを回す（リーンスタートアップのあれ）。
・検証による学び(validated learning)
我々は「これは価値になるはず」と思い込みがちである。
そう思っているなら早く検証する、"検証による学び"というのがポイントだ。
On budget, on planningでは不十分で、お客が満足しなければアウトである。
・ポートフォリオかんばん(Portfolio Kanban Board)
我々は劇的な透過性(Radical visibillity)という考えを用いている。
これは、『見えないことはリスクであり、プロジェクトの全てが見えているのであればリスクは低減できている』ということを意味している。
そして、劇的な透過性を得るためにポートフォリオかんばんを使っている。
ここにはチームレベルの情報が入っていて、入ってくるもの出て行くものをチームが見ることができる。また、価値が検証されてお客様に届くまでの流れも書いてある。
1. study
まずはスタディしてアイデアを出す。
2. ready
ここでは実験。acceptance, validation criteriaが重視される。
全て想定に基づいていた今までのやり方をバリデーションに変え、検証することをかなり絞る。
3. work cell
リリースに向けて動いている段階。
ワークセルの中をいっぱいにするのではなく、リミッタをかけて最小限にしている。
やっているものがほとんど終わったら次を入れる。
ブロックされている場合、一目でわかるのでディスカッションが始まる。
ここで依存関係も見ることができる。
4. release
ここではエンドユーザが試用を行う。
ほとんどのアジャイルチームはここで作業は終わり。
しかし、我々は"contenious validation learning"をしたいので…
5. 1. Pivot
もうちょっと考えが必要かな？というものはPivotにおいておく。
5. 2. Failed
失敗してしまったものはFailedというところにいれておく。
Failedも別に悪いことではない。学べればそれは大変な教材である。
5. 3. Validated
価値が検証されたものが入る。
…そしてこれはサイクルになっている。
Pivotを見ていて浮かんだアイデアは、ワークセルに入っていく。
ポートフォリオかんばんで、コンプライアンスやプロジェクトの健康状態・進捗・学びが一目瞭然に共有されるようになる。
・かんばんの重要さ
かんばんは、ソフトウェア開発から戦略変更まで使うことができる。
かんばんが何故こんなに重要か？
大野耐一も言っている。「イノベーション・改革・継続的な改善を促すためにかんばんは不可欠だ」
◇最後に
・本当のビジネスアジリティを得るために
20世紀のやり方というのは1890年代にさかのぼる。
このような古い考え方に固守せず、離脱しなければいけない。
本当のビジネスアジリティを得るためには、20世紀のやり方を捨てないといけない。
もうずっと続いていてしみこんだ考え方だが、これを捨てれば、顧客からのフィードバックでさくさくと開発していくことができるはず。
それは21世紀型の思考を持っているからだ。
意識を切り替えることは簡単ではないが、まずは自分達の組織からTryするということ。
得られる結果はすばらしいものばかりである。
◆質疑応答
◇質問
Q.
アイデアには優先順位をつけないといけないが、アイデアの評価というものは難しくないか？
どうやれば？
A.
それは顧客からのフィードバックによる。
エンドユーザに聞いてみるのがよい。
携わる人が会議室に篭って評価しても、それは「思う」だけのことに過ぎない。
David Joyce様, ThoughtWorks Inc.様, 株式会社テクノロジックアート様ありがとうございました。
0 件のコメント:
コメントを投稿