本業に直結するシステムの開発をアウトソースすることはつまり、“競争力の源泉”を他社に任せることと同じ。企業戦略的に得策ではなく、常識的に考えてあり得ません
大規模な案件は特にですが、受託開発はビジネスの形態上、“硬直した開発体制”になりやすいんです。それによるコストの増大やプロジェクトの炎上、ひいてはプロジェクト失敗となる確率の高さなどを冷静に考えると、惰性で過去のシステムを踏襲するという理由以外には、とても正当化できるビジネスとは思えません。
http://hrnabi.com/2017/12/06/15766/
もともとシステムエンジニアってプログラマーよりも視野が広く問題を解決できることを指していたけど、最近はプログラムがかけない人のことを指している
日本ではユーザー企業のシステム開発は外部委託が基本だ。はっきり言ってしまえば丸投げである。SIerがそれを請け負い、IT業界の多重下請け構造をフル活用して、人海戦術で開発プロジェクトを推進する。従って日本におけるプロジェクトマネジメントは、いわゆるベンダーマネジメントの側面が極めて強い。これもはっきり言えば、無理を聞いてもらえるよう下請けベンダーをうまく管理することである
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00138/022100017/?n_cid=nbpnxt_twbn
- 工場で重要なのは品質管理や工程管理で、実際に手を動かす作業員より管理担当の技師が重要。それは食品工場でも同じ。一方、レストランでは実際に手を動かす料理人が重要に決まっている。プログラマーを重視するか否かはこれと同じで、作業員か料理人かの違い。ただしデジタルの時代は料理人がほしい。
- 人月商売の大手ITベンダーはシステム開発を工業化しようとして、製造業の工場モデルの導入を試みた。自分たちは設計や品質管理、工程管理（≒プロマネ）に特化し、実際に手を動かすプログラマーを工場の作業員と同じ扱いにした。それで本当に工業化できたかと言うと、見事大失敗だった。
信頼されるよりも尊敬される組織になろう
絶対に逃げないに価値はない
http://itpro.nikkeibp.co.jp/atcl/column/14/463805/021000073/
https://blogs.msdn.microsoft.com/nakama/2017/05/25/devmodernization/
https://docs.com/decode2016/9106
https://blogs.msdn.microsoft.com/nakama/2016/06/16/decode-2016-clt016/
https://blogs.msdn.microsoft.com/nakama/2016/06/24/waterfall/
https://blogs.msdn.microsoft.com/nakama/2016/07/03/nextstep/
富士通の事例
http://dev.classmethod.jp/tool/github/github-constellation-conf-fujitsu/
セゾン情報システムの事例
http://blog.livedoor.jp/lalha/archives/50528045.html
ヤクザ関係者多数
低劣な技術者多数
技術の分からない文系役職者多数
わけのわからない契約多数
組織犯罪者との内通多数
セキュリティ駄々漏れ事態多数
使途不明とも取れる不要な支出多数
ブラック企業のブラック求人多数
労働関係法令ぶっちぎり多数
派遣偽装請負多数
非日本人系の人間多数
https://thinkit.co.jp/article/10634
-
コストカットできる（気がする）
-
リスク分散できる（気がする）
-
技術力を外部から補充できる（気がする）
-
チーム間の縦割りに加え、会社間の横割りがある
-
問題は同じ会社内でフォローしろ、という悪習がある
-
下請けの品質が悪いという理由に落とせば、下請けの費用で製品の改修ができる。（と思っている人がいる）
-
人月精算が多く、成果が下請けの直接的な利益UPに繋がらない。
-
下請けが利益を出すにはさらに下請けを使い仲介料をとる必要がある。
-
下請けの低賃金化が進む
-
氏はない代金は不当に下げられたりしないが、実施作業を増やすという特殊な買い叩きがある
-
必要なときに必要な人数を集め、不要になったら切る
-
分業により技術力が低下し、ノウハウが蓄積しない
-
分業により若手が育たない
-
自社業務による帰社や、休みが取りづらい
-
自社への帰属意識が下がる
-
仕事への動機づけが難しい
-
契約した勤務時間が月固定で無駄に仕事する場合がある
-
下請けがこれらを改善する要望を出すと、取引を切られる。
- 受け身で何も提案しない
- コスト構造がブラックボックス
- 技術力なし
- 抵抗勢力の巣窟
- ピンはねする存在
- 我々の業務に対して無知
- ガバナンスが効かない
ITはあくまでも製造物であり、仕様を提供して、入札・応札を行い、同じ仕様で最も品質がよく、安くいいものを調達する、すなわちソフトウエアを「工業製品化」する、という思想がそこにある。 http://jbpress.ismedia.jp/articles/-/52025
①Obious/Symple（単純系とか自明系と呼ぶ）原因が明確で誰でも分かる課題。自明。
②Complicated（煩雑系とか困難系と呼ぶ）こみ入っていて分かりにくいけれど、専門家の助けを借りるなり分析すれば論理的に原因が分かる課題。因果関係は明確なわけだ。
③Complex（複雑系とか複合系と呼ぶ）いくら分析しても解けない。因果関係は後から振り返ることによってのみ分かる。やってみなければ解決できるかどうか分からない。失敗して学習するしかない。
④Chaotic（カオス正に混乱系と呼ぶ）突発的に起こりともかくすぐにその状況から脱出しなければならない課題。因果関係が存在せず危機的状況。危機かも知れないけれど機会かもしれない。リーダーシップはカオスから抜け出すこと。
http://www.shayashi.jp/myfailures.pdf
「オペミスしました」
「根本原因究明の上、対策をせよ。二度とあってはならない」
「オペレーションの前に目視チェックします」
「よし」
「オペミスしました」
「根本原因究明の上、対策をせよ。二度とあってはならない」
「オペレーションの前に複数人による目視チェックします」
「よし」
「オペミスしました」
「根本原因究明の上、対策をせよ。二度とあってはならない」
「オペレーションの前に上司の承認印を得るようにします」
「よし」
「オペミスしました」
「根本原因究明の上、対策をせよ。二度とあってはならない」
「オペレーションの前に上司の上司の・・・」