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

Strategic Choice

2014-04-18

[]ペアで開発する

どういうこと?

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

どうして?

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

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

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

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

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

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

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

どうすれば?

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

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

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

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

2014-04-17

[]失敗プロジェクトの通夜

どういうこと?

心血を注いだプロジェクトが中断されたときは、「プロジェクトの死」を悼んで、「通夜」を開催します。

どうして?

仕方のない外的要因のせいであっても、チームにとって、心血を注いできたプロジェクトのキャンセルは、特に士気を下げる原因となります。

キャンセルの裏にある事情を、チームが理解しているかどうかは、さほど問題ではありません。とにかく、悲しい気持ちになるのです。無力に感じたり、無気力に陥ったり、時には裏切られたように感じます。

チームには、即座に始めなければならない次のプロジェクトがあったとしても、なんらかの休憩は必要です。最悪、チームメンバーは辞めてしまうかもしれません。

プロジェクトがキャンセルされたのは、自分たちのせいではないにも関わらず、成功したプロジェクトにしか、報酬は与えられません。これは、きわめて強い不公平感を生む可能性があります。

どうすれば?

失敗したプロジェクトのための「通夜」を開きます。愛する人を失ったときと同じように、プロジェクトの死にも喪の期間が必要です。通夜は、喪の期間を乗り越えるうえで役に立ちます。

プロジェクトが「成功」したという「偽りの賞賛」でチームをなだめようとしてはいけません。プロジェクトが大失敗したのは誰もが知っていることです。

通夜は、大がかりなパーティーにします。カフェテリアでケーキとフルーツポンチを食べるだけではダメです。プロジェクトのふりかえりではなく、本当のパーティーにします。ふりかえりの機会は別に設けます。

通夜は、職場とは別の場所でやるのが一番です。そうすることで、古いプロジェクトと距離を取り、ふりかえりが始まってしまうことを避けられます。

通夜は、業務時間内にやる方が効果的です。平日のどこかの午後がベターです。業務時間内に通夜をやることで、ちょっとした感謝の気持ちを表すことができます。報酬がもらえないことは周知ですが、チームの努力がなんらか認められたことについて、チームは感謝してくれます。

通夜は、カタルシスになります。通夜に参加した人は、次のプロジェクトに入っていくのが容易になります。上位の経営陣が、チームの努力に対する感謝を明確に表現するのが重要です。プロジェクト失敗の原因が、開発チームで下した判断ではなく、ビジネス上の判断である場合には特にです。こうした感謝を示すことで、メンバは落ち着き、企業内での自分たちの将来についてあまり心配しなくなります。

2014-04-16

[]成功報酬

どういうこと?

成功したいなら、成功へ導くふるまいに報酬を与えなければなりません。さもないと、大切なふるまいが埋もれてしまい、成功を測るのが難しくなってしまいます。

それゆえ、チームと個人の両方に対し、様々な報酬の仕組みを確立します。

どうして?

うまくいっているプロジェクトというものは、「成功へ導くようなふるまい」に報酬を与えることで、うまくいき続けています。

スケジュールという動機は自己達成的になりがちで、同じタスクに対しても様々なスケジュールがあり得ます。さらに、あらかじめ与えられたスケジュールは、動機付けとしては弱い部類です。

組織によっては、利他主義に頼っているところもあります。しかし、わがままでない献身的なチームなどというものは、時代遅れの考え方です。

チームにも、そこで目立った個人にも、しっかり報いるべきです。

どうすれば?

プロジェクトがうまくいったときは、貢献した個人のために豪華な報酬を用意します。また、チーム全体にもそれに負けない報酬を与えて、士気を下げないようにします。ただ、やはり、特別貴重なチームメンバーには、チームの生産性とは別に特別な賞を授与するべきです。

以下、報酬に関する具体的なポイントです。

  • 祝賀会を開く。
    • 祝賀会も効果的な報酬である。
  • ハードワークではなく成果に対して報酬を出す。
    • 最長労働時間賞であってはならない。
  • マネージャーへの手厚い報酬は、慎重に行う。
    • 部下に重労働を強いる文化を育ててしまう恐れがある。
  • 報酬の対象は、目標を達成した方法よりも、目標を達成したこと自体にする。
  • 組織が価値を置くものについて、報酬を与える。
    • 人は、報酬を与えられることをやるようになる。

2014-04-15

[]トラックナンバーはほどほどに

どういうこと?

組織内で、ドメインに関する重要な知識を唯一持っている人の数を、「トラックナンバー*1」といいます。リスク管理の観点から、このトラックナンバーを極力低く保ち続けます。

f:id:asakichy:20140417225435p:image

どうして?

プロジェクトが少数の個人に依存しすぎるのはよくない状態です。

確かに、専門分野を持つのは重要です。ありきたりの職歴では、特異な経験をもつ人材にはなれません。

ただ、特異な経験は、ロールという概念には組み込まれていませんし、ドキュメントやナレッジベースの中に見つけることができません。開発者をどこかから連れてきて置き換える、などということはできないのです。専門知識は、生きた人間に組み込まれています。そして、そういう人こそ、意志決定ができるのです。

こういう人は、チームにとって諸刃の剣です。たとえば、その組織を辞めて、別の会社に移ってしまうかもしれません。あるいは、交通量の多い交差点でトラックの前に飛び出し、二度とプロジェクトに戻ってこないかもしれないのです。

プロジェクトが、そのような個人だけが持つ知識にあまりに依存しているなら、それはリスクです。

トラックナンバーは大きくしたくありません。トラックナンバーが大きくなるということは、特定のチームメンバーがいなくなることによって、重要な専門知識が失われる可能性が高まるということだからです。それではリスクが高すぎます。

どうすれば?

トラックナンバーを低く保ち、独自の知識を持っている主要な専門家の数を少なく抑えます。

知識を共有する文化を構築し、それによって時間をかけて知識に広がりを持たせていきます。簡単に体系化したり教えたりできるのに、そうしないと隠されてしまうような知識については、特にそうです。

トラックナンバーは、組織の脆弱性の指標です。計算するのは簡単です。こう問いかけます。

「プロジェクトで、いなくなったらどうしようもなくなってしまうのは誰だろう」

何人かの名前がすぐに頭に浮かびます。主要なアーキテクトやプログラマ、もしかしたらテスターかもしれません。そういう人が欠かせないのは、他の人が知らないことを知っているところです。だからこそ、その知識をチームの他のメンバーと共有してもらいます。

ただ、トラックナンバーを極小値にするのは限りなく不可能です。仮にできても、それは意味がありません。トラックナンバーが1だったら、それ以外の全員が「重複」していることになるからです。ある意味、一人を除く組織内の全員が、給料の高すぎるソフトウェア組立ライン工夫になり下がっているということです

リスクを減らすあらゆる活動と同様、トラックナンバーを減らす活動にもトレードオフがあります。ある人の専門知識を冗長化することは、費用面や時間面で効率が悪いこともあります。よって、リスクとうまくつきあう必要があります。

*1:ある人が、組織の中のあるドメイン(領域/分野)の知識を独占している場合があります。
その場合、その人が(トラックに轢かれる等、何らかの理由で)いなくなることは、その組織にとってリスク(脅威)です。
そのリスクの度合いを、「独占ドメインの数」をカウントし、「トラックナンバー」と呼んでいます。[以下、修正前]「何人トラックにひかれていなくなると組織が脅かされるか」の数を、このような名称で表現しています。

2014-04-14

[]スキルに応じたサブシステム

どういうこと?

長い目で見て、サブシステムを組織化する必要があるなら、スキルに応じて分割するようにします。

どうして?

アーキテクチャと組織は、互いに合致させたいところです。事実、ソフトウェアと、それを構築する組織の両方をまとめる原則は、かなりの数存在します。

ただ、それらは、大規模レベルのガイダンスは提供してくれますが、グループレベルの細かい構造には当てはまりません。

どうすれば?

スタッフのスキルの種類や、スキルに対する要求に応じてサブシステムを分割します。これは、時間を経て、スタッフのスキルが変化してしまうことを防ぐことが目的です。

特に小さいプロジェクトでは、UIデザインをインフラ設計やドメイン設計と組み合わせられるだけの様々なスキルを持っている人はわずかしかいません。そして、おそらく、プロジェクトの後継者たちも、そのような多様なスキルを持ち合わせていません。その結果、システムを進化させるのはより難しく、コストもかかるようになります。

専門分野を別々のサブシステムに分ければ、チームは自分たち独自の問題に対して、自分たち独自のボキャブラリーであたり、集中できるようになります。

そして、自分たちの後継者がそれらの問題を個別に理解し、プロジェクトの人員配置を容易に行えるように仕向けられます。そこでは、多くの専門知識を要求されないからです。