図解 鬼速PDCA
[購入動機]
これまで何となく目標設定をし、あまりしっかりとした計画も立てず、思いつきで行動して、きちんと振り返りなども行っておりませんでした。
様々なビジネス書などを読んでいくうちに、圧倒的な自己成長をし、成果を出していくには、体系化されたフレームワークに沿ってしっかり計画を立てた上で、振り返りを行っていく必要があると感じておりました。
そこで、PDCAという確立されたフレームワークを用い、それに沿って行動することで、成長し、転職先で結果を出したいと思い本書を購入しました。
[気づき]
本書は”図解”というタイトルにある通り、図が豊富に使用されており、理解を促進することができた。
また、各章ごとに、PDCAを進める上での基本事項（実施すべきこと）と、応用編、そして最終項にて、全体の振り返りという構成でまとめられており、非常にわかりやすかった。
また、ただフレームワークの説明をするだけでなく、具体例も交えて記載されていたので、イメージがしやすかった。
本書を読んだことで、PDCAの具体的な進め方を理解することができたのは勿論のこと、以下の内容を知ることができたのは、私にとって大きな収穫であった。
・課題を洗い出す際は、理想像を掲げ、何ができているべきかを考えることがコツ。
※どうやったら理想の上司になれるかではなく、理想の上司とは？と考える。
・課題を発見する時は、Why（なぜできない？/できた？）で5階層まで分解。
・解決案を発見する時は、How（どうやって構成されてる？/達成する？）で分解。
・MECEで因数分解する場合、プロセスで分解すると確実。（最低1段目のみ実施）
・やり方やスキルといった”質”だけでなく、時間効率を意識した”量”も意識する。
・Doをtodo（メモ帳にかけるレベル）に落とし込むことで、行動力がアップする。
・日々の習慣（笑顔で挨拶する）なども、日々事項評価することで数値評価が可能。
・行動指標KDIが未達の場合、時間をかけられず未達か、時間をかけたが未達かで
切り分け、具体的になぜできなかったか深掘りする。
・KPI未達の場合、KPIとそれに対する解決案、解決案とそれに対するDo、Doに対するKDIが連動していない
・KGI未達の場合、KGIとそれに対する課題、課題とそれに対するKPIが連動していない
[今後]
・2019年度の目標設定をし、本書に沿ってしっかりとPDCAを回して仕事で成果を出したいと思います。
知らないからできる 既成概念を覆す「0(ゼロ)ベース思考」
[購入動機]
2018年11月に転職をし、新たな職場で働き出したが、前職で得た知識や経験をベースに考える場面が多々あります。それは、悪いことではなく、これまで培ってきた知識や経験を活かすことは重要ではあると思っています。ただし、これまでと全く違う考え方やルールを受け入れ、また、これまでの既成概念に囚われない思考が必要だと思っています。
そこで、プロジェクトを推進する上で、マネジメントする上で、既成概念を覆す思考法について、理解を得たく本書を購入しました。
[気づき]
本書では一見冴えない中年おじさんケイと、就職して2年経過した若手女性サラが、数々の困に立ち向かい、これまでの考え方や概念を覆し、プロジェクトを成功に導く物語で、実際にあった話をベースに、小説として描き下ろしています。
進捗が大幅に遅れているPJにおいては、メンバー全員を招集し、メンバー自らがPJ目標を設定するようファシリテートすることで、メンバーの自覚とモチベーションを上げることに始まり、タスクに関しても、電車に乗って目的地に向かう前に後ろから逆算して準備や家を出る時間などの予定を立てるように、前方積み上げるのではなく、逆算してタスクを洗い出すことで、納期に間に合うWBSを組み立て直すことをします。
また、進捗会議においては、動かしようのない過去の実績にとらわれるのはなく、動かすことができる未来に対し、遅れをどうリカバリしてくかに焦点をあてていきます。また、「問題ないか」と質問するのではなく、「問題があるとしたらなに？」と質問することで、問題意識をもたせる手法をとり、さらに、「何か助けられることはないか？」と質問することで、チームワークを強めるとともに、助けを求め他メンバーの主体性と責任感を作り上げていく手法を取ります。
上記は、これまで私が行っていた進捗会議とは全く異なり、簡単に思いつくようで、衝撃的な内容でした。
[今後]
上記、マネジメント手法を実践してみようと思います。
また、物語の中で、数々の困難を、嫌とは思わずむしろエキサイティングと捉え、ワクワクしながらチャレンジしていく姿勢は、非常に刺激となりました。
自身の仕事においても、これまで経験したことないことや、様々な困難が降りかかることもあるかと思いますが、本書の内容を思い出し、困難に対しても、楽しみながらチャレンジしていこうと思います。
イラスト図解式 この一冊で全部わかるWeb技術の基本
[購入動機]
これまで、ベンダーSEとして約6年半、小売業のお客様向けにシステム構築を行っていました。店舗で利用するシステムで、担当したシステムはすべてWebでした。しかし、設計～結合テストまでを協力会社に発注し、私の仕事としては、、プロジェクトマネジメントが中心だったので、正直、Webの基本的な知識を体系的には理解しておりませんでした。（お恥ずかしい）
今回、ユーザSEとして転職したことで、現状は、事業部の方々が企画したサービスに対し、技術面での支援を行うことがミッションとなっている。そして、転職先
でスマホアプリとWebアプリのサービスの要件定義工程から参画することなりました。しかし、Http通信やCookie, セッション、OAuthやOpenIDについて、何となくの浅い理解しかなく、これはまずいと思い、改めて、体型的にWeb技術を体系的に、広く
学びたいと思い、本書を購入しました。
[気づき]
この本は、見開き2ページが、各技術要素が完結しており、説明文と図解を用いて折、非常に読みや好く、理解しやすかったです。
これまで、単語、単語で理解していた技術が、一連のWeb技術として繋がりを理解でき、体型化して整理できたことは、本書を読んで良かったと思います。
[今後]
この本での知識をベースに、個々の技術を深掘りして理解しようと思います。
具体的な方法としては、以下。
・ネットで調べる。
・本を購入する。
※2019年1月末に、翔泳社からOAuthに関する本が発売されるので、チェックしようと思います。
だまし絵を描かないための 要件定義のセオリー
[購入動機]
転職後、ユーザSEとして、業務要件定義を行う事となったため、下記の点について整理したく、購入しました。
・業務要件定義の進め方
・要件定義工程で必要とされる成果物
また、次工程以降、前工程への手戻りを極力抑えられるよう、要件定義工程で必要な検討事項を、体系的に漏れなく整理する必要があると考えています。
[要約]
要件定義とは、システムで実現すべき制約を明確にし、「要件」として確定すること。
具体的には、①ToBeモデルを作成し、②Asisを分析して、制約を加味して、③新ToBeモデルを作成すること。
要件定義の目的は、以下の２点。
・構築すべき仕様（データ、プロセス、機能）を明確にする。
・要件を設計へ移行可能な状態にする。
要件定義を開始する前に実施しておくこと。
１．システム化企画/業務分析
①目的、対象、効果の明確化
②ToBeモデルの作成
・プロセスの概要フロー、概念データモデルの作成
③現状分析
(1)非機能要件
(2)データ構造
(3)コード体系
(4)業務フロー
２．要求の明確化
①各要求の一覧化
②要求のブレークダウン
ビジネス要求→業務要求→システム要求
③要求の精査
※技術的困難、コスト、納期の制約により実現が難しい要求を洗い出す
④ToBeモデルのブラッシュアップ
要件定義にて実施すること。
①要求範囲の明確化
・各要求をシステム要件へと整理。
※新ToBeモデル（プロセスモデル、データモデル、機能、UI）を想定できる要件
②システム全体図の作成
・外部連携の明確化
③業務フローの作成
・トップダウンアプローチにて骨組みを明確化し、ボトムアップアプローチで肉付けする
④業務プロセス要件の明確化
・各業務プロセスの5W2Hをを定義する。
※ここでいう業務プロセスは、最下層の業務フローを構成する要素（1つのアイコン）
⑤UI機能要件の明確化
・業務プロセス定義の5W2Hを実現するための機能を明確にする。
また、UIは、業務プロセス定義を支援する機能を成立させるために存在する。
・UIにて、データ操作（CRUD)を明確にする。
※バッチは例外として、業務プロセスとして定義されているか確認する。
・ユーザシナリオをユースケースの記述形式で書く。
⑥データの明確化
・概念データモデルから論理データモデルを作成。
※概念データモデル…ER図
論理データモデル…ER図の各エンティティの属性を明確にし、正規化する。
※属性は主要なものだけでもOK
⑦CRUDマトリクスの作成
・エンティティのライフサイクルを確認する。
・プロセス・機能に関して、データ操作漏れが内科確認する。
⑧非機能要件の定義
・操作性、信頼性、性能、保守の容易性、セキュリティ要件、移行要件、運用要件の定義。
※非機能要件は、業務プロセスからも洗い出す。
⑨システムインフラアーキテクチャの定義
・システム形態（Web、クラサバ、スマホアプリ…）の定義
・サーバの設置場所（オンプレ、クラウド（Iaas, Paas, SaaSなど）…）の定義
・分散方針の定義
・移行要件、運用要件の定義
⑩アプリケーションアーキテクチャの定義
・標準化（画面UI, 画面遷移、業務フロー表記、業務プロセス5W2H、データモデル表記、PG言語、通信プロトコル、排他制御、ログ）の定義
※業務プロセスは、ビジネスの動的側面で、データモデルはビジネスの静的側面。
要件定義にて定義した内容の妥当性確認および合意形成
(1)妥当性確認
・要求から要件として整理された各要件の妥当性確認
・システム要件に基づき、機能/非機能要件が適切に定義されているか。
・機能/非機能要件を満たすアーキテクチャとなっているか。
・業務要件を満たすToBe業務フロー及びプロセス定義（プロセスモデル）となっているか。
(2)合意形成
・要件化されなかった先送り事項となった要求の明確化および、ビジネス要件、業務要件への影響の把握。
・ビジネス要件→経営層、ビジネス責任者。業務要件→ビジネス責任者、担当者。システム要件→担当者。への合意形成。
[気づき]
本書では、エンターブライズ、コンシューマ向けの2タイプの形態に対して、また、新規、カスタマイズの側面から、要件定義の進め方および必要となる成果物について述べられたいた。
前半は、要件定義とは何であるか、なぜ必要なのか、どのように進めればいいのかといったことについて、概念的な内容で著者の考えが述べられており、しっかり読み込まないと、理解が難しいと感じたが、じっくり読むことで、頭の中を整理することができた。中盤あたりから、業務定義で具体的に何をするかが述べられており、具体的な進め方および成果物をイメージすることができ、前半で述べられていた筆者の考えを、より深く、理解することができた。
私はこれまで、エンタープライズ領域において、既存の業務フローが存在するなかで、一部の業務を見直す、あるいは追加するといった要件定義しか経験したことがなかった。そのため、要件定義では、業務フロー、要件一覧、非機能要件一覧を作成すればOKという認識でいました。
しかし、本書を読んだことで、超上流工程から始まり、要件定義工程にて必要となる考え方を理解し、整理することができた。
特に、これまでUI工程にて定義すれば良いと考えていたデータモデルの設計についても、安定的なビジネスに必要不可欠な要素で、ここを早期に定義することで、後々の手戻りも抑えることができる理解できた。さらに、苦手であった、非機能要件についても、業務プロセスモデルから洗い出すことができるということや、業務プロセスを5W2Hで整理することで、業務プロセスを実現可能かという観点で機能を洗い出せ、また、機能を成立させるUIを整理することができると知ることができた。
[今後]
現在取り組んでいる、モバイルアプリ開発案件において、以下のことを実施する。
・プロセス定義（各プロセスの5W2Hの明確化）
・論理データモデルの作成
・CRUD図の作成（データライフサイクルを意識）
・非機能要件の定義（業務プロセスからの洗い出し）
・インフラ、アプリケーションアーキテクチャの定義
（
