nekoTheShadow’s diary

IT業界の片隅でひっそり生きるシステムエンジニアです(´・ω・`)

沢渡あまね『システムの問題地図 :「で、どこから変える?」使えないITに振り回される悲しき景色』(技術評論社)を読んだ。

システムの問題地図 ~「で、どこから変える?」使えないITに振り回される悲しき景色

システムの問題地図 ~「で、どこから変える?」使えないITに振り回される悲しき景色

もともとはCodeIQ Magazineで連載、CodeIQがSunSetした後はリクナビNextジャーナルに移籍した「運用ちゃん」という連載があって、いつも楽しみに読んでいるのだが、この「運用ちゃん」の作者(シナリオ)が書いた本だということで、興味をもって読んだ1冊です。

運用ちゃんの記事一覧 | リクナビNEXTジャーナル

本書のターゲットはIT業界全般というよりはむしろ受託開発。受託開発における問題とその原因が、ユーザ側と受託側の両方の観点からうまく整理されています。よくもわるくもSIは日本のIT業界の中心であり、かかわる人も多いはず。わたし自身もSIに勤めるSEなので、本書であげられるエピソードには「あるある」と首肯しつつ、ちょっと遠い目になってしまったり(´・ω・`)

「あるある」ポイントをあげだすと、まったくきりがないのですが、読書メモからいくつか抜粋しておきます。

  • 「運用でカバー」。これは本当にやめましょう、というかやめて(´;ω;`)ウゥゥ DevはOpsのことを考えてシステムを構築しない、というか予算や納期に押しまくられてOpsのことまで考えている余裕がない。Opsはひどいシステムのお守りに時間を取られて、スキル向上や現場カイゼンに割く余裕がない。DevとOpsに一線を引く、そして前者を上位におく日本のIT業界の慣習は改めていく必要がありますね。
  • 「俺はITシロウト」という開き直りは、程度の差はあれよくやられる手法です。エンドユーザならともかく、情シスや情報子会社までこの開き直りすることがあって、これが本当にたちが悪い。この開き直りをどうさばくのかがベンダーの腕の見せどころなのですが、金を払う側ともらう側という関係上、コントロールがなかなか難しいというのも現実だったり……。
  • 予算の見積もりや要件定義が甘くて炎上。プログラマの屍を積み上げて、その炎上を消し止めたものの、構築したシステムをユーザは使おうとしない。だれも幸せにならなかったパターンですが、SI業界にはざらに転がっています。まったく生産的ではないので、すくなくともわたしの世代で止めていきたい(謎の決意)
  • システム開発においては要件定義が重要。というか上流が失敗すると、まず間違いなくPJTは炎上もしくは破綻します。業務要件はもちろんのこと、忘れられがちなのがシステム要件。いわゆる非機能要件というやつで、ユーザはどれぐらいか、DiskやCPUはどのぐらい必要か、サービスの開始と廃止の基準はどのように設定するのか etc。これらをないがしろにすると、本当に痛い目に合うので、気を付けましょう(実体験&現在進行形)

「問題地図」とタイトルにあるとおり、システム開発・受託開発における問題点がこれだけうまく整理されている本はほかにないのでは? SI側の人間はもちろんのこと、何の因果かユーザ側のIT部門に飛ばされたというような人にとっても、勉強になる1冊ではないかと思います。ただ褒めるだけはよくないので、しいて文句をつけておくと、本書は「問題を列挙する」ことに焦点を置いています。もちろん、問題点をMECEに列挙するだけでも、たいへんな価値はあるのですが、それをどう解消するかについてはやや薄いという感想を持ちました。

もちろん問題に対する解決策が示されないわけではないのですが、やや書生論のきらいがあるように感じたのも事実。たとえば業界全体の風土の刷新であるとか、ユーザ企業側のリテラシ向上であるとか、確かにその解決策は理想的で論理的ではある。しかしなんの力も持たないSIer勤務のSEや社内SEが身近なところから実践していきたいという場合、本書には即効性はないと言わざるを得ないでしょう。

ただそんな即効薬を本書に求めるのは間違っているという指摘は正しいですし、本書の価値のほとんどは「問題点をまとめて、論理的にわかりやすく説明してみた」というところにあります。そんなに分厚い本ではなく、実際サイゼリアで夜ご飯とデザートを食べながら1.5時間ぐらいで読み切れる分量(行儀悪い!!)なので、SI業界に問題意識がある人(いない人などいるのか?)は読んでみて損はない1冊だと思います。