デブサミ行ってまいりました

id:habuakihiroさんの枠を聞いて、その後部下と色々と飲みながら話した事。

決定の遅延

確かポッペンディークの本にあったんだと思ったけど、ヒューレット・パッカードのプリンタの話を思い出しました。

最初、完パケの状態で在庫を抱えてたんだけど、海外へ輸出するにあたって電源プラグの形状が違うんでいちいち付け替えてたと。それをやめて電源コードの付いてない未完成の状態で在庫を抱える様にして、発注がかかった時点で出荷先にあわせて電源コードを付けるようにして最適化したとかなんとか。

なぜアジャイルなのかの理由としてそんなエピソードが挙げられてました。

大事な決定はなるべく遅らせるって事ですね。

はぶさんの話と同じですね。違うのは、何を電源コードとするかって所じゃないでしょうか。

アジャイル開発プロセスの場合はそれは仕様のベースラインであって、スタロジさんのやり方の場合は、納品するコードそのものな訳です。物が違うだけでやってる事は一緒。

さて、仕様のベースラインを遅らせて実装を作っては出し作っては出しってのは、案件の性質にもよると思うんですけど、所謂業務システムの構築の場合は、やっぱり凄い計画立案・管理能力と、凄い詳細設計能力と、凄い実装力を求められると思うんですよ。

はてなみたいな永遠のベータシステムとかの場合はまた違うと思うんですけど。

自分らのやってる仕事にとって、どっちがしっくりくるかと云えば、やっぱりはぶさんのやり方の方かなと。思った訳です。

UIスケッチ

あれはお客様に書いてもらってるんでしょうか。凄い。そこまでお客様の手を動かさせるってのは、凄いですよ。流石にそこまでは出来ませんでした。

営業フェーズ

今やってる案件のマジカとUIスケッチが完成した時点で、マネージャーさんにそれらを見せて進捗報告して、「今度からはこの段階で見積り出しましょうよ、引越し屋だって契約前に部屋の荷物見に来るでしょ」と提案して、OK貰いました。さて次からどうなる事やら。頑張ろう。

さてここで、営業フェーズにかかるコストはどうやって組み入れるかってのがあります。

見積りをどう云う単位で計算するかは、取り敢えずここでは洗い出した機能単位って事にしますが、その機能それぞれにちょっとずつのせるのか。つまり要件定義コストを共通費扱いにするって形。

それとも、契約時になって、それ以前の要求定義分の工数として明記するのか。

お話の中で、お客様はそんな所に金は使いたがらない、なんて事をおっしゃていたので、前者なのかな。俺はそっちの方がいいと思いました。

恵まれてるよなあと云う事

基本が元請けで、上から下まで一貫して開発プロセスをコントロール出来る環境ってのがまず前提な訳です。

あそこの会場に居た人達の中で、自分達の仕事に当てはめて「うう〜ん」とうなっていられた人って何人居たのだろうか、と。下請けが主だったり、開発プロセスを提案出来る立場に居なかったり、それでも「いつかは」みたいな心境で聞いてる人も多いと思うんですよ。

はぶさんは「出来ない環境に居るのが嫌なら会社作っちゃえばいいじゃん」とおっしゃると思いますけれども。

その中で我々は、案件やチームの規模こそもっと小さいけど、お客様のターゲットも割りと近いし、すぐに「やってみる」事が出来る環境に居る訳です。会社作る所から考えなくて済んでる訳です。

これは本当に恵まれてるんだよなあ、だからこそやらんといかんのだよなあ、と部下と二人で、我らが社長の妙に強力な営業力に感謝しつつ、深酒致しました。