実際のチェックリスト

インナーソースプロジェクトを開始する事に対してプレッシャーを感じるのはその通りで、ましてや、真のインナーソースまたはオープンソース企業への移行を通じて、あなたの組織をかじ取りをするのは簡単ではありません。 PayPal 社は、自社独自の経験と、インナーソースへ移行している他社に勤める同志の経験からチェックリストを記載しています。 私たちは、あなたが何をすべきかを整理し、集中するのに役立つよう、ここにチェックリストを提示します。 もちろん、このチェックリストに素直に従うだけでは、成功は得られません。 全ての組織は、調査、議論、インナーソースの恩恵を得るための文化的に変化することを始めていく必要があります。 しかし、あなたがこのチェックリストを常に確認していれば、進捗があることがわかり安心するでしょう。

このチェックリストは、GNU宣言と Checklist Manifesto(邦訳：アナタはなぜチェックリストを使わないのか？(晋遊舎, 2011)) の両方に触発されたものです。 私たちはあなたがインナーソースにむけて少なくとも小さな一歩を踏み出し、あなた自身のチェックリストを作成し、それを私たちにも共有(展開)してくれることを期待しています。 Apache Way はチームにとって重要なインスピレーションであり、あなたもこのリストに同じような感覚を感じることでしょう。

準備

個人

• これが会社にとって実行可能な戦略と思っていますか？それとも、観念的な誓約と理想論から抜け出そうと活動していますか？

• インナーソースで成功するために必要な変化を理解していますか？

• あなたは、他人にアイデアを提示したり、相手の心配事に耳を傾けたり、偏りのない共通点を見つけたりするのが得意ですか？

プロジェクト

• このプロジェクトは会社にとって重要ですか？戦略変更を受け入れられそうですか？

• 妥当性

  • このプロジェクトは、オリジナルの開発チーム以外の開発者にも興味をもってもらえそうですか？

    • それは今時点で社内の他のチームが依存するほど広く使われている、もしくは広く使われそうですか？

    • オリジナルチームが予想できなかったような形で、他の開発者による拡張によって利益を受け入れることができますか？

  • 他のチームがバグ修正やリファクタリング作業によってコントリビューションすることで、プロジェクトはその利益を受け入れることができますか？

  • 他チームの開発者が有用なコードや提案を提供してくれますか？

  • 他チームの開発者がコントリビューションの要請に応えてくれますか？

• コードの成熟度

  • プロジェクトは簡単にかつ安全に変更が行えるよう十分なモジュール化がされていますか？

  • コードは十分にドキュメントがそろっていますか？

• 既存の工程

  • リリースを頻繁に行うことができますか？

  • 継続的なテストや統合が行われていますか？

  • 全てのコードがGitHubのようなバージョン管理リポジトリに登録されており、ブランチやプルリクエスト、マージが簡単にできるようになっていますか？

チーム

• チームメンバーがインナーソースの課題に挑戦する準備ができていますか？

  • 他チームの開発者からのコードやコード変更を受け入れられますか？

  • 他チームの開発者が投稿した完ぺきではないコードに責任を持てますか？

  • あまり完ぺきとは言えないコードを見てもらえる他チームの開発者がいますか？

  • 他チームの開発者のコントリビューションの受け入れや拒否について、それらが時々困難であり会議しなければなりません

  • コントリビューターへの助言し、助言できるようになるよう学べますか？

• チームメンバーはインナーソースプロジェクトを実行するための要件を理解していますか？(メンバーがオープンソースプロジェクトに参加したことがあると望ましい)

  • ゲストコントリビューターのためのドキュメントの作成・保守

  • フォーラムに参加する意思、根気強く質問に回答する意思

  • 廊下での会話の代わりに、誰もが見ることができる履歴付きのフォーラムの使用(オプションで、ミーティング最中にノートをとることができ、全ての決定とその説明が文書化される)

  • 外部からの提出物のコードレビュを行う意思

  • バグトラッカーのメンテナンス

  • トラステッドコミッターの役目を交代できる

• トラステッドコミッターを選択したことがありますか？

  • 彼らは自分たちの責任を理解していますか？

    • GitHub の CONTRIBUTING.md ファイルに名前を書き、保守する

    • 投稿されたコードのレビュ(プルリクエスト対応)

    • ゲストコントリビューターへの助言

    • プルリクエストのマージ

    • モジュール化とリファクタリングを率先して実施

    • 議論リストを使った質問の共有と回答

    • お知らせ・告知

    • 連携の機会を見極めと提案

  • 彼らはこのポジションへの潜在的(内在的・仕事関連)な報酬を理解していますか？

    • コードベースへの理解度を深める

    • あなたのチームのコード品質を改善する

    • より良い統合により、組織内のコード品質が全体的に改善する

    • 多くの投稿されたコードサンプルを見ることにより、開発者として学び成長する

    • 外部からのコントリビューションを促進するためのコードのリファクタリングやモジュール化の方法を理解する

    • ゲストコントリビューターへの助言や交渉を通じて、対人能力やリーダシップ能力を養う

  • これまでの職務内容に無いことをするための余裕が与えられていますか？

• チームメンバの仕事のスケジュールには、これら新しい責任のための時間が確保されていますか？

• チームメンバーはこれら責任を履行するための訓練を受けていますか？

• 組織内の誰もがフォローしたり、検索したりできるようなアナウンスの仕組みがありますか？(例：Slack, E-mail)

• 全てのゲストコントリビューターからの質問やチーム内の決定事項が新たなゲストコントリビューターから検索できるように、議論を記録しておける仕組みがありますか？(例:Slack, オンラインフォーラム)

企業

• 経営層 (CxOレベル)

  • 幹部はインナーソースとしてプロジェクトを運営する目的と価値について理解していますか？

    • 組織全体に部族内知識を広めていく価値

    • 独自に抱えている拒絶意識やボトルネックを取り除くチームを持つ価値

    • より相互に繋がった組織の価値

    • コードベースの多くの機能をより深く理解している高度なチームメンバーを持つことの価値

    • インナーソースが、基本的な優れたプラクティスを推奨し、さらに優れたコーディング&開発プラクティスの形成と浸透支援をどの程度行うか

    • インナーソースが個々の開発者の学習と開発力をどの程度育てるか

  • 幹部は柔軟な仕事の要件や部門を超えたコントリビューションに費やされる時間を喜んでサポートしていますか？

  • 幹部は実験、失敗、再配置を受け入れることができますか？

  • 幹部はマネージメントを必要としないキャリアアップのための道筋を喜んでサポートしていますか？

  • 経営層は、このイニシアチブを支持していますか？

  • 会社の目標と KPI が明確に示され、共有されていますか？

  • 会社のビジョンとミッションには関連性があり、最新のものであり、明確であり、尊重され、守られていますか？

• 人事部

  • インナーソースの価値観に基づいた昇進のための補修や基準がありますか？

    • 他部門のプロジェクトにコントリビュートした人への報酬(制度)

    • 他部門からのコントリビューションを担当した人への報酬(制度)

  • コミュニティの役割を尊重し、管理職への昇進を必要としない昇進の道筋が必要

• 組織体制

  • 中心で調整してくれるチーム

    • チームの準備が整っていますか？

    • インナーソースに興味を持っているプロジェクトとコミュニケーションをとる準備ができていますか？ そのプロジェクトとチームの準備ができているかをこのチェックリストの基準に評価できますか？

    • どのようにプロジェクトをインナーソースとして登録しますか？

  • スタッフメンバーは外部プロジェクトにコントリビューションする時間がありますか？

  • スタッフメンバーはチームの損益の計測と実証をするリソースが割り当てられていますか？

  • スタッフメンバーは自身の専門性やモチベーションに基づいてどのプロジェクトに取り組むかを選ぶことができますか？

  • 様々な方向からの優れたコントリビューションを評価できる実力主義の理念がありますか？

• 開発者

  • "会社関連のある"開発者たちは、インナーソースプロジェクトへコントリビューションできることを理解していますか？

  • その開発者たちは他のプロジェクトへコントリビューションすることの価値を理解していますか？

    • 外的妨害要因の除去

    • 他のツールとの統合を自ら構築すること

    • 他のチームがどのようにコードを構築しているか例を通じて学ぶこと

  • その開発者たちは他のプロジェクトへコントリビューションするためのプロセスを理解していますか？

    • 議論への参加

    • コントリビューションするためのルールの閲覧

    • "FAQ/要望ファイル"の閲覧や記入

    • 告知への署名

  • その開発者たちはツールの使い方を知っていますか？

    • バージョン管理システム

    • プログラミング言語

    • テスト開発用ツール

  • その開発者たちは、インナーソースにおける自分たちのチームの役割をサポートする方法を知っていますか？

    • その開発者たちは、生産的にフォーラムに参加できますか？

      • コントリビューターからの質問への回答

      • その方法を選択した理由の明確な説明

      • フィードバックに対する建設的な対応

    • その開発者たちは、自分たちのコードのレビューに関する意見交換会に参加できますか？

  • その開発者たちは自部署以外のプロジェクトへコントリビューションすることが許可されていますか？

    • その開発者たちは自分たちのプロダクトオーナーやマネージャからサポートを得る方法を理解していますか？

リポジトリ

• リポジトリに紐づいて、下のような"補助的なリソース"がセットアップされていますか？

  • ドキュメント

  • 議論用のフォーラム

  • バグトラッカー

  • Wiki

• 以下のファイルが置かれていますか？

  • README.md

    • プロジェクト名

    • このプロジェクトの以前の名前やコードネーム

    • プロジェクトの説明

    • チームリーダーのプロジェクトマネージメント(組織)の連絡先

    • 検索目的のキーワード

      • 人々がこのプロジェクトを名前で検索できるように

      • 人々がこのプロジェクトをやっていることで検索できるように

    • 告知リストへの登録方法

    • 議論用のフォーラムのURL

    • 他関連リポジトリ(例:JIRA, Rally, Confluence)のURL

  • CONTRIBUTING.md

    • 必須

      • 目次

      • トラステッドコミッターの名前と連絡先

      • トラステッドコミッターのスケジュール

    • 任意

      • コミュニティガイドライン

      • コーディング規約

      • テスト規約

      • ブランチ作成規約

      • コミットメッセージ規約

      • 良いプルリクエストを作成するためのステップ

      • 機能リクエストの提出方法

      • バグレポートの提出方法

      • セキュリティレポートの提出方法

      • ドキュメントの書き方

      • 依存関係情報

      • (自動)ビルドプロセスのスケジュール

      • スプリントスケジュール

      • ロードマップ

      • 有益なリンク，情報，ドキュメント

      • リポジトリのクローズタイミング

  • HELPWANTED.md

    • 最初は空っぽでも可

    • 要望や提案が投稿されたフォーラムとリンクを張ることが可能

    • 要望や提案のリストを含むことが可能

  • GETTINGSTARTED.md

    • コントリビューターがアプリを立ち上げてコーディングを開始するまでに必要なステップ全て

    • インターンシップ生のような初心者や初めてコントリビューションされた方たちが、始めるにあたって自分にとって役に立ったであろうことについてのフィードバックに基づいて、記入が可能

• 誰がリポジトリのドキュメントをレビューしますか？

ソフトウェアツール・システム

• バージョン管理システム

• 継続的統合システム

• 試験ツール、試験システム

プロジェクト実施の計画

• スプリント

• コードアソン(コーディングに特化したハッカソン) 特にツール関連

• 教育

• 試験

• ゲーミフィケーション(参加者の意欲をかき立てる手法)

• レポート作成

  • 直近のプルリクエストの

    • 総数

    • ライン数

    • 種類

    • プルリクエスト送信者の名前

  • ベースラインの指標

  • 継続的なトラッキング

    • 人的・物的リソース

      • 費用

    • 時間

  • 測定結果を誰が閲覧するか？コミュニティへ開示するか？

• バグ修正

• 製品責任者

9章の訳注

原著では、本章は9章という扱いではなく、付録(Appendix)です。 ですが、構成的には章であり、原稿を公開している GitHub および本書を公開する Gitbook においても章として見えることから、9章と致しました。 また、原著にはセクションがありませんでしたが、見やすさを考慮してセクションを設けました。 そして、よりチェックリストらしく、Markdown の拡張形式である * [ ] を用いた記述としました。