ウチのシステムはなぜ使えない の商品レビュー

岡嶋裕史【著】

2024/10/22

読んでて普通に面白い。
「なるほど、実に興味深い」という意味での面白いではない。 読んでて「フフッｗ」っと笑ってしまう方の面白いである。
若手に読んで欲しいというよりは、ITおじさん、ITおばさんに、酒のつまみとしてお勧めな本。

2023/06/30

発注する側だとしても積極的に話に行くことがシステムの導入成功に繋がる

SRにまつわるトラブルが色々書かれているが結局のところコミユニケーションエラーが主な原因となっていると思った。発注する側と受注する側もそうだけど、タスクを振る側と振られる側、社内外両方におけるコミユニケーションにどっか問題があるせいで、しっちゃかめっちゃかなシステムが作り上げられているのかもしれない。

2018/10/20

まじめなタイトルがもったいない！SIerの仕事内容をクソ面白く語った本。本書の想定読者は顧客側だが、これからIT業界を目指す人に読んでほしい。大体こんな感じだから。そして同業者にも。1部2部で「あるあるww」とニヤニヤしつつ、3部で爆笑できる。人におすすめしたい良書。

2018/10/13

タイトルが失敗学なので、失敗から何を学んだのかを知りたかったが、特に学ばなかったようだ。だから次も失敗するのだろう。 著者は何を伝えたかったのだろうか。タイトルにだまされた感じ。

2021/08/08

たまたま図書館でタイトルが目に留まったので読んでみた。どこの会社もシステムにおける悩みは共通なのだと笑ってしまった。昨年中に本書を読んでおけばよかった。

「顧客としては当然の欲求であり、要求だが、手作業には手作業の流儀があるように、IT化した業務にはIT化した業務の流儀がある。手作業で最適だった仕事のやり方が、IT化済み作業で最適であるとは必ずしも言えないばかりか、むしろ異なることの方が多い。
　せっかく高いお金をかけてIT化するのであれば、多少今までと仕事のやり方が異なることになっても、従来の手法では不可能だった業務やサービスを可能にする等の高度化や効率化を追求した方が吉である。
　…
　少なくとも、仕事の高度化によるメリットと、新しい仕事の進め方による各種のデメリット（習熟コストなど）のバランスポイントは追求するべきで、手作業の仕事のやり方を一つも変えたくないのであれば、IT化する必要そのものがないケースが多い。」
「顧客の立場でIT企業の営業さんと付き合う場合は、その営業さんがどの程度の技術知識を持っているかをシビアに見極めなければならない。困難でもやり遂げなければならないミッションである。でないと、とんでもない作品が納品されることになる。営業さんの技術知識に不安を感じたら、迷わずに技術者も同席してもらおう。」

「IT企業が顧客に感じる不満として、『具体的に何をしたいのか』『社内での意思統一』といった『基本的な意思決定ができていないこと』が上位に燦然と輝いている。」

「オブジェクト指向ではカプセル化といって、プログラムを小さな機能単位に分割して閉じこめてしまう。
　小さく区切られた単位によってプログラムが独立しているため、別のプログラムに移し替えることが比較的簡単なのである。一から一〇まで大工さんが作り上げる家と、ブロック工法の違いである。
　したがって、オブジェクト指向になって誰が嬉しいかというと、プログラムを作っているSEやSIerが嬉しいのである。システムを構築した経験が増えるほどにオブジェクトのストックが増え、次に何かを作るときの手間が減っていく。顧客に直接のメリットはない。」

「アジャイル開発では、短期間でごく小さなプログラムを作成しリリースしていく。ウォータフォールモデルが計画重視であるのに対して、アジャイル開発は適応重視である。問題点が次々と噴出しても柔軟に対応できるように、高度な能力を持った数人単位のチームで密なコミュニケーションのもと、開発を行う。このチームには顧客も参加するので、いつでもシステムに対するフィードバックが可能である。」
「アジャイル開発を進めるための開発方法は色々提唱されているが、最も有名なものはエクストリーム・プログラミング（XP）であろう。
　…以下の四つの原理があることは知っていてもいいだろう。
　・コミュニケーション
　・シンプル
　・フィードバック
　・勇気
原理の中に『勇気』が含まれているのが素晴らしくも恐ろしい。むしろ、エクストリーム・プログラミングを実施している企業に仕事を依頼する勇気が試されているようにも思える。
　勇気は時に人生を切り開くが、蛮勇との区別はしっかりつけておきたいところである。エクストリーム・プログラミングの成否は、通常の開発手法以上に人に依存することが多いため、採用する場合はSEとの連絡をいっそう密にして成功や破綻の気配を感知しよう。」

2018/10/07

システムの発注側の視点から、ベンダーの営業・SEとの付き合い方を多少おもしろおかしく書いています。,ベンダー経験が無い人にとって「SEとは？」がわかりやすいと思います。,ちょっとSEを小バカにした感じが気になりましたが、筆者自身があとがきで「悪役として書いた」としているので、まあOKです。,,第3部のケーススタディはかなり笑えます。

2016/01/25

非常にありそうな話で既視感がすごかった。

同じ領域の人たちと仕事をしていれば基本的には大きな間違いは起こらないと感じるが、例でもあったような(極端だが)今川焼の個人商店向けにIT導入となると、まぁなんでもありのような、うまくコミュニケーションをとることもできないんだろうなーと。

とはいえ、そういう専門外の人にも説明ができることこそ必要だし、そんなになぁなぁな感じで仕事してたら競合に一瞬で抜かれてしまうんだろう。

この業界での営業は立ち位置が難しい、だからこそ技術的な面の理解が欠かせない、両方できるように、と思っていたが、本書では技術的役割と業務的役割に分かれていてうまく存在意義が表されていた。

情シス部門が顧客ではないため、ITの知識のみならず顧客の製品の知識も求められるため日々大変ではあるが、こんな感じで達観して面白おかしく仕事が出来たらなと思う。

2015/06/25

軽妙な語り口でネタや比喩が多め。SEという生態がある意味的確に描かれている。システム開発はなぜ「不幸」をもたらす場合があるのか、「開発崩壊」はなぜ起きるのか、そのヒントになる。

ノンバーバルコミュニケーションも含めて、メッセージをしっかり伝え合うことが大切。「不幸」はきっとコミュニケーション不足から生まれる、というのが現場で働いているSEの実感。この本でもコミュニケーションの大切さが随所に描かれている。

第三部でユーザ側とSE側から同時進行でシステム開発がケーススタディで進むがコレはひどい。さすがに同じSEとして、ココまでは…と思いたい。優秀な人も一定数いるんだから、SEには。SEが全体的にひどいと思われないかが心配になるレベルの記述だった…。

SEからしたら、「まぁこんな人いるよね」というくらいで読めると良いのだろう。

2015/03/28

あとがきを読んでると、SEについて悪く書いてる本みたいな印象を受けたけど、自分はそんなふうには感じなかった。まあ、大変な職業なんだろうね。自分はプログラマという職業に甘んじたい。
でもなにより運用が大変だと思った。同情を禁じ得ない。運用を希望する人って滅多にいないんだろうなぁ・・・。
ところで、クラウドという言葉が登場しそうなところでクラウドという言葉がでなかったけど、本書が2008年の本というのが理由だろうか。いや、自社サーバだからクラウドとは少し違うか・・・。
最後のフィクション話のWeb 5.0で噴いた。電車内で読んでたけど、マスクしながら読んでてよかったと思った。

2014/10/06

皮肉や誇張もあるけれど、結構実態を克明に表しているかも知れない。
当事者には笑えない話かも知れないが、第三者的には笑える。
著者とは同年代かとも思ったが、10歳も年齢が下とは・・・