一緒に仕事したくなる発注者、見捨てたくなる発注者とは？〜読書記録vol.32～

わりとこだわりの強いタイプです。
でも、これだけは決めているんです。

どれだけ他のこだわっているものがあっても、
それらを一旦置いといて、

人からオススメされた本は、必ず読み切るといういうことを。
しかも、すぐに。
即座に。

最近の私は、あまり時間に余裕がなくて。
ってか、幼児を子育てしながら時間に余裕がある人なんて、この世に存在するのだろうか。
いたら是非ともお会いしたい。

子育てしながら「時間に余裕ある」って言える人は、きっと何か素敵な時間の使い方をしているはずだ。

で、時間に余裕のない私は、
仕事仕事育児育児仕事仕事育児家事育児仕事、
みたいな生活を日々送っているんですよね。

でも、やっぱり自分のための時間が欲しいんです。
じゃぁどこかの時間を削らないと、自分のための時間を捻出できない。
仕事や育児の時間は削りたくないし、家事はこれ以上ないほど削っています。お掃除ロボに洗濯乾燥機にと色んな家電を駆使しているし、食事作りにいたっては、家電駆使を通り越してすべて外注。

これ以上、どこにスキマ時間があるのかなって、時間の棚卸をしてみたら、
通勤時間が長いことに気が付きまして。とてもとても長いんですよ。

となると、通勤時間を「しんどい時間、睡眠時間」として過ごすのではなく、「自分のための自由な時間」として過ごそうと決意したのです。

で、今はその通勤時間を「英語の勉強時間にふりきる」って決めていたんです。5月から。
こだわりつよーいタイプなんで、「一度これをやる」って決めると、変えたくないんですよね。

だからこそ、通常1~2年かかると言われているCIAも5ヶ月で合格できたと思っています。
あの5ヶ月、すべての時間をCIA勉強に振り切ったから。
仕事育児家事以外の時間はすべて。
大晦日も元旦も勉強していました。

で、5月に「3月頃までは通勤時間を英語の勉強時間にふりきる」って決めていました。

という感じで、前置きが長くなりましたが、
わりとこだわりの強いタイプです。
でも、これだけは決めているんです。

人からオススメされた本は、例えそれがどんな本であっても、必ず読み切るといういうことを。
しかも可能な限りすぐに。
即座に。
高速、いや、光速で。

ということで、超優秀な同僚からオススメされた本を読みました。というか、貸してくれました。

『システムの「外注」するときに読む本』細川義洋

システムを「外注」するときに読む本

ITコンサル＆トラブル解決のプロが教える成功率を3割から9割に上げたスキルと知識！
納期オーバー、予算オーバー、使い勝手の悪いシステム……
膨大な失敗プロジェクトから成功のポイントをあぶり出す7つのストーリー

とても参考になる本だったと同時に、
内容がストーリー仕立てになっており、とても読みやすかったです。
何より、今の業務に直結する本で、読みごたえがありました。
やっぱり、仕事に直結する本って、スムーズに読めるんですよね。
読めるというか、読む意欲がわく、というか。

借りたその日とその翌日の通勤時間で読み終え、
（私の通勤時間は本当に長いので…）
その後も何度も繰り返し読んだほどです。

「この本を読んで良かった」と心の底から思いました。
（やっぱり、強すぎるこだわりは捨てなきゃね。）

本の中では、
ベンダが逃げたり、不正があったり、情報漏洩があったりと
色々なストーリーがあって、
だからこそ読みやすかったです。
でもストーリーだけでなく、仕事に必要なティップスも多くあり、その点において、読みやすい点と参考になる点が両立している本でした！

実は今の部署に異動する時に、いくつか関連する本を読んだのですが、
今いちピンとこず。
それが、この本は抽象と具体とがどちらも書かれており、抽象的な概念を理解しつつ具体的にどう業務に落とし込むかが書かれていました。

自分で見つけ出した本よりも、
人からオススメされた本の方が、
本として良い出会いがあるなぁって改めて思いました。

読んだ本はアウトプットしてこそ定着すると言われています。
実践するのが一番ですが、まずはインプットで終わらせないために、ここにアウトプットと自身の備忘録をかねて、読書記録を残しておきます。

▼こんな人にオススメ

・営業やら経理やら、システムとは別部門から等の異動で、いきなりシステムのプロジェクトに関わることになった人
・システム開発のプロセスで何が起きているのか俯瞰したい人
・システムを外注するにあたって、自分たちにどんな役割があるのか知りたい人
・なぜ、システム開発でトラブルが起こるのか、知りたい人
・システム開発の発注者

▼一言で言うと

システムを「外注」するときに読む本です。
となると、題名そのままなので……（笑）
システム開発者としての心得、ポイントが分かりやすく詰まっている本です。

▼印象に残ったこと

色々印象に残ったことはあったので、箇条書きしていきますね。
借りていた5日間ほどで何度も繰り返し読んだのですが、自分でも買って、定期的に読み直したいなと思う本でした。はよ本屋さんに行こ。

・発注者が「お客様」から「プロジェクトメンバー」になったとき、システム開発はグッと成功に近づきます。
・発注者がシステム開発をリードする時代に入った

特にこれも印象に残りました。

Q.一緒に仕事したくなる発注者、見捨てたくなる発注者とは？

A.ベンダは発注者が決めること決めなきゃ何もしないし、プロジェクトの状況をちゃんと確認しない発注者は見捨てる。
⇒肝に銘じよう……！

その他、備忘録的にまとめていきますね。

◆システム作りは業務フロー図から

・システム担当者が最初にやるべきことは「要件定義書」、
システムと、それを使うひとの動作を決める作業のこと。
ー業務要件定義
ーシステム要件定義

社内全体の業務を俯瞰して、全体最適の視点から、業務の問題点や新しいシステムが実現することで改善される点、全社的なメリットなどがひと目でわかる資料を作成すること

ー機能要件
ー非機能要件

・要件定義は2つの「業務フロー図」を作るところから
As Is　と　To Be

・業務を行う上での懸念事項や疑問点も書く
…この段階では、システムのことは極力考えないようにする。
業務フロー図の段階でシステム化する範囲を決めちゃうと、本当はシステム化すべきじゃない業務を範囲に入れちゃったり、逆にシステム化すべき部分が未検討になったりする。

・「その他」は使わない

　▼システム化する範囲を間違えないたった1つの「判断基準」

システム化するのは、効果が明確に説明できるところだけ。
システム化する範囲は、本当にそこをコンピューターでやるべきか、何度も考えて決める。

・新システムを使う人と企業の「喜び」を表現する
社員やお客さんがどんなふうに喜ぶのか、イメージする

　▼業務フロー図を書く人に必要な「メンタリティ」

サイトを使う人全員の立場になりきって、喜びとかいらだちとかの感情を含めて全部共有しないと、本当に役に立つサービスを作ることはできない

◆要件定義で最低限確認しておくべきチェックリスト

●要件の必要性・十分生をチェックするための3ステップ
「システムの方針や業務要件が、そもそもプロジェクトの目的に合致しているか？」
１．書き出した要件を「必要か？」の目線でチェック
２．書き出した要件で「十分か？」をチェック
３．「ほかに手段はないか？」をチェック
ー本当に今回のプロジェクトでシステム化すべきことかどうか？

●１●要件は必要かつ十分であるか
●２●要件は十分に詳細化されているか
●３●業務の例外や異常を考慮しているか
●４●要件が正しく管理されているか
●５●体裁・文言

詳細は是非読んでみて下さい。
「機能要件は第三者が見ても同じ理解ができるか」と言う部分は、特になるほどな～と思いました。

・同心円状のフィーリングマップを使う

◆プロジェクトの進捗管理、リスク管理の具体例

ープロジェクトで行われる作業を5日単位の小さなタスクに分ける
ー作業開始と終了の日付
ー使用する工数の予定と成果物が書かれたWBSを使用して管理
ーリスクについては、対応策を発動する「しきい値」を決め、定期的に監視する。
ーシステム開発請負の見積もりで、プロジェクト管理工数を全体の10%と見積もる。見積りの段階で管理工数が5%を下回っていたらどこかに抜けがあるって考えた方がいい。

▼読書感想文

この本の読書感想文は、こちら。

＜覚えておきたいことたち＞

◆要件定義のポイント

★ここから先は、3日後からメンバーシップの方々にのみ公開に変更予定です。