白川克のレビュー一覧

会社のＩＴはエンジニアに任せるな！

自分が普段の会社でもやもやと不安に思っていたことが全て言語化されていた。
・システムとはツールではなくプラント型であり経営目線で見られるべきものである。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

教科書というと通りいっぺんの事しか書いてない印象がある。また、外資系コンサルティング会社の人が書くと、やたらと横文字のコンセプトを多用したあるべき論になっていることも多い気がする。
これは、カッコつけた感じはせず、手触り感のある表現を使ってわかりやすく、しかし網羅的に書かれている。コレを読んで、これなら大したことない、自分たちでもできる、と思われることも多そうだが、できないんだなぁ、コレが…

会社のＩＴはエンジニアに任せるな！

会社でITを有効活用する、ITプロジェクトを成功させる、というのは非常に難しいことだが、それに対するアプローチや考え方が書かれていてとても面白い。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

業務改革プロジェクトの立ち上げ方を丁寧に記述した本。理論的な整理と、実体験に基づく地に足がついた筆致のバランスが素晴らしい。「業務改革」というほど大袈裟でなくとも、なんらかのチェンジマネジメントが必要な人は読むべき一冊

会社のＩＴはエンジニアに任せるな！

基幹システムの刷新を経営層に提案する際に費用対効果がどうしても出せずに悩んでいたところ、本書に出会いました。
結論から言うと、まさにこうした悩みに応えてくれる内容が詰まっており、大げさではなく先の見えない道に一筋の光明を見出した思いでした。

IT部門の人間にとって、経営層や業務部門のITに関する誤解や理解不足をひとつひとつ「ほぐしていく」作業は非常に骨の折れるものですが、本書で紹介されている「プラント型IT」「ツール型IT」という分類を念頭において会話をすることで、相手の課題解決に本当に必要なITが何なのか掘り下げることが可能となります。
「あ、この人（部署）はいまツール型ITの話をしているんだな」といった具合です。

IT部門のあり方に関する考査も同様で、当面は維持発展型でいくのかそれとも新事業創出型を目指すのか、現状の認識と今後の方向性を考える際に参考になります。

「熱海の旅館」や「遷宮」など、分かりやすいたとえ話が全体的に散りばめられています。経営層と話すときにフレーズをそのまま引用できると言っても過言ではありません。

最後に、エンジニアの力量を生かすも殺すもその技術の「使い方」次第、というのが私の考え方ですが、本書に書かれているとおり、すべては経営層の覚悟と優れたITリーダーが生まれるか否かにかかっていると改めて実感しました。

会社のＩＴはエンジニアに任せるな！

確かに、世の中のふつうの会社では、ITなしの仕事は、もう考えられないはず。単なる経理処理や給与計算だけにとどまらず、「プラント型IT」という言葉のとおり、会社のノウハウ、ビジネスロジックが、ITにエンベッデドされているのだが、経営学の普通のテキストは、めったにそんなことを書いていない。
この本は、そういうところを明快に示している。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

プロジェクト管理をどう行えば良いのか。現場の人が対応できるように業務改革の実例を紹介しながら、書かれていました。

プロジェクトの目的、目標が実現可能なように、著者たちが実際に使ったツールが公開されていたのも良かったです。

リーダーが育つ変革プロジェクトの教科書

プロジェクトを進め方よりも、プロジェクトの中で如何に人材を育ててプロジェクトを成功させるかに重心を置いた書籍。プロジェクトが終了した後、コンサル会社は離れてもその会社のプロジェクトは続く、一旦終わってもまた発生する。自走していくためには自社の人材を育てることが必須、むしろ自社の業務をより詳しく知っている人間がプロジェクトの進め方にも精通しているのであれば最強。

具体的な育成テクニックもあるのだが重要なのは土台にしっかりとした方法論があり、それをベースにして初めて育成ができると言うこと。著者も書かれていたことだが、方法論が明確化されていないのに育てと言われても何を基準にして良いかわからない。プロジェクトスキルに関わらず、外部に依頼するのではなく自社の人材が持つスキルを方法論として消化させることが人材育成の基本。それを怠って「最近の若者は〜」というのは確かに違うと感じる。

人材育成に重心を置いているとは言ってもプロジェクトを成功させるコツはふんだんに盛り込まれている。常々コンサル側がヒアリングや資料作成を必死にやるだけではダメだと感じていた。しっかり顧客にも当事者意識を持ってもらい、発言を行い自分たちで未来を描く状態にならなければコンサル側の自己満足で終わってしまう。そのために顧客の学びのモチベーションを上げるなどのテクニックは非常に重要。

育成させようとは考えず（あまり意識せず）、まずはプロジェクトを成功させるための顧客を巻き込むスキルという理解で実践で試していきたい。結果としてコンサル側も顧客側もスキルが上がっていくのが好ましい

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

•業務改革でなくても、規模の大小にかかわらず、プロジェクトと名のつかないものでも、最初に読んでおきたい一冊
(いくつか類似本を読んできからの感想で、最初の一冊だと違っていたかも)
•要再読

システムを作らせる技術 エンジニアではないあなたへ

「システムを作らせ」ているという事に携わっていると言う意識のある人々、全員にとっての必読書では？
何がどのような形でいつまでに必要なのか。を決めることが何よりも大事。・・・そして何よりも難しい、というか骨が折れるので、なかなか出来ない。


以下、おわりに　より引用
"世の中には「オレが欲しいシステムをアイツらに作らせればいいんだ」と思っている人々が厳然として存在しているからです。皮肉なことにそういう人々がいくらカネを払っても、「システムを作らせる」という態度のままでは、システムをうまく作ってもらえない(これはシステム構築プロジェクトに潜む最大のパラドクスかもしれない)。"

システムを作らせる技術 エンジニアではないあなたへ

システムを作らせる技術
A章作る前に知っておくべきこと
・関係者。経営陣、業務部門、PLが作らせる人。IT部門とそれに紐づくベンダーが作る人。
・why？→how？→whatでストーリーを納得させる。例）工場ごとにバラバラな業務を統合し、一つの会社として運営すべき→統合後の業務プロセスはこうあるべき→そのためにこういうシステムを作ろう
・whatから考えるのでなく、whyから考える。

B章プロジェクト全体の進め方
・メンバー間の意識を合わせる（C章）
・今の仕組みを調べる。ここまでがwhy（D章）
・howにあたる3つを行う。ビジョンを明らかに、そこに到達するための施策を練る、施策群をまとめて1つの計画立案（E章）
・どんなシステムが必要か（F〜M章）
・ベンダー選定（N〜R章）
・プロトタイプ検証（S章）
・システム設計やデザイン（T〜W章）
・切替作業（X章）

C章 ゴール(Why)を明らかにする
・良いプロジェクトゴールづくりの4つのコツ
以降の工程で使えるゴールにせよ
地に足のついたゴールにせよ
何のためのプロジェクトかゴールやコンセプトに込めよ
ゴールのわかりやすさにこだわれ

D章 現状の棚卸をする
・今のシステムの棚卸しを、スイムレーンチャートわタスク一覧表、全体システム構成図などなどから把握

E章 将来像(How)を明らかにする
・システムが変わったらどういう絵姿になっているか？という将来像を描く
・変化点を必ず書き出し、メインフローや概要から取り掛かる

F章 システム要求(What)を求めるプロセス
・要求定義はシステムを作らせる人が求めることを明確にすること。要件定義はシステムを作る人が実装すべき機能を明確にすること。
・網羅性がない、予算オーバーになる、立場が違えばシステムに求めるものが違うなどから、要求定義は難しい
・要求定義の成果物。
FM（ファンクショナリティ・マトリクス）H章で。
非機能要求定義書（M章）
キーチャート

G章 機能を洗い出す7つの方法
・要件定義の第一歩はシステムに求めることについて片っ端から要求を書き出す作業。現行フローや業務フローから洗い出すのも良し。

H章 要求をFMにまとめる
・前章で洗い出した項目を整理。グループに分けて並べて…（サイトなども参考に）

I章 要求の詳細をFSに表現する
・先の項目に対して、具体的に書く。FSファンクション・スペック。
・FSに書くこと。実現したいこと、扱う情報、他の機能との関連、バリエーションやイレギュラー
・FSに書かないこと。実装方法、画面イメージ。

J章 優先順位の基準を決める
・FSにおける優先順位はビジネスベネフィット（ビジネス上どれほど価値があるか？）組織受入体制（そのシステムをどれほど使いこなせるか？）、技術的容易性の3点を3段階評価で決める。
→セルごとに色分け

K章 作る機能を決める
・先の優先度が高いレーティングの機能から作る。

L章 FMがシステム構築を成功に導く　

M章 機能以外の要求を定義する
・非機能要求おアーキテクチャの議論が必要。
・非機能要求仕様定義ガイドライン参照。
・システムアーキテクチャの３つのポイント。パッケージか手作りか、オンプレかクラウドか、複数システム間の連携

N章 パートナーの1次選定
O章 提案を依頼する
P章 パートナーを決定する
Q章 稼働までに計画を立てる
・ベンダーから全体スケジュールが展開されるが、そのまま採用するわけにはいかない。精査が必要。
マストな期限が守られているか、業務繁忙期とシステム構築のピークは重なっていないか、工程ごとのゴールが明確か、成果物をチェックするマイルストーンはあるか、各領域の整合が取れているか、各フェーズの期間バランスが適切か
・テストも誰がやるのか、何のテストか確認が必要。どの工程でも、どこまでやったら次の工程に進めるのか、工程ごとに確認を

R章 プロジェクトの投資決裁を得る
・費用対効果のシミュレーションを行う。不確実性があるので、数回行いブラッシュアップを

S章 課題を先出しする
・要求定義に相対するユーザー受入テスト。プロトタイプを使ったチェックでBPPと言われる

T章 開発チームの立ち上げ
U章 キーチャート
V章 開発中の関与
W章 データ移行
X章 いよいよ新システムの稼働

システムを作らせる技術 エンジニアではないあなたへ

･類書少ないので、参考になった。
･A～Zの章立てが分かりづらい(大きい見出しもあるが、そこは目次になっていない)
･経験と知識が足りないからか、しっくりこない点あり(ユーザー企業に代わっての作らせる側の立場で書かれているからかも)

システムを作らせる技術 エンジニアではないあなたへ

とにかく分厚くて網羅している範囲が広い。
これだけ内容があると、システム発注側でなくても役に立つ情報がある。
手元に置いて適宜見るのもいい。

システムを作らせる技術 エンジニアではないあなたへ

あのプロジェクトのときここまで丁寧にこちらからも確認していたらもっと手間減らせたなあ、、
とか、逆にお客さんのあの態度はなかったよなあ、、とか思い浮かんでいった。
これを参考に1からプロジェクトやってみたいな。

社員ファースト経営

〇本書のメッセージ
・変革をリードする人材を育成、社内に定着させるには、社員ファーストの経営が必要
・会社は社員ファースト、社員は顧客ファーストの両輪を保て
・会社として受けない仕事の指針を持つ
・仲良く喧嘩する。方針は徹底的に議論する
・原理原則で経営する
・社員ファースト経営を突き詰めると、社員は皆主体的でなければならない

〇印象に残ったフレーズ
>>「力を入れてきたこと」といっても、なぜかそこに学問を含めてはいけないようだ。聞かれたままに「こういう研究に力を入れていました」と話しはじめても、「ほら、バイトとかやってないの？その話してよ」とか、「それを勉強していて、なんでウチの会社う

>>待遇と仕事の面白さにはゆるい相関があるもの

〇本書を読んだ感想
・ファシリテーションが専門性である企業らしい経営方針
　・ファシリテーション力(マインド)が無いと、そもそも相手ファーストで意思決定を行うのは難しいと思う
　・社員のためをおもって行う施策が空回りしかねない
・私は筆者の日本語、書く文章が好き

システムを作らせる技術 エンジニアではないあなたへ

業務側として大きな案件のシステム担当になり、要件定義〜立ち上げまで経験した。利用者への理解活動や開発の手戻り（検討漏れ）に苦労し、正解はなんだろうと思っていたが、本書には正解に繋がるエッセンスが散りばめられていた。

システムを作らせる技術 エンジニアではないあなたへ

システムを構築する上で踏むべき手順が、わかりやすく書かれていると感じました。
システム改修の最中にこの本を紹介された際は読む余裕がなく、再雇用後に読むこととなりましたが、これからの業務改革にも使えそうです。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

プロジェクトの立ち上げから進め方までを、
一通り学ぶことができました。

実例も記載されており、
初学者でも理解しやすい内容でした。

プロジェクトに携わる際には、
一旦、最後まで通読し、実際の流れに合わせて、
再読する教科書のような存在です。
本のタイトル通りの内容でした。

事業計画案などの資料作成方法については、
この本では詳しく触れていないので、
また、別の本を読む必要があります。

業務改革の教科書－－成功率9割のプロが教える全ノウハウ

業務改革の手順を実務的に記載した本

手触り感のあるリアルな内容でよかった。
次は業務改革PJをやろうと思った。

システムを作らせる技術 エンジニアではないあなたへ

何らかの業務課題を解決するため、システム開発を外注する場合に必要な一連のアクティビティ（コンセプト設計から運用まで）が掴める。システム開発に取り組むチーム員と読んでおくと、認識を合わせる上で非常に有用だと感じた。