モダナイゼーション：モダナイゼーション・プロジェクト・チームの構築

この記事では、成功への準備が整ったチームを構築し、アプリケーションのポートフォリオをモダナイズするための提案について説明します。前回のブログ記事 で紹介した整合性に関するポイントも考慮に入れます。ここで話すチームは、長期に渡って継続されたり、企業文化の重要な部分となったりするようなチームではないことを覚えておいてください。前回の記事で説明したように、業務を遂行するためには、予算と時間枠が設定されます。この記事で提案しているのは、これらの制約の下で結果を出すチームを構築することです。

プロジェクトの目的は何ですか？

チーム体制について考える前に、以下の 3 つの質問に答える必要があります。

1. どのような結果を望んでいますか？

2. クライアントは誰ですか？

3. スポンサーになるのは誰ですか？

1.どのような結果を望んでいますか？

プロジェクトの承認において、ビジネスケースが重要であることと同様に、モダナイゼーション・プロジェクトの価値 (つまり、なぜアプリケーションを提案された未来の状態に移行する必要があるのか) は、プロジェクトの実行全体を通して、公に伝達される必要があります。

私はかつて、コンテナ・テクノロジーに関する事実調査チームに参加したことがあります。私たちは何度もミーティングを重ね、概念実証に取り組んでいました。しかし、私たちの方向性に関して、何かしっくりこないものがありました。そこで、私はあるセッションの冒頭で、「私たちは何を達成したいのか？なぜこれを達成したいのか？」と書かれた 1 枚のスライドを見せ、プレゼンテーションを始めました。

すると、とても気まずい空気が流れ、部屋中が静まり返りました。プロジェクトの推進役である幹部は、テーブルの端に座って話を聞いていました。しかし、突然立ち上がり、去ってしまいました。その後、非常に気まずい沈黙が続く中、ようやく誰かが声を上げ、「わかりません」と言いました。 このプロジェクトが、俯瞰的視点による目標を掲げて推進されていたことは確かだと思いますが、この目標をチームに伝えていなかったことは間違いだったと言えます。プロジェクトに注力するためには、私たちにもその情報が必要だったのです。

何をする必要があるのか、なぜそれを行うのかについての定義は、すべてのチームメンバーがアクセスできる場所に公開する必要があります。これは、混乱やズレが生じたときに、チームを導く「北極星」のような役割を果たします。

2.クライアントは誰ですか？

ビジネスケースが承認されると、一般的にアプリケーションを所有するビジネスユニットがクライアントになります。モダナイゼーション・プロジェクトにおけるクライアントの最も重要な役割は、適切なものが構築されているかどうかを検証することです。このフィードバックを提供するために、ビジネスユニット内の特定の人々を選ぶ必要があります。選ばれた人々は、ビジネスユニットのリーダーシップに関する懸念について話すことができなければなりません。

たとえコスト削減のためのモダナイゼーション (ミドルウェアのアップグレードや交換など) であっても、現在アプリケーションが提供している機能が、変更による影響を受けないことを検証する必要があります。

しかし、社外のクライアントがアプリケーションを使用する場合は特に、フィードバックが伝言ゲームのように感じられることがあります。この仕事をするために選ばれた製品チームは、これらの外部クライアントに直接アクセスすることができないかもしれません。これには多くの理由が考えられますが、そのほとんどは企業のサイロ化とその周りに形成されるチームに起因しています。これは、時には避けることができない残念な状況です。そこで、信頼できる製品チームを支える次なる重要な役割について考えたいと思います。

3.スポンサーになるのは誰ですか？

プロジェクトを妨害されたり、チームが成功するために必要なものにアクセスできなかったりする場合は、スポンサーに支援を求める必要があります。

支援を求める相手として、この役割に関するビジネスケースを作成した人物を選びたくなるものです。しかし、前述のように、レガシー企業は不思議な場所だと言えます。ビジネスケースを作成した人は、作成できる人材が他にいなかったために作成したに過ぎないという可能性があります。このようなプロジェクトを成功させるためには、スポンサーに以下のような具体的な内容を理解してもらう必要があります。

1. モダナイゼーションによってもたらされる価値に関心がある。

2. 製品チームの取り組みが、この価値にどう結びつくかを理解している。

3. 企業内の変化に影響を与えることができる (理想的にはサイロ間をまたぐ形で)。

この役割を担うのは、幹部レベルか幹部候補で、(影響力を持つ幹部に意見を聞いてもらえる) 人物である可能性が最も高いです。この役割は、チームが企業環境におけるシステム的な課題に対処する場合に、非常に重要となります。

チーム体制

チームは、価値を生み出すプロジェクトの実行のために、必須要件である企業のナレッジとイノベーションとのほどよいバランスを取りながら、簡単に合意を得ることができなければなりません。

企業チームが大きな成果をあげた例として、1966 年に SR-71 Blackbird (コードネーム Skunk Works) を製造した Lockheed Martin のチームが挙げられます。

このチームのリーダーを務めた Clarence "Kelly" Johnson 氏は、プロジェクトをどのように編成し、運営すべきかについての ルールのリスト を作成しました。今の時代にそぐわない Johnson 氏の代名詞の使い方や、軍産複合体をめぐるニュアンスを除けば、非常に政治色の強い環境の中でチームがプロジェクトを実行するために作成されたルールの一部は、今でも完璧なものと言えるでしょう。

リーダーは 1 人でなければならない

Johnson 氏は、プロジェクトを完全に管理することができるプロジェクトマネージャー (私はプロジェクトリーダーと呼びます) が 1 人必要だと述べています。これまで述べてきたように、企業には個人では制御しきれない多くの要因があります。そこで登場するのがスポンサーです。

以下は、プロジェクトリーダーに求められるスキルになります。

• テクニカルな面に精通している。

• 感情面で成熟しており、プロ意識を持って難しい話し合いができる。

• 企業での運用経験がある。

• スポンサー、そして可能であればクライアントと、直接コミュニケーションをとることができる。

これらのスキルと能力を備えた人物は、以下を実行する必要があります。

• アプリケーションのアーキテクチャに取り組む、または所有する。

• 仕事内容の説明と完了時の成功の判断基準を提供する。

• コードベースでのプルリクエストをレビューし、フィードバックを提供する。

• クライアントと会い、アプリケーションに関するフィードバックを収集する。

• 問題をスポンサーにエスカレートする。

プロジェクトの範囲やプロジェクトの進行における潜在的な問題について議論する場合、スポンサーおよびクライアントと対話するのは、プロジェクトリーダーでなければなりません。これは、オープンな文化を望む多くの企業と相容れないかもしれませんが、私たちは限られた時間枠でプロジェクトを実行しようとしていることを忘れないでください。オープンな環境は、チームがプロジェクトリーダーに懸念事項を提起し、プロジェクトリーダーがその懸念事項にどのように対処したかについてチームに報告するという形で存在しています。次に、チームのサイズについて説明しましょう。

チームを小さくまとめる

Johnson 氏は、小さな「優れた」チームの構築について語っています。チーム内の人数は、非常に重要です。たとえ大きな仕事であっても、チームは小さくなければなりません。これは、Amazon のピザ 2 枚ルール にも反映されています。

人数が少ないということは、過剰なコミュニケーションによるリスクを含むコミュニケーション問題が発生する可能性が少なくなることを意味します。ミーティングが多すぎると、生産性に悪影響を及ぼします。しかし、多くの企業では、ソフトウェアサイクルは、何度も繰り返されるミーティングや意見のすり合わせの犠牲となり、何一つコンセンサスを得ることができません。

チームへの不必要な変更を避ける

Johnson 氏は、「プロジェクトに関わる人の数は、冷徹とも言えるやり方で制限されなければならない」と述べています。

一部の企業には、ナレッジの共有を促進するために、チームメンバーをローテーションで入れ替える必要があるという考え方があります。この考え方に価値を見出すこともできますが、この場合、プロジェクトの成果物に注意を払いつつ、非常に慎重に進める必要があります。

優秀な小人数のチームが意気投合し、うまく機能するようになるまでには、多少の時間がかかります。新しい人が加わるとチームはリセットされた状態になり、不適切な人が加わるとチームは大惨事になる可能性があります。

新しいチームが編成されたら、チームで協力して仕事することを学ぶ時間を与えなければなりません。チームで協力できるようになったら、あとは成果を出せるように任せておく必要があります。チームメンバーの入れ替えは、機能性が提供され、プロジェクトリーダーとスポンサーの承認を得て始めて行うことができます。

以下の図は、これまでに説明した主要な役割について解説しています。

プロジェクトリーダーとスポンサーは、クライアントから評価される成果を得るために、引き続き生産的なチームを構築する必要があります。

企業のソフトウェアチームに必要な優秀な人材

理想的なチームは、企業経験と不断の努力をうまく融合させ、価値に重点を置いたチームでなければなりません。企業経験の必須要件をもとに、チームが必要とする次の役割について考えたいと思います。

賢者

プロジェクトリーダーは、企業に長く携わり、その企業環境でコードを運用する方法について深いナレッジを持っている人をチームに採用する必要があります。有力な候補者は、以下の能力をいくつか持ち合わせていることが必要とされます。

• その企業で複数のアプリケーションを実稼働環境に導入している。

• アイデアについてオープンに話し合いをする。

• プロジェクトリーダーと良好な関係を築いている。

• 重要なサイロ (データベースチーム、インフラストラクチャチーム、ネットワークチームなど) と良好な関係を築いている。

では、プロダクトチームのプロフィールについて説明します。

目立った変化をもたらすストーリー処理者

最初の注意点に戻りますが、この仕事は予算も時間枠も設定された中で、結果を出さなければなりません。プロジェクトに参加して、プロジェクトの期間中はストーリーを実行することだけに同意する (そして、妨害された場合はチームに知らせる) 開発者のチームが必要です。これらの人々は、開発者であることをやめようと躍起になっているわけでもなく、企業での出世に夢中になっているわけでもなく、別の企業に移るために経歴を築こうと思っているわけでもありません。

プロジェクトリーダーは、このような人々の仕事ぶりを検討し、評価することになるため、人材選びには関与する必要があります。プロジェクトリーダーにとって最も困難な状況のひとつとして、技術的な指導をしにくい人材が配属されることが挙げられます。これでは、良いチームワークは望めません。

最後に、これらのチームメンバーがフィードバックを受け入れ、プロジェクトが提供する価値を理解して受け入れられることが重要となります。

チームの大半はストーリー処理者である必要があります。

避けるべき危険な人材

それでは、避けることが推奨される性格タイプについて見てみましょう。

サイエンスプロジェクトは時間の無駄

開発者の中には、企業の一員にはなりたくない人もいます。このようなタイプは、おそらく、Google、Amazon、Microsoft のようなパブリッククラウド・プロバイダーで働く方が向いているのでしょう。彼らが企業から得ようとしているものは、履歴書に追加できる特定のバズワードです。

また、新しいソフトウェアでコーディングすることは好きだけど、実稼働環境への移行やレガシーなものを扱うなど、つまらない仕事には興味がない、という開発者もいます。要するに、彼らはただ遊びたいだけなのです。このタイプの開発者は、「サイエンスプロジェクト」を推し進める傾向があります。 これらは基本的に、チームメンバーにとって、約束した価値を提供するために骨を折るといったことに邪魔されずに、興味のある技術で遊ぶ機会なのです。

たしかに、新しい技術は、時にプロジェクトの流れを変えることがあります。しかし、別の記事で詳しく説明しますが、企業環境におけるアプリケーションの正しい選択は、純粋なエンジニアリングの観点からは必ずしも正しい選択であるとは限りません。新しいアイデアの探求は、賢者からの情報をもとに、プロジェクトリーダーが開始すべきものです。

社内政治プレーヤーは、必ずしも実行重視型ではない

チームに社内政治プレーヤーが配属されることがたまにあります。彼らはサイロをうまく操っていますが、主な関心は社内出世にあります。彼らは、エンドユーザーはもちろん、アプリケーションが実稼働環境へ移行するかどうかさえも、気にしないかもしれません。このような人々は、自己の利益のために、プロジェクトを別の方向に進めようとするかもしれません。つまり、出世のために適切と思われる人たちと一緒に仕事をしようとするのです。

通常、企業には中間管理職が非常に多いので、幹部の誰かがこのような人材をプロジェクトに投入することがありますが、反発することはできません。このような場合は、誰かが社内政治的な利益のために成果を出す妨げをしているのであれば、スポンサーにエスカレートできるように、プロジェクトリーダーに権限を与える必要があります。

管理職との期待値の設定

これまでのところ、理想的なモダナイゼーションチームを構築するための以下のように基盤を確立してきました。

• モダナイゼーションが提供する合意された価値

• フィードバックを提供するクライアント

• プロジェクトの障害物を取り除き、その価値の重要性を理解することができるスポンサー

• 深いテクニカルスキルと企業での経験を持つプロジェクトリーダー

• 企業での豊富な経験と人間関係を持つ賢者

• 割り当てられたストーリーを処理する準備ができており、プロジェクトリーダーからフィードバックを受け取ることができる開発者

次の記事では、モダナイゼーションの戦略を決定する方法について説明します。