# 組織内にあてはめる: 計画の理解 **要約** * 計画段階において、透明性はとても重要です。我々の経験上、組織内での透明性を確立することで、外部からのコード受入れ件数は桁違いの向上を見せる事がわかっています。 * 組織内での正式なプロセスを作成し、定型化することで、全員が共通認識を持てます。 * もし仮に透明性が無く、意思決定の背景や理由を知らないようであれば、従業員はコードの修正提案を行う事ができなくなります。 トップダウンによるマネジメントは複雑で、めったに機能する事はありません。オープンな共創こそスケールするのです。 *** インナーソースとオープンソースの最大の違いは、企業における事業構造や制約に起因します。 企業の中では往々にして組織階層や権力が存在しますが、これらは透明性と個人の主体性を重んじるオープンソースの文化に反してしまいます。 一方で、ビジネスの世界ではオープンソースから学べる場合が多々あることも事実です。 では、どのように我々はオープンソースの基本的な文化を薄めることなく、企業内に応用していけばよいのでしょうか？ ## 小さく、シンプルでありながらメンバーを巻き込む 私たちの最大の成功は、企業組織の中において既に存在している鍵となるような力を発見し、それをどう活用するかにありました。 現状のプロセスを見直し、それらをインナーソースに向けて小さく修正していくための方法を見つけるのです。 私たちは透明性や所有権について議論することなく、 *なぜ* ではなく *どのように* を考えながらビジネス環境の要望に応え、結果を改善するための明確な手段をシンプルに相手に伝えています。 適応性を高め、大きな組織が変化に対する拒絶反応を起こさないようにするためにも、変更は出来るかぎりシンプルにするのがベストです。 例えば、私たちのコントリビューション協定を作成するためのプロセスは非常にシンプルで、要求事項はほとんどありません。 コントリビューション協定はトラステッドコミッターが所有し、他のチームからも閲覧が可能であり、トラステッドコミッターの連絡先や予定が書かれています。 むしろ、トラステッドコミッターの連絡先と予定以外には何も強要していません。 もちろん、他の情報も多く記載される事は推奨していますし期待しています! ゲストコントリビューターが直面する問題は、コントリビューション協定の追加や変更を経験する理想的な学習体験になります。 これは誰かの家に泊まった時、その家の家主が深夜2時以降は音楽を大音量で流してはいけない、というルールがあるのと同程度です。 トラステッドコミッターのプロセスで重要なのは、その変更の影響を最もうける従業員には、それを管理するためのより大きな権限を持つという事にあります。 これらのシンプルな要求事項に加え、トラステッドコミッターがコードの変更を受け入れるか拒否するかのルールというのは、比較的小さいもので、インナーソースプロセスに対してあまり警戒されません。 しかし、こうした要求事項は次の結果につながるのです。 * トラステッドコミッターには、新しいプロセスに関与するという大きなインセンティブが生まれます * 協定に連絡先が掲載されていれば、すぐによいコミュニケーションとドキュメンテーションが始まります * 明確に期待している事がドキュメントに書かれていれば、更に良いコラボレーションへつながります * コードの変更は、更に迅速なポジティブフィードバックループへつながります * 多くのコードを変更し、トラステッドコミッターがより多くのメンタリングを行う事は、結果として多くのドキュメンテーションにつながります * トラステッドコミッターは自分達のコードと外部への影響について更に深く理解する事になります 要求事項を必要最低限に抑えることにより、チームのプロセスをチーム固有のニーズ(オープンソースの信念)に合わせることができます。 そして、良いコラボレーション、良いインテグレーション、ボトルネックの低減、整理されたコードというインナーソースの目標にもつながるのです。 ## 企画&製品スペシャリスト トラステッドコミッターとコントリビューション協定を活用しインテグレーションを加速させることに成功した後、製品を企画するプロセスにおいても同様の必要性を感じました。 製品のライフサイクルにおけるあらゆる側面を注視している製品スペシャリストは、チームや製品間のサイロをなくし、社内にある他の製品とインテグレーションできる方法を常に考える必要があります。 また製品スペシャリストは他チームと適切に交渉しつつ、実装すべきフィーチャーの優先順位を決める事ができる能力と知識が必要になります。 しかし、製品のコードや製品のインテグレーションに関わっている人でさえ本来は腰を据えて他のチームとじっくり議論しなければならないと *知っていつつも* 強制されない限り時間を作らないものです。 元の予定に無かったものは、簡単に後回しになります。 その結果、コミュニケーション不足、遅延、誤解を生じさせます。 これを正すための手段は、正式なプロセスを変更し必要な会議を必ず開催すると同時に、適切な参加メンバーをより多く集め、透明性を高め、サイロ化された考え方をより多く壊していく事となります。 製品スペシャリストとは、このオープンなプロセスを改善するために協調しています。 ## インクルージョンと透明性 プロセスを円滑に進めていくためには、全てのチームが最初の企画段階から参加する事が不可欠となります。 ストーリーグルーミングのプロセスでは、主要なコードのオーナーだけでなく各チームの代表者が参加する必要があります。 ときにチーム間で優先順位は異なり、それらは相反することもあります。 各チームの企画者が集まることで、全てのタスクが完了するために何が必要か互いに話し合う事ができます。 インクルージョンによって協業は更に円滑になります。 企画段階での透明性も同時に重要で、対立の減少に役立つと我々は考えています。 お互いの会話がパブリックな記録に残すつもりで行われると、参加者は全体によってより良い優先順位を考えられるようになる事を発見してきました。 つまり、サイロ化の考えに打ち勝てるという事です。 企画会議に参加する人数を増やした事で透明性が更に高まるという側面もあります。 トレードオフの議論をする場に、より多くの人が参加できるからです。 また、行った変更がたとえ小さなものだったとしても、関連するチーム同士の全ての会話をパッシブドキュメンテーション(4章)として保存しておく事は非常に重要です。 これは、将来に渡り過去にどんな会話があったかをチェックできると同時に、チーム同士の会話のあり方自体を変えるという事を意味します。 そして、会話が自動的に保存されていくということは情報の過多を防ぎ、検索性を向上させ、スパムをへらすことにも繋がります。 通常多くの企業では、プロジェクトやリソースをどう優先順位付けするかという議論を密室の中で行います。 そのため、従業員はその優先順位を説明するためには独自の物語を考えなければなりません。 ここでも *なぜするのか* ではなく、 *どうするのか* という事に焦点をあてなければ、その都度物語を考えさせられるはめになり、改善に向かえません。 不透明であるという事は、社員の意思決定のスピードを遅らせエスカレーションのプロセスも悪くなる要因となります。 プロセスを透明化する事で、メンバーは必要に応じ軌道修正ができるようにもなります。なぜなら、本当のゴールを理解することで、誰かに指示されたものの間違った成果に繋がるやり方を妄信的に進むことがなくなるからです。 加えて、優先順位付けとリソース配置の透明性を高めることで、組織階層から生じる権威への不安や、実際にその権威の出現は少なくなります。 ## 企画者はプロセスに影響を与えられる 私達はシンプルなルールから着手しました。 リスクや需要が大きいコードベースでは、計画を形式化する必要があることがわかりました。 そこでプロダクトスペシャリストとTCが協力し、外部のコントリビューターが重要な変更を提出する際にはイシューリクエストの提出を義務付けるよう、コントリビューション協定にルールを追加しました。 ここでの"重要"とは、Rallyにおける３以上のストーリーポイントを使用する事を意味します。 このルールは、両チームの製品スペシャリスト同士、またコントリビューターとTCが協調する事を必須とする、強固なプロセス形成のための第一歩となりました。 他のコードベースではこのような形式ばったミーティングは必要となりませんでした。 その代わり、決められたコミュニケーションチャネルの中で、潜在的なコントリビューターがTCと製品スペシャリストに事前に連絡しておくことをコントリビューション協定の中で定めています。 繰り返しになりますが、柔軟な適用性がキモとなるのです。 ## ルールを定めた結果 計画段階から関連メンバを巻き込むことは最初はリソース上の問題を引き起こします。 たとえば、大勢のメンバーの都合のつく予定を見ながら会議を設定する事が難しかったり、会議自体が予想よりも長引く事もあります。 また、会議に参加しなければならないメンバーは他の業務を後回しにしがちです。 しかし私達はそれ以上の価値をすぐに理解しました。 チームメンバーは優先順位付けのプロセスを今まで以上に理解しはじめ、アジャイルプロセスの改善に活かされました。 一方でコアチームが外部からのコードを取り入れるスピードは非常に大きく改善されました。結果として、計画段階に費やされた時間の10倍以上を補填する事にまで繋がりました。 そして、何年もの間バックログに放置されていたコントリビューターチームの要望を完了できたのです。 より多くの人を巻き込んでプロセスを開かれたものにし、高い透明性を確保することは組織間のコラボレーションを行うにあたって非常に良い効果を発揮します。 これによって、チーム内・チーム間を問わずより効率的な意思決定が出来るようになりました。 また、パッシブドキュメンテーションを徹底することによってコミュニケーションの質自体も改善し、結果として会議時間の縮小にも繋がる事もわかりました。 初期段階でコミュニケーションを増やすには、外部からのファシリテートが必要であることがわかりました。 重要なのは、会社にとってWin Winとなる解決策を常に模索し続け、より効果のあるコミュニケーションを製品スペシャリストに徹底してもらうよう働きかけた事です。 この期間は比較的短く終わりました。チーム間で物事が円滑に進むようになった後はコラボレーションが劇的に増加し、外部からの支援はほとんど必要がなくなりました。 ## 企画から開発者までのギャップを超える 私達の大きな目標を実現するために、PayPal 内のチームは抜け目がなく非常に複雑な交渉を共同で進めました。 ある製品スペシャリストは我々が実際にインナーソースチェックリストに追加した簡単なプロセス変更を考案しました。それは、製品スペシャリストは *HELPWANTED.md* というファイルを自分たちで作成し、所有しなければならないというものです。 彼らは透明性を保ちつつ、このバックログをファイルの中に記載して掲載できます。 通常、作業対象のコードリポジトリを探している開発者たちは、たとえアクセス権があったとしてもプロジェクト管理ツールの中まで調べようとは思いません。 よって、 *HELPWANTED.md* をコードリポジトリに設置する事となるのです。 繰り返しますが、発見のしやすさは重要です。 いくつかの良くできた *HELPWANTED.md* は、ノートや優先順位付けのレベルも含め、プロジェクト管理ツールから生成されました。 これはゲストコントリビューターが他のチームが求めていることを知るのに大きく役立っています。 潜在的なコントリビューターは自分達の抱えているプロジェクトと近しいストーリーを見分けやすくなり、最もコントリビューションできそうなものを選びやすくなります。 *HELPWANTED.md* は、Win/Winの精神に大きく寄与しています。 コントリビューターは他のチームのバックログの中にあるアイテムをこなす代わりに、自分達が追加したい変更をレビューリストの上位に移動するといった取引ができるようになりましたし、実際に行っています。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://jp-contents.innersourcecommons.org/understanding-the-innersource-checklist/contents/6-working-within-the-enterprise-understanding-planning.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.