CSP-SM受けてみることにした そのxに向かって「Leanとアジャイルの関連を深める」
これまでのあらすじはここから
Googleドキュメントでのお題が終わり、いよいよTrelloボードにある課題に対してレポートをしていく形式になってきた。
そうなってくるといよいよ記事に日本語でまとめてから英語に編集する方がインクリメンタルだと思った。
なので、記事として先に公開していく形式にする。
それぞれの設問(英語を意訳)に対して、私の回答を記載する。
1.4 Leanのプラクティスとアジャイル開発の原則を最低3つ紐付けよ
まずは3つを選ぶ(Leanを基準に抽出)
フロー効率
加工のムダ
従業員の創造性を使わないムダ
フロー効率を考える
「フロー効率」をアジャイルと関連させる
このプラクティスが関連づけられるものはアジャイルだと
プロセスやツールよりも個人と対話を
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
ここらへんか？
リーンの「フロー効率」をあげるというプラクティスに対して、アジャイルマニフェストとプリンシプルから言葉を引用し関連づける。
リーンにおいては、リソース効率(人的リソースを余すところなく使う！残業せず給料の分だけ的確に働かせる！)よりもフロー効率(顧客に価値を届けるためには、多少の人の余りよりも価値提供を優先する)が重要視される。
それにおいて「プロセスよりも対話」という概念と「ビジネスと開発は一緒に働く」という概念は必須である。
なぜならば、価値提供を優先するためには時にはプロセスよりも対話が重要になってくる。
例えば、あなたが顧客対応のメンバーだとす。目の前の顧客に対して些細な手助けや価値提供をするために、わざわざ本社の社長にお伺いを立てるだろうか？
プロセスが大事ではないと言っているのではなく、提供する価値の大きさとお伺いを立てるなりのプロセスの、より良き塩梅を目指すことが重要だという意図になる。
そのためには、プロダクト開発において、ビジネスメンバーと開発者は同じ土俵で共に進む必要がある。
よくないのは例えば以下。
ビジネスメンバーが開発者のことを蔑ろにして指示だけをする。
逆に、開発者がビジネスメンバーのことを蔑ろにして機能美や内側の美徳のみを優先する。
そうなった時、そのプロダクトは部分最適な顧客に価値が薄いサービスになるだろう。
ビジネスと開発が共に顧客すらも気づいていないニーズに対して多様な意見を出し合っていく場が存在し、判断していくことで価値提供が早くなる。
双方の意見をプロダクトに反映し価値提供をするためには、縦割りやプロセス遵守をして遠回りをしている時間はないのだ。
どのプロセスに則るか、ツールはどこからのみ受け付けるかなどを守ることよりも、変わりゆくニーズに対してJust In Time(トヨタの言葉)で価値提供をする必要がある。
実体験による学び
あるプロダクトチームでは、さまざまなチームがそれぞれの得意な領域によって分断されていた。例えば、ビジネス企画と開発、マーケなどである。
ある日、ビジネス企画チームが開発チームに追加機能開発の見積もり依頼をしたときの出来事だ。
ビジネス企画チームの要求に対して、開発チームはとても大きな見積もりを出した。私が聞いている「本質的提供価値の実現」のためにかかるにしてはあまりにも膨大な見積もりを回答した。
ビジネス企画チームと開発チームは、何往復かののちに、当初の何分の１かの工数を提示することになった。
ここからの学び・・・ビジネス企画の要求により、厳密に見積もりを行った開発チームは正直に膨大な工数を見積もってしまった。
しかし、提供価値を実現するためにはもっと最小の工数で実現が可能であった。
要求を満たすことに終始したために膨大となった工数も、最初から本質的価値を理解し取り組めば、顧客への到達見積すら短縮ができたはずだ。
さらに、その往復のリードタイムですら、無駄でしかない。
加工のムダを考える
「加工のムダ」をアジャイルと関連させる
このプラクティスが関連づけられるものはアジャイルだと
計画に従うことよりも変化への対応を
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
「加工のムダ」は、過剰な加工をすることは、加工に対する時間とお金のムダになる。さらには、ムダな加工の品質を担保することに対しても対価を払うことになる。必要なものだけ必要な量供給することが、最適であるという話。
「変化に対応する」そのためには、過剰な加工をしている余裕はない。いくら”計画”が計画された当初は完璧なものだったとしても、それは変わりゆく。計画当時に必要だった加工が今不要だと知ることができたなら、それは喜んで捨て、加工するはずだった余力を他への対応に向けるべきだ。
さらにそのためには「シンプルさが本質」である。
ムダのない生産をし価値を届けることができていれば、必ずムダなく対価が手に入る状態である。必要な加工で必要な価値を届けるいことが全体最適となる。
実体験による学び
あるプロジェクトで、かなり高い確実でいつか使うであろう機能開発をおこなった。機能開発には3ヶ月ほどの期間がかかった。いつか使うであろう機能なので、汎用的な機能とはいえ具体的な仕様は決まりづらく、ちょっとした仕様を決めることすら想定よりも難易度が高かった。そのような経緯をたどって完成した機能である。しかし、その機能は、そもそものプロダクトが作られないという現実により、最短で公開する機会を失った。
この話は、かけた工数だけのムダでは終わらない。
なまじ機能ができてしまったがために、次にこの機能をリリースしたいプロダクトが現れた時には、このプロダクトの初期よりも短い開発期間が求められるだろう。
しかし、その時にどれだけこの機能についてエンジニアが記憶しているかわからない。
機能についてどこまで覚えているかわからないにもかかわらず。その状態でカスタマイズを施す可能性すらある。
いつ使うかわからない機能を完成させたがために、不確実性を多く含ませてしまった例だ。
従業員の創造性を使わないムダを考える
「従業員の創造性を使わないムダ」をアジャイルと関連させる
このプラクティスが関連づけられるものはアジャイルだと
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
顧客すら自分達のニーズに気付けないVUCA時代と言われる今だからこそ、少しでも多様な意見を取り入れるためには働いている全ての人の価値観は重要である。
従業員の創造性は、プロダクトに直接的にも間接的にも結びつく。
プロダクトの特徴として何かの意見を出してくれるかも知れない。
プロダクトを作るにあたってのカイゼン提案をしてくれるかもしれない。
満場一致ではなく、ほんの僅かな人が感じる違和感こそが物事の本質かも知れない。
従業員の創造性をより発揮するためにはどうするか。
「意欲に満ちた人で構成する」これは、意欲のある人を集めるという意味だけではないと思う。意欲がある状態にするのがスクラムマスターの視点では重要である。メンバーを意欲的にし、自由に意見を発信し、能動的にプロダクトと向き合ってもらう必要がある。
そのためには、環境と支援が不可欠である。
プロダクトを創造的に作る環境。物理的にも精神的にもである。
スクラムマスターのみならず、ステークホルダーも支援をする必要があるだろう。
最も重要な部分は「信頼」である。信頼というとまるで精神論に聞こえてしまうが、適切な決裁権を与えることは可能である。
より良い成功体験のために失敗できる環境を与え、成功も失敗も学びに帰られるように安全な背景と決定権を渡す。
これにより、プロダクトチーム全体での相乗効果を最大化する必要がある。
実体験による学び
規律と統制の取れた営業組織で新たに企画されたプロダクトがある。トップダウンで推奨され、次世代の企業を担うサービスとされ営業コストも多大にかけている。
壮大な計画のもと運営されているこのサービスは、従順なソルジャーたる営業部隊に下支えされ営業活動が行われている。
しかし、なかなか結果が出ない。
なぜならば、レッドオーシャンの市場に単純に代わり映えのしない機能しか持っていないプロダクトだからだ。
そのプロダクトに対して意見をするメンバーはいない。
どうやってプロダクトをよくするかではなく、
どうやってKPIを達成するのかのみが語られている。