私は約2年間、ソフトウェアベンダでリーンソフトウエア開発の実践を担っています。この期間、企業向けソリューションのふたつの連続するバージョン(V2とV3)の開発を通じて大きなチームにコーチングを提供してきました。
私たちは組織に、7つの変更を加えることでR&D部門を支援し、開発プロセスから無駄を排除して、成果があがるようにしました。この記事では、この7つの変更について、そして私たちが獲得したこと、私たちが学んだことについて書きたいと思います。
チームとプロジェクトについて
この企業向けソリューションの新しいバージョンには70人が関係していました。チームに分割すると下記の通りです。
- 開発 : 6のスクラムチーム、ソリューションの開発を行う。
- 統合 : 統合テストを実施する。
- 機能アナリスト : たいていの場合プロダクトオーナ
- 機能アーキテクト : 異なるアプリケーション間の機能の一貫性を担当する。
- テクニカルアーキテクト
- UXデザイナー
- 継続的統合とリリースチーム
問題の設定
最初のV1(標準的な開発プロセスで開発)では、12ヶ月の期間を計画しました。10ヶ月の機能開発期間と2ヶ月のコード凍結/統合テストの期間です。
実際は機能を開発し、統合テストチームに開発した成果物を渡すまでに12ヶ月かかりました。2ヶ月遅れたのです。そして、さらに統合テスト/機能の安定に11ヶ月(2ヶ月ではなく)かかりました。さらにふたつのサービスパックバージョンの提供に7ヶ月かかりました。
コスト/アクティビティの観点から考えると、私たちは開発スケジュールやコスト(20%の遅延)について大きな問題とは思っていませんでした。大きな問題だったのは、統合/メンテナンスです。安定化に2ヶ月ではなく、11ヶ月もかかってしまったことです。サービスパック開発の7ヶ月はリリースとは別で考えていました。メンテナンス予算に含んだのです。
リーンの考え方の場合(例えば、顧客の観点から見る)は、以下のような問題が現れます。
- 12ヶ月の開発計画が23ヶ月かかって顧客に価値を提供することになってしまった(サービスパックを考慮すると30ヶ月)。11ヶ月の遅延。その結果は以下の通り。
- 遅延: 遅れたことは顧客を幸せにしない。
- コスト: 追加で11ヶ月分のコストを支払い、リリースするためのリソースを確保した。
- 遅延: リリースNを準備している間、準備できないリリースN+1も遅れる。
- 収入: 売り上げがあがるまで11ヶ月遅延する。会社が投資したソフトウエアスタックは積み上がる。
図 1: 遅延の観点から見た問題
- 安定化期間とサービスパック開発でのバグフィックスのための開発は、時間と労力は無駄になってしまいます。
図 2: 無駄の観点から見た問題
関係者の意見
プロジェクト開始時点で関係者の多くにインタビューをしました。次のような発言がありました。
R&Dが何かをシンプルに実施するのは難しいことです。顧客に対して価値を持つある機能があったとして、それが簡単に開発できるとしても、R&Dでは誰も関心を持ちません。
R&Dには顧客が製品を使って何をするか知っている人は誰もいません。R&Dが提供した製品からマーケティングチームは5分で20のバグを見つけました。
組織を通じて責任が薄められるので、パフォーマンスを上げるために一丸となって動くよりも、個々人によって生存戦略が異なるようになる。
原因分析: 誤解を理解する
開発プロセスの間、私たちは次のような大きな誤解をしていました。
- 機能開発が最大の目的である。機能が顧客に対する価値になるのだから。
- いくつかのバグがあっても問題ない。安定化期間で対処するから。
- コード凍結して品質の高いソフトウエアを提供するのに2ヶ月あれば十分。
上述の通り、このような誤解はコスト/アクティビティの観点から生まれています。この観点から考えると自分たちのソフトウエア開発プロセスは受け入れられるものだと思ってしまう傾向があるのです。
その結果、チームは機能開発を懸命に行い、品質にはあまり目を向けませんでした。«2ヶ月の安定化期間がある。それで十分。».
そして、コード凍結の期間で起こったことは、
- バグの下に更なるバグが隠れていた。
- ある部分のテストカバレッジが低いため、バグ修正でさらにバグが生まれる。
- 上のふたつが原因で、いつコードがリリースできる状態になるか予測がつかない。実際は11ヶ月かかった。
- 追加の7ヶ月でふたつのサービスパックを開発しなければならなかった。
V1開発で発見した上記のような問題をふまえ、以下では次のふたつのバージョンでリーンソフトウエア開発を実践し、どのようなことを実施したのかについて説明します。
私たちの仮説
リーンソフトウエア開発の手法を導入した私たちは異なる視点を持ちました。
私たちの仮説はこうでした。最初の段階の低い品質がリードタイムを毀損し、大量の手戻りと18(11 + 7)ヶ月の手戻りを生み出した。
基準
リーンの基準は品質に対してかなり率直です。品質に問題があると認識しているものを、次のステップに渡してはならない。
とてもシンプルです。しかしJeffrey Pfeiffer氏とRobert Sutton氏がThe Knowing Doing Gapで説明しているようにシンプルであることと簡単であることは同じではありません。日々の実践でシンプルを実現するのは難しいことです。
プロセスを理解する
ソフトウエア開発の観点から考えると、プロセスを理解するということは次の3つの点を明確にし、プロセスを強化できるようにすることです。
- プロセスを構成する作業
- 異なるステップで構成される実際のプロセス。
- 各ステップのインターフェース。どの程度の品質水準であればOKで次のステップに進めるか。
作業単位はユーザストーリーです。
プロセスは3つの大きなフェーズに分割しました(フェーズはさらにステップに分割されます)。
- 機能分析: ユーザストーリーを定義する。
- 開発とテスト
- 統合テスト
私たちはインターフェースとOK/NOKの条件を決めました。
- ひとつのユーザストーリーはReady To Developというステータスにならなければ開発しない。このステータスは機能アナリストと機能アーキテクト(ソリューションの機能的一貫性に責任を持つ)、UXデザイナー、開発者、テスター(チーム内の)が設定する。
- ひとつのユーザストーリーはDoneというステータスにならなければ統合されない。つまり、機能的なスコープでバグが0(例えば、正常系のテストがOKなだけではなく、チーム内のテスターが定めたテストがすべてOK)で、機能アナリストもUXデザイナもユーザストーリーに対してOKを出しているという状態になってから統合が行われる行なわれる。
- 統合テストのすべてのプロセスでバグがない状態になるまで、リリースしない。
無駄を削減するための7つの変更
ルールを定義した後、このルールを適用するための方法をチームに提供する必要がありました。私たちは次の7つを導入し、チームを支援しました。
- 作業単位をユーザストーリーにする。
- デイリーフォローアップ
- ビジュアルマネジメント
- 機能分析のためのフォローアップ
- 組み込みテスター
- スプリントのコード凍結をやめる
- Stop the Line
ユーザストーリー
プロセス全体の設計をしているときに、メンバーがひとりでプロセスの各ステップにフォーカスしていることが多いことに気づきました。プロセス内の作業単位について十分に思考を巡らせることに時間を使っていないようなのです。
私はユーザストーリーが大好きです。小さくてシンプル、そして最も大事なことですがユーザの視点で記述されているからです。価値を視覚化してくれますし、簡単に見積もれます(頭字語INVESTを参照してください)。
ユーザストーリーを作業単位として考えると、顧客の要求とチームの努力が合うようになるのでとても便利です。ユーザに対してシステムの能力を押し付け、ユーザがその能力の活用の仕方を身につけ仕事をするのに任せるのではなく、顧客の要望から開発を引き出すことができます。こうすることでリーン界のリーダーであるDaniel T Jones氏が2013 edition of Lean IT Summitで話した大きなポイントをカバーできます。すなわち、技術的な機能をプッシュするモードから顧客の要望からソリューションを引き出すモードにIT戦略を変えるということです。
これは、単なる言葉遊びのようにも聞こえますが、ソフトウエアエンジニアの働き方にとっては大きな変化です。裏返しにして定義し直すのではなく、システムは外部からのユーザストーリーによって定義されるということです。以下のように図示できるでしょう。
IEEE 830 ソフトウェア要件定義 : システムはこの図のように定義される
ユーザストーリー : ある{役割}としてBenはある{アクション}をし、{成果としてのビジネス価値}を手に入れる
ユーザストーリーを実装するのはとても難しいことでした。特にソフトウエアエンジニアにとっては、日々の仕事に対する見方を根本的に変わるからです。
うまくいくようにするには、以下の点が重要でした。
- ユーザストーリーについてトレーニングする。
- 機能アナリストをコーチして正しいユーザストーリーを定義できるようにする。
- 初回の機能分析セッションはすべての役割(開発、テスト、UX)のために行い、ユーザストーリーの設計とユーザストーリーがReady To Developになることに対して貢献してもらう。
ユーザストーリーの設計が簡単できない技術的領域もあります。そのような場合は、開発者に考え方を変えて木々津的なソリューションをユーザストーリーに組み込むことはできないかどうか確認します。できない場合(ほとんどありませんが)は、技術的な仕様に基づいたアプローチを薦めます。しかし、私たちはチームのデフォルトの振る舞いをユーザストーリーを考慮した設計をする、ということに変更することができました。
デイリーフォローアップ
当初、多くのソフトウエア開発チームと同様に、私たちは、長い公式の週次ミーティングを実施しているので、プロセスは強化されていると考えていました。マネージャにテーブルに着いてもらい、正式に時間を取って会議することによって、プロジェクトが管理できていると思い込んでいたのです。しかし、私たちは何も管理できていませんでした。V1をリリースするのに18ヶ月も遅延したのですから。
V2では、私たちはスクラムを導入しました。すべてのチームが朝、15分のスクラムミーティングを実施し、それをプロジェクトレベルにスケール合うとしたのです。
- 9:30: 6つのアプリケーション開発チームがそれぞれスクラムミーティングを実施します。開発者だけでなく、テスターや機能アナリストも参加します。
- 9:45: 異なるチーム(チームはコンポーネント駆動。例えば、ビジネスレイヤ、アプリケーションレイヤ、ウェブレイヤなど)のすべてのスクラムマスタ、機能アナリスト、テストリーダー、リードアーキテクト、マネージャが参加するプロジェクトスクラムを実施。
しかし、情報を失っているということが明らかになりました。チームAに属するビジネスレイヤの開発者はチームBに属するビジネスレイヤの開発者とともにアクションを起こせる十分な可能性を持っていませんでした。同じようにチームAのテスターはチームBのテスターと情報を共有する機会がありませんでした。その結果、作業は重複し、協力体制にも問題が発生しました。
V3では、チームスクラムとプロジェクトスクラムの間で、朝、機能チームによるスクラムを追加しました。新しいスケジュールは次のようなものです。
- 9:30: 6つのアプリケーション開発チームがそれぞれスクラムミーティングを実施します。開発者だけでなく、テスターや機能アナリストも参加します。
- 9:45: 機能スクラム、各機能チーム(ビジネスレイヤ、アクションレイヤ、テスト)がミーティングを行い、アプリケーションチームからの情報を整理する。これによってメトリクスの観点から情報を編成できる。
- 10:00: プロジェクトスクラム。すべてのスクラムマスタ、機能アナリスト、テストリーダー、リードアーキテクト、マネージャが参加する。
朝の10:15に最後のミーティングが終わったときには、全員(プロジェクトマネージャ)が、プロジェクトの立ち位置、主要な問題、責任の所在、スプリントの目的を達成する見込みなどについて、明確に理解しています。
図 3: デイリーフォローアップをプロジェクト全体にスケールする
公平に言えば、これは、当初私が達成したいと思っていたことですが、このような組織はHenrik Kniberg氏の著書Lean From The Trenchesに描かれています。しかし、私はコミュニケーションのオーバヘッドが発生するため、チームの受けは悪いだろうと思っていました。良かったのは、チームがV2のデイリーミーティングの効果を認めてくれたことです。週次の1時間のミーティング、週2回の機能レベルの問題を扱う30分のミーティングで失敗をして、最終的には15分のデイリーミーティングを行うことに自然に決まったのです。
あらかじめ指示をするのではなく、チームに行動を促すことでチーム自身でこの結論にたどり着いたのです。コーチではなくチーム自身が考えたことなので、今も続いているのです。
ビジュアルマネジメント
V1の終わりに、私たちは異なる人々に質問をして、どこにプロジェクトの情報があるか尋ねました。答えを聞いたところ、だれもどこにあるか知らず、V1のプロジェクトの状態がどうなっているのか、状況を改善するために毎日何をするべきなのか、わかっていませんでした。
各自がプロジェクト内でどこに位置しているのかを理解させるため、プロジェクトレベルでビジュアルマネジメントを導入しました。デイリーフォローアップと同じように、スクラムのビジュアルボードのアプローチをプロジェクトレベルに拡張しました。アプリケーション開発チームのスクラムで実施している、タスクについてのフォローアップではなく、プロセスの作業単位のステータスを確認します。つまり、ユーザストーリーを確認するのです。
このビッグボード(下図)を使い、各スクラムマスタはユーザストーリーレベルのステータスを使って機能アナリストやプロジェクトマネージャ、UXデザイナ、リリースマネージャ、リードテスターと共有します。
図 4: 開発ボード
各行はひとつのアプリケーションチームを表しています。各列はプロセスの異なるステップです。ユーザストーリーを左から右へしっかりとした品質レベルを保ちながら素早く動かしていくのが目的です。丈夫の小さなラベルは、チケットを次のフェーズへ動かすときに守らなければならないルールです。技術的な観点から見るとこの流れは、上位から下位へプッシュするということです。これは、作業が顧客の要求によって引っ張られていくというプルのフロー(標準的なリーンのアプローチ)ではありません。
外部の問題(スクラムチームは朝のミーティングでは対処できません。外部に依存している問題だからです)が発生したら、プロジェクトレベルで支援できる人が対処します。問題は日常の作業によって対処され、あるひとつの点でチームが立ち往生しないようにします。また、問題はピンク色のポストイットを使って視覚的に表現されます。ポストイットにはアクションを起こす人の名前が書かれます。だれも読まないメールに問題が書いてあるよりもボードに名前入りで問題が明確になっているほうが素早いアクションが生まれます。
V2のときは、ボード上の開発プロセスに従っていただけでした。
V3のときは、補完的なボードを導入しました。
- 機能チームのデイリーフォローアップのため: ビジネスレイヤ、ウェブレイヤ、インテグレーション。これらの部分では作業単位は変更された(または開発された)コンポーネント単位。または、統合チームのテストのためにも使います。
- 機能分析のためのフォローアップについては次のセクションで詳述します。
機能分析のためのフォローアップ
開発に集中するデイリープロジェクトスクラムを立ち上げたので、V2のときには、開発可能ではない状態で開発フェーズに入ってくるユーザストーリーに関する問題がたくさんあることがわかりました。未解決のUXの問題を抱えたユーザストーリー、十分な時間がなかったために適切に見積もられていないユーザストーリーがあったのです。その結果、開発期間中にスクラムマスタとプロダクトオーナの間でやり取りが発生し、ユーザストーリーが安定していないがために多くのバグが生まれました。
V3では、機能分析フェーズを標準化しました。ユーザストーリーを開発可能な状態にするのが目的です。これはふたつの形式で行われます。
まず、週次で機能分析セッションを各チーム毎に行い、すべての役割の担当者が参加しました。開発者、テスター、UXエンジニア、機能アーキテクトです。このミーティングの目的は限られた数のユーザストーリーを開発可能な状態にすることです。内部で対処可能なすべての問題が俎上にあがります。外部に依存する問題(機能をまたがった一貫性に関する問題やUX)は機能アーキテクトとUXの担当者が個別に対処します。
次に、開発ボードの上にふたつ目の機能分析ボードを立ち上げました。朝のプロジェクトスクラムで論じるためです。その結果、午前10時のプロジェクトスクラムは現在のスプリントでのユーザストーリーの開発に明確な状態を与えるだけでなく、次のスプリントのユーザストーリーの分析についても明確にします。
図 5: 機能分析ボード
アプリケーション毎にひとつの行があり、プロセスのひとつのステップにひとつの列があります。そして、ユーザストーリーをあるステップから次のステップに移すためのルールはすべて明らかになっています。目的はユーザストーリーを開発準備完了の列に移動し、効率的に開発できるようにするためです。
組み込まれたテスター
当初(V2のとき)、私たちは機能を横断した開発チーム(Bug Fixing Vs Problem Solvingという記事をご覧ください。利点についてはここでは詳述しません)を立ち上げました。チームと品質と効率性を改善するため、私たちはV3ではチームの内部に1人、ないしは2人のテスタを抱えるようにしました。
それまでは、テスターは開発者とメールでやり取りしながら、毎週のリリースのためにテストをしていました。
開発者の中にテスターを配置するのは大きな変化です。このテスターの役割は次の通りです。
- 機能分析の段階に参加し、ユーザストーリーが開発可能であることを承認する。これはテスターがユーザストーリーを理解し、何をテストすればいいか理解しているということだ。
- ユーザストーリーの品質が十分であることを保証するテストを書く。
- チームのデイリースクラムと統合チームのスクラムでテスト/問題、バグの状況を報告する。
- テストを実行し、可能な限り素早く、バグを見つけ、直させる。
- 機能分析とUX担当者によるユーザストーリーの検証を支援する。
多くの理由でこのやり方はうまくいきました。振り返ってみると、大きかったのは開発者が品質に関する自分の悪い習慣の結果を毎日見ることができたことだと思います。ひとつのすばらしい例を紹介したいと思います。
あるチームのテスター(Terryと呼びましょう)は2週間休まなければならなくなり、チームにはアサインされたテスターがいなくなってしまいました。開発者はスクラムが完成しないと考え、この問題を自分たちで解決しようとしました。チームのひとり(Bobと呼びましょう)をTerryの代役にしたのです。Bobは以前、2日間Terryとともに仕事していたので、やり方(正しいテストの書き方、テストの実行の仕方など)を理解していました。Bobは2週間、Terryの仕事をして、もう1日でTerryが戻ってきたときに引き継ぎを行いました。
Bobはテスターとして働く間に正しくないリリースが行われることがいかにイライラすることなのかを体感しました。開発者の一貫性のなさが、いかにTerryの仕事をストレスがたまるものにしているのかを理解したのです。開発者の仕事に戻ったBobは多くの改善提案を行い、Terryの仕事をより簡単にしようとしました。
テスターをユーザストーリーのライフスタイル全体に関係させることは品質の改善を超えた気付きをもたらしてくれます。テストはバリューチェーンの最後にある汚い仕事ではない、とテスター自身が思ってくれるようになります。
この方法を実施して一番良かったのはテストマネージャが私に次のように話したことです。“最初は部下をいろいろなチームに分散させるのは嫌だったが、より効率的になったので良いことでしたね。”
スプリントのコード凍結をやめる
私たちはチームが既知のバグがあるソフトウェアを統合テストフェーズにリリースしてしまう理由を見つけようとしました。多くのスクラムマスタは、十分な時間がないため欠陥のあるソフトウェアをリリースせざるを得ないと言いました。
私たちはスクラムマスタとチームにバグのない機能を提供するためにどのような支援ができるか尋ねました。彼らは«もう何週間か欲しい»というものでした。そこで私たちは4週間のスプリントのうち、1週間は完全にコードを凍結して、この1週間で次のことをできるようにしました。
- バグのないユーザストーリーを提供し、
- 次のスプリントのユーザストーリーを開発可能な状態にするための設計と準備をする。
実際は、ひとつのスプリントで5人の開発者のチームは5人の開発者 x 5日 x 3週間 = 75人日(100日のうち)稼働できるようになりました。
V1のときは、開発の最後に無駄なフェーズを持ってきましたが、それとは逆に異なるスプリントに無駄なフェーズを散らばらせるようにしました。このやり方がリーンではないことはわかっています。しかし、私たちはある種の妥協をしました。チームの仕事の仕方に多くの新しい変化があったからです。
開発コストが突然25%も上昇したと主張するマネジメントとの戦いは大変でした。私たちは自分たちの対応策をチェックして、全体のリードタイムについて利点があるのかどうかを確認したいということを説明しなければなりませんでした。
ユーザストーリーを完成させるのにバグを0にしなければならないということは、厳密さと品質の観点から、よりプロセスが大変になるということです。コード凍結の1週間よってチームはこの目的を達成することができます。
開発完了の定義も楽観的な見積もりしてしまったチームが直面する問題を可視化するのに役に立ちます。ユーザストーリーに対してより適切な見積もりをできるようになりました。
チームの見積もりが正確になり、しっかりとした機能分析ができる体制になったので、スプリントからコード凍結期間を除外しました。チームは品質の点で成熟しました。このステップは予測可能性を構築するための土台となります。
Stop The Line
ここで言うStop the LineとはリーンのStop The Line (aka Andon)ではありません。リーンのStop The Lineはチェーンを止めて問題についてマネージャによるサポートを要求します。私たちのStop The Lineはアプリケーション開発チームにある考えをしみ込ませるということです。その考えとはバグ修正を後回しにして新しいユーザストーリーを開発するというのは良くないことだという考えです。開発者ひとり当たり大きなバグがひとつあったら開発を停止するというルールを作りました。ひとりのテスターを含めて6人のチームの場合、5つのバグが上限で、この上限に達したら開発者は開発を停止して、バグ修正に注力しなければなりません。
このやり方は純粋なリーンのやり方ではありません。リーンの場合はひとつでもバグがあったら停止しなければなりません。私たちはチームが受け入れられるように少し薄めて実践したのです。
このやり方は品質に多大な影響を与えました。最終的にはコード凍結の段階で、バグのバックログがほとんどなくなったので、納期に間に合いました。私たちはまだ、価値を生まない行為を抱えていますが、少なくとも納期を守ることはできたのです。
チェック
私たちはV2とV3の開発を通じて上述した変化を段階的に組織に導入し、プロジェクトの遅延の観点から大きな成果を上げました。プロダクトオーナがこの結果に満足したのは言うまでもありません。
結果について説明する前に、これらの変化がリーンソフトウェア開発(LSD)の実践においてどのようにして段階的に導入されたのかを説明したいと思います。
(クリックして拡大)
図 6: バージョンを通じた段階的な変化の導入
次の図で示すことができます。
品質
図 7: 進化率
品質の進化率(リリース時に残っていたバグの数を開発の工数で徐す)は、テスターと開発チームを結びつけたこと、Stop The Lineを導入したことが品質に大きく影響しているのを示しています。
本当のリーンのアプローチの場合はふたつの対応策を個別に検証し、それぞれがどの程度品質に影響を与えるのかを完全に把握するでしょう。
遅延
図 8: 遅延の変化
関係者の感想
プロジェクトの開始のときと同様、私たちはプロジェクト終了のときも多くの関係者にインタビューしました。プロジェクトに関わったすべての人と議論をしました。
このバージョン開発したおかげて、高品質なソフトウェアを納期内に提供することができるということを理解しました。
製品を一日中使ってもバグが見つかりませんでした。R&Dに対する信頼が生まれました。
アプリケーションに一貫性があるので、私たちマーケティングは顧客向けのすばらしいストーリーを簡単に作れます。
製品のグローバルなビジョンが見えるまで成長することができました。
チームは引き続き良くなっています。私たちはプロセスと特定のニーズに適用することで多くの問題を解決することができました。
チーム全体がユーザストーリーの設計からテスト、統合まで関わるので、皆、開発したものにオーナシップを持ちます。これは大きなモチベーションの源泉です。
お金は?
著名なフランスのリーンの専門家であるMichael Ballé氏に私たちが体験から得たことを説明すると、いつも次のように質問されます。“それで、お金は?”
V1で完全に遅延してしまったのがスタートポイントです。この遅延分と同じ工数でV3を実現したとすると、7ヶ月に70人投入したプロジェクトだったので、(70x7=) 490人月のコストになります。つまり、490人月を削減できたのです。これは、40 FTE (Full Time Equivalent)に相当します。組織の負担は2年前よりも40 FTE分軽くなっています。FTEをユーロに変換すると私たちの会社は250万ユーロを節約できたことになります。
キャッシュが生まれるまでの時間にも影響があります。7ヶ月の遅延ではなく、予定通りにソフトウェアをリリースできたということは、売り上げは7ヶ月早くなります。
私たちが学んだこと
各ステップで品質を保証することはプロセス全体での無駄の削減に大きな効果があり、遅延を回避し、チームのやる気を向上させるということが最も重要な教訓です。Stop the Lineを導入したことでプロセスがより効率的になりました。
ふたつ目は、プロセスの可視化はチームによる共同のオーナシップを取り扱うのにとても便利だということです。問題が可視化されるだけでなく、チームの動きを編成するのにも役に立ちます。すべてのユーザストーリーがテスト段階で止まってしまっていることをすべての開発者が認識できるので、テストに力を貸せます。これは数ヶ月前では不可能だと思われていたことです。
そして、プロジェク共通の優先順位を各プロジェクトチーム全体で調整しながら、小さなスタンドアップミーティングの連続がプロジェクトの状態を共有するのに便利だということです。さらに、チーム内で信頼を醸成するのにも役に立ちます。1週間毎日プロジェクト状況を確認するミーティングに参加したスクラムマスタが、Stop The Lineのルールにより、バグ修正をしているので新しい開発ができないと発言したことを覚えています。勇気が必要な発言ですが、品質の欠如についてコメントしたり悲嘆したりせずに聞いたチームのメンバの優しさも必要です。このことがあり、私は組織全体に誇りを持ちました。私たちは正しいトラックの上を走っていたのです。
さらに、変化のマネジメントはゆっくりとしたプロセスであり、忍耐が必要で、変化を促すエージェントからの傾聴や慈愛が必要だということも教訓です。私にとって一番うまくいったのはすべての異なる役割と30分のコーチングセッションを設けたことでした。スクラムマスタ、テストリード、機能アナリスト、プロジェクトリーダ、マネージャとのセッションです。変化が生まれると大きな不安もうまれます(Edgar Schein氏がこの点について書いています)。不安を解消するためのスペースを提供する必要があります。私たちのプロジェクトでは1対1でミーティングをするというのが効果的でした。
次のステップ
振り返ってみると、このプロジェクトではリーンのシステムの中核であるふたつのことが実現できていないと思います。プルフローとPDCAを使って日次での問題解決です。
プルフローは顧客の要望に従って仕事を編成します。次のプロセスが実現可能になり対処できるようになって、初めてユーザストーリーが次のステップに進みます。ユーザストーリーを管理するボードはありましたがカンバンではありません。私たちは制限のないプッシュフローを使い、フローを制御するシグナルは下流から得ることはありませんでした。これによってテスターが検証するべきユーザストーリーに溺れてしまうような状態になりました。
満足できる結果ではありましたが、まだ問題は残っており、除外するべき障害、改善の余地あります。しかし、チームは今、正しいトラックを走っています。
著者について
Cecil DijouxはOperae PartnersのリーンITコーチ。25年間ITプロフェッショナルとして働いています。21世紀のマネジメント(リーン、アジャイル、エンタープライズ2.0)に情熱を持ち、英語とフランス語で相互接続された世界の組織文化についてブログを書いています。氏のブログのある記事はNew York TimesやRead Write Enterpriseに取り上げられました。また、国際的にスピーカー、著者としても活躍しており、"#hyperchange- petit guide de la conduite du changement dans l'économie de la connaissance"というフランス語のダウンロード可能な電子書籍を発表しています。