ブライアンフィッツパトリック、ベンコリンスサスマン「チームオタク：理想的なIT企業」：チームカルチャーは何でできているか

今日、私たちはブライアン・フィッツパトリックとベン・コリンス・サスマンによる「チームオタク：理想的なIT企業」という本で知り合い を 続けています。前回はチーム内のコミュニケーションから始め、主に個々の従業員の考え方が彼らにどのように影響するかについて話しました。今回は、チームをより広く見る必要があります。独自の内部文化を持つ統一されたグループとして、何らかの形で形成され、何かに必要とされています。



チーム文化は、特定のプログラマーグループに固有の知識、価値観、および目標のセットです。これには、プログラムコードの作成方法、人と人とのコミュニケーションのスタイル、ワークフローの編成方法が含まれます。コンポーネントはたくさんあります。それらのいくつかはそれほど重要ではなく、簡単に行き来でき（たとえば、金曜日にピザを注文してボードゲームをプレイする習慣）、その他は文化の「バックボーン」を形成し、プログラマーの世代全体を生き残ることができます（たとえば、コード検査、テスト、文書化などのプロセスの手順。さらに）。



元の形式では、文化は通常、創設者と元の技術チームによって設定されます。その後、必然的に開発され、変更が加えられますが、強力で実績のあるチーム（Google、Apple、Microsoft、Oracleが例として挙げられます）の場合、ほとんどの場合、元の顔をある程度保持します。ルーツとの接続が完全に失われるわけではありません。



一般的な誤解に反して、チーム文化は完全にリーダーの手と良心にあるわけではありません。それが本当に存在するのであれば（文化が本当にない場合にどうなるかについては、少し後で話します）、ほとんどすべての従業員によって放送されます。これは、初心者チームが通常どのように統合するかを見ると明らかになります。新しい開発者は、ここでどのように受け入れられるか、同僚とのやり取りを通じて何が重要で何が重要でないか、コードで何に注意が払われているか、修正の必要性をどのようにどのようなトーンで説明しているか、競合はどのようになっているのかを理解します解決しました。







自立したチーム文化：パン屋の比喩

なぜチーム文化に取り組むのですか？

したがって、チームの文化は、一緒に働く人々が同じ波長にとどまることができるようにする、異なる態度と合意の一種の拡散した混合物です。自然な疑問が生じます：これについて心配する価値はありますか？仕事の過程で従業員同士が相互に影響し合うことは自然に起こり、どんな文化もそれ自体で形成される可能性があります。



ここでの問題は、すべての自発的なプロセスと同様に、自発的に進化する文化がより多くのエントロピーを生成し、予測できない結果を生み出す可能性があることです。言い換えれば、遅かれ早かれ、「ここでは慣例として」を自分の手で決定する人々がいるでしょう。彼らが正気で同じ方向に行動することが判明した場合、エンディングは幸せになります。しかし、多くの場合、それは同じ古き良きオフィス戦争、またはさらに悪いことに、チーム内の崩壊のポケットに変わります。



したがって、物事を手放すことは最良の選択ではありません。以上、文化を無理に浸透させることはできないが、意識して文化の形成に取り組むことができるということをお話しました。各参加者が前章の原則に従って行動するだけでなく、チームのレベルに参加させようとし、協力にとって危険な行動を抑制し、すべての人に共通のルールを交渉することを恐れない場合、リスク不快な驚きの減少。

チーム文化はどうあるべきですか？

もちろん、この質問に明確かつ徹底的に答えることは不可能です。作物は非常に多様であり、健康的で生産的なバリエーションの範囲は広いです。よく組織された快適な仕事は、誰もが参加している混沌としたスタートアップでも、明確なプロセスと距離を保っている大企業でも可能です。多くの要素のそれぞれにベンチマークを設定しようとしても意味がありません。



最も一般的な用語では、文化は次のようになります。

• . . , , . , : .
• . , , , , . . , , – .
• . , , , : , , . , – , .
• . , , . , . , .

コミュニケーションチャネルは、文化の中で最も制御しやすいコンポーネントであり、著者はそれらに最も注意を払っています。ただし、詳細に入る前に、他のより微妙な要素に関するヒントをいくつか示します。



ときにそれがに来る 意思決定の方法、そしてほとんどの場合、プログラマーは民主的なモデルを好みます。おそらくこれは、彼らの悪名高い独立への欲求によるものか、あるいは職業が本質的に創造的であるという事実によるものかもしれませんが、事実は残っています。開発者が発言権を持ち、自分の考えを共有する能力を持つことが重要です。リーダーは、意思決定プロセスを編成する際にこれを考慮に入れる必要があります。一般投票ですべての問題を解決する必要はありません。従業員が実際に耳を傾け、システムは彼らが自分の所有権を感じるのに十分なコンセンサスを前提としています。 コミュニケーション



の 仕方も、彼女は攻撃性よりも強調された礼儀正しさに引き寄せられるべきです。叫び声や断定的な口調を使って自分自身を主張するチームの問題は、落ち着いた心の人々を押して圧倒することです。対立しがちな人は、攻撃的な環境でも礼儀正しい人でも非常に快適に感じるでしょう。それどころか、落ち着いた、控えめな人（プログラマーの中にはたくさんいます）は、攻撃的なチームで適切に開くことができません。したがって、攻撃的なコミュニケーション方法を奨励または単に採用することにより、潜在的な強力な従業員の一部を自動的に遮断します。これは実用的ではありません。



同時に、正しさと相互尊重の文化はより脆弱であり、外部の影響を受けやすいことを理解する必要があります。ハーモニーを揺るがすには、1人の断定的な初心者で十分です。したがって、受け入れられているコミュニケーション方法に反する試みをやめ、破壊的な行動によって人々が勝利を収めることを防ぐことが非常に重要です。これを行うための最良の方法は、単に攻撃的な口調でのコミュニケーションを拒否することです。

コミュニケーションチャンネル

情報の固定と伝達がチーム文化において決定的な役割を果たすことがわかりました。現代の状況では、この目的のために多くのツールが利用可能です。このセクションでは、最も一般的なもののみの概要を説明します。



成功したチームの共通の特徴は、さまざまなコミュニケーションチャネルを積極的に使用して、全員が移動の一般的な方向と現在の作業の進捗状況の両方を認識し続けることを保証することです。同時に、第一に情報を公開し、第二に非同期通信の可能性を最大限に活用するチャネルに重点が置かれています。



さらに、著者は、技術チームでコミュニケーションを行うための特定のツールをいくつか検討しています。それらの目的と使用規則を明確にする。



ミッションの定義



そのようなタイトルから、読者とプログラマーはおそらく自分自身を横切るでしょうが、実際には、すべてがそれほど怖いわけではありません。技術的な仕事では、ミッションは個々のプロジェクトのレベルで策定され、漠然と華やかな表現で会社を称賛するのではなく、何が行われ、何が行われていないかを明確に示すことを目的としています。言い換えれば、ミッションステートメントは、製品開発の方向性とその範囲を制限することの簡潔な定義です。



そう言いましょう：

GWTの使命は、開発者が既存のJavaツールを活用して最新のブラウザー用のAJAXアプリケーションを作成できるようにすることで、ワールドワイドウェブのユーザーエクスペリエンスを根本的に改善することです。

オープンソースプロジェクトに積極的に関与している人々として、フィッツパトリックとサスマンは、彼ら自身の経験から、そのような措置が長期的にチームのためにどれだけの時間、エネルギー、神経を節約できるかを知ることができました。新しいメンバーが絶えず仕事に参加し、それぞれが独自の野心、コメント、明るいアイデアを持っている場合、グループの「コア」はプロジェクトの本質を明確かつ均一に理解している必要があります。それ以外の場合、作業は白鳥、かに座、パイクに関する寓話のシナリオに従って行われるか、途中でこれらの問題を明らかにしようとするために絶えず血栓が発生します。



したがって、ミッションステートメントは2つの点で役立ちます。まず、プロジェクトの目標と範囲について主要な利害関係者の間で意見の相違がある場合、それはすぐに表面化し、遅滞なく解決されます。第二に、議論の結果は、主な論文を含む文書になり、鈍いまたは過度に熱心な新参者を参照することが可能になります。



ミッションステートメントは、プロジェクトに関する決定の足がかりをチームに与えますが、絶対に不可侵であると見なされるべきではありません。仕事の目標や状況が根本的に変わることが（主にスタートアップで）起こることがあります。緊急事態では、元の任務がまだ関連しているかどうかを正直に評価し、それに応じて修正することは理にかなっています。



プロジェクトのドキュメント



ミッションが「何」という質問に対するすべてのプロジェクト参加者に対して単一の回答を作成するように設計されている場合、プロジェクトのドキュメントは「どのように」という質問に対する同様の作業を意味します。



プロジェクトドキュメントは、将来のプロジェクトとその技術的な詰め物のより詳細なスケッチを提示します。通常、1人の所有者、2人または3人の作成者、およびかなりの数のレビュー担当者がコメントを投稿します。ドキュメントを書くことは、それを我慢するのがどれほど難しいかに関わらず、コードの作業に先行する必要があります-批判に耳を傾け、実装計画を調整するには、1行も書かれていない瞬間が最適です。完成したプロジェクトドキュメントは、ロードマップを作成したり、作業の段階を強調したりするときに非常に便利です。



設計文書は、その性質上、ミッションステートメントよりもはるかに柔軟性があります。それは教義ではなく、生き物です。開発プロセス中に、いくつかの詳細を修正する必要があります。理想的には、チームが遅れないように、ドキュメントにこれらすべての変更をリアルタイムで反映する必要があります。実際には、残念ながら、製品のリリース後に編集されることがよくあります。



ミーティング



多くの人は、ここでも十字架の印を付けるのがいいと思うでしょう。ミーティングは開発者の間でかなり悪い評判があります。著者によると、その理由は、それらが不十分に編成されており、非同期通信チャネルに目を向ける方が合理的である場合によく使用されるためです。



形式の選択が失敗した良い例は、一定の規則性（通常は週に1回）と多くの人々で開催される「会議」です。通常、重要なアナウンスがそこで読まれ、一般的な結果が要約されます。実際、チラシのすべての内容は、電子メーリングリストに変換するのが非常に簡単で生産的です。ただし、それが正確に必要な幅広い集合的な議論である場合を除きます。



本当になくてはならない会議については、以下のルールに留意してください。

• . – , , , . « » — . , - .
• , , . , . , , .
• . – .
• (, ). , – Google .

メーリングリスト



Eメールは、プロジェクトの履歴をバックグラウンドで文書化するための非常に便利なツールです。トラフィックがはるかに多く、規制がはるかに少ないインスタントメッセンジャーから情報を抽出するよりも、情報を抽出する方がはるかに簡単です。したがって、以前の場所に関係なく、すべての重要な情報をメーリングリストに送信することをお勧めします。会議の計画とメモのコピー、特定の問題に関する議論の結果、プロジェクトドキュメント、エラーの分析です。このようにして、一元化されたデータウェアハウスが形成され、特定の情報を見つけるだけでなく、決定の起源と議論の過程を追跡するために、いつでも戻ることができます。もちろん、アーカイブには索引付き検索が装備されている必要があります。



文書化、したがって郵送の重要性は、チームがスペースにどれだけコンパクトに配置されているかによって決まります。一部の従業員がリモートで作業したり、不定期にオフィスに現れたりする場合、主要なプロジェクトニュースをメールで複製するという持続可能な慣行が緊急に必要になります。そうでなければ、「空中にある」情報のほとんど（廊下やテーブルの近くでの議論、会議に参加していなかった人々への新しい情報の口頭での伝達）は彼らを通り過ぎます。



チームが大きく、プロセスが混乱している場合、参加者は間もなく異質な発表の流れに溺れ始めます。この状況では、ドキュメントは、関心のある従業員を含むさまざまなテーマ別のメーリング（開発、プログラムコードの分析、ユーザーサポート、テストなど）に分割されます。ただし、1つのストリームから始めることをお勧めします。分離が必要な場合は、すぐにそれが伝えられます。



オンラインメッセンジャー



メッセンジャーは、同期通信と非同期通信の中間に位置します。これらは文書化には最適ではありませんが、特に分散したチームでは、問題を迅速に解決するために不可欠です。コマンドカルチャーの観点から、ここでは2つの側面が重要です。



第一に、私的議論と公的議論の境界線。社内メッセンジャーと商用メッセンジャーの両方の大多数は、ユーザーに特定の人または人々のグループとのコミュニケーションを選択する機会を与えており、これは非常に便利です。しかし、フィッツパトリックとサスマンによれば、最近は孤立する傾向があり、議論はますます非公開で行われています。



いくつかの点で、これは悪いことではありません。私的な問題がすべての従業員に「空気を詰まらせる」ことは絶対にありません。しかし一方で、人々は議論の過程をたどり、コメントを挿入し、すぐに変更について学ぶ機会を奪われています。初心者も、一般的なチャットで活発なディスカッションを黙って読むだけで多くの貴重な情報を得ることができるため、多くを失います。多くの場合、議論はニッチすぎるためではなく、脆弱性に対する同じ恐れのために非公開になります。すべての人の前で質問したり提案したりしたくないのです。彼らが愚かであることが判明した場合はどうでしょうか。開発者はそのような動機に気づき、パブリックドメインにとどまるのが賢明なことを隠さないようにする必要があります。



第二に、インスタントメッセンジャーは、すべての瞬間的な反応にもかかわらず、ライブコミュニケーションの完全な代替ではないことを覚えておく必要があります。一部のフレーズを和らげたり明確にしたりするようなイントネーションや表情はありません。これにより、謙虚さ、尊敬、信頼の原則を脅かす誤解のリスクが高まります。これを念頭に置く必要があります。



バグ追跡システム



このツールは、上記のツールほど一般的ではありません。特定の条件下では、非常に有益な場合があります。

• エラーを処理およびソートするための手順が利用可能であり、タイムリーな登録と修正が保証されます。システムのデバッグに十分な注意が払われていない場合、人々はそれを使用しないか、または小さな方法でそれを悪用します。
• . « » , .
• . – .
• . , , .

開発の一環としての



コミュニケーション技術チームでのコミュニケーションは、コード内だけでなく、コード内でも直接行われます。ここでのメインチャネルは、もちろん、 開発者のコ​​メントです。



著者は、コードコメントの基本的なルールに簡単に触れます。これはおそらく誰もが知っていることです。何が行われているのかではなく、なぜ行われているのかを説明し、関数とメソッドのレベルでコメントし、簡潔で、実行されないようにします。詳細を離れて。残りのコメントスタイルは主観的なものであり、各チームはニーズと一般的な雰囲気に応じて独自に開発します。重要なことは、この一般的なスタイルは原則として存在する必要があるということです。この場合の均一性という事実自体が、特定の特性よりも重要です。



コード内で通信するもう1つの方法 は、帰属、つまりファイル内の開発者の署名です。文書にあなたの名前を残す習慣は古代にまでさかのぼります。古いプログラムでは、そのようなサインをよく見ることができます。





FitzpatrickとSussmanは、今日、これらの署名は時代錯誤と見なされるべきであると主張しています。心理的な観点から、もちろん、著者であることを示したいという願望は自然で理解しやすいままです。これは、行われた仕事に対するプライドと責任感の表れです。ただし、実用面では、これはメリットよりも多くの問題を引き起こします。記事の最初の部分ですでに確立したように、開発はチーム活動になりました。実際には、一度に複数の人が1つのコードに関与する可能性があります。つまり、作成者の問題を解決すると、論争、恨み、そして最終的には時間の浪費を引き起こす可能性があります。



現在の環境では、コード内で直接作成するよりも、プロジェクトレベルで作成者を追跡する方が便利です。コードの特定の部分に関する質問に誰が連絡するかを正確に知る必要がある場合は、バージョン管理システムが役に立ちます。



IT企業の「人間的側面」の中核をあらゆる側面から見てきたので、周辺層、つまりチームとユーザーを取り巻く外部要素に移ることができます。