「ソフトウェアが世界を飲み込んでいる」と、有名なベンチャーキャピタル会社アンドリーセン・ホロウィッツの共同創設者兼一般開業医のマーク・アンドリーセン氏は言う。デジタル デバイスが急増し、新しいテクノロジーが生活を変えるにつれて、ソフトウェアはあらゆるビジネスにとって不可欠な要素となっています。不動産や医療に従事している人でも、何らかのシステムやアプリケーションを使用する必要があります。したがって、ソフトウェアを効果的かつ効率的に開発することが、あらゆるビジネスの存続と成功の鍵となります。
しかし、アジャイル、スクラム、エクストリーム プログラミング (XP)、カンバン、チーム トポロジなど、多くの概念やプロジェクト管理フレームワークが登場しているにもかかわらず、ソフトウェアを効率的に開発する方法を知っている企業はわずかです。私は、最終的にはスケジュールの遅延、ソフトウェアの品質の低下、顧客満足度の低下につながる多くのエラー パターンに遭遇してきました。非効率な管理を回避し、より良いパフォーマンスを達成するには、ソフトウェア プロジェクト/製品管理のベスト プラクティス、概念、原則を理解する必要があります。
最も影響力のある実践の 1 つは、チームの構成方法です。多くの研究 (コンウェイの法則など) は、チーム構造が間違った方法で構築されると、チームのパフォーマンスが大幅に制限されることを証明しています。この記事では、私の経験と綿密な調査に基づいて、組織に効果的な構造を構築するためのいくつかの原則を説明します。
1. まずはシステム設計
高性能の研究開発チームを構築するための第一原則は、チーム構造を設計する前に、必要なシステムを設計することです。アメリカのコンピューター科学者でコンピュータープログラマーのメルビン・エドワード・コンウェイは、1967 年にコンウェイの法則 (コンウェイの法則) を提案しました。これは、生産のシステム設計を制約する組織の構造とコミュニケーション方法を説明したものです。組織がデザイン チーム、ビジネス チーム、フロントエンド チーム、バックエンド チームを設立した場合、システムの出力もビジネス ドキュメント、デザイン コンポーネント、フロントエンド コンポーネント、バックエンド コンポーネントになります。最終的な統合を完了してユーザーに提供するために、多くのチームコミュニケーションが必要です。コンウェイの法則に基づくチーム構造は、最も一般的なアンチパターンの 1 つであり、現在でも多くの組織で使用されています。
(コンウェイの法則の例)
以下のチーム構成では、頻繁なコミュニケーションを必要とせず、チームが独立してユーザーに価値を提供できます（ただし、完全に独立することはできません）。フロー調整チーム、機能別チーム、機能横断型チームとも呼ばれます。
2. 認知負荷を考慮する
Matthew Skelton と Manuel Pais が 2019 年に出版した「ハイパフォーマンス チーム モデル: 迅速なソフトウェア配信をサポートする組織構造」では、ソフトウェア開発組織の 4 つの基本的なチームについて説明しています:ストリームに合わせたチーム、イネーブル チーム (イネーブル チーム)、複雑なサブシステム チーム (複雑なサブシステム チーム）、およびプラットフォーム チーム（プラットフォーム チーム）。これら 4 つの基本的なチームの背後には、認知負荷、つまり使用される作業記憶リソースの量という重要な心理理論があります。
前の原則で説明されたチーム構造は、ハイパフォーマンス チーム モデルではフロー調整チームと呼ばれます。フロー調整チームは部門横断型であり、独立してユーザーに価値を提供する主力です。ただし、フロー調整チームは忙しすぎて、新しいテクノロジ、管理方法、リーダーシップなどの新しいガジェットについていくことも、インフラストラクチャに対処することもできません。フローに沿ったチームに責任を課しすぎると、チームはタスクを処理できなくなり、チームのパフォーマンスが低下します。したがって、認知負荷を軽減するために、残りの 3 つのチーム (イネーブル チーム、複雑なサブシステム チーム、プラットフォーム チーム) がサポートに来ます。
(チームトポロジ)
- 実現チームは、フローに合わせたチームがテクノロジー、アーキテクチャ、UI/UX、管理方法など、ユーザーに高い価値を提供するために必要な新しいことを学ぶのを支援します。実現チームは、流れに沿ったチーム内で新しいことを教え、実装できる内部/外部のメンター、コーチ、またはコンサルタントで構成されます。
- 複雑なサブシステム チームは、機械学習モデル、特殊なグラフィック/アニメーション、認証 API など、特別なスキルを必要とする、または通常の提供から分離できる特定のコンポーネントを担当します。 Complex Subsystems チームが取り組むコンポーネントは、Flow Alignment チームとの間に明確な境界がないため、話し合いを通じて決定されます。
- プラットフォーム チームは、フロー調整チームがスムーズにデプロイおよびリリースしてユーザーに価値を提供できるプラットフォームの構築と提供を担当します。チーム トポロジのコンテキストでは、プラットフォームは、ドキュメント、ガイダンス、DevOps、フロー調整されたチームがスムーズに展開できるように設計されたインフラストラクチャを含む包括的な概念です。
3. チームをスリムに保つ
3つ目の原則は、「小さくても洗練された」チームを維持することです。多くの研究や有名企業は、「小さくて洗練された」方が「大きくて完全な」ものよりも効率とパフォーマンスが高いことを示しています。これは、小さなチームでのコミュニケーションがより効果的であり、チームの全員がいつでも状況や状況を理解できるためです。エンゲージメントを高めます。 Amazon は創業以来、「ピザ 2 枚」の原則 (つまり、チームの構築と会議への出席は 9 名以下) を実践し、真の成功を収めてきました。
「アジャイル革命」の著者であるジェフ・サザーランド氏も「スクラムガイド」の中で次のように説明しています。小規模なチームの方がコミュニケーションが良くなり、より効率的に仕事ができることがわかりました。」
4. サーバントリーダーシップ
ダニエル・H・ピンク氏は著書『ドライブ』の中で「ドライブ3.0」を提唱した。彼は、人間の動機は産業時代以降変化したと主張し、私たちを動機づけ続ける自律性、専門知識、目的という動機の 3 つの要素を考察します。
- 自律性：人間は何をするかを決定したいと考えています。
- マスタリー：人間は成長したいと思っています。
- 目的: 人間は意味を求めます。
ロバート・K・グリーンリーフ氏が提唱した「サーバント・リーダーシップ理論」は、ドライブ3.0を具体化したものです。これはリーダーシップの哲学であり、その主な実践は、チームに奉仕し、チームメンバーのエンゲージメントを高め、モチベーションを高め、職場で持続的に成長し続けることです。伝統的なリーダーシップスタイルでは、リーダー（上司）がチームメンバー（部下）に何をどのように行うべきかをコマンドアンドコントロール方式で命令します。従来のリーダーシップ スタイルでは、個人のモチベーションを高め、エンゲージメントとパフォーマンスを向上させることができません。
一方、サーバントリーダーは、目標やビジョン（目的）を設定し、その目標やビジョンを達成するための手段を個人に委ね（自律性）、新しいことを学ぶ機会（専門性）を提供します。
5. 継続的な改善
2024年1月現在、世界最大の自動車会社であるトヨタの実践と理念は、7つの廃棄物、5S（整理分別、整頓、清掃、清掃、清掃、しつけリテラシー）、3Mなどあらゆる産業に影響を与えています。 (ムリ過多、ムダ無駄、ムラムラ)。その中でも最も有名な概念は、ビジネスプロセスを継続的に改善するカイゼン（改善）です。業種や状況に関係なく（業界トップシェアの企業であっても）、改善の余地は100％あります。完璧なビジネスは存在しないため、成長し続けなければなりません。
長期的には、継続的な改善により複利効果が得られます。この用語は元々、金融における「複利」に由来しており、利子が時間の経過とともに指数関数的に増加し、不労所得を生み出すことを意味します。同様に、チームとビジネスが改善し続けると、ビジネス プロセスも大幅に改善され、売上収益が飛躍的に増加します。欠点は、ほとんどの人が短期的には大きな効果が見られないため、継続的な改善をやめてしまうということです。長期的には、継続的な改善のメリットは非常に大きいため、継続性と忍耐が必要です。
スクラムはトヨタ発の最も人気のあるアジャイル フレームワークであり、継続的な改善の実践です。スクラムでは、スプリント レトロスペクティブ中に継続的な改善が行われます。スプリント レトロスペクティブでは、スクラム チームが今後の作業で何が改善できるかを話し合います。これが、スクラムがチームのパフォーマンスの問題を解決し、最も広く使用されるアジャイル フレームワークとなった最大の理由の 1 つです。
6. 安定性
パフォーマンスの高い研究開発チームを構築するための最後の原則は安定性です。つまり、チームの構造/メンバーシップと作業プロセスは安定した状態を維持する必要があります。不安定性はチームに混乱をもたらし、生産性やパフォーマンスに影響を与える可能性があります。
1 つ目は、チームの構造とメンバーの安定性です。これは、頻繁に変更したり移動したりしないことを意味します。たとえば、組織が開発者をチーム間で頻繁に移動させる場合、開発者は新しいチームに割り当てられたときに作業スタイル、コード ベース、ドキュメントに再度慣れる必要があり、その結果生産性が低下します。
2つ目はワークフローの流れの安定性です。作業プロセスが標準化および統一されていない場合、チームメンバーは作業方法に混乱し、成果物の品質にばらつきが生じます。トヨタは、標準化をビジネスにおいて最も重要な慣行の 1 つと定義しています。これは、大野氏が、作業は障害や無駄がなくスムーズに進むべきであると強調したためです。トヨタ生産方式（TPS）をきっかけに、作業工程や作業状況を可視化する「カンバン」が登場しました。
要約する
ソフトウェア研究開発組織では、チームの効率とパフォーマンスを向上させるために、効果的なチーム構造を構築することが重要です。この記事では、パフォーマンスの高い研究開発チームを構築するための 6 つの原則を要約します。
原則 1:システム設計はチーム構築よりも早く完了する必要があります。
原則 2:認知負荷を十分に考慮し、コア チーム (フロー調整チーム) の作業を支援するサポート チーム (イネーブル チーム、複雑なサブシステム チーム、プラットフォーム チーム) を編成します。
原則 3:チームを小さく美しく保ちます。チームが大きくなるにつれて、コミュニケーションはより複雑になり、生産性が低下します。
原則 4:サーバント リーダーシップを実践し、チームが Drive 3.0 に関するエンゲージメントとパフォーマンスを向上できるよう支援します。
原則 5:何があっても継続的な改善を主張します。たとえ業界ではるかに先を行っていたとしても、改善の余地は確実にあります。
原則 6:チーム構造と作業プロセスの安定性を維持する。これは、混乱やコストの追求を避け、チームのパフォーマンスを向上させるために重要です。
（原著者はEiki、内容はLigaAIが翻訳・編集したものです）
技術情報、研究開発管理の実践、その他の共有について詳しく知りたい場合は、LigaAI に注目してください。
LigaAI のインテリジェントな R&D コラボレーション プラットフォームを試し、インテリジェントな R&D コラボレーションを体験し、一緒に大きく強く成長することへようこそ!
マイクロソフトの中国AIチームは数百人を巻き込んで米国に渡ったが、 未知のオープンソースプロジェクトはどれだけの収益をもたらすことができるだろうか? 華中科技大学のオープンソースミラーステーション の立場が調整されたとファーウェイが正式に発表した。 外部ネットワークへのアクセスを正式にオープンしました。 詐欺師は TeamViewer を使用して 398 万件を転送しました。リモート デスクトップ ベンダーは何をすべきでしょうか? 初のフロントエンド視覚化ライブラリであり、Baidu の有名なオープンソース プロジェクト ECharts の創設者である - 有名なオープンソース企業の元従業員が「海に行った」というニュースを伝えた: 部下からの挑戦を受けて、技術者はリーダーは激怒し、無礼になり、妊娠中の女性従業員を解雇しました。OpenAI が AI にポルノ コンテンツを生成させることを検討したと 、Rust Foundation に報告されました。time.sleep (6) の役割を教えてください。 ?