2015-03-29

今まで与えられたプレッシャーの量を覚えているのか



「ねーよw」と返事をしたものの、実は話をしたことがあった。そして、会話の内容は、仕事の仕方に、影響を与えていることに気づいた。ありがとうデマルコ先生。

2004年のデベロッパー・サミット、略してデブサミの第1回のとき、会場の廊下にいた。退学と就職の間を彷徨っていた私は、Python ユーザ会のブースの留守番をしていたのだ。

トム・デマルコは、基調講演者だかゲスト・スピーカーとして来日していた。金払っていないので講演は聞いていないし、別にイベント自体の運営には関係なかったのだけど、懇親会の会場に潜り込めた。主催者の翔泳社の人に「デマルコと、話してきていいですよ」と言われて、ひゃっほうってな感じで話しに行った。

とはいえ、別に話すことを準備していたわけではない。ただ、前から気になっていたことを聞いた。

「『プレッシャーを与えても速く考えられるようにならない』というのは、正しそうだが、認めるのは難しいと思う。とくに締め切りのきつい仕事だと。どうやって信じられるようになったのか？」みたいなことを聞いた。すると「私にもそれは難しかった。でもね、君はプレッシャーを与えられたら速く考えられるようになる？」と言われた。当たり前のことなんだけど。「合理的に YES と答えた人は今のところいない。だから信じるしか無い」と。

そのときは「サンキュー・ベリーマッチ」くらいしか返事をしなかったと思う。

それから10年たった。

開発者にたいして、設計/実装/テストをアサインする立場で仕事をすることがある。スケジュールから遅れがあった時でも、プレッシャーを与えたりしない。ということに、さっきのツイートで思い出した。どのくらい意識しているのかわからないけれど「どうしても要るのだ。だから全部しよう」とは、たぶん言っていないと思う。言ってたらごめんなさい。

やりたいことを分解すると、いくつのコンポーネントになるのか？ それぞれの規模は？ 各コンポーネントの依存関係は？ そういうことを聞きながら、ビジネスレイヤーでの価値を最大化するには、何を捨てられるかを考える。開発者が間に合わないと言ったら、十中八九間に合わないだろうという前提を持っている。少なくとも、彼らが想定している成果物と方法では、間に合わないのだ。私の責任は、ビジネスレイヤーに対してアウトプットする付加価値を最大化できるような、技術レイヤーでの取捨選択とプロセスの調整だ。

だいたいこれまでだって私が「それは十中八九無理だ」と思ったことは、十中八九無理だった。スーパーハッカーを連れてきたらできたかも知れないが、たいていそんな時間はない。3日でなんとかしろとか、あと3時間で始まる生放送までになんとかしろ、なのだ。

今、デマルコに会えたら、もっといろんな質問をするだろうし、言いたいこともある。けれど、中退したての私にしては、あの質問は我ながらよい質問だったし、それを10年後の今、活かせていることは光栄だ。あの日、「話してきたら？」と言ってくれた @turky  には感謝している（忘れてたけど）。

ラベル:

2015-02-15

Coplien、 Harrison「組織パターン」 〜 一部を犠牲にして、全体を進める

スケープゴート


組織パターンという本に「誰か一人を犠牲にする」パターンが紹介されている。

どんなに細かくても余計な作業には対処しなければならない。しかし、第一優先のタスクをやるべき時間がとられてしまうことも忘れてはならない。[...]
細かい余分な作業が大量にあると、やりたい仕事ができなくなるのだ。
それゆえ：
誰か一人余計な作業に割り当てて、その作業を終わらせてもらおう。

犠牲とか一人とか言い回しは、おそらく意図的だろう。犠牲になった人の作業が終わったら、元の仕事に戻してあげようとか書いてある。

ここでは、機械的に話を進める。もうすこし抽象化して捉えて、メインのプロジェクトから、派生したプロジェクトを分離し、一時的にリソースを配分する、という風に考える。ひとつのリソースを複数のプロジェクトに割り当てると、たしかに効率が悪いことがある。

余計な仕事が発生


本を閉じると、そこには現実が待っている。ちょうど数ヶ月スパンでプロダクトを開発しているところだ。プロダクトは機能の多さよりも、キャパシティのほうが重要である、という種類ものだ。運用が始まったとき、機能には妥協ができるが、トラフィックに対するキャパシティは妥協やコントロールがしにくいからだ。

現時点で手元には、

  • そこそこのキャパシティで稼働する、機能 A
  • 開発中の機能 B

がある。機能AやBというのは、実際には複数の機能群だ。フルキャパシティで動く部分もあれば、要件半分くらいでしか動かないだろうという部分もある。だが話を単純化しておこう。

このプロダクトのデモを見たい、という仕事が入ってきた。デモという言葉は曖昧なので、よく聞いてみると「プロダクトの機能 A, B, Cを利用したアプリケーション開発と運用を、実験として行う。運用フェーズを想定して、複数のサードパーティが、アプリケーションを開発する」というものだ。

突っ込みたいところや、だるいところがあり、その過程で感情的になり、箸が転がってもブチ切れるという精神状態になったりもしているが、ここでは機械的には話を進めよう。

不足しているものを列挙すると、以下の3つだ

  • 機能 B（作りかけ）
  • 機能 C（次のフェーズで開発する）
  • サードパーティへのサポート（文書、トラブルシュート）
  • アプリケーションの参照実装

である。問題は機能BとCである。機能Bはキャパを考慮して実装中なので、キャパの低い実装に切り替えると、トータルの手戻りが大きい。C は次のフェーズで開発する機能だ。

  • アプリ
  • プロダクト機能 A  + 機能 B と C を追加

えらく変更/追加が多いではないか。急に入ってきた仕事は「プロダクトができること」を見せるものだ。本番運用があるわけでもない。やっつけ仕事だ。けれど、プラットフォームを使う必要がある。

汚れ仕事


とうわけで、汚れ仕事を分離することにした。プロダクトは予定通り開発をすすめる。この仕事用に、別の使い捨てのコンポーネントを用意する。

  • アプリ
  • やっつけラッパー (B + C)
  • プロダクト (A)

アプリから見ると、A, B, C を提供するプラットフォームが存在する。A を提供するプラットフォームは、きちんと存在していて、ラッパーがプロキシする。

機能B と C はやっつけラッパーの中で、やっつけ実装する。

こうやってプラットフォームの開発を、（ほとんど）遅らせることなく、途中で入ってきた依存関係のあるプロジェクトを進めている。あと2週間くらいは、アルコールの摂取量が、高めになるだろうけど、酒を飲む程度の余裕があるということだ。


ラベル:

2015-01-25

Power of 複数案

仕事の合間（つまり、起きている時間の大半）に Twitter を眺めていたら、こんなツイートに辿り着いた。


念のために書いておくと、プロならベストな一案を持っていくべきとか、事前にすりあわせろとか、そういう話をしたいのではない。

自分の役割はなんなのか、相手の役割はなんなのか、という認識を醸成するという話なんだろうなと思った。それによって、前に進ませるのが目的なのだ。

ここで、ちょっと話をずらす。ダン・アリエリーが「予想通りに不合理」で出している例で、雑誌の定期購読の価格設定のエピソードがある。

1. オンライン購読 $59/year
2. 雑誌の定期購読 $125/year
3. オンライン + 雑誌の定期購読 $125/year

2 には、意味がないように見える。けれど、1、2、3 を提示した場合と、 1 と 3 だけを提示した場合では、後者のほうが 3 を選ぶ率が高かったという結果がある。「これは選ばないんじゃないかな」っていうのが入っていると、相対的に欲しいものがより明らかになってくる（あるいは、相対的に魅力的な選択に見えてくる）。

「これだろ」って提案がベストであっても、ちょっと外れた案が見えることによって、本命提案の精度が明らかになり、それゆえ精度を上げていくことができる気がする。



登録: 投稿 (Atom)