カプセル化と組織パターン - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです
。

カプセル化

カプセル化(リンク先はwikipedia)は情報隠蔽の手法で、オブジェクト指向にも取り入れられています。カプセル化することで外部には必要な情報のみが公開され、内部のデータや処理は守られます。オブジェクト指向において、外部からはメソッドを介してのみ情報を得ることができます。

オブジェクト間で連携するには、呼び出しとデータストア共有の2つの方法があります。呼び出しは責務を果たしてくれるオブジェクトのインタフェースを定めてその参照を知って知っていることで、オブジェクトに対して定められた方法で呼び出すことで、オブジェクト間で連携できます。データストア共有ではデータベースのようなデータストアを介する方法です。データ構造をあらかじめ決めておいて、オブジェクト間でデータの参照や更新を行います。

組織パターン

組織パターンは，開発チームをどう編成すればいいのかをパターンとして整理したものです。組織パターンはアジャイル開発のひとつであるスクラム開発にも取り入れられていて、プロダクトオーナーとスクラムマスターは、それぞれ門番、防火壁に相当します。チームへのインタフェースを限定し、外部からチームを守ります。チームをカプセル化するわけです。アジャイル開発に限らず、チームを外部から守り、必要な情報を提供できれば、チームは外部のストレスを受けないで開発に集中できます。また依頼すべき役割を担うチームを知り、適切な方法でアクセスすることでチーム間の連携ができます。

データストアによる情報共有はその方法によってメリット・デメリットがあります。

• タスクカード：壁やホワイトボードに張り出すことでチームの状況を見える化します。無意識に目に入るので常にゴールを共有できます。その反面、色分けなどで工夫しないと管理や検索が難しいので電子化されることも増えています。
• チケット：RedmineやGitHUBなどのチケット（イシュー）を使ってタスクを管理します。優先順序などそのままでは扱いにくいので、タスクカード風のUIをもつJIRAやプラグインが使われることもあります。
• 資料：チーム内で資料を共有します。いつでも再確認ができる反面、資料の質がコミュニケーションの質になります。
• ミーティング：もっともアナログな情報共有です。音声による情報共有はニュアンスなど情報量鵜が多いので、チケットや資料などの共有と併せて実施されます。人数や時間によって工数がかかります。

システム開発と同じように、どのようにチーム間あるいはチーム内で連携するかで、成否が決まります。ウォータフォールや味あるなど既存のプロセスを利用するとある程度の品質は得られますが、そのプロセスのメリット・デメリットを把握していないと効率的な開発は行えないでしょう。

この記事はSRAアドベントカレンダーでも公開しています。