デブサミ行ってまいりました
id:habuakihiroさんの枠を聞いて、その後部下と色々と飲みながら話した事。
決定の遅延
確かポッペンディークの本にあったんだと思ったけど、ヒューレット・パッカードのプリンタの話を思い出しました。
最初、完パケの状態で在庫を抱えてたんだけど、海外へ輸出するにあたって電源プラグの形状が違うんでいちいち付け替えてたと。それをやめて電源コードの付いてない未完成の状態で在庫を抱える様にして、発注がかかった時点で出荷先にあわせて電源コードを付けるようにして最適化したとかなんとか。
なぜアジャイルなのかの理由としてそんなエピソードが挙げられてました。
大事な決定はなるべく遅らせるって事ですね。
はぶさんの話と同じですね。違うのは、何を電源コードとするかって所じゃないでしょうか。
アジャイル開発プロセスの場合はそれは仕様のベースラインであって、スタロジさんのやり方の場合は、納品するコードそのものな訳です。物が違うだけでやってる事は一緒。
さて、仕様のベースラインを遅らせて実装を作っては出し作っては出しってのは、案件の性質にもよると思うんですけど、所謂業務システムの構築の場合は、やっぱり凄い計画立案・管理能力と、凄い詳細設計能力と、凄い実装力を求められると思うんですよ。
はてなみたいな永遠のベータシステムとかの場合はまた違うと思うんですけど。
自分らのやってる仕事にとって、どっちがしっくりくるかと云えば、やっぱりはぶさんのやり方の方かなと。思った訳です。
UIスケッチ
あれはお客様に書いてもらってるんでしょうか。凄い。そこまでお客様の手を動かさせるってのは、凄いですよ。流石にそこまでは出来ませんでした。
営業フェーズ
今やってる案件のマジカとUIスケッチが完成した時点で、マネージャーさんにそれらを見せて進捗報告して、「今度からはこの段階で見積り出しましょうよ、引越し屋だって契約前に部屋の荷物見に来るでしょ」と提案して、OK貰いました。さて次からどうなる事やら。頑張ろう。
さてここで、営業フェーズにかかるコストはどうやって組み入れるかってのがあります。
見積りをどう云う単位で計算するかは、取り敢えずここでは洗い出した機能単位って事にしますが、その機能それぞれにちょっとずつのせるのか。つまり要件定義コストを共通費扱いにするって形。
それとも、契約時になって、それ以前の要求定義分の工数として明記するのか。
お話の中で、お客様はそんな所に金は使いたがらない、なんて事をおっしゃていたので、前者なのかな。俺はそっちの方がいいと思いました。
恵まれてるよなあと云う事
基本が元請けで、上から下まで一貫して開発プロセスをコントロール出来る環境ってのがまず前提な訳です。
あそこの会場に居た人達の中で、自分達の仕事に当てはめて「うう〜ん」とうなっていられた人って何人居たのだろうか、と。下請けが主だったり、開発プロセスを提案出来る立場に居なかったり、それでも「いつかは」みたいな心境で聞いてる人も多いと思うんですよ。
はぶさんは「出来ない環境に居るのが嫌なら会社作っちゃえばいいじゃん」とおっしゃると思いますけれども。
その中で我々は、案件やチームの規模こそもっと小さいけど、お客様のターゲットも割りと近いし、すぐに「やってみる」事が出来る環境に居る訳です。会社作る所から考えなくて済んでる訳です。
これは本当に恵まれてるんだよなあ、だからこそやらんといかんのだよなあ、と部下と二人で、我らが社長の妙に強力な営業力に感謝しつつ、深酒致しました。
作戦会議メソッド
はぶさんのプレゼン資料では、色んなものを壁に貼ってる様子の写真が何枚もありました。
今の案件でマジカをやった時、現状フローにしたのを壁に貼ろうとしたら貼れる部屋じゃなかったんですよ。
しょうがないので机の上にどーんと置いて、それをお客様と一緒に取り囲みました。最初俺が立ち上がって指さしながら色々説明して確認してたんですが、その内お客様も意見を云う時は立ち上がり始めて、そのままスタンダップミーティングになりました。頼んでないのに自然と。
これがよかった。皆で立って下を向いてフローとにらめっこしながら腕組んで議論。まるで海図をみながら作戦を立ててる提督と参謀みたいで、まさにProblem vs Us。
色んな会社の互助会みたいな団体さんがお客様なので、兎に角ステークホルダーが多く、打ち合わせはどうしても講演会や大学の授業みたいになりがちなんですが、この時ばかりは皆さんの顔が違いました。いつも黙ってるだけの人も人垣の隙間からどれどれみたいな感じでやじうまっぽく参加してて、座って話を聞いてるだけより参加意識は格段に高かったと思います。
作戦会議メソッドは今後も使えるかも。長時間は疲れちゃって無理だけど、ある程度固まってさておさらいしましょうか、なんて時はいい感じです。
