ワークフローを平滑化する：「フラット」スタイルのプロジェクト管理ガイド

フラットな組織が人気を博すにつれて、それに伴う方法やプロセスも同様に普及しています。このブログでは、フラットな組織構造自体ではなく、プロジェクト管理の領域内でフラットな組織がどのように機能するかについて議論します。フラットな組織から学んだプロジェクト管理の原則は、最もフラットな会社から最も階層的な構造を持つ組織まで採用することができます。

「フラット」であることは流行っていますが、なぜそれを行うべきなのでしょうか？

「なぜフラットなプロジェクト管理に興味を持つべきか？」という質問をしているかもしれません。プロジェクトマネージャーにとって、答えはシンプルです：委任の必要が少なく、状況の確認を求めることが少なく、監視も少なくなります。これは、あなたが好きなことにもっと時間を割くことができるということを意味します... それが仕事の管理を楽しんでいる場合は（その場合はここで読むのをやめるべきです）。管理される側にとっても、明らかです：なぜ常に状況を追及され、仕事の正しいやり方を「助言」される必要があるのでしょうか？再び、それが好きなら、これはあなたにとって正しいスタイルではないかもしれません。ここでの考え方は、マネージャーが少ない管理を必要とし、他のすべての人が自分の仕事を望むように自由に、そして自律的に行うことができるということです。

前提条件

プロセス自体を始める前に、これを実際に機能させるための3つの主要な前提条件があります：信頼、透明性、そしてコミュニケーション。

ここ

図1. 信頼、透明性、コミュニケーション

信頼：お互いを信頼することは、フラットなプロジェクト構造を成功させるための鍵です

透明性：全員が自分が何をしているのかを完全にオープンにする必要があります。これは、以下のようないくつかの媒体を通じて彼らの仕事を伝えることで行うことができます：

1. コードのコミット
2. Wikiページ
3. 課題追跡システム
4. エスプレッソマシン（つまり、新しいウォータークーラー）

コミュニケーション：全員が互いにコミュニケーションを取る能力を持ち、そうすることが奨励されるべきです。

信頼があるところには透明性があります。透明性があるところでは、人々は安全だと感じ始めます。人々が安全だと感じ、自分の仕事についてオープンであることが奨励されると、コミュニケーションは自然に起こります。

実装

前提条件をカバーしたので、フラットプロジェクト管理の実装について話し合うことができます。

プロジェクトリーダー：「でも、フラットな構造では誰もボスではないと思っていましたが？」確かに「指揮と管理」に従事する必要がある人はいませんが、ファシリテーターがいることは重要です。プロジェクトリーダーを、全員が調和して同じリズムで演奏していることを確認する指揮者だと考えてください。

明確な目標と目的：プロジェクトの目標は、プロジェクトの開始時から明確に伝えられなければなりません。「私たちの目的は何ですか？何を達成しようとしていますか？誰がこのウィジェットを欲しがっているのですか？」といった質問は定義される必要があり、Wikiスペースはそれを行うのに最適な場所です。

要件と責任：プロジェクトリーダーやマーケティングであれ、要件は文書化される必要があります。そうでなければ、フラットなプロジェクト管理スタイルでは混乱が生じる可能性があります。明確な方向性がなければ、「ボス」が普通の環境で簡単に介入して片を付けることができます。フラットな環境では、明確に定義された要件がなければ、人々は簡単に迷子になることがあります。Jiraのような問題追跡システムでは、これらの要件をタスクやストーリーとして記録できます。標準的な実践では、プロジェクトリーダーが個々のタスクを担当者に割り当てます。よりフラットな作業環境では、未割り当てのタスクリストがチームに提示され、彼らが自分自身（または他の人）にこれらのタスクを自己割り当てできるようになります。このシステム（つまり、すべてのタスクが提示されるシステム）は、共有Excelワークシートとして単純なものから、カンバンボードのようなおしゃれなものまで様々です。これが設定されると、ボスでなくても、誰もがプロジェクト全体の状態を見て追跡することができます。

集中設計リポジトリ：集中設計リポジトリは、このスタイルのプロジェクト管理を作成し維持する上で重要です。各チームメンバーの設計を「上司」に対してロールアップしたり、常に状況を報告することはありません。人々が互いの作業を見ることができなければ、チェックとバランスがありません。各チームメンバーは、他のメンバーのチェック役です。ソフトウェアの世界では、これはプルリクエストを作成し、同僚にコードレビューを通じて作業をチェックしてもらうことで正式に行われます（上司がゲートとして機能するのではなく）。回路図のキャプチャやレイアウトでも、同様のプロセスで達成できます。このブログでは、設計をGitリポジトリ（つまり、新しい「SVN」または「CVS」）にコミットすることについて議論しています。この場合、開発ブランチにコミットし、その後プルリクエストを発行するという、ソフトウェアエンジニアリングの同じ実践に従います。このトピックに関する詳細は、AtlassianのGitチュートリアルでプルリクエストの作成方法を参照してください。

例：組み込みシステムウィジェット

この例では、組み込みシステムウィジェットを構成するさまざまな要件を含む小さなプロジェクトを設定したことがわかります。この場合のプロジェクトは、"Blinky LED"ボードを構築するための要件を含むEpicです。

図2. “Fancy Blinky LED PCB”を構築するための設計要件を含むEpic

このプロジェクトスペースには、機械、電気、およびソフトウェアの「コンポーネント」があり、それぞれのコンポーネントがコンポーネントリードに割り当てられています。

図3. プロジェクトのすべてのコンポーネントとコンポーネントリードのビュー

図4. 複数のコンポーネントを含むタスクの例

電気はAltiumを使用しており、彼のコードをGitサーバー（この場合はBitbucket）にプッシュしています。

図5. 回路設計のGitコミット

ソフトウェアおよび機械エンジニアも同様のことを行います。この特定のプロジェクトには3人のチームメンバーしかいませんが、コンポーネントリード（つまり、プロジェクトのその部分に対して責任を持つ人）がいる限り、無数のチームメンバーを含むことができます。

このWikiスペースにより、製品コンセプト、実装、または検証フェーズに参加しているすべてのユーザー間で会話が行われます。

図6. 製品に関する情報（タスクを含む）を含むウィキページ

スプレッドシート、タスクリスト、ウィキページ、またはメールの流れであれ、プロジェクトファシリテーターとチームの残りのメンバーがプロジェクト内で起こっているすべてを見ることができる能力を持つことが重要です。これにより、全員が単一のマネージャーではなく、互いに責任を持つことができます。私たちの会社では、プロジェクト活動をすべて視覚化する最良の方法としてカンバンボードを見つけました。

図7. 例のプロジェクトのタスクを含むカンバンボード

最後に、チームメンバーが問題を見つけた場合、躊躇することなくタスクを作成し、他のチームメイトに割り当てることを感じるべきです。彼らがバグを見つけたのか、ソフトウェアの実装をサポートするために追加のハードウェアが必要だったのかにかかわらず、彼らは自信を持ってその要求を横からではなく、上から始めるべきです。

結論

マイクロマネジメントはもう古い話です。プロジェクトをフラットな形で管理することは、トップダウン方式よりも流行っているだけでなく、全員のプレッシャーを軽減します。プロジェクトマネージャーはステータスの追跡にかかる時間が少なくなり、デザイナーもそれらのステータスレポートを作成する時間が少なくなります。この記事では、プロジェクト管理におけるフラットスタイルアプローチの背後にある原則と、その実装がどのように見えるかについて説明しました。フラットスタイルのプロジェクト管理アプローチを採用するために、企業全体の構造をフラットにする必要はありません - 上記の原則を採用し、すぐに取り組むだけです。

次のPCB設計でAltiumがどのようにお手伝いできるかもっと知りたいですか？Altiumの専門家に相談してくださいまたは、Altium Designerの包括的なコンポーネントライブラリが設計およびシミュレーションツールと直接連携し、必要な機能を備えた組み込みシステムを簡単に設計できる方法についてさらに読み進めてください。

チームで協力して節約

新しいAltium Designer^® シートを追加するときに特別割引を受ける