感情タグBEST3
Posted by ブクログ
マネジメントの大切さ、会議の進め方のこつ、要求分析段階はすべて計画フェーズであるなど、役に立つ話が満載。特に第二部のWBS作成は、WBS作成の参考になる本がなかなかないなか、かなり参考になった。
Posted by ブクログ
自分が飛び込んでいく世界について。
会社からの宿題。普段本を読みなれているからすぐに読めるだろうと思いきや、一言一言の意味を理解したりイメージするのに時間がかかり、期限ギリギリになってしまった。
この選書の他のシリーズを読んでみよう。
Posted by ブクログ
確かに、そんな経験あるある、という内容が多く、膝を打つ場面もあり、とても読みやすい物でした。SEを3,4年やっている人にはうってつけかも。
特に、「成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない」という部分はとても共感します。自分も、これまでの業務経験の中で、そういうPMを複数見てきたので。
また、当然の事ではあるけど、「顧客に提供するのは、システムではなく、システムを使った結果のサービスである。」という意識は大切だと思う。
究極のところ、顧客の立場にたつって事だけど。
□SE/PMとは
使う側と作る側のコミュニケーションの橋渡しがSE/PM。
SE/PMの仕事は、コミュニケーションが全て。
PMは、成果物と、プロジェクトの２つを作らないといけない。
プロジェクトを作る=プロジェクトを成功させる。
成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない。
プロジェクトの成功=プロジェクトのステークホルダ全員が「よかった」と思える状態。
□顧客とは
顧客に提供するのは、システムではなく、システムを使った結果のサービスである。
プロジェクト憲章の時点では、「システム」という単語を使わず、システムを使い続ける事に
よって顧客が得られる「利益」を定義する。
そしてその利益は、費用対効果が無いといけない。
□プロジェクトに失敗する原因
目標達成のために必要な情報を、知らないままor伝えないままにする。
→その原因は、
・知らないと言えない
・知らない事をばかにする、怒る
・説明を面倒臭がる
→その解決策は、
相互に理解した事を確認する。
自分や相手のポジション、知らない事、知っている事を把握する。
□仕様の策定方法
細かい所は、後から問題になってきて、しかもユーザーの不満をうみやすい。
細かいだけに、後から直しずらい。
→最初から詳細な仕様を作る。
(それが無駄にならない事が確認できた時点で)
委託契約の場合、手間がかからないほど利益が多いので、なぁなぁにしてしまいがち。
□コミュニケーションの基本
明るく話す！！
詳細に話す
事前に練習/レビューする。
□会議の実践術
・ホワイトボード活用法
→収集がつかなくなった時に、ホワイトボードに向かい、意見のありそうな人に、何を書きましょうか、と聞く！
すると、自然と話しが進んで行く。
・議事録
その場で作成し、声に出して読み上げる。
会議=プレゼンである。
最初に目的があって、その目的の方向へ引っ張っていく事。
□プロジェクト初期段階の工夫
最初のコンタクト時に、質問シートを渡そう！
・案件の目的
・最も求められている事
・別案件での苦い経験
・心配事
・組織構成
・現場見学の可否
・資料提供の可否
業務内容を、顧客よりも深く理解する事！
顧客業務分析
設計書の前段階の文書。要件確認よりも前。
最も重要な工程。徹底的に確認する。
→できれば、業務の現場を見る。実際に作業を行う。
顧客の放つ、用語の意味する内容を、詳細に理解する。
業務分析結果を、顧客にレビューしてもらう。
業務内の、今回の要求のスコープを明確にする。
顧客には、夢も含めて全てを話してもらい、実現可否は要相談とする。
プロトタイプを作る目的
・見せた時のリアクションを見る！
・開発側の理解を深める
スケジューリングのコツ
スケジュール最適化を行うタイミングをスケジュールする。
変更管理方針を、はじめから確定しておく。
□プロジェクト運営中の問題
責任追及が始まったら、プロジェクトは破綻する。
実作業者が、正しい行動ではなく、「怒られない」ための行動をしてしまうのは、より上位の人間の責任。
皆が同じ程度に悪い状況だから、自分の状況も許される、という意識がプロジェクト内に芽生えると、最悪の信号。
Posted by ブクログ
「業務システム」の開発について
基本的なことを広く書いている。
良い点は、「IT」の個別要素技術云々ではなく、
作りに入るまえの「業務システム」のデザイン部分が書いてある点。
重要だと理解してたけど、改めて言及してもらった、
という部分は以下。
・顧客業務の徹底理解をスタートダッシュで行う。
徐々にとか、設計レビュー時に説明されてる、とか、
やっているとあらゆる面で差が出る。
・顧客業務の理解について承認を得る。
・前提条件は自分で確認する
→PMBOKの「リスク特定プロセス」のツールと技法にある
「前提条件分析」
・前提条件は確定要素、リスクは不確定要素
・どんなに簡単でも可能な限り早く具体的実装を行い判断
・バーチャートよりもプロジェクト・ネットワーク図
（PMBOKでもこっちを利用）
・失敗PJの根源は、計画や計画活動に対する理解不足
Posted by ブクログ
プロジェクトが上手くいくために、できることは全てやる
【感想】
SEとして成果を上げてきた著者による、SEの仕事術についてまとめた話。書いてあることはまっとうなことばかりなので、納得感はある。現実的なSEの問題で考えると「いかに限られた時間・リソースで要件定義、設計を終わらせるか」という問題に帰着してくることが多い。時間をかけて、丁寧にやれば対象のプロジェクトは上手くいくことが多いが、実際はそんなに余裕がないことが多い。逆に言えば、「当然やっておくべきこと」をしっかり実践できていれば、相応の成果が出やすいのがSEの仕事ともいえる。とりわけ創造性や発想力が必要な業務は少ないからだ。本書を読みながら、いかに当たり前のことを、当たり前にやっていけるチーム作り・部内統制を創っていくかが課題に感じた。
【本書を読みながら気になった記述・コト】
■分からないコト、ちょっとでも疑問に思うことは顧客にきちんと聞く
■「誰がやるべきことなのか」というコトにこだわらず、プロジェクトの成功のためにやった方がいいことは率先して行う
Posted by ブクログ
仕事の関係で購入。
SEの仕事の進め方やシステム開発の流れが素人にも分かりやすく書かれており、仕事のイメージがつけやすかった。
しかし、図を使っての計画を立ててのプロジェクトの進め方にページを割いている割には、文章の説明がほとんどで後半は分かりづらいのは残念だ。
