Kantegaのプロジェクトリーダで部門マネージャのMaja Selmer Megard氏は、2020年春のカンファレンスに向けて、"From Heaven to Hell"と題したプレゼンテーションを用意した。このプレゼンテーションで、氏が自身の経験を公開するプロジェクトは、当初はすべての要件に対して完璧にフィットしていると思われながら、最終的には氏が経験した中で最も大変な、葛藤に満ちたプロジェクトになったものだ。
プレゼンテーションの中でMegard氏は、我々の多くはプロジェクトが複雑なものである(complex)ことを知りながら、単にややこしい(complecated)ものとして行動する傾向がある、と述べた。プロジェクトにおける問題や課題は複雑で、簡単には修正できない、従ってソリューションはただひとつではなく、ひとつのソリューションで解決できるものでもないことを、我々はもっと認知するべきだ、というのが氏の主張だ。そうするべきだ、そうしたい、と分かっていても、簡単な解決方法を求める考え方を改めることの難しさに気付いているのは、氏だけではないかも知れない、と氏は考えている。
レッドフラグ(red flag)はかなり早い段階で上げられているのだが、それが取り上げられなかった、とMegard氏は言う。
当初、私は話をしっかりと聞かず、残念なことに、報告された問題は"コップの中の嵐"だと思っていたのです。
状況を改善するための活動はいくつか行われたものの、プロジェクトは継続された。何度かのレトロスペクティブを行い、新たな目標をセットして、ドキュメントを増やし、明確なメッセージでもっと状況報告を書くようにした、とMegard氏は言う。実現できたことのひとつは、相互に支援しあうことのできる、本当の意味で優れたチームを構築することだ。共通の敵があるという認識が、この理由のひとつにはあったのかも知れない。
プロジェクトが完了した後に行ったレトロスペクティブでは、記憶に留めて注視する必要のあったレッドフラグの長大なリストが出来上がった。リストがあまりにも長大であるため、Megard氏は問題の本質について考えることにした。自身の記憶に残っていて、十分な汎用性のあるものを探したのだ。
この期間、同僚と私は複雑な(complex)トピックとややこしい(complecated)トピックについて議論を重ね、それが以降のことに気付くきっかけとなりました。プロジェクトの課題は複雑ではない、ややこしいだけだ、というような行動を避けるために、私は3つの簡単なことに注力するようにしました — 聞くこと、時間をとること、勇気を持つこと、です。
聞く: 難しいかも知れませんが、集中し、オープンマインドであることが必要です。私たちのリスニングスキルはプロジェクト中にどんどん上達して、明確なメッセージがなくてもパターンを見つけられるリスニングを習得しました。
時間をとる: 私たちはみな多忙なので、何かを改善するために多くの時間を費やすような優先度付けをするのはとても難しいことです。そして私たちは、問題が複雑であること、簡単な解決策のないこと、ソリューションはひとつでなく、ひとつのソリューションでは解決できないことを忘れがちです。その上において、"構築(build) — 計測(measure) — 学習(learn)"テクニックを使って、忍耐強いことが求められます。努力をしても、肯定的な結果は何も得られないかも知れないのです。
勇気を持つ: レッドフラグにたじろがないでください！有害な非難的環境はしばしば、私たち自身や自分の能力に疑問を抱かせ、恐怖を感じさせます。このようなレッドフラグに対しても、自分の直感を信じ、チームの声を聞きましょう — そして、勇気を持つのです！後で後悔するような妥協はしないでください。
問題の問題たる所以は、誰もそれを望んでいないからだ — 抱えているのが問題だけならば、両手を広げて迎え入れられることはまずあり得ない、とMegard氏は言う。問題をエスカレーションすることで、マネージャも優先順位を付けざるを得なくなり、多くの時間を費やすことが可能になるのだ。
Maja Selmer Megard氏に、プロジェクトからの氏の経験について話を聞いた。
InfoQ: そのプロジェクトは、どのように始まったのでしょう？その時点では、どのような希望がありましたか？
Maja Selmer Megard: 既存ソフトウェアをリプレースするソリューション開発を落札したのです。ちょうどよいサイズのプロジェクトで、セットアップも完璧に思われました。当社には有能で意欲に満ちたクロスファンクショナルなチームとアジャイル調達契約があり、オンサイトとクライアント側の両方に人員を配置していました。
プロジェクトの目標は、既存のバックエンドに統合された、シンプルなフロントエンドソリューションを提供する、というものでした。5人で5ヶ月という、スコープとしても管理しやすいものでした。
私の仕事はチームを密接にフォローし、必要ならばチームメンバをサポートし、アジャイル思想が確実に実践されフォローされるようにする(チームコーチ)、というものでした。部門の責任者である私のスケジュールはタイトでしたが、週に2～3時間の実践的経験を通じて、現場への関与を続けられることを楽しみにしていたのです。
InfoQ: 講演では、途中から事態がスムーズに進まなくなった、という話がありましたが、レッドフラグはどのように示されて、それに対してどう対応したのでしょうか？
Megard: チームからは次のような話がありました ...
- "このプロジェクトの価値は一体何なのでしょうか？"
- "既存のバックエンドを大幅に変更しなければ、ユーザの期待に応えることはできません ..."
- "いい仕事ができません。"
- "決定されていないので、コーディングを始められません / これが明確にならなければ、コーディングを始められません。"
- "ユーザは相変わらず、'そんなに難しくはないだろう？'とか、'これをどうすればいいのか知っている人は、あなたの会社にはいないのか？'といった、私たちの能力を疑問視するような、微妙な発言を続けています。"
- "ユーザは状況を理解していないようなのです。"
- "プロダクトオーナは他のタスクが忙しくて、まったく顔を出してくれません。"
- "ステークホルダやエンドユーザと直接話すことができないのです。"
- "このコードには、自分の名前を書きたくありません。"
- "このプロジェクトはきっと失敗しますよ！"
ユーザの不信感が高まっている兆候と思われるものも始まりました。それは、無駄なことをするな、という絶え間ないプレッシャであったり、エンドユーザと話をする必要があることへの理解の欠如でした。
ユーザが自分たちの見解を、敵意を持って、見下すような態度で伝えているように、私たちには思われました。新たな課題が明らかになると、彼らは、プロジェクトが複雑であるからではなく、私たちの能力不足に原因があるのだと決めつけました ("解決方法を知っている人は、あなたの会社にはいないのか？")私たちが見つけた複雑性を伝えることができなかったのです。
プロジェクトに最初の遅延が発生した時、意見の相違がエスカレートして、弁護士の関与が始まりました。
残念なことですが、ユーザによる圧力がかかった時、開発チームと私は屈服して、困難な状況からできる限りのものを作り出そうとしました。ユーザを満足させ、ユーザと私たちの間の苦渋の状況を緩和しようとして、決してするべきではない妥協をしたのです。
InfoQ: 勇気を持って行動を起こす必要のある人たちに、何かアドバイスはありますか？
Megard: アドバイスは難しいのですが、議論するには有意義なトピックだと思います。
圧力を掛けられた時のチームの撤退を受け入れるのではなく、問題を含んだメッセージを受け取る私なりの方法を、もう一度考えなくてはなりません。人は誰しもトラブルを起こしたくはないですから、彼らがレッドフラグを上げる時は、正当化されるのが普通です。直ちに解決策を提供したいという衝動と戦って、自分に起きるストレスを許容する(そして受け入れる)ことが必要なのです。
問題の修正を喜ぶような人であっては、ユーザと協力してソリューションを見出そうというのは困難です。絶え間ない困難な状況とユーザの不信は、私(とチーム)の自信を傷付けて、適切な仕事を実行できないと感じさせるに至りました。レトロスペクティブでは、これによって課題を明確に伝えられず、自分の立場を保つのが難しくなったことが分かりました。次の機会にはこれが何であるかを認識して、不快な状況にも自信を持って立ち向かう(勇気を持つ)ことができれば、と思っています。
今の私には、不快な状況によりよく立ち向かうための、3つのスローガンがあります。すなわち、
- 個人的に捉えないこと
- ユーモアのセンスを使うこと
- 休憩する(新鮮な空気で深呼吸する)こと
シンプルですが、同時に難しくもあります。