ブログトップ 記事一覧 ログイン 無料ブログ開設

Strategic Choice

2014-04-24

[]ロールは少なく

どういうこと?

組織の中でコミュニケーションのオーバーヘッドが高く、待ち時間が長くなっていたら、組織内のロールを見定め、ロールの数を16以下に減らします。

どうして?

プロジェクトに携わる人々は、プロジェクトを進捗させるために、互いにコミュニケーションします。しかし、コミュニケーションにオーバーヘッドがあると、進捗が妨げられるという本末転倒が生じます。

ロール同士で想定されるコミュニケーションパスの数は、ロールの数が増えるのに応じて二次曲線的に増加していきます。

たとえば、ロールが5個あればコミュニケーションパスは10通りですが、ロールが10個ならコミュニケーションパスは45通りです。そして、ロールが20個あれば、コミュニケーションパスの数は190にもなります。

各ロールが、他のすべてのロールと会話をするのは、明らかに不可能です。ゆえに、ロール間の情報のやりとりは、別のロールが中継することもあります。こうしたプロセスは待ち時間(遅延)とオーバーヘッドを増やしてしまいます。

一人が複数のロールを演じる場合もあります。そのうちのいずれかのロールに向けられた情報を受け取ったときに、自分の演じる他のロールに役立つこともあるかもしれません。しかし、ロールが異なれば、コミュニケーションの必要性も大きく異なります。そのため、一人が複数のロールを演じても、必要なコミュニケーションパスの数は減らないのです。情報の源泉が情報の中身と同じくらい重要なこともあります。

追跡調査すると、「最も健全で生産性の高い組織は、16〜20のロールをもつ」というデータが出てきました。

どうすれば?

組織内のロールを見定めます。その上で、ロールの数を16以下に抑えるようにします。

コミュニケーションの組み合わせを考えると、ロールは少ない方がよいことがわかります。ロールが少なければ、リソースの点でも速度の点でもコミュニケーションが効率化されます。

必要とあれば、ロールの数を減らすことを試みます。様々なロールの価値を見定め、得られる価値の少ないロールをまとめたり、削除したりします。ロールの数を減らすためなら、必要に応じてロールを追加してもかまいません。

ロールは人と同義ではありません。同じロールを何人かで演じることができるからです。たとえば、たいていの組織では、開発者のロールを演じている人は何人かいます。

逆に、一人が複数のロールを演じていることもあります。たとえば、開発者というロールを主に演じつつ、時にはプロジェクトマネージャーとして仕事をする人もいます。一人が複数のロールを演じるのは、小さいチームではよくあることです。同じことは、大きな組織でもよく見られます。

時間が経つにつれて、ロールは組織の中で安定する傾向にあります。プロセスよりも安定するし、場合によっては組織に所属する人よりも安定します。ロールは組織の文化や価値を反映しています。ロールの数を少なくたもてば、新しく入った人が容易に組織の文化になじみ、組織の一員になれるようになります。

2014-04-23

[]グループでの検証

どういうこと?

品質管理に盲点を作らないよう、システムを検証する際には、「開発チーム全体」で品質問題に取り組みます。

どうして?

プロダクトの品質は企業の成功にとって欠かせません。

ただ、通常、品質管理部門は、最終プロダクトの品質評価を、「ブラックボックス確認」と「検証」のみで行います。

開発チームであれば、製品問題に対する多くの洞察と機会を持っています。しかし、個々人では、システムに巣喰うバグの発見に必要な洞察力を持っていないかもしれません。

どうすれば?

品質管理部門を巻き込む前であっても、(顧客を含む)開発チームは、設計について検証できます。

「CRCカード」や「グループデバッギング」といったテクニックを用いれば、問題を個人ではなくグループでのものとしたうえで、その問題を解決できるようになります。

2014-04-22

[]アプリケーションの設計はテストの設計により境界付けられる

どういうこと?

テスト開発者とソフトウェア開発者の協力関係を作るため、プロセスを整理して、アプリケーションの設計はテストの設計により境界付けられるようにします。

どうして?

テスト計画をいつ設計し、テストスクリプト*1をいつ実装するのか、という課題があります。

テスト開発には時間がかかるため、コーディングが終わってから始めるのでは間に合いません。要件がわかればシナリオはわかります。こうしたシナリオの多くはプロセスの早い時期にわかります。

テスト実装チームは、メッセージフォーマットやインターフェイスを始めとしたアーキテクチャ上の性質を、詳細に知る必要があります。テストスクリプトとテストツールを作るためです。ソフトウェア開発者もテスターも同じ「スクリプト」について、一緒に作業する必要があります。その「スクリプト」とは、顧客の要望を定義したユースケースです。

ただし、ソフトウェアを外部から見るテストは、ソフトウェアの内部構造に影響されません。したがって、ほとんどのテストは、ソフトウェアの設計や実装と並行して進められるのです。

コードの実装は日々変化します。しかし、テスト設計がそれを追跡する必要はありません。

どうすれば?

ユースケース駆動のテスト設計を行います。

これは、顧客がユースケースの要件について最初に合意したときからスタートします。そして、ソフトウェアのアーキテクチャが定まる頃に、テスト設計の基礎が出来上がります。

テスト設計はソフトウェア設計と一緒に成長します。

ただし、テスト設計が変化するのは顧客のユースケースが変わった場合だけです。そのため、基になるソフトウェアにテスターが触れることはできません。アーキテクチャ上のインターフェイスが定まったと開発が判断したら、具体的なテスト設計と実装を進めます。

ソフトウェアの設計者は、テスト仕様を要件の重要な試金石として使えますし、またそうしなければなりません。

関連

テストスクリプトは、あらかじめテストを実施するステップを定義しておき、各ステップ実施による予期される結果を記載したものである。

*1:エントリ最下部「関連」を参照してください。

2014-04-21

[]品質管理を巻き込め

どういうこと?

開発者自身での検証には限界があります。そこで、品質管理部門を巻き込みます。

どうして?

品質を「後回し」にしたり、品質を開発プロセスの後半に行われるテストと同一視したりする組織が多くあります。しかし、成功するかどうかは、「品質の高さ」にかかっています。本質的な品質問題に対処するためには、テストによる、早期のフィードバックが重要です。

ほとんどの開発者は、自分でテストを実施します。しかし、自分自身でテストを考えると、簡単に盲点ができてしまいます。しかも、開発者は、テストを自分の品質基準として使うかもしれませんが、そもそも、テストの品質をプロダクトに含めることはできません。できるのは、プロダクトを構築してその品質をテストすることだけです。

どうすれば?

品質管理部門を開発プロジェクトに巻き込みます。

品質管理部門を巻き込むことで、プロジェクトは顧客にアプローチする準備が整います。品質管理と顧客を巻き込めば、品質管理プロセスの準備が整います(たとえば、ユースケースを集めることができます)。

品質管理部門の組織メンバは、要件や要望の資料には反映されていない視点から、顧客の要望を把握するためのスキルや経験を持っているのです。

テストすべきものが開発できたら、すぐに品質管理部門を開発と密接に関連づけます。テストが始まる頃では、品質管理をスムーズに進めるために必要な信頼関係を築くには遅すぎます。テスト計画の策定は、コーディングと並行して進めます。

品質管理を担う組織は、開発のコンテキストの外にいなければなりません。つまり、テストの計画と報告の責任は、開発組織に属してはならないのです。理由は2つあります。第一に、開発者とは異なる視点でも検証が必要だからです。第二に、品質管理は客観性を保つため、開発組織の影響の外にいなければならないためです。

2014-04-18

[]ペアで開発する

どういうこと?

個々の開発者の作業効率を改善したければ、ペアで開発してもらいます。

どうして?

一人で作業したがらない人がいます。一人で作業すると、盲点ができたり、作ったものが周りとうまくあわないことがあるからです。

手伝ってもらわなければ問題を解決できない人もいます。そもそも、問題によっては、一人では解決できないものもあります。そのため、一人で作業するのが好きな人も、やはり誰か別の人と一緒に作業しなければなりません。少なくとも、作業に一通り目を通してくれる人は必要です。

ただ、常にペアで作業すると、リソースは余分にかかります。それゆえ、コードのウォークスルーや検査、それにレビューをすれば、問題に十分対応できるという意見もあります。

しかし、こうしたレビューは分析的で、機をとらえることがありません。レビューの場合は、プログラマにレビューアが敵対する構図となり、批判する側は結果に対してプログラマのような責任を持たなくなってしまいます。

さらに、レビューが問題を捕捉するのは、対象の構造やアルゴリズムに対してプログラマがコミットし、それを練り上げるうえで多大な努力を払った「後」です。考えている段階での問題を捕捉できるわけではありません。そして、こうした判断の多くは、設計レビューで俎上に載せるにはあまりに複雑です。にもかかわらず、こうした問題は重篤で、コードの実行や保守性を脅かしたりします。

キーボードの前に座って互いの成果を確認できる人の数は限られています。人数が増えるほど、コミュニケーションや調整にかかる手間は加速度的に増えます。したがって、一つの成果物を一つの画面の前で一緒に作る「チーム」を作ることはできません。

ペアで開発すると、全体とし、実装プロセスがより効率的になります。単純計算とは反対に、ペアでプログラムする方が、コーダーが一人でコードを書くよりもコストが低いことがわかっています。

どうすれば?

それぞれ一人前の設計者をペアにします。二人が一緒になれば、二人が別々にした作業を合計するよりも、大きな作業ができます。

この努力を成功させる鍵が二つあります。

第一に、それぞれが協同作業をうまくできなければなりません。つまり、思い付きでペアにしてはいけません。ペアを作る際に一番考慮するのは、二人が一緒に作業したいかどうかです。

第二に、ペアで開発する際のスタイルを指図してはいけません。個々人に任せます。たとえば、「二人が両方ともキーボードの前にいなければ一行もコードを書いてはならない」というようなルールを作ってはならない、ということです。ペアを割り当てたら、開発のやり方は任せます。