[http://www.seshop.com/event/dev/2009/timetable/Default.asp?mode=detail&eid=124&sid=743&tr=01%5F%8AJ%94%AD%83v%83%8D%83Z%83X#743:title=「使う」と「作る」がつながるシステム開発]

以下、適当にメモったものです。嘘書いてるかもしれないので注意。

はじめに

平鍋さん

  • 作る人と使う人は別の大陸にすんでいて間に川がある。
  • つなぐ方法
    • フェリー = 仕様書
    • 橋をかける = 会話をする

倉貫さん

  • ビジネス習慣
  • 契約
  • 使う人と作る人が違う
  • 作りたいけど受託開発はいやだ
  • SaaS 起業。今は幸せ。

千貫さん

  • ユーザー部門が全部自分でやる。
  • 実際に行なわれてる。
  • 中途採用で引き抜く。
  • ハイレベルな人材が必須であり、高コスト。

橘さん

  • 受注ベースのソフトウェア開発ビジネスの価値生産性の低さに慄然
  • 悩める「SIer擁護派」

作る人と使う人をつなぐには?

千貫さん

  • SIerにたよらず自分で設計するのが大事。
  • 設計をちゃんとやればオフショアでもOK
  • 体力がないので大部分は丸投げ。
  • ちゃんとした設計にしようとすると変化に弱い。
  • 早く動く画面を見せることで、早い内にギャップを埋める
  • 作る人とビジネスする人の上司が同じであればもめない。
  • 究極的には SIer いらない。
  • ユーザ企業が雇用すればいい。

橘さん

  • お客さん先に出向いて開発。
  • 契約の問題は置いといて。
  • 契約の問題を解決しなくても技術社は協力できる。
  • お客さんが雇用しないのは、ずっとは雇っていられないから。
    • (千貫さん)偽装派遣になってしまうのを気をつけないと。

平鍋さん

  • SIer は作るのがミッション
  • 作ったものでビジネスするとこまでは責任を持たない。
  • 客と SIer でゴールが異なる。
  • 納品で区切られてしまう。
  • 日本でどうすればいい?

橘さん

  • 専門的な技術者は SIer の方が育ちやすいのでは。

千貫さん

  • プロジェクトが大きければ大きいほど評価されるのがおかしい。
  • プロジェクトを作ることで出世するのは不公平。
  • 優秀な人はお金もリスクもかけずにうまくいく。
  • 優秀でない人だと巨大になってしまう。

橘さん

  • 1000人くらい集めて作らないといけないプロジェクトもある
  • 決める人と作る人をちゃんとわけて、ちゃんとやるのもいいのでは。
  • なんでも共有するのがベストではない。

倉貫さん

  • そんな大きなプロジェクトばかりではない。

平鍋さん

  • Internet 技術, SaaS 技術で、狩猟型から農耕型にできるのでは。

千貫さん

  • 大きなプロジェクトだと管理が大変になる
  • 管理を回避するために、大きなプロジェクトを細分化した。
  • 「分割して統治せよ」
  • 分解することがうまいひとが尊敬される。
  • 分解せずに大きなプロジェクトにしてしまう人が出世してしまう。
  • 会社を変えないと。
  • トラブルを起こすと出世する。トラブルシューティングで目立つ。

会社の評価

橘さん

  • それぞれやってることが違うので評価がむずかしい。
  • コミュニケーション能力重視。
  • でも技術も見る
  • 一概にはいえない

今後アジャイルは増えていく?

橘さん

  • アジャイルは主流になると思う。
  • 1千万〜何百億の仕事があるが、数億以上のものは少なくなっていく
  • SaaS, フレームワーク
  • 本業回帰といってITをアウトソースする会社が増えていたが、それが変わるのではないか。
  • 日本だと SIer 多重請負だけど、ユーザ企業が下の会社と契約するようになる。
  • どうしても大きな開発は残るので SIer はそういうことをやる。
  • 専門性

千貫さん

  • 企業によってシステム部門に違いがある。
  • SIer が必要となる企業もある。
  • ユーザが大きくしようとするシステムを、SIer が小さくしてやる
  • でもスモールでライブでリリースすると運用の手間がかかる

橘さん

  • IS 部門と SIer の違い
  • IS は小さくしたい
  • SIer は大きい方が儲かる

千貫さん

  • ユーザをちゃんとコンサルした人が社内でも評価されるべき。

倉貫さん

  • なぜ大きくしないと儲からない?
  • 人月契約がおかしい。

千貫さん

  • 画面単位で単価を決めてみた。
  • 結構うまくいった。

橘さん

  • SIer の価値が低い
  • 一点もの。リフォームとかと比べると価格に対する価値が低い。
  • はやく人月から脱却しないといけない。

千貫さん

  • 建築業界は人月を絶対に開示しない
  • ボルト本数、ペンキ平米等を単価にしている
  • 業界で相場感ができている

作る人と使う人をつなぐには

平鍋さん

  • 人材流動が必要

千貫さん

  • 技術が進歩していけば EUD (End User Development) が進む。
  • SIer はなくならずコンサルタントになっていくのでは。
  • 中国オフショアのコストメリットをいかすためには、仕様をしっかり決めないといけない。
  • 国内でフェリーはありえない。

橘さん

  • EUD で吸収できる領域はあるけど、大半は違うのでは?
  • 最終的にどんどん要求がふくれて大規模化してしまうのではないか。
  • セグメント
  • ちゃんと大きなシステムをユーザに提供できる技術
  • 全部を繋げるのは無理。どこかで作る人と使う人をわける必要がある。

平鍋さん

  • プロの魚屋は売るだけじゃなくて付加価値をつける。
  • そんなサービスが SIer の強みではないか。

千貫さん

  • 契約がそれを許さない

倉貫さん

  • SaaS
  • 毎回個別にオーダーメイド→自社用新幹線を毎回作ってるのと同じ
  • 新幹線サービスを使えばいいのに。
  • 今の SIer は「新幹線を作るのが得意」
  • 3つのセグメントにわかれるのではないか。
大
↑    運営会社を作る
         ダムとか
    --------+----------
            |
      SaaS  |    EUD
↓          |
小    普遍  |   特殊
  • ミッションが共有されているところにDeveloperがいる
  • SIerは登場しない

さいごに

千貫さん

  • 労働環境が劣悪なこの業界をどうにかしたい。
  • 人月契約の弊害である SE 奴隷を解放したい。

橘さん

  • ソフトウェア作る仕事は絶対将来性がある。
  • みんなが IT業界に入りたいような業界にしたい。

倉貫さん

  • プログラマの地位があがればうれしい。
  • そういう仕事をしたい