久しぶりに仕事関係の記事を。
問題地図シリーズというのをこの本を読むまで知らなかったのですが、売れているみたいですね。
この本はシステム開発における問題点をいくつかまとめた本ですが、ざっくり自分が気になったところと感想を書きます。
目次
本の概要
【累計15万部】『職場の問題地図』『仕事の問題地図』『働き方の問題地図』、『職場の問題かるた』に続く働き方改革のバイブル、シリーズ最新作!
「システムを新しくしたらかえって仕事が増えた、なんとかしてくれ」 「こんなシステム使うなんてめんどくさい、元に戻せ」
現場の生産性を向上させるためのシステムが、なぜ使えない・使われないものになってしまうのか? システムを「使う人」「作る人」「守る人」いずれの立場も経験した著者が、問題の原因を図解で示しつつ、解決策を教えます。
Amazonの書籍紹介より。
リンクは↑にある本のところです。
まとめ
ツイートしながら読んでいたので、ポイントとなるところについてはツイートを貼り付けます。
久しぶりに仕事関係の読書。#システムの問題地図
— えーこ🌗 (@pm_poupe) 2018年10月19日
また個人的にメモしてきます〜
システム化とは「見えないもの」を「見えるもの」に変える取り組み。
— えーこ🌗 (@pm_poupe) 2018年10月19日
業務設計のために次の5つの力を身につける。
・現行業務をフローに分解する
・インプット、アウトプットを定義する
・見えない関係者を特定し、メリットデメリットを整理する
・ヒアリング能力、質問力、リフレーミング能力（気づきを促すために異なる見方を投げかける）、言語化能力、図解能力
— えーこ🌗 (@pm_poupe) 2018年10月19日
・ムリ、ムダ、ムラを発見し改善提案する
・グローバル、全体最適、ガバナンスの3大ワードが出たらアウト。どこまでグローバル共通を追求すべきなのか？や全体最適の優先度は？など疑ってかかること。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・システム化の際に気をつけたい3つの不明は、システムの主管部門不明、データの責任元不明、エンドユーザーの管理元不明。
・要件定義の段階から運用メンバーを巻き込んで知見をフル活用する。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・リリース時にはPRをしっかり！
・システムの廃止基準も持つ。
・無駄&無用の長物システムが生まれるのは
— えーこ🌗 (@pm_poupe) 2018年10月19日
・現行業務・現行仕様に固執しすぎ
・はてしなき要件追加
・意識高すぎ・低すぎ
・現行業務・現行仕様に固執しすぎの悲劇
— えーこ🌗 (@pm_poupe) 2018年10月19日
1.無駄に多機能 → 運用コスト増
2.無駄に密連携 → 例外パターンに対応できないなどの弊害発生
3.バッチ処理のラッシュ → 遅延で業務影響発生
無駄に密連携についてはうまい例えが使われてました。
わかります…そもそもプログラム修正の調査に時間がめちゃくちゃ取られますし、どっかがコケると自分のシステムまでやられるんですよね…
— えーこ🌗 (@pm_poupe) 2018年10月19日
本では、路線があちこちと直通運転するようになって栃木の人身事故で静岡の電車に影響が出た、といううまい例えをお使いでした。
・例外処理を含めてすべてシステム化すると逆に別の業務の発生やクレームなどのムリやムダを生む。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・スモールスタートやアジャイルも検討する。ただしとにかくアジャイルにしよう！は危険。環境準備をしっかりする。
・クラウド利用も視野に入れる。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・クラウドを使うには、需要管理（ユーザー数、トラフィックなど）、構成管理（ライセンスやアカウント数など）、変更管理（アカウント追加などの変更手続き方法などを決める）をうまく管理する。
・とりあえずシステムを作っておけ！となる原因4つ。
— えーこ🌗 (@pm_poupe) 2018年10月19日
1.予算ありき
2.スケジュールありき
3.運用でカバー
4.俺ら、ITシロウトだから！
・2.スケジュールありきがさらに辛くなる原因。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・多重請負構造 → 各社がバッファを積んでスケジュールがきつくなる
・PMＯの横槍 → 無駄な資料の作成や報告増加
・購買部門の干渉 → 無理な価格交渉をする
・3.運用でカバーしようとするとこんなシステムが出来上がる。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・必須機能の実装漏れだらけ
・性能、使いやすさ、拡張性、可用性などの非機能要件が考慮漏れだらけ
・過密でいつも綱渡りな夜間バッチ処理
・運用でカバーは問題の先送り。
・運用は業務を中々引き取ろうとしなくなる。
・すべてのシステムプロジェクト共通の共通リザーブ予算を用意しておく。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・ユーザーとベンダーとの契約は要件定義とそれ以降で別にしないと要件が膨らんでベンダーは痛い目を見る。
・当該年度予算でどうにかしようとしない。
・プロジェクトに参画しているベンダー各社全員がバッファを積まないスケジュールを一旦引いて最低限必要なバッファを積み直す。そこから適切なスケジュールに調整する。
— えーこ🌗 (@pm_poupe) 2018年10月19日
・PMは信頼できる人でないと本音で話してもらえない。
・PMは以下の情報はいち早く共有する。
— えーこ🌗 (@pm_poupe) 2018年10月22日
・方針の変更
・スケジュールの変更
・要件の変更
・トラブル情報、インシデント情報
・人は情報を与えられないと疎外感を感じる生き物。
・抜け、漏れの発生地図。
— えーこ🌗 (@pm_poupe) 2018年10月22日
1.隠れたステークホルダーを洗い出しきれてない/本当のステークホルダーに聞いていない
2.要件を言語化しきれていない
3.後送り体質&運用丸投げ
4.有識者がいない
5.火吹きの経験が生かされない
https://t.co/AvgMy2BHpv屋のプレゼンス（地位）が低い
・エンドユーザーを巻き込むための4つのポイント
— えーこ🌗 (@pm_poupe) 2018年10月22日
・プロジェクトメンバーとして参画してもらう
・部分参画なども検討
・巻き込む相手がどういった人か確認
・日頃から業務部門と接点を作る
・時にはトップダウンも大事
— えーこ🌗 (@pm_poupe) 2018年10月22日
・インタビューの専門家を読んでユーザーにヒアリング
・業務のやり方を張り付いて見るシャドーイングを実践
・運用者を上流工程から参画させる→運用担当者の主体性も変わる
・非機能要件も忘れずに
— えーこ🌗 (@pm_poupe) 2018年10月22日
・リリース後に振り返り会をやってシステム機能の評価、非機能評価などを行うことでノウハウを貯める→PMOがやるとよい
・二度とベンダーから信頼されなくなるNG行為トップ10
— えーこ🌗 (@pm_poupe) 2018年10月22日
①仕様凍結後に平然と要件追加
②要件追加したのに納期変更・予算追加は認めない
③追加機能が完成するまでお金を払おうとしない
④金額をたたく、増員を認めない
⑤「コストを下げろ。方法はあなた達で考えて。」
⑥コストを削った割に、トラブルがあると「お前らのせいだ」
— えーこ🌗 (@pm_poupe) 2018年10月22日
⑦そもそも、トラブルのないシステムを求める
⑧とにかく相見積もり、なんでもかんでもコンペ
⑨決めない
⑩情報中抜き、提案泥棒
・ITシロウトだから、が蔓延した理由
— えーこ🌗 (@pm_poupe) 2018年10月22日
①ユーザー企業の立場が強い
②ユーザー企業におけるシステム部門のプレゼンスが低い
③ベンダーがユーザーをマネジメントできない
・ユーザーが直接ベンダーとやり取りする時代になっている
— えーこ🌗 (@pm_poupe) 2018年10月22日
・シロウトでも知っておくべき5つのポイント
①RFPの進め方
②プロジェクトマネジメント
③ITサービスマネジメント
④多重請負構造
⑤技術トレンド・ソリューションのトレンド
・なんでもベンダーや情報システム部門が肩代わりしない
— えーこ🌗 (@pm_poupe) 2018年10月22日
・ユーザーのわがままをなんでも聞かず、リスクを明示して毅然と断る
・IT人材不足が危惧される近い将来、めんどくさくてリスクの高いお客はベンダーからそっぽを向かれる
・火吹きプロジェクトがなくならない原因
— えーこ🌗 (@pm_poupe) 2018年10月22日
1.俺ら、ITシロウトだから！
①そもそもRFPがイケてない
・要件が網羅されてない
・業務フローがわからない などなと
②購買部門が無下に価格交渉・コストだけでベンダーを選ぶ
— えーこ🌗 (@pm_poupe) 2018年10月22日
③変ななわばり意識
ベンダーが増えすぎて各社の調整をしないユーザー、グレーゾーンの発生
④ユーザー部門が勝手にシステムを立てる
2.マネジメントがイケてない
— えーこ🌗 (@pm_poupe) 2018年10月22日
①プロジェクトをまとめられる人がいない
②ユーザーがマネジメントを放棄する（当事者意識がない）
③ベンダーがユーザーの要求を断れない
④仕事のやり方がバラバラ、ルールがない（開発手法、報連相のルールなど）
⑤属人化
— えーこ🌗 (@pm_poupe) 2018年10月22日
ドキュメントが一切残ってない
⑥報告地獄、報告祭り
・とにかく役割責任を明確に！
①プロジェクト計画書
②WBS
③課題管理表、インシデント管理簿
・「とりあえずRFP」はやめておく
— えーこ🌗 (@pm_poupe) 2018年10月22日
→ベンダーにも機会損失が発生する
・コストだけで考えない、そろそろ利益・付加価値重視のITを！
・プロジェクトの一体感醸成には「人間くささ」と「共通言語」が必要
・リリース後の火吹きの予防策として上流工程で机上運用テストをやる
— えーこ🌗 (@pm_poupe) 2018年10月22日
・ユーザーもベンダーもやる気の下がるメンバーはアサインせず、なるべくメンバー交代は発生させない
・トラブルが発生したとしても「見える化」と「言える化」で情報共有を
— えーこ🌗 (@pm_poupe) 2018年10月22日
・現場がすでに疲弊するのに、さらに火に油を注ぐような細かなトラブル報告を現場に求めない
・ユーザーはベンダーとのコミュニケーションを大切に、相手も人間
— えーこ🌗 (@pm_poupe) 2018年10月22日
・ユーザーとベンダー間で交換留学してみるのも手
・ITは大変なのにリスペクトがなくプレゼンスが低い理由
— えーこ🌗 (@pm_poupe) 2018年10月22日
①ユーザーが無下に価格交渉してくる
②経営者が労働環境を改善しない
③ユーザーのベンダーに対するリスペクトがない
④ロールモデルがない
→特に運用職種の人に聞いても答えが返ってこない
・内外からシステム部門を知ってもらうことでITのブランディングを行い、人材が集まるようにする
— えーこ🌗 (@pm_poupe) 2018年10月22日
→これからの労働人口減少社会では人を集めることが大切
・シャドーITを引き取る
感想
ツイッターにも書いたのですが、これ。
・「想像してみてください。あなたのそのワガママ。あなたが我慢すれば、何人の下請けこ人たちとその家族の笑顔が守られるかを」
— えーこ🌗 (@pm_poupe) 2018年10月22日
→本当にこれだよな〜。お客様は神様気質がユーザーに蔓延ってて、システム屋を同じ人間と思ってないところがある。
#システムの問題地図 読了。
— えーこ🌗 (@pm_poupe) 2018年10月22日
同じことが何回も出てきてもっとまとめようがあるのでは？と思いつつも、あるあるの問題ばっかりで頷いてばかりの本だった。
ユーザーに届くといいなぁ…（遠い目）
システム屋関係なく、自分の身の回りの親しくないサービス提供者（コンビニ店員とかいろいろ）に同じ人間として接せられない人がいるのはなんでだろう…？
— えーこ🌗 (@pm_poupe) 2018年10月22日
様々な問題がここに集約されてる気がする。お互い人間として尊重できれば起きない問題がたくさん。
お金払ってるから偉い、お客様だからは違うんだよなぁ。
— えーこ🌗 (@pm_poupe) 2018年10月22日
自分ができないことに対して対価を払ってるわけで、お金を払ってるから客が偉いわけではない。
各種サービスを提供できるコンビニがなければどれだけ手間と時間が掛かるか、と。
なんだろうね、日本のお客体質。
2次受けベンダーとか、さらに下を経験したけどまーひどいもんだった。
なーんもわかってない某Nのつく1次受け様からも人間扱いされず、パワハラで何人もプロジェクトからいなくなったよ…
お金を払ってる方がえらい、っていう感覚、みんなやめるべきだと思うんだ…
そういった意味でもこの本はエンドユーザーに読んでもらいたいのよね…
そして多重請負構造早く滅べ！！
あとプロジェクトの管理側にも耳が痛いこと言われてましたね…
十分注意してるつもりだけど、さらに気をつけねば…
ベンダーにもユーザーの言うことなんでも聞きすぎという悪い点があるので、ベンダーとしてもちょっとずつでもやり方変えていかないとだよね。
確かどこかのシステム会社が社員の働き方を重視して仕事を受けてうまくいったと聞いたので、全体に広まるべき！
何回も同じ問題点や理由が出てきて、結局は同じ問題にたどり着くんじゃん？もっとうまくまとめられたんじゃ？と思う本ではあるものの、システム屋としてはあるあるすぎて涙なしには読めない本なので気になる方はぜひ。
