一緒に仕事したくなる発注者、見捨てたくなる発注者とは？〜読書記録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日後からメンバーシップの方々にのみ公開に変更予定です。

・システムを導入する目的を忘れないように書きとめておく
・業務フロー図には、懸念事項や課題もモレなく書き込む
・システムを導入して誰が喜び、誰が困るのかも書き込む
・システム化の範囲は、効果が明確に説明できる部分に限る
・システム担当者自身が、業務をどのように改善するかという「意志」を持つ
・システム担当者となったからには、自分の思いは隅に置いて、改善の推進者になりきる

◆発注者が最低限知っておくべきこと

・システム担当者にはシステム化する対象業務の知識が必須
・発注者側の責任でとん挫したプロジェクトの賠償責任は発注者にある
・システム担当者がモチベーションを上げるには、経営者の視点でシステム導入の意味や目的を考えてみるとよい

◆ベンダ選びのポイント

・ベンダの示すプロジェクト管理項目と管理工数が十分かを見極める
・信頼できるベンダは、自社内のリスクも含めて、ユーザーと共有する
・要件の変更や追加を、ただ承諾するベンダには、プロジェクト管理義務違反の恐れがある
・ベンダの示すリスクを、まずは傾聴する

◆社内の協力を得るためのポイント

・システム担当者は、往々にしてエンドユーザーの協力が得られず孤立する
・エンドユーザーにヒアリングするときには、最低限の業務知識を得ておくこと
・難解なIT専門用語を使わない
・相手が忙しい中、時間を割いてくれていることに感謝する
・システム担当者が他部門と調整するときには、その上司がフォローと支店をする
・エンドユーザーの協力を得るには、システム開発の意義や目的について、経営トップからのメッセージングを繰り返す
・経営陣は、システム開発も社員全員の本業であるという意識づけとしくみの改革をすること

◆プロジェクトのリスクを的確に把握するためのポイント

・ベンダにリスクを開示させるために、発注者側は真摯に聞く姿勢を忘れない
・ベンダのリスクもプロジェクトのリスクと同じように、発注者側が知るべきことと認識する
・ベンダのリスクは発注者側から引っ張り出す
・定量的なプロジェクト状況やスキル評価、工数の妥当性のほか、プロジェクトに合わせて設定した評価軸でベンダのリスクを評価する

◆ベンダとのコミュニケーションのキモ

・期限までに要件を決めきれないことは日常茶飯事
・要件定義工程完了前に、「今後どうすべきか？」を改めて話し合うチェックポイント会議を開く
・ベンダへの質問に遠慮は不要。技術でも業務でもどんどん聞くべき。
そうすることで、ベンダ側の知識が醸成されることもある
・たとえパッケージソフトを使うときでも、どうしてもこだわりたい自社の調書は入れ込む
・発注者とベンダは、お互いに「自分たちのほうが損をしている」と思う程度（７：３）がちょうどいい

◆セキュリティ被害を最小限に抑えるポイント

・機密情報を扱うシステムでは、漏洩時の影響を踏まえてトリアージを行い、重大度に合わせた対策を実行できるうように準備しておく
・情報漏洩時の見舞金や補償金の相場は500円から5,000円程度をいわれる
・運用担当者にモチベーションを維持してもらうためには、必要な待遇改善を検討すべきだし、キャリアパスも定義する必要がある
・情報漏洩時には、そのシステム自体を捨てる覚悟も必要。たとえ良いシステムであっても、それに固執すると、企業の信用を損ねたり、再発を起こす可能性もある

何度も読み直す本にランクインしました。
もし私と同じ立場の人がいたら、積極的にオススメしたい本です。

（4,900字ぐらい）

▼前回の読書記録

▼読書記録の人気記事