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