子供の頃から私は、成功するためには個人として一番にならなければならないと教えられてきました。このことはほとんど全ての学校に当てはまり、楽器を演奏するときや、評価の要素があるところにならどこにでも現れました。私が他人と協調できるかどうか、妥協点を探せるかどうか、他人に行動を起こさせるように鼓舞できるかどうかに興味がある人などほとんどいませんでした。このことに特に注意を払う人もいませんでした。私たちは協調することも、互いに助け合うことも教わりません。これによって格付けされることありません。それはソフトな特性、育ち、経験した境遇の結果として、自然発生的に起こるのです。
しかしながら、成功の裏にチームがいることの方が多い
しかしながら、現実が示しているように、成功の裏には個人よりチームがいることの方が多いでしょう。私はスポーツが好きなので、次の例が最もよく納得できます。最近、2人のサッカー選手がベスト・フットボール・プレイヤーの称号を獲得しました - RonaldoとMessiは、様々な試合や投票で数々の成功を収めることと、リーグ戦や国際試合でベスト・サッカー・プレイヤーの称号を獲得することを交互に行なっているのです。しかしながら彼らは、Real Madrid、Barcelona、ポルトガルのナショナルチーム、アルゼンチンのナショナルチームの仲間なしには、このような功績を収められなかったでしょう。コーチング、医療、PRやマーケティングスタッフの適切なサポートがなければ、ガラスケースにこれほど多くのトロフィーを飾れなかったことでしょう。彼らは個人として並外れていますが、並外れた集団の中で能力を発揮する才能を持っているというだけなのです。これが今日における成功のレシピなのです。
アジャイルがmBankに来る前…
スポーツの話は置いておきましょう。私が書きたいのはそれについてではなく、私が伝えたいのは、アジャイルをmBankのデータ・ウェアハウスに取り入れた、自分のマネージャとしての経験についてです。アジャイルの作法に沿ってソフトウェア開発にアプローチし始める前は、どのような状況だったのでしょうか？私がウォーターフォールや、他のあまり知られていないアジャイル ウォーターフォールカンバンのハイブリッドで単に管理していただけと言ったら、何も新しいことにはなりません。
社員の視点からはどう見えたか…
開発者の視点からすると、プロセスにはよく、ビジネスコーディネータやマネージャから社員に任される仕事がありました。その多くは、他の開発者とほんの少しインタラクションがある独立した仕事でした。いわゆるビジネスというやつです。社員はマネージャが主導する以外には、ミーティングに邪魔されることはありませんでした。彼らは予算内、スコープ内で時間通りにデリバリすることを期待されていました。特例は場合によっては必要で、例えば”カード代の払い戻し”といったらChrisが担当に適していると誰もが知っているといった具合です。Chrisが休暇中の場合は、彼が戻って来るのを待たなければなりませんでした。怠慢？ChrisはPCを休暇にも持って行っているでしょうか？
マネージャの視点からはどう見えたか…
マネージャの視点からすると、この仕事は主にタスクの委任、タスクの受領、仕事の監視、ビジネスで実行されるべきタスクの生成を含んでいました。チームの代わりに、マネージャは個人主義者のグループを持っていて、プロジェクトのニーズに応じて適宜チームにまとめていました。それは、与えられたプロジェクトが完了してすぐに解消されるいわゆるツギハギというやつで、チームのビジョンと戦略、定期的な1-on-1ディスカッション、チーム全体でのシステマティックなミーティング、社員育成の活性化のための時間が慢性的に不足していました。しかしわたしたちは何とかやり遂げました。ソフトウェアを作って、ビジネスはうまくいっていました。
組織の中でアジャイルはどう見えるか？
ある日、ITの新しいトップがmBankに来ました。明らかになったのは、彼は過去にいくつかの機関において、ソフトウェアの生産にアジャイルアプローチを導入し、成功させているということでした。今のところは、アジャイルは”うまくいかない”と彼を説得できた人はいません。
わたしはアジャイルについて何を知っていたか？
Wikipediaで読んだこと、”ITプロジェクトマネジメント - 方法論の手引き”と題された本、そして友人の話から知識を得ました。当時、”アジャイルプロジェクトマネジメント”という研修も受講して、資格の基礎レベルを修了しました。そのため、わたしはかなり多くの情報を持っていましたが、実践経験はあまりありませんでした。悩みましたし、自分とチームのためにこのような変化は必要なのかどうか疑問を持っていました。自分たちの仕事は結構うまくいっていたからです。
悩み
チームへの影響力を失うのではと悩んでいた
多くの時間を取ることに加えて、進行中のタスクの委任と受領、進捗状況の監督は犯罪感をもたらしました。わたしは自分の部下が何をしているか、それをどうやってやるか、いつまでにやるか、など主導権を握っていました。このアジャイルの現実では、わたしの代わりに優先順位、予測と期限を決める部外者 - プロダクトオーナー - が現れるのです。事実、プロダクトオーナーはわたしの部下の仕事を管理し、わたしは退かなければなりませんでした。誰の気も散らさず; 彼らをただサポートし、彼らから何か必要かを丁寧に聞くだけです。
会議で時間を浪費していること（人日を読むこと）について悩んでいた
2週間のスクラムのスプリントの間、チームはデイリー（15分以内）、リファインメント（週に1回ないし2回、1-2時間）、レビュー（隔週で1-2時間）、レトロミーティング（隔週で1-2時間）で毎日顔を合わせなければなりません。2週間のスプリントでこれらの時間を合算すると、開発者は会議によって少なくとも6.5時間から最大14.5時間を奪われると結論付ける人もいます（それがなければ、彼／彼女は今のところ効果的に働いています）。5人チームの場合、2週間で4-9人日(MD)を消費するということです。これでは実行できるタスクも減りますし、1年でいくつものプロジェクトを完了させることはできないでしょう。ビジネスは満足いくものにはなりません。スクラムは安くはないのです。
アジャイルコーチについて悩んでいた
アジャイルコーチとはなんと奇妙な役割でしょうか。組織の幹部に、アジャイルの教育にトーチを運ぼうとするグループが現れたのです。彼らはチームにおけるソフトウェアのアジャイル開発の発展を活性化しようとし、障害を取り除き、チームとマネージャと話をし、ソフトウェアの開発について違った考え方をするよう促し、旧い方法をやめさせようとしていました。彼らはわたしの部下と話し始め、コーヒーなどを飲みながら様々な質問をするようになりました。彼らと一緒にオープンスペースに座り、何が起こっているのかを観察していました。彼らはわたしの部下とどんな話をしていたのでしょうか？もっと悪いことには、誰が彼らに知らせていたのでしょうか、そして何について？彼らはミステリアスなエージェント・スミスのように、会議から会議へとコソコソ動き回るのです。何が起こっていたのでしょうか？
変化について悩んでいた
機能しているものをなぜ変えるのでしょうか？わたしにはスクラムを紹介する必要性を見出せませんでした。わたしのチームがそれがなくてもゴール達成していたからです。触らぬ神に祟りなし … 触ると火傷するのですから。
プロダクトを分割できないことについて悩んでいた
わたしのチームには、長年に渡って大量のソフトウェアを作っている人々がいました - レポート、システム抽出、アプリケーション、ITシステム、データマートなど。スクラムが本質的にインタラクティブなプロダクト開発に焦点を当てていることを知り、個々のチームが集中すべきこの環境でプロダクトをどうやって探せばいいのか不思議に思いました。そんなシステムは山ほどあるからです。大きなプロジェクトにおいて、チームに快適な環境を提供するなど不可能です。システムをグループ化し、サブジェクトのカテゴリに対応してみることしかできません。それから、このようなシステムのコレクション周りにチームを作ろうとすることに価値はあるのでしょうか？
地理に関して悩んでいた
恐らく、”地理”と戦うのは賢明ではないでしょう。ウッチとワルシャワ、130kmも離れている2つの都市で働く人がいるチームをどうやって作れるのでしょうか？むろん、可能ではあります。ウッチ出身の人同士なら、ワルシャワ出身の人同士なら最高でしょう。しかし、それができない場合はどうしますか？Excelでは可能でしょうが、現実には、難しいことです。
経験のあるスクラムマスターの不足について悩んでいた
スクラムが始まると仮定しましょう。プロダクトは分かれていて、チームを作る調整をして、人とタスクのフルコントロールがないことを受け入れるとしましょう。それぞれのチームにどうやってスクラムマスターを調達できるでしょうか？個々のチームでスクラムの原則に沿ってアプリケーションを気にかけてくれる人々をどうやって探せるのでしょうか？ポジションは決まっています。わたしは新しく誰かを雇うことはできません。一方、希望もあります。
時間が増えるよう願っていた
わたしはツギハギする時間を減らしたいと思っていました。タスクの委任、優先順位付け、進捗確認、エスカレーションへの対応など … これらは全て日常的なことです；重要な、極めて重大な、より必要なタスクです。問題は、最初から最後までわたしがこれをやらなければいけないのかということです。チームのビジョン、社員の育成などに時間が足りることがありませんでした。まるで社員やチームの育成はマネージャの仕事ではないかのように、より重要なことが常にあるのです。それは本当なのですが、”今の仕事”が終わらないと回ってきません。
サステナビリティを取り入れることを願っていた
社員が休暇でいない場合、99%何かうまくいかないことが起きると予想できます。チームの機能全てを2人以上の配置にしてはいなかったからです。リスクも上がりますし、失敗が起こるとイライラしていました。うまく対処して、友人に電話しなければなりませんでした… 休暇中のです。チームの団結心がポジションの互換性を可能にし、人を効率的に入れ替えられるように願っていました。
本当のチームを作れることを願っていた
既に述べたように、わたしは個人主義者のチームを管理していました。そこには、何かを変える良い機会がありました；人々が互いに協力し、知識を伝え合い、学び合い、同僚が提案したより良いソリューションに気付けるよう促すのです。これによって、よく書かれた、欠陥の少ないソフトウェアをより最適に生産することができました。個人ではなくグループが責任を持つものです。
ビジネスが優先順位付けの責任を負うように願っていた
外部の顧客から電話がきて、タスクを遂行してくれる開発者の選出を依頼されるのは喜ばしいことです。マネージャとして自分が重要な存在で、必要とされていると感じるでしょう。依頼者が出した見積もりの倍速で作業する開発者の選出を要求された場合は、それほど嬉しくはありません。開発者がおらず、ステークホルダーがあなたに罰則を課そうしたり、CEOとつながっていると脅し始めたら、さらに喜びは減ります。もちろん、これは会社の日常的なノルマで、リソースの供給を超えて人日の要求をすることはごく普通のことになっています。一方、ITを理解し、プロダクトとビジネスについても知っているビジネスプロダクトオーナーの手に投げて委ねられるのは魅力的です - それがアジャイルドリームです。
悩みと希み
|
あなたがチームにアジャイル変革を検討しているチームリーダー／マネージャの場合:
|
わたしは、自分の悩みや望みが優位を占めるかどうか判断するまでしばらくかかりました。しかしながら、リスクを冒し、準備に時間を掛け、答えを見つける必要があると知りました。他はなんとかなるでしょう。
わたしが何から始めたか？
実践者、わたしより賢い人、アジャイルで働いたことのある人に会いました。ウォーターフォールからアジャイルへの変遷プロセスがどんなものかを見せてくれる人です。わたしは質問し、疑問はなくなっていきました。翌年、わたしは新しいチームとアジャイルコーチとともに”アジャイルを作る”試みができる領域を選定しました。レポートの領域が選ばれました。キックオフミーティングを開催し、そうして始まりました。まず、あるチームが動き出し、それから数ヶ月ごとに、他のデータ・ウェアハウスの領域のチームが動き出しました。全部で4つのチームを工藤しました。あるチームはスクラムからカンバンへと歩みを進めました。他の3つのチームは全期間をスクラムで作業しました。彼らはそれぞれその特異性、挑戦、特性を持っていました。あるチームは別の構成に戻るために解散しました。そして最も良いチームの1つとなりました。
わたしにとって最も難しい要素は何だったか？
F…g スクラム
ある日、わたしのチームの1人で、プロダクトオーナーである同僚が、チームレトロスペクティブの後に話しかけてきました：”F…g スクラムだ。以前は命令したらよかったのに、今は尋ねなきゃならない”と。スクラムでは、チームを自律させる基礎を固めたいなら、彼らに何かを命令するだけではいけません。尋ねて、議論を展開しなければなりません。もちろんこれには時間が掛かります；一方で、彼らに責任感が育まれます。わたしにとって、チームの人々が重要なタスクに着手できるようプロダクトオーナー、ビジネスパーソンに頼むのは大きな挑戦でした… 以下がその理由です…
プロダクトオーナー(PO)に道を譲る
POに優先順位を決めさせ、ステークホルダーと話させ、わたしのチームの顔にするということです。わたしは目立たないようにしなければならず、また他にやるべきタスクもありました（社員の育成と統合、チーム開発の活性化、チームのビジョンと戦略、大きなプロジェクトの管理、予算、など）。
マネージャやPOの役割の組み合わせ
理論と経験により、マネージャとPOは兼任ではなく別にした方が、自分の精神とチームワークがずっと健康的であると知りました。わたしが遂行しなければならない非通常のタスクのひとつは、チームのPOの役割でした。POは長い疾病休暇（数ヶ月）を取っていて、代理を探すことなく、わたしが代わることに同意しました。最初の数週間はよかったのですが；しかしながら、後から不適切な振る舞いが現れ始めました - マイクロマネジメント、チームへの不要なプレッシャーなどです。結果、部下はわたしにデイリーミーティングに出席しないよう頼んできて、わたし抜きでレトロをするようになりました。これは簡単なことではありませんでした - 彼らにとっても、わたしにとってもです。
スクラムマスターは時間を必要としている
|
あなたがスクラムマスターの役割を担おうとしているソフトウェア開発者の場合、わたしのアドバイスは:
|
これには驚きました。スクラムの原則に従う人は時間の半分、すなわち2週間のスプリントではおよそ5人日がスクラムマスターの仕事に必要ということが判明したのです。わたしたちのチームにスクラムマスターがいなかったため - この役割は開発者によって全うされました - チームで半人分少なくなるという意味です。これはわたしにとって最も痛いところでした。貴重な人日の問題に関するステークホルダーのプレッシャーに対応しながらPOとマネージャの役割を同時に果たしていたからです。
結果は？
困難、懸念、希望… つまり全てはどう終結して、取り入れられた変化の結果はどのようなものだったのでしょうか？
データ・ウェアハウスの段階では、4つのチームと3人のスクラムマスター、そして1人のカンバンマスターがいました。POがタスクを委任したので、わたしは少々力を失いました。一方、他の作業に時間を取り戻せました（社員の育成と統合、チーム開発の活性化、チームのビジョンと戦略、大きなプロジェクトの管理、後任者の育成）。
特にスクラムの場合、会議に費やされる時間が開発する人日を奪っていくというわたしの恐れは現実のものとなりました。一方、組織は数値化が難しいものを勝ち取りました - システムに関する知識の伝搬、考え抜かれたITソリューションです - グループで議論され、エラーは学ぶための材料となり、カーペットの下に隠されることはありませんでした。投資した時間は、実施されたプロジェクトとそのメンテナンスでフルに返済されました。チームの代替性が現れ、作業的なボトルネックのリスクは基本的には存在しなくなりました。
アジャイルコーチは情報提供者ではなく、手助けがしたいとても親切な人だということもわかりました… わたしたちの成功は彼らの成功なのです。変化はいくらか混乱を招くものですが、恐れるべきではありません。新しい品質と、さらなるエネルギーを生むものでもあるのです。今や、旧いやり方に戻りたい人などいないでしょう。
全てのことをやりたいようにやるための管理はしませんでした。ひとつのプロダクトをひとつのチームに分けることはできず、今もそのまま働いています。
ウッチとワルシャワのチームは機能しています。ひとつのロケーションに集まれれば理想的ですが、背に腹は変えられません。Skype、電話、車や電車でなんとかなります。
しばらくして（およそ2.5年）、さらなる変化を取り入れたい後任者とマネージャが現れ、ビジネスステークホルダーにプロダクトをグループ化することを可能にし、開発者に働くチームを変える機会を与えました。変化が変化を生みます… しかしこれはまた別の話です。
必ずしも変わる必要はない。生き残ることは強制ではないのだから。 William Edwards Deming
著者について
Tomasz Dutkowski氏は、リテールとコーポレートカスタマーを対象としたmBankのデータ・ウェアハウス領域における経験豊富なシニアITマネージャである。ビジネスとITの双面で14年の銀行業の経験がある。チームレベルでのアジャイルソフトウェアプロダクションの変革におけるリーダーである。チームワークでのイノベーションに熱心である。個人としては、既婚で二児の父である。