Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイル・スクラム勉強会_第2回

 アジャイル・スクラム勉強会_第2回

Satoshi Harada

July 20, 2022
Tweet

More Decks by Satoshi Harada

Other Decks in Programming

Transcript

  1. トヨタ生産方式(Toyota Production System)では、ムダを顧客に とっての付加価値を高めない各現象や結果と定義している。 このムダを無くすることが重要な取り組みとされる。ムダとは代表 的なものとして以下の7つがある。 • 作り過ぎのムダ • 手持ちのムダ

    • 運搬のムダ • 加工そのもののムダ • 在庫のムダ • 動作のムダ • 不良を作るムダ 2. 包括的なドキュメントよりも動くソフトウェアを価値とする 動くソフトウェア以外は中間生成物である。 • 各種設計書や仕様書 ◦ 要件定義書 ◦ 基本設計書 ◦ 詳細設計書 ◦ テスト仕様書 などなど • 動かないソフトウェア ◦ 実装途中のプログラム ◦ テストが完了していないプログラム ◦ レビューが完了していないプログラム ◦ まだリリースしていないプログラム 進捗はあくまでも顧客に価値をもたらす 「動くソフトウェア」で測るべきである
  2. 3. 契約交渉よりも顧客との協調を価値とする 受託開発の現場では、顧客との契約で既に取りまとめられているQCDSが優先されがち。 • Q:Quority(品質) • C:Cost(予算) • D:Derivary(期限) •

    S:Scope(範囲) しかし、プロダクト開発をLeanな状態(顧客までの価値の流れのムダを取り除き、高付加価値な製品を スピーディーに提供している状態)にしたくても、開発側に契約書面で示されたQCDS固定では変化に対 応できないという問題がある。 そのため、開発者は受託開発で言うところの顧客(発注元)と協調する必要があり、SaaSの自社開発で あれば自社のビジネス側の人と協調する必要がある。 協調とはすなわち、日々開発側とビジネス側の人が一緒に働くこと・対話をしていることである。 高付加価値な製品をスピーディーに提供するために 開発側の人とビジネス側の人は、日々一緒に働いて対話するのが良い
  3. 4. 契約に従うことよりも変化への対応を価値とする 受託開発の現場では、顧客との契約で既に取りまと められているQCDSが優先されがち。(再掲) そして、一度契約で取り決められたスケジュールや スコープを後から変えるのは大変難しい。 しかし、半年や1年といったスケジュールやロード マップを作ったとして、それがそのまま半年後や1年 後も市場において何も変わらずに競争力を持ってい ることは稀である。

    市場の変化するスピードや、顧客の変化する環境に合わせて、 スコープや優先順を柔軟に調整することが重要 変化を否定したり無視するのではなく、変化は積極的に受け入れる 3ヶ月 リリース1回 QCDS固定 リリース12回 QCD固定 S:スコープと優先順は、市場や顧客の状況に 応じて柔軟に調整・並び替えをする (例)
  4. 左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 左記の価値を認めながらも、 顧客までの価値の流れのムダを取り除き、高付加価値な製品を

    スピーディーに提供するには、右記の事柄を重視すべきだとしている 右記のことがらにより価値を置くが、左記の ことがらに価値はない・やる必要は無いとは 言っていない。 そのため、「アジャイルではドキュメントを 作らない」「アジャイルでは計画は作らな い」といった解釈は誤り。 アジャイルであっても、顧客に価値をもたら すために必要なのであれば左記のことがらに 取り組むことは当然ありえる。
  5. アジャイル宣言の背後にある12の原則 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的 に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化 を味方につけることによって、お客様の競争力を引き上げま す。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだ

    け短い時間間隔でリリースします。 4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒 に働かなければなりません。 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境 と支援を与え仕事が無事終わるまで彼らを信頼します。 6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・ トゥ・フェイスで話をすることです。 7. 動くソフトウェアこそが進捗の最も重要な尺度です。 8. アジャイル・プロセスは持続可能な開発を促進します。一定 のペースを継続的に維持できるようにしなければなりませ ん。 9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高 めます。 10. シンプルさ(ムダなく作れる量を最大限にすること)が本質 です。 11. 最良のアーキテクチャ・要求・設計は、自己組織的なチーム から生み出されます。 12. チームがもっと効率を高めることができるかを定期的に振り 返り、それに基づいて自分たちのやり方を最適に調整しま す。 4つの価値を実現するための行動指針が12の原則。 これらの原則をより具体的なルールとして落とし込んだ フレームワークやプラクティがScrumやXP
  6. アジャイルとは目指すべきものなのか Don't just Do Agile, Be Agile. アジャイルを行おうとするのではなく、アジャイルになろう。 アジャイルを行うことや、アジャイルのプラクティスを正しく行うことが目的ではない。 アジャイルソフトウェア開発宣言は、あくまで顧客に価値を提供する上で重視すべき4つの価値

    や、大切にすべき12の原則を提示したに過ぎない。 これら4つの価値や12の原則を厳格に行っていても、Leanな状態(顧客までの価値の流れのム ダを取り除き、高付加価値な製品をスピーディーに提供している状態)になっていないのな ら、そのアジャイルは無意味である。 どうすれば顧客に高付加価値な製品をスピーディーに提供できるか。それを考え尽くした末 に、自分の行動がアジャイルになっていた…という状態が理想と言える。 (故に、有識者は”アジャイルは「旅」である”と言うことがある)
  7. モーフィアス「これは最後のチャンスだ。先に進めば、もう戻れない。 青い薬を飲めば、お話は終わる。君はベッドで目を覚ます。好きなよう にすればいい。赤い薬を飲めば、君は不思議の国にとどまり、私がウサ ギの穴の奥底を見せてあげよう」 Morpheus: This is your last chance.

    After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes. アジャイルの4つの価値・12の原則を現状を変えずに取り込もうとする のは「青いピル」であり、自らのコンフォートゾーンを出ていない。 アジャイルの「赤いピル」を飲むとは、自らのコンフォートゾーンを飛 び出て、成功も失敗も自ら引き受けながらチャレンジしていくこと。 どちらを選ぶかは自分次第である。 赤いピルと青いピル ※赤いピルと青いピルのメタファーは、 James Coplien氏がよく使っている