XP祭り2007に行ってきたよ

勉強会

※後で追記するのでブックマーク等はちょっと待って下さい。

注意：発表資料に書いてなかったことを中心にメモしています。できるだけ本人の表現で書いたつもりですが、聞き間違い、意図の取り違えがある可能性があります。

「トリアージプロジェクトマネージメント 」 (相馬純平さん・株式会社ラグザイア)


そういえば、僕が今年の新人１名に最初に与えた課題は、相馬さんの『WEB+DB PRESS Vol.38』の「新人歓迎企画 これからのソフトウェア開発者に求められること」を読んで書評をまとめ、TracWikiにアップロードさせる、というものだったなぁ。

  • かつてのソフトウェア学習法
    • 昔はソースをネットでぐぐれない。タンスの中からファイルを探し出して読むといったやりかた。
  • 見積もり方法
    • 世の中には「えいや」という便利な言葉がありまして、部長が言うわけですよ。「えいやで、ざっくり見積もってくれ」と。
  • 昔はウォーターフォール
    • 後戻りのないWFもあるらしいが、政府も含め通常は、修正する場合は滝をもう一本起こす。
    • クローズドだった時代は見積もりが今より外れにくかったが、オープンになって見積もりが合いにくくなった。
    • コンベもあるし、予算は厳しい。結局契約時にいくらもらえたか。
  • 反復型へ
    • 結局ケツカッチンで開発者にしわ寄せがくる。
  • アジャイルへ
    • XPやAgileは無法地帯、開発者天国みたいなイメージを持たれる。
    • 少なくとも見積もりしないでコンベに行ったら間違いなく受注できない。
  • XPの力
    • XPは反復型でリスクが少なくて、ペアプロとかリファクタリングできれいなコードが書ける。
    • でもXPのパワーはそれで終わりじゃないだろ！
  • 保守は難しい
    • ソフトウェアはイチから作る方が楽。保守の方が難しい。
  • ４つの要素
    • コスト、機能、品質、納期（新人教育でよく習うような。）４つのいくつかに余裕を取る。
  • PMになりたくない理由
    • 会場で挙手を募る。PMになりたい人は一人もおらず、なりたくない人には半数以上が手を挙げる。
    • リーダーは
      • 進捗を「見る」
      • お客さんに謝る
      • ごきげんを伺う
      • ピザを買ってくる
    • ことしかできない。
    • → 計画駆動型では、４つの要素をロックインして中が埋まるのを眺めているだけ
  • 技術者に大事な能力２つ
    • 理解する能力
    • 思いつく能力
  • もともと結果がユーザにはあるはず（今見えなくとも徐々に見えてくる）
    • エンドユーザはIT化の前に業務分析を結構やっていることが多い。経営上、目的は必ずあるはず。
    • ３つはロックインされていることが多いので、１つを動かせるように交渉する。
    • ラグザイアではどうしているか
      • 顧客の前でガンガンつくる（リードタイムの長そうな機能のみ仮実装）
      • Railsでもまだ画面のリードタイムが長い(HTMLだから)。
      • UIはUI専用言語、専用環境にまかせる（昔からUIだけでもMS製品を使ってみたかった。今ならAdobe AIRやMS Silverlightがある。）
      • 今は実装のリードタイムがどんどん短くなってきているので、検討も速くしなくては間に合わない
    • エピソードをひとつ
      • あるEU企業に「ある会社に見積もりを出したら200億と言われた。相馬さんのとこならいくらか見積もってよ？」と言われ、次の週に、若干チープではあるが完成品を持っていき、その場で顧客の「こここうしてよ」を聞いて変更していった。
  • TPMにおける要素が測定できると非常に説得力がある
  • 契約形態
    • いままでで最悪のプロジェクト
      • 3000万という額は決まり
      • 機能がなくてあるのは要求だけ
      • 作っていて途中で実現できないことに気づくと「貸しだ」と言われる。
      • ユーザ企業が不動産や金融だとかなりヤクザなことを言ってくる（ITベンチャーも）
    • 両極端しか存在しない契約形態
      • 一括請負
        • 受ける方が負担
      • SES契約
        • 顧客が負担
    • ラグザイアの順請負契約（実際は個々の契約で少しずつ違う）
      • 今の所上手くいっている

時間に余裕があったのでここからアドリブでした。

  • とにかくまずは業務分析（たしか、必ずしもSEでなくてもよい、というようなことを言われたと思う）、次にシナリオの抽出。
  • 価値の単位
    • ログイン機能は価値じゃない。ユーザ登録画面と一体で価値がある。さくさく動くのは価値じゃない。
    • お客さんが価値を受け取る単位を抽出する
  • 技術力
    • 一番最初に大事な機能を作って動く状態を維持しながら検討を続ける
    • →きれいなコードを書く技術（リファクタリング、名づけ等）が重要
  • これらの技術がないと開発が進むにしたがって検討に対する実装のスループットが追いつかなくなってくる。

Q&A

  • 機能を最初に決めなくて大丈夫か？

逆に「本当に決めてしまって大丈夫か？」ときいてみればいい。オンライントレードの企業やベンチャー企業はは小さい投資で最大の効果を得たいと考えているところが多い。@ITの記事も参照してほしいとのこと。

  • 受託開発ではなくパッケージ開発ではどうか？

（すみません。suginoyは聞き逃しました。実績があるということだけは覚えています。）

  • 信頼を最初に得るのは難しいのでは？

小さいところからコツコツやるしかない。また、技術教育を重視していて、セールス的な「できます」は言わせないようにしている。

  • （上記回答に関して）営業にも徹底しているのか？

このあたりは今の代表と気があって一緒にやっていけると思ったところなのだが、営業の人も開発を経験しなくてはいけない。「あれやってみないとわかんないよね。意外とハマるから。」というのがわかる。

  • 今までの説明ではまだ本当に信用してもらえるのかという懸念がある

SIは整体師に似ていると言える。マッサージしてもらう前に効果を約束させるのか？延長するかどうかはサービスを受けてみてから決めるはず。こちらは技術をもってサービスを提供する。また、ラグザイアでは開発プロセスに効果測定と提案がある。効率性を信用してもらう。次の号の『WEB+DB PRESS』誌にラグザイアの代表が提案書の書き方について寄稿するので参考にしてほしい。

  • 業界には非効率だからこそお金がもらえている事実がある。大きな会社に通用するのか。

SIerが大きくある意味があるのか？ほとんどないはず。絵描きの事務所が大きくて意味があるのか？SI業界は競争がフェアじゃない。