特定の機能が提供されない理由を理解するのは、往々にして困難です。経営陣は技術チームを責め、技術チームは経営陣を責めるかもしれません。一方、ビジネス側は板挟みになり、状況に関係なく結果を出そうとしながら根本原因を特定しようとします。このシナリオは、通常、会社が著しく成長した後、または以前は簡単に解決できた以前の問題が時間の経過とともに放置された後に発生します。テクノロジー企業におけるすべての問題は純粋に技術的なものだというのはよくある誤解ですが、これは真実とはほど遠いものです。 この記事では、機能の提供を著しく妨げる可能性のある、企業組織内の領域について説明します。また、根本的な原因を特定するための調査の方向性も提案します。その原因は、権限レベル内でエスカレーションまたは解決できます。 変更や改善を実施する前に、職場環境を理解することが非常に重要です。このテーマについては多くの洞察に満ちた本が書かれていますが、すべてのアプローチがすべての企業に当てはまるわけではありません。これは、何か間違ったことをしているということではなく、各企業の独自の性質を認識しているということです。 重要な注意点は、ここで共有される洞察は主にソフトウェア開発に関連しており、従業員が 50 人以上の企業または部門に最も当てはまるということです。 組織構造 まず第一に、会社の規模と構造を理解します。さまざまな部門を特定し、それぞれに期待することを明確にします。これらすべての部門が必要かどうかを評価します。組織構造の図を作成し、各部門とその役割を詳細に記述して、各部門の業務内容と存在理由を理解します。多くの場合、各部門は複数のチームで構成されます。これらも図に含めますが、今のところは説明せず、チーム名のみにしておきます。 企業が成長するにつれて、組織構造が複雑になり、進捗状況を追跡することが難しくなります。この複雑さの中で、特定の部門やチームを創設した当初の理由を見失う可能性があります。一部のチームは、もはや重要ではない問題に対処するために設立された可能性があります。ここでは、概要としてどのように見えるかを示します。 組織構造の明確な図ができたら、次は何をするのでしょうか? 従業員階層 次に、従業員の階層構造を明確にすることが重要です。誰が誰に報告するのか、またその理由は何かを把握することが重要です。ライン マネージャーは、大規模な事業部門を管理するか小規模なチームを管理するかに関係なく、部下と効果的にコミュニケーションを取る必要があります。コミュニケーションは、技術用語でもビジネス用語でも明確にする必要があります。両方を扱うのは難しい場合があるためです。大企業では、責任分野が異なる直接的なマネージャーと機能的なマネージャーがいる場合があります。これは、階層構造図で明確に表す必要があります。 従業員の階層は、報告ラインを明確にするだけでなく、組織内の垂直方向の識別にも役立ちます。垂直方向とは、デザイナー、人事、DevOps、さらには開発者など、複数の部門間で共有リソースとして機能する階層構造です。垂直方向は非常に有益ですが、特に開発者がさまざまなプロジェクトに取り組んでおり、ビジネス目標や技術的な課題に精通していないマネージャーに報告する場合に、ボトルネックになることがあります。その結果、開発者は適切なフィードバックを受けられず、マネージャーは適切なコンテキストを持ちません。したがって、潜在的な問題やタスクの優先順位を特定して分析するには、階層を理解することが不可欠です。最終的には、次のようになります。 注釈 CEO — 最高経営責任者 CPO — 最高製品責任者 CTO — 最高技術責任者 COO — 最高執行責任者 HD — デザイン責任者 PO — プロダクトオーナー HE — エンジニアリング責任者 HS — 営業部長 HM — マーケティング責任者 D — 開発者 PM — プロダクトマネージャー TL — 技術リーダー EM — エンジニアリング マネージャー S — 営業マネージャー M — マーケター 組織構造と報告ラインを比較すると、各従業員がさまざまな活動にどのように関わっているかがわかります。さらに、組織構造と従業員階層を一致させることで、個人が同じ部門やチーム内で共通の目標に向かって働いているかどうかを確認できます。マッピングのテンプレートは完全に自由ですが、次のようになります。 チームの責任 各チームが活動する領域を明確に定義することが重要です。チームがコードを扱う場合は、使用するサービスと所有するサービスを指定します。意外にも、これらは異なることがよくあります。チームが 1 つの部門内でのみ活動しているのか、それとも他のチームが直接変更することなく利用するコア機能に取り組むプラットフォーム チームなのかを判断します。 チーム名、部門、所有するサービスのリスト、チームが変更できるが所有していない一般的なサービスのリスト (理想的には、そのようなサービスは存在しないはずです)、簡単な説明などの列を含む表を作成すると非常に役立ちます。この表は、複数のチームが同じコードベースで作業して競合が発生していないか、または責任範囲が明確でないかどうかを調べるのに役立ちます。また、チームが主にバグを修正しているのか、明確な焦点を持たずにさまざまなタスクに取り組んでいるのかを明らかにすることもできます。 このレベルの詳細は、チームの責任の重複、競合、ギャップを特定し、よりスムーズなコラボレーションとより効率的なプロジェクト実行を確保するために不可欠です。 従業員の責任 チームの説明に加えて、従業員の一般的な役職を理解し、その責任の詳細な説明を準備することが重要です。経営陣が想定していることと、従業員が実際に行っていることは大きく異なることがよくあります。ソフトウェア開発業界にはさまざまな役職があり、会社によって期待される役割は大きく異なります。たとえば、エンジニアリング マネージャーの役割は大きく異なる可能性があります。デリバリー マネージャー、データ サイエンティスト、アーキテクト、テクニカル リードなどの役割は言うまでもありません。企業によっては、1 人の人物が複数の役割を果たすことが期待される場合もあります。 各ポジションに明確な期待を設定することは不可欠です。この明確さは、活動を適切に追跡するのに役立つだけでなく、従業員が自分に何が期待されているか、何が自分の範囲外であるかを理解するのに役立ちます。これは、組織内のすべてのポジションに適用されます。明確な役割定義は、重複を防ぎ、混乱を減らし、全員が効率的かつ組織的に共通の目標に向かって作業できるようにします。 機能提供プロセス ここまでで、会社の構造、従業員の階層、および各自の責任を明確に理解できたはずです。混乱しているように思えるかもしれませんが、目標は変更を加える前にまず現状を理解することです。次は、機能提供プロセス、つまりビジネス機能が最初のアイデアから本番環境に移行するプロセスについて説明します。 ここでは、CI/CD などの技術的な側面ではなく、開発者がコードを記述してそれを直接本番環境にデプロイすることを前提として、ビジネスから開発者へのフローに焦点を当ててください。目的は、ビジネスからチームへのプロセスにおける問題を特定し、従業員がそれにどれだけうまく対応しているかを確認することです。 以下の点を考慮してください。 どのくらいの頻度で新機能を計画し、各部門やチームに作業を割り当てていますか? 主要業績評価指標をどのように設定し、測定しますか? マイルストーンを使用していますか? 最初の準備には誰が関わっていますか? チームでどのように計画しますか? 計画と実行のプロセスを調整するのは誰ですか? 貴社は真にアジャイルな企業ですか? SAFe、Prince2、PMP などのフレームワークを使用していますか? あるいは、貴社に適したカスタマイズされたフレームワークをお持ちですか? チーム間の複雑なタスクをどのように処理し、進捗を管理していますか? 構造化されたアプローチを採用していますか、それとも、物事が何らかの形で解決されることに頼っていますか? 覚えておいてください。管理とレポートの各レベルは、方向性に関係なく、複雑さと不確実性を追加します。最終的に、プロセス図は 1 つの単純な質問に答える必要があります。「どのように？」 テンプレートを試して、ニーズに合わせて調整することができます。これは、配信を管理する主要なプレーヤーはいないが、時間枠がある、配信プロセスの非常に高レベルの例です。 この図の作成方法がわからない場合は、BPMN (ビジネス プロセス モデルと表記法) または四角形や線などのよりシンプルな形式を使用して、関係者全員に明確さと理解が得られるようにすることを検討してください。重要なのは、プロセスを明確かつ理解しやすいものにすることです。 フィードバックを集める 会社の構造、従業員の階層、チームと役職の責任、およびデリバリー プロセスをマッピングしたら、すべての調査結果を組織と共有し、できれば匿名でアンケートを実施します。このベースラインは、会社の運営方法を明確にします。この概要を自分で準備したり、一部のタスクを委任したりしたかもしれませんが、開発者、設計者、アナリストが直接関与していない可能性があります。彼らからのフィードバックは、調査結果の正確性を評価するために不可欠です。 従業員にドキュメントの品質を評価してもらいます。配信プロセスについてどう思いますか? ドキュメントは実際の作業方法を反映していますか? どこに障害があると思いますか? さまざまな苦情やフィードバックが寄せられることを予想してください。それらは、調査結果を精査して会社の業務の実態に合わせるのに役立ちます。階層が複数あるとコンテキストが失われることが多いため、このフィードバックは不可欠です。すべてのレベルから意見を集めることで、組織のより明確で正確なイメージが得られます。 結果を見積もる 会社や部門の運営方法の包括的な説明ができたので、潜在的な問題の分析と探索を開始できます。このベースラインは、問題を理解して解決するための明確な出発点となります。 重点を置くべき領域は次のとおりです。 部署は構造化されていますか? 報告ラインは明確ですか? ラインマネージャーは、自分の責任範囲に関して本当にフィードバックを提供できるのでしょうか? ビジネス要件を技術的なタスクに変換するときに混乱や不確実性が生じますか? 開発中に遅延を引き起こす他のチームへの依存関係はありますか? 従業員は主な責任範囲外の活動に従事し、本来の業務の妨げになっていませんか? 従業員の階層はチーム構造とどの程度一致していますか? 報告階層は効果的ですか、それともコミュニケーションとコンテキストにギャップがありますか? 異なるチームが同じサービスに取り組んでいるため、タスクの所有権を決定する際に競合が発生し、時間が無駄になっていることはありませんか? 責任が明確に定義されていない、または主要な担当者がいないチームや部門はありますか? 一部のチームはどの部門にも統合されていないのでしょうか? 最後に、会社が抱えている実際の問題のリストを作成し、それに取り組むことになります。すぐに対処する必要がある重大な問題から、「あったらよい」改善まで、優先順位を付けます。 変更方法 「これは素晴らしいことのように思えますが、実際にどのように改善すればいいのでしょうか?」と疑問に思うかもしれません。これは良い質問であり、正直な答えは、あなたが特定した具体的な問題とビジネス ニーズによって異なります。ただし、重要なアドバイスの 1 つは、すべてを一度に変更しようとしないことです。代わりに、小さな変更を段階的に実装し、結果を評価し、反復します。アジャイル アプローチはソフトウェア開発だけでなく、あらゆる種類の組織変更に適用できることを覚えておいてください。 改善プロセスをガイドする手順は次のとおりです。 従業員が自分の役割に含まれるものと責任の範囲外のものを正確に理解していることを確認します。 明確に定義された部門またはドメインを作成し、各ドメインに特定のチームを割り当てます。 責任範囲を明確に定義し、部門やチームの重複を最小限に抑えます。 ソフトウェア開発のさまざまな側面をカバーするために、プラットフォーム チーム、ストリーム整合チーム、有効化チーム、複雑なサブシステム チームを導入するチーム トポロジ アプローチについて理解を深めることを検討してください。 新しく確立されたドメインとチームに合わせて従業員の階層を確認して調整します。 報告構造が明確であり、進捗状況の追跡が簡単であることを確認します。 機能の配信と結果の追跡に使用する方法論またはフレームワークを選択します。 できれば重要な部門以外の任意の部門で変更をテストし、影響を評価して、フィードバックと結果に基づいてアプローチを改良します。 選択した考え方を組織の変更に適用することで継続的に改善します。 これらの手順に従うことで、情報に基づいた段階的な変更を加え、組織の効率性と有効性を徐々に向上させることができます。 まとめ 私は、どの会社や部門でも起こり得る共通の問題に焦点を当てることを目的としました。各会社には独自の目標と構造があり、何が最適かを判断することが重要であるため、特定のフレームワークやアプローチを推奨することは意図的に避けました。 開発者を責めるのは簡単ですが、開発者がビジネスの優先事項を認識していなかったり、不明確な配信プロセスによって妨げられている可能性があることを忘れないでください。ビジネス自体が無意識のうちに障害を作り出している場合もあります。この記事が改善への第一歩を踏み出すのに役立つことを願っています。
