無料マンガ・ラノベなど、豊富なラインナップで201万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで201万冊以上配信中！
※本書は2009年に発行された書籍の電子版になります。
【業務システム開発のNo.1取扱説明書！】
SEの仕事の成否を分けるのは、コミュニケーションとマネジメントだった！ 業務システム開発の本質は「人」にあるということをいち早く見抜き、20年以上にわたって開発プロジェクトを次々に成功させてきた著者が、その成功の秘密を公開する、SE必読の書。続編『SEの教科書2』とあわせて改訂・再校正した完全版。
■こんな方におすすめ
・これからSEになろうと考えている大学生
・SEに転職しようと考えている人
・SEになりたての人
・SEとして楽しく仕事をしていきたい人
■目次
●第一部 成功するSEの考え方、仕事の進め方
第1章 SEの仕事は「人」が9割
第2章 失敗の原因はコミュニケーション不足
第3章 マネジメントが成否の鍵
第4章 コミュニケーション重視の会議術【準備編】
第5章 コミュニケーション重視の会議術【実践編】
第6章 プロジェクト初期段階の仕事術
第7章 成果物作成の仕事術
第8章 顧客業務分析の仕事術
第9章 設計・実装・テストの仕事術
第10章 プロジェクト運営の仕事術
第11章 業務システム開発は「伝言ゲーム」
●第二部 成功するSEのプロジェクト計画・運営術
第12章 名ばかりプロジェクトマネジメント
第13章 誤解がプロジェクトを破綻させる
第14章 上流工程はすべて計画活動
第15章 本当の計画、名ばかりの計画
第16章 ネットワーク図による計画作成術（アナログ式）
第17章 ネットワーク図による計画作成術（デジタル式）
第18章 ネットワーク図による計画の最適化
第19章 IT業界が日本を救う
■著者プロフィール
深沢隆司（ふかさわ・たかし）：(株）イマジンスパーク代表取締役。陸上自衛隊少年工科学校第25期生。PMP。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後、SE としてソフトウェア開発に携わり、一部上場企業や官庁での基幹システム開発等で仕様策定、プロジェクトマネジメントに従事。独自の手法で成功に導く。著書に、『デスマーチよ！ さようなら！』『いちばんやさしいPMBOK の本』（いずれも技術評論社）、『ベースラインで成功する プロジェクトマネジメント』（日本実業出版社）など多数。
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
確かに、そんな経験あるある、という内容が多く、膝を打つ場面もあり、とても読みやすい物でした。SEを3,4年やっている人にはうってつけかも。
特に、「成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない」という部分はとても共感します。自分も、これまでの業務経験の中で、そういうPMを複数見てきたので。
また、当然の事ではあるけど、「顧客に提供するのは、システムではなく、システムを使った結果のサービスである。」という意識は大切だと思う。
究極のところ、顧客の立場にたつって事だけど。
□SE/PMとは
使う側と作る側のコミュニケーションの橋渡しがSE/PM。
SE/PMの仕事は、コミュニケーションが全て。
PMは、成果物と、プロジェクトの２つを作らないといけない。
プロジェクトを作る=プロジェクトを成功させる。
成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない。
プロジェクトの成功=プロジェクトのステークホルダ全員が「よかった」と思える状態。
□顧客とは
顧客に提供するのは、システムではなく、システムを使った結果のサービスである。
プロジェクト憲章の時点では、「システム」という単語を使わず、システムを使い続ける事に
よって顧客が得られる「利益」を定義する。
そしてその利益は、費用対効果が無いといけない。
□プロジェクトに失敗する原因
目標達成のために必要な情報を、知らないままor伝えないままにする。
→その原因は、
・知らないと言えない
・知らない事をばかにする、怒る
・説明を面倒臭がる
→その解決策は、
相互に理解した事を確認する。
自分や相手のポジション、知らない事、知っている事を把握する。
□仕様の策定方法
細かい所は、後から問題になってきて、しかもユーザーの不満をうみやすい。
細かいだけに、後から直しずらい。
→最初から詳細な仕様を作る。
(それが無駄にならない事が確認できた時点で)
委託契約の場合、手間がかからないほど利益が多いので、なぁなぁにしてしまいがち。
□コミュニケーションの基本
明るく話す！！
詳細に話す
事前に練習/レビューする。
□会議の実践術
・ホワイトボード活用法
→収集がつかなくなった時に、ホワイトボードに向かい、意見のありそうな人に、何を書きましょうか、と聞く！
すると、自然と話しが進んで行く。
・議事録
その場で作成し、声に出して読み上げる。
会議=プレゼンである。
最初に目的があって、その目的の方向へ引っ張っていく事。
□プロジェクト初期段階の工夫
最初のコンタクト時に、質問シートを渡そう！
・案件の目的
・最も求められている事
・別案件での苦い経験
・心配事
・組織構成
・現場見学の可否
・資料提供の可否
業務内容を、顧客よりも深く理解する事！
顧客業務分析
設計書の前段階の文書。要件確認よりも前。
最も重要な工程。徹底的に確認する。
→できれば、業務の現場を見る。実際に作業を行う。
顧客の放つ、用語の意味する内容を、詳細に理解する。
業務分析結果を、顧客にレビューしてもらう。
業務内の、今回の要求のスコープを明確にする。
顧客には、夢も含めて全てを話してもらい、実現可否は要相談とする。
プロトタイプを作る目的
・見せた時のリアクションを見る！
・開発側の理解を深める
スケジューリングのコツ
スケジュール最適化を行うタイミングをスケジュールする。
変更管理方針を、はじめから確定しておく。
□プロジェクト運営中の問題
責任追及が始まったら、プロジェクトは破綻する。
実作業者が、正しい行動ではなく、「怒られない」ための行動をしてしまうのは、より上位の人間の責任。
皆が同じ程度に悪い状況だから、自分の状況も許される、という意識がプロジェクト内に芽生えると、最悪の信号。
Posted by ブクログ
プロジェクトが上手くいくために、できることは全てやる
【感想】
SEとして成果を上げてきた著者による、SEの仕事術についてまとめた話。書いてあることはまっとうなことばかりなので、納得感はある。現実的なSEの問題で考えると「いかに限られた時間・リソースで要件定義、設計を終わらせるか」という問題に帰着してくることが多い。時間をかけて、丁寧にやれば対象のプロジェクトは上手くいくことが多いが、実際はそんなに余裕がないことが多い。逆に言えば、「当然やっておくべきこと」をしっかり実践できていれば、相応の成果が出やすいのがSEの仕事ともいえる。とりわけ創造性や発想力が必要な業務は少ないからだ。本書を読みながら、いかに当たり前のことを、当たり前にやっていけるチーム作り・部内統制を創っていくかが課題に感じた。
【本書を読みながら気になった記述・コト】
■分からないコト、ちょっとでも疑問に思うことは顧客にきちんと聞く
■「誰がやるべきことなのか」というコトにこだわらず、プロジェクトの成功のためにやった方がいいことは率先して行う
Posted by ブクログ
「業務システム」の開発について
基本的なことを広く書いている。
良い点は、「IT」の個別要素技術云々ではなく、
作りに入るまえの「業務システム」のデザイン部分が書いてある点。
重要だと理解してたけど、改めて言及してもらった、
という部分は以下。
・顧客業務の徹底理解をスタートダッシュで行う。
徐々にとか、設計レビュー時に説明されてる、とか、
やっているとあらゆる面で差が出る。
・顧客業務の理解について承認を得る。
・前提条件は自分で確認する
→PMBOKの「リスク特定プロセス」のツールと技法にある
「前提条件分析」
・前提条件は確定要素、リスクは不確定要素
・どんなに簡単でも可能な限り早く具体的実装を行い判断
・バーチャートよりもプロジェクト・ネットワーク図
（PMBOKでもこっちを利用）
・失敗PJの根源は、計画や計画活動に対する理解不足
※アプリの閲覧環境は最新バージョンのものです。
