katapedia

IT業界

日本のIT業界についてのMatzの意見

本業に直結するシステムの開発をアウトソースすることはつまり、“競争力の源泉”を他社に任せることと同じ。企業戦略的に得策ではなく、常識的に考えてあり得ません

大規模な案件は特にですが、受託開発はビジネスの形態上、“硬直した開発体制”になりやすいんです。それによるコストの増大やプロジェクトの炎上、ひいてはプロジェクト失敗となる確率の高さなどを冷静に考えると、惰性で過去のシステムを踏襲するという理由以外には、とても正当化できるビジネスとは思えません。

http://hrnabi.com/2017/12/06/15766/

SE

もともとシステムエンジニアってプログラマーよりも視野が広く問題を解決できることを指していたけど、最近はプログラムがかけない人のことを指している

SIer

いままでのSIer

日本ではユーザー企業のシステム開発は外部委託が基本だ。はっきり言ってしまえば丸投げである。SIerがそれを請け負い、IT業界の多重下請け構造をフル活用して、人海戦術で開発プロジェクトを推進する。従って日本におけるプロジェクトマネジメントは、いわゆるベンダーマネジメントの側面が極めて強い。これもはっきり言えば、無理を聞いてもらえるよう下請けベンダーをうまく管理することである

http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00138/022100017/?n_cid=nbpnxt_twbn

SIerの歴史

これからのSIer

信頼されるよりも尊敬される組織になろう

絶対に逃げないに価値はない

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/

変化するSIer

富士通の事例

http://dev.classmethod.jp/tool/github/github-constellation-conf-fujitsu/

セゾン情報システムの事例

http://blog.livedoor.jp/lalha/archives/50528045.html

SIerの問題

ヤクザ関係者多数

低劣な技術者多数

技術の分からない文系役職者多数

わけのわからない契約多数

組織犯罪者との内通多数

セキュリティ駄々漏れ事態多数

使途不明とも取れる不要な支出多数

ブラック企業のブラック求人多数

労働関係法令ぶっちぎり多数

派遣偽装請負多数

非日本人系の人間多数

https://thinkit.co.jp/article/10634

多重下請け構造

ここがすごい

  1. コストカットできる(気がする)

  2. リスク分散できる(気がする)

  3. 技術力を外部から補充できる(気がする)

ここがだめ

  1. チーム間の縦割りに加え、会社間の横割りがある

  2. 問題は同じ会社内でフォローしろ、という悪習がある

  3. 下請けの品質が悪いという理由に落とせば、下請けの費用で製品の改修ができる。(と思っている人がいる)

  4. 人月精算が多く、成果が下請けの直接的な利益UPに繋がらない。

  5. 下請けが利益を出すにはさらに下請けを使い仲介料をとる必要がある。

  6. 下請けの低賃金化が進む

  7. 氏はない代金は不当に下げられたりしないが、実施作業を増やすという特殊な買い叩きがある

  8. 必要なときに必要な人数を集め、不要になったら切る

  9. 分業により技術力が低下し、ノウハウが蓄積しない

  10. 分業により若手が育たない

  11. 自社業務による帰社や、休みが取りづらい

  12. 自社への帰属意識が下がる

  13. 仕事への動機づけが難しい

  14. 契約した勤務時間が月固定で無駄に仕事する場合がある

  15. 下請けがこれらを改善する要望を出すと、取引を切られる。

システム子会社

親会社からの意見

システム子会社ができた理由

ITはあくまでも製造物であり、仕様を提供して、入札・応札を行い、同じ仕様で最も品質がよく、安くいいものを調達する、すなわちソフトウエアを「工業製品化」する、という思想がそこにある。 http://jbpress.ismedia.jp/articles/-/52025

イノベーション

Cynefin Framework

①Obious/Symple(単純系とか自明系と呼ぶ)原因が明確で誰でも分かる課題。自明。

②Complicated(煩雑系とか困難系と呼ぶ)こみ入っていて分かりにくいけれど、専門家の助けを借りるなり分析すれば論理的に原因が分かる課題。因果関係は明確なわけだ。

③Complex(複雑系とか複合系と呼ぶ)いくら分析しても解けない。因果関係は後から振り返ることによってのみ分かる。やってみなければ解決できるかどうか分からない。失敗して学習するしかない。

④Chaotic(カオス正に混乱系と呼ぶ)突発的に起こりともかくすぐにその状況から脱出しなければならない課題。因果関係が存在せず危機的状況。危機かも知れないけれど機会かもしれない。リーダーシップはカオスから抜け出すこと。

ミス

失敗事例

京都大学 林晋

http://www.shayashi.jp/myfailures.pdf

オペミス

「オペミスしました」

「根本原因究明の上、対策をせよ。二度とあってはならない」

「オペレーションの前に目視チェックします」

「よし」

「オペミスしました」

「根本原因究明の上、対策をせよ。二度とあってはならない」

「オペレーションの前に複数人による目視チェックします」

「よし」

「オペミスしました」

「根本原因究明の上、対策をせよ。二度とあってはならない」

「オペレーションの前に上司の承認印を得るようにします」

「よし」

「オペミスしました」

「根本原因究明の上、対策をせよ。二度とあってはならない」

「オペレーションの前に上司の上司の・・・」