【読んでみた】システムの問題地図

こんにちは。 「問題地図」シリーズを読んでみたエントリです。

目次

読んだ本

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

どうしてこの本を読もうと思ったの？

今のプロジェクトがあるあるな火吹き案件で
どうしてこういう悲劇って繰り返されるのかな？
どういうところに原因があってどうしたら良くなるのかな？というのを
うまーくまとめている本とかないかなと思って。

本の目次

• はじめに～どうして生まれる？「使えない」「使われない」残念な情報システム
• １丁目　「だれのため？」「何のため？」のシステム
• ２丁目　無駄にハイスペック
• ３丁目　「とりあえず作っとけ！」
• ４丁目　「抜け」「漏れ」だらけ
• ５丁目　「俺ら、ＩＴシロウトだから！」
• ６丁目　必ず火を吹く
• ７丁目　「仕様ですから」「言われていませんから」

読書メモ

全般的に大事なことてんこ盛りで書いていますが、自分が特にささったところをメモ。

１丁目　「だれのため？」「何のため？」のシステム

業務設計のための５つのチカラを身に着けよう

1. 現行業務をフローに分解するチカラ
2. インプットとアウトプットを定義するチカラ
3. 見えないステークホルダー（関係者）を特定し、メリット／デメリットを整理するチカラ
4. ヒアリング能力／質問力／リフレーミング能力／言語化能力／図解能力
5. 「ムリ」「ムダ」「ムラ」を発見し、改善提案するチカラ

がんばってチカラつけていこー！

７丁目　「仕様ですから」「言われていませんから」

こうして生まれる？ＩＴ屋の受け身マインド

• ＩＴ業界内部要因
  • 縦割り意識（ユーザに対するリスペクトも信頼もない）
  • ほかのやり方、ほかの技術をよく知らない（メンバーのモチベーションが低い） （P.220-P.221）

    ユーザーは、いつも無邪気に要件変更や追加を要求してくる。毎度火を吹く。
    しかし、コストもスケジュールもいつもカツカツ＆ギリギリ。
    当然、自分たちの守備範囲以外の仕事に手を出そうなんて思わなくなる。
    いわゆる縦割り意識。さらに会社間の政治的なブレーキも働く。
    「それはウチの仕事じゃない。手をだすな」
    「ユーザマニュアル作成がプロジェクトのＷＢＳ（作業項目）から抜け落ちている。後々、焦ることになりそうだ。
    でもウチ（ベンダー）はそんなの知ったこっちゃない。知らんふりしておこう。」

ほんとコレすぎる。。。

過度な客先常駐を解消、たまには帰社日を設けて社内コミュニケーションを

（P.231）

客先常駐の常態化。請負型ＳＩや運用の会社ありがちな光景です。
しかし、これはエンジニアを不幸にしてしまいます。
「ほかの現場のことがわからない…」
「ほかのやり方やトレンドを知らない…」
「新しい技術を習得できない…」
井の中の蛙になってしまいがち。
せめて、たまには帰社日を設けて、自社のほかのエンジニアと触れたり
情報に触れられる機会を作りましょう。

外の風に触れてもらって成長を促そう

（P.232）

断言します。エンジニアを毎晩夜遅くまで／休みなく現場にいさせてはダメです。
たまには（時には半強制的にでも）、外の風に触れさせてあげましょう。
エンジニア同士の勉強会、業界のフォーラム、技術を軸にしたミートアップなど、
まわりを見回せばチャンスはたくさん転がっています。
・エンジニア同士、技術に関する議論をたたかわせる
・社外のロールモデルを見て刺激を受ける
・新しい技術を知る、潮流を知る
それがエンジニア自身を成長させ、価値あるアウトプットにつながります。

感想・気づき

相手を「知る」ということ

今回のお話の内容、実はいろんなところで起こりうる話。
この世のモメごとの大半は「相手への理解のなさ」に原因があると思います。
システム開発の世界に限った話ではないと思います。

相手のことを知らない、知ろうともしない。
自分だけの正しさ・立場だけを一方的に主張して「自分は悪くない」「悪いのは〇〇だ」
そんな姿勢で両方わかりあえるなんてあるわけがなくて。

（P.225）

たまには景色を変えてみる。ユーザとベンダーで「交換留学」をしてみるといいのでは。
（中略）...「相手目線で考える」言うは易し、行うは難し。
現場のリアルな実践で身に着けるのが最良の方法です。

これ、仕事をしていくなかで「相手を知る」一つの解では？と思いました。
今いてるプロジェクトも現場に見学、とかはあるみたいだけど
ここまで踏み込んだことはしたことないな。（今までもない）
実現するのは難しいかもしれないけどこういうの、自分もいつかやってみたいです。

井の中の蛙になるな！外の世界を知ろう

世の中には日々いろんな問題解決のための方法や技術が出てきている。
それを知ろう・学ぼうともしないというのはまさに「井の中の蛙」であり、もったいないこと。
外部の勉強会などを通じてもっといろんな知見を得て業務に生かしていこうということを
今回のお話では強くおっしゃっているのではないかと思いました。

外の世界を知ることなく、居続けることに自分も強い危機感を感じています。
自分は客先常駐のＳＥＳ商売を生業にしている会社に勤めていますが
同じ職場で永久に居続けられる保証なんて、どこにもないんですよね。

体制が縮小する、といったことが起こるとまず切られるのは我々みたいな人間。
どんだけその職場で通用し貢献していたとしても
一歩外にでたら通用しなくなるかもしれない。

なので、いつ自分が今の職場を放りだされることになったとしても
どこにいっても通用し、貢献できる力を身につける努力を今、しています。

今自分がやるべきことは何か

最新技術トレンドのキャッチアップ（継続）

去年くらいから社外の勉強会に参加したり
PyQやProgateなどのサービスを使って
新しいプログラミングスキルを 学習するようにしています。
これは今後も継続、内容を充実していきたい。

「お客さまの要件に応じて、最適な解決方法を提案できるエンジニアでありたい」

これを実現するために
新しい技術や開発手法を学んで、問題解決の手段を
一つでも多く持ちたいと考えています。

勉強会に行って満足するだけでなく、得たことを
ブログ、勉強会、現場などを通じてアウトプットして
己の血肉に変えていきます。

勉強会で社内・社外を盛り上げる（継続）

• インターナルブランディング
• エクスターナルブランディング を、勉強会で実現しようかなとこの本を読む前から考えていました。

まずは社内で「教えあい、学びあってお互い成長する」カルチャーを
作っていかないとなと 思っていて、去年くらいから社内の勉強会を始めました。
（これがインターナルブランディング？）

まだ社内のごく一部の人だけしか勉強会ができていないんですけど
勉強会のコンテンツも少しずつ充実させたりして
自社の人たちに多く広めていきたいです。

これはまだまだなんですけど、最終目標は勉強会を社外公開して
外の人とのつながりをつくるとともに自分と自社の取り組みを知ってもらい、
「おー、あの会社っておもろいことやってるやん」と
社外のファンも増やすきっかけができたらいいなと考えています。
（これがエクスターナルブランディング？）

会社の仕組みを変えていきたいな（できる限り。。。）

今は自分にそんな力ないんですけど。。。
- 過度な客先常駐を解消、たまには帰社日を設けて社内コミュニケーションを - 外の風に触れてもらって成長を促そう 時間かかるかもだけど、うまく会社を巻き込んで
これらを仕組みに組み込んでいきたい。

本、読みやすい！

２時間くらいで一通り読み終えました。
前にも『マネージャの問題地図』を読んだんですけど、
沢渡さんの本はとても「読みやすい」です。
本の内容が「わかりやすい」だけでなく「どんどん読んじゃう」という感じですね。

きっと我々読者に「そうそうそれそれ！」と思い共感させて読ませることを
常に考えて本を書いていらっしゃるんだろうなと。
自分も人前で何か発表するときやこういうブログとかでこういった
相手にわかりやすく、かつ「ぐいぐい人を惹きつける」文章が書けるようになりたいです。
（いつも「お前の話（メール）は長い！」って上司に叱られるからｗ）

参考

本の中でおすすめ書籍が書いていたので
あとで読むためにリンクを張っておきます。

はじめよう! 要件定義 ~ビギナーからベテランまで

プロジェクトの失敗はだれのせい? ~紛争解決特別法務室“トッポ―"中林麻衣の事件簿

なぜ、システム開発は必ずモメるのか?

そのままではITプロジェクトは永遠に失敗する