One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -

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

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

をヒントに、開発とマネージメントの共通点として、今回は「One fact in one place」と「チケット駆動開発」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

One fact in one place

データベースの正規化で使われる言葉です。ほかのデータから算出できる推移従属のデータを除いて、データを1か所に限定することです。同じデータは1か所にしかないので、常に一貫性のあるデータ集合を求められるようにします。他のテーブルと関連付ける場合もデータベースの機能を使えば、矛盾の生じない構造を実現しつつ多くの情報を管理することができます。

チケット駆動開発

チケットで障害やタスクを管理するRedmineやTracなどを用いて、情報共有しつつ開発を進めていく方法です。これらのツールはITS(Issue Tracking System) あるいじはチケットシステムと呼ばれ、チケットを介して議論やステータスの管理ができます。プロジェクトの様々な情報をこのチケットに紐づけて管理すれば、最新の状況をチーム内で共有できます。

チケット駆動開発をうまく実践するには、チケットで情報を一元管理することです。ITS本来の使い方である障害や課題だけでなくタスクもチケットで管理し、バージョン管理ツールやWikiの情報もチケットと関連付けます。こうすることでプロジェクトの様々な情報をチケットと紐づけて管理できます。

何らかの理由で表計算ツールなど他の形式にする場合も、チケットから生成すれば情報の一貫性が保てます。とはいっても情報の粒度や目的などで自動生成できない時もあるでしょう。そのような場合も一から作成するのでなく、チケットの情報を確認しながら作成する、関連するチケット番号を記載するなどで、情報間の矛盾を減らし、正確で詳しい資料を作ることができるでしょう。

このような考え方はチケット駆動開発だけではありません。開発ドキュメントは工程間で抜け漏れなくトレースできないといけませんし、お客様への説明も一貫性がないといけません。アジャイル開発のストーリーカードとタスクカードの関係も同じでしょう。チケットシステムを利用しなくても、情報を小さな単位で整理して矛盾が生じないようにしましょう。

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

マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -

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

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

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

マルチスレッド処理

複雑な問題を短時間で処理する方法の一つです。複数のスレッドを用いて並列処理すれば効率的です。シングルスレッドの処理をマルチスレッドで処理する場合、以下のような順になるでしょう。

1. 並列処理の準備
2. スレッド開始処理
3. スレッドの主処理
4. スレッド終了処理
5. 並列処理の後処理

これらはマルチスレッドを考慮して設計します。うまく設計できればスレッド数に応じて効率化されますが、うまく設計できないで主処理以外のオーバーヘッドが多い場合はスレッドが増えても効率化できません。特にすべてのスレッドの完了を待つ場合は最も遅い処理に全体が引きずられるでしょう。

進捗管理・配員・作業分割/割り当て

並列処理の簡単な例は進捗管理です。リーダーが各メンバーから順にヒアリングするには多くの時間が必要ですが、メンバーそれぞれが進捗を報告すれば短時間で終わるでしょう。しかし、各メンバーがバラバラな形式で好きなタイミングで報告するなら、内容の把握や確認でかえって時間がかかるかもしれません。手分けする準備として情報共有の仕組みを用意しておけば、メンバーの処理が標準化でき、その管理や集約も容易になるでしょう。

配員の場合はさらに工夫が必要です。進捗や成果物の共有環境を用意するのはもちろんのこと、メンバーが独立に同程度の品質を保てるようにします。具体的には横展開できるように先行して部分開発してサンプルを用意します。サンプルは成果物だけでなく、部分開発を踏まえたルールや手順などを用意して、サンプルをたたき台に作業を横展開できるようにします。

作業の分割にも工夫が必要です。作業量を平準化しやすいように時間のかかる作業は細かな作業に分割します。また、マイルストーンに合わせないといけない作業とそれ以外を分けておき、予定通りに進まないときに作業の空きがないように工夫します。

作業の割り当てにも工夫が必要です。作業者の得意な作業を割り当てれば一見、効率的ですが、作業には偏りがあるので、作業量がバラツキが出て手が空いてしまったり、誰かが体調を壊すとプロジェクト全体が止まってしまうことになります。このようなことを防ぐには、教育的な視点で作業を割り当てたり、処理の実装とテストで担当者を分ける、ペア/モブプログラミング（作業）などを長期的な視点で取り入れると良いでしょう。

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

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

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

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

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

カプセル化

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

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

組織パターン

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

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

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

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

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

Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば
　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)
をヒントに、開発とマネージメントの共通点として、今回は「Greedy algorith」と「2割8割の法則」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

greedy algorithm

世の中には簡単な問題と難しい問題があり、例えば並べ替えするときに単純に2重ループするとデータ数Nが増えるとその2乗（N^2）ほど時間がかかりますが、処理を工夫して木構造にデータを並べておけばその木の高さ（logN）で処理が済みます（実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -）。

これに対してナップザックにいろいろな大きさの荷物を入れるような問題は、NP困難と呼ばれる難しい問題です。すべての組み合わせを確認しないと隙間を最も少なくできないからです。そこで Greedy algorithmという手法がとられます。これは隙間の少ない（価値のある）大きなものから貪欲に詰めていく方法です。最適ではないですが、ほどほどにうまく詰める方法です。

プロジェクト管理においても最適な計画を立てることは簡単ではありません。そこで、大事な作業や後回しにすると問題になる作業から実行あるいは計画すると、ほどほどに良い計画を作ることができます。アジャイル開発のやり方はまさにこのような方法です。計画駆動な開発ならこの方法でできた計画をたたき台に、より最適な計画を作成することができるでしょう。

＃初期のスクラムガイドは優先順序だけで実行時順序を決めていたので、リスクの考慮が乏しいものでしたが、その後見直されたようですね。

閑話休題。プロジェクトの実行や計画には様々な要素があって簡単ではありません。まずはどの作業が価値があるか、すなわち重要あるいは後回しにできないかをまずは見極めてそれに基づいて計画しましょう。

もちろん、そもそものソフト性能にも利用できます。ソフトウェアの処理データが増えることで処理が遅くなるような場合に、網羅的で単純な繰り返し処理になっていないか、調査してみてください。

2割8割の法則

網羅的に実施しない場合に重要なものから実施するとどのような効果があるのでしょう。2割8割の法則はパレートの法則とも呼ばれ、度数順に要素を並べるパレート図を描くと、一般に上位2割が8割を占めているという法則です。

この法則に基づくと、アプリケーションの価値のある2割の機能を実現するだけで8割の価値があり、残りの8割の機能はあまり価値がないということになります。アジャイル開発では価値のあるものから開発し、随時リリースすることで価値の少ない8割の開発よりもリリース後の外界の変化に対応することを選んでいると考えられます。

2割8割の法則は障害の対応や改善において用いられています。分析して障害の量や質が問題になる上位2割の障害対策を行えば、より効果が得られるでしょう。

プロジェクトを進化させる

プロジェクトは日々変化します。プロジェクトもそのままではうまくいかず、常に変え続けないといけません。ソフトウェア開発ではリソースが潤沢ではない場合が多いので、孫氏の兵法に示されるようにパワーを分散せずにポイントを絞って攻めるとうまくいくでしょう。

グリーディアルゴリズムや2割8割の法則も同じようにポイントを絞る方法で、大事なことを見極め、優先順位をつけるという特徴があります。これらを生かせば、プロジェクトを変え続けてより効果的に進化させることができるでしょう。

参考：
（[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～）