答えはまだでないけど、このままじゃいかんよね、ということを伝えたかったんやー

1. 第28回長岡IT開発者勉強会
SIの現場から感じた未来
∼請負とSESの間に∼
2012/09/22
@nemuzuka

2. 自己紹介
id:nemuzuka, @nemuzuka
サーバサイドにJavaを使用したWebアプリ
ケーションの開発を主にやっております
色々作ってます
・GAE/J上で動作するITS
https://sites.google.com/site/mishimabts/
・Heroku上で動作するグループスケジューラ（RoR）
https://sites.google.com/site/yoitagroupscheduler/
8月に三男が産まれました！

3. 今日のお題
スーツ vs ギーク
よりも
身も蓋もないことを

4. 自社の売上に
興味あるヒトー？

5. 売上が右肩上がりのトコー？

6. 売上が上がっても
稼ぎは変わらない？

7. 売上が下がったら
稼ぎは絶対に上がらない
※場合にもよります

8. 売上が下がったら
稼ぎは絶対に上がらない
下手すると人員整理が
はっじまるよー
※場合にもよります

9. SIで生きていくために
そろそろ本気で考えたほうがよくね？
的な話を
※個人の見解です

10. はじめに
・SI(System Integration)の定義
顧客の業務内容を分析し、問題に合わせた情報システムの企画、構築、運用などを一括して
行うこと。システムの企画・立案からプログラムの開発、必要なハードウェア・ソフトウェ
アの選定・導入、完成したシステムの保守・管理までを総合的に行う。
→平たく言えば、お金貰ってシステム開発しますよ、ってことです。で、これで稼いでいる
企業を今回SIerと呼びます。

11. 会社に所属すること
↓
会社から給料をもらって仕事をすること

12. かの元帥も言ってます
誰しも給料に対しては、相応の忠誠心を示さなく
てはなりませんからね、私もそうでした。
あれは紙ではなく、実は鎖でできていて人を縛る
のですよ。

13. 会社とあなたを繋ぐ
給料

14. 給料をもらっているから
気の乗らないことも
やります

15. そんな給料は
会社の売上から出てきます

16. SIの売上
請負契約
顧客から仕事の完成を依頼され、その仕事の結果に対して報酬を支払う契約。
アルバイトのように仕事をすること自体で報酬を貰うのではない。
利益 ＝ 完成時に顧客から貰う金額 ー 実際にかかったコスト
となり、作業のコストを下げることで利益を多く出すことができる
ex.) 1000万で受注した仕事を実コスト100万で完成させた場合、900万の利益！

17. いい話ばかりじゃない
長時間働いたからといって、報酬が多くもらえるわけではない。
良い物を早く作ったからって、報酬が多くもらえるわけではない。
長時間働いても仕事が完成しない場合、報酬はもらえず結局タダ働きになる
ことも！
下手すると債務不履行で損害賠償を求められることも
発注側とすれば、金さえ払えば丸投げできる良い契約

18. 遠い「仕事の完成」
決まらない仕様
Aさんがいないと仕様が決まらない？あー、Aさん１週間出張なんだよねー
実装できない設計
これでユーザと合意しちゃったから、何とか頼むよ
終わらない実装
80%の進 率ってどういうこと？ってか先週と変わってないんだけど
収束しないバグ曲線
やべぇ、発散してる
多発する仕様変更
この変更、今のスケジュールに入るよね？（追加工数なし）

19. 挙げたらキリがない
想定外の作業範囲
え？テストのエビデンスに画面のハードコピー全部取る必要あっ
たの？
社会人たるもの空気や行間も読めないと
仕様書・設計書には明記されてないけど、だからって考慮してな
いのはおかしいでしょ
瑕疵責任と仕様変更の間で
この動きってバグじゃないの？から始まり、そもそもさぁ・・・
に繋がる脅迫
※ユーザとの間に複数社存在する多重請負の場合、
「わかりづらいStrutsベースの自社フレームワークの強要」
等さらに要因の追加が見込まれます

20. そんな中で
ユーザとWin-Winの関係

21. ( ́,_ゝ｀) ﾌﾟｯ

22. そうならない為の努力
見積りの精査
前提条件の網羅
見積時に設計するくらい時間をかけなきゃ細かいものは書けない
「時間かけたけど、失注したよ」→かけた時間はタダ働き
リスク込みの金額で
「高い、下げて」
プロジェクト運用
一度決めた仕様は追加工数無しに変更できません！
険悪ムードになって重箱の隅をつつくような間柄に
開発側の努力
生産性を上げよう
「P⃝P使って生産性上がるなら工数減らしていいでしょ」

23. いろいろ頑張ってきたけど
手詰まり
「やりようによって」では
カバーできないレベルに来てますよ

24. そろそろ見直しませんか、
契約のこと

25. システムの完成を保証するビジネスモデルから、
ユーザに価値あるシステムを作るビジネスモデルへ

26. バグの少ない高品質で多機能なシステムを完成させても
価値がない（使われない）システムはガラクタ
※画像はイメージです

27. もちろんユーザの理解も必要
システムが完成しないリスクよりも
価値のないシステムが出来上がることを
よりリスクと思ってくれれば・・・
もし、そんなユーザがいたら逃がしたらいけません

28. ならアジャイルだ！

29. アジャイルは救世主？
開発プロセスとしてはものすごく正しい
無駄な投資を抑えることができる
【ただ、請負契約との相性最悪】
ヘタをすると追加工数無しで延々と開発側の持ち出しで
開発をすることになる・・・かも
かといって準委任契約だと、ユーザ側が一方的にリスクを負うから
いい顔しないでしょう

30. どんな契約がいいか
答えはまだない

31. 考えてみませんか？

32. まとめ
新しい契約形態を考えてみませんか？
こんな変な業態日本だけですし、海外にその答えを求めても解決策は出てこないと思う
言われた通りに良い物を作ってるだけじゃ、ビジネスとして成り立たない
新しい開発手法・技術を勉強するのもいいですけど
いっそのことSIから離れるのもひとつの考えかも
SIerだけ頑張ってもダメ
システムにお金を払うユーザあっての話なので
自分の仕事が金 けに繋がらなきゃプロと名乗るべきじゃない
売上があがって余裕が出れば、新しいことにチャレンジする余裕も出てくるさ（きっと）
会社の中でそんな話、してみません？