SEの教科書 【完全版】 (技評SE選書)

著者 :
  • 技術評論社
3.56
  • (7)
  • (10)
  • (11)
  • (2)
  • (2)
本棚登録 : 130
レビュー : 12
  • Amazon.co.jp ・本 (352ページ)
  • / ISBN・EAN: 9784774140162

作品紹介・あらすじ

SEの仕事の成否を分けるのは、コミュニケーションとマネジメントだった!業務システム開発の本質は「人」にあるということをいち早く見抜き、20年以上にわたって開発プロジェクトを次々に成功させてきた著者が、その成功の秘密を公開するSE必読の書。2006年の初版発行以来、増刷に増刷を重ね、No.1マニュアルとして全国のSEから絶賛されてきた『SEの教科書』が、続編『SEの教科書2』とあわせて改訂・完全版で登場。

感想・レビュー・書評

並び替え
表示形式
表示件数
  • 良く言えば様々な観点で勉強になる。
    が、悪く言えば、まとまりやメリハリが無い。

  • SEの仕事の成否を分けるのは、コミュニケーションとマネジメントだった!業務システム開発の本質は「人」にあるということをいち早く見抜き、20年以上にわたって開発プロジェクトを次々に成功させてきた著者が、その成功の秘密を公開するSE必読の書。2006年の初版発行以来、増刷に増刷を重ね、No.1マニュアルとして全国のSEから絶賛されてきた『SEの教科書』が、続編『SEの教科書2』とあわせて改訂・完全版で登場。

  • SE本来の仕事の進め方。
    理想なんだけど、現実と離れすぎていてショックを受けてしまう。

  • 「業務システム」の開発について
    基本的なことを広く書いている。
    良い点は、「IT」の個別要素技術云々ではなく、
    作りに入るまえの「業務システム」のデザイン部分が書いてある点。

    重要だと理解してたけど、改めて言及してもらった、
    という部分は以下。

    ・顧客業務の徹底理解をスタートダッシュで行う。
     徐々にとか、設計レビュー時に説明されてる、とか、
     やっているとあらゆる面で差が出る。
    ・顧客業務の理解について承認を得る。
    ・前提条件は自分で確認する
     →PMBOKの「リスク特定プロセス」のツールと技法にある
     「前提条件分析」
    ・前提条件は確定要素、リスクは不確定要素
    ・どんなに簡単でも可能な限り早く具体的実装を行い判断
    ・バーチャートよりもプロジェクト・ネットワーク図
     (PMBOKでもこっちを利用)
    ・失敗PJの根源は、計画や計画活動に対する理解不足

  • とても為になる一冊
    コミュニケーション、マネジメント
    折衝などSEにかぎらず、ビジネス全般に応用出来る、事象が、経験を踏まえた内容で書かれている、良書です。

  • SEとして理想的な仕事の仕方が書いてあり、参考になった

  • 自分が飛び込んでいく世界について。

    会社からの宿題。普段本を読みなれているからすぐに読めるだろうと思いきや、一言一言の意味を理解したりイメージするのに時間がかかり、期限ギリギリになってしまった。
    この選書の他のシリーズを読んでみよう。

  • 仕事の関係で購入。

    SEの仕事の進め方やシステム開発の流れが素人にも分かりやすく書かれており、仕事のイメージがつけやすかった。
    しかし、図を使っての計画を立ててのプロジェクトの進め方にページを割いている割には、文章の説明がほとんどで後半は分かりづらいのは残念だ。

  • 「名ばかりプロジェクトマネジメント」が気になる

  • 確かに、そんな経験あるある、という内容が多く、膝を打つ場面もあり、とても読みやすい物でした。SEを3,4年やっている人にはうってつけかも。

    特に、「成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない」という部分はとても共感します。自分も、これまでの業務経験の中で、そういうPMを複数見てきたので。

    また、当然の事ではあるけど、「顧客に提供するのは、システムではなく、システムを使った結果のサービスである。」という意識は大切だと思う。
    究極のところ、顧客の立場にたつって事だけど。


    □SE/PMとは
    使う側と作る側のコミュニケーションの橋渡しがSE/PM。
    SE/PMの仕事は、コミュニケーションが全て。
    PMは、成果物と、プロジェクトの2つを作らないといけない。
    プロジェクトを作る=プロジェクトを成功させる。
    成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない。
    プロジェクトの成功=プロジェクトのステークホルダ全員が「よかった」と思える状態。

    □顧客とは
    顧客に提供するのは、システムではなく、システムを使った結果のサービスである。
    プロジェクト憲章の時点では、「システム」という単語を使わず、システムを使い続ける事に
    よって顧客が得られる「利益」を定義する。
    そしてその利益は、費用対効果が無いといけない。

    □プロジェクトに失敗する原因
    目標達成のために必要な情報を、知らないままor伝えないままにする。
    →その原因は、
    ・知らないと言えない
    ・知らない事をばかにする、怒る
    ・説明を面倒臭がる
    →その解決策は、
    相互に理解した事を確認する。
    自分や相手のポジション、知らない事、知っている事を把握する。

    □仕様の策定方法
    細かい所は、後から問題になってきて、しかもユーザーの不満をうみやすい。
    細かいだけに、後から直しずらい。
    →最初から詳細な仕様を作る。
    (それが無駄にならない事が確認できた時点で)
    委託契約の場合、手間がかからないほど利益が多いので、なぁなぁにしてしまいがち。

    □コミュニケーションの基本
    明るく話す!!
    詳細に話す
    事前に練習/レビューする。

    □会議の実践術
    ・ホワイトボード活用法
    →収集がつかなくなった時に、ホワイトボードに向かい、意見のありそうな人に、何を書きましょうか、と聞く!
    すると、自然と話しが進んで行く。

    ・議事録
    その場で作成し、声に出して読み上げる。

    会議=プレゼンである。
    最初に目的があって、その目的の方向へ引っ張っていく事。

    □プロジェクト初期段階の工夫
    最初のコンタクト時に、質問シートを渡そう!
    ・案件の目的
    ・最も求められている事
    ・別案件での苦い経験
    ・心配事
    ・組織構成
    ・現場見学の可否
    ・資料提供の可否
    業務内容を、顧客よりも深く理解する事!

    顧客業務分析
    設計書の前段階の文書。要件確認よりも前。
    最も重要な工程。徹底的に確認する。
    →できれば、業務の現場を見る。実際に作業を行う。
    顧客の放つ、用語の意味する内容を、詳細に理解する。
    業務分析結果を、顧客にレビューしてもらう。
    業務内の、今回の要求のスコープを明確にする。
    顧客には、夢も含めて全てを話してもらい、実現可否は要相談とする。

    プロトタイプを作る目的
    ・見せた時のリアクションを見る!
    ・開発側の理解を深める

    スケジューリングのコツ
    スケジュール最適化を行うタイミングをスケジュールする。
    変更管理方針を、はじめから確定しておく。

    □プロジェクト運営中の問題
    責任追及が始まったら、プロジェクトは破綻する。
    実作業者が、正しい行動ではなく、「怒られない」ための行動をしてしまうのは、より上位の人間の責任。
    皆が同じ程度に悪い状況だから、自分の状況も許される、という意識がプロジェクト内に芽生えると、最悪の信号。

全12件中 1 - 10件を表示

深沢隆司の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
デール カーネギ...
ブライアン カー...
ウォルター・アイ...
ウォルター・アイ...
ロバート キヨサ...
デール カーネギ...
有効な右矢印 無効な右矢印

SEの教科書 【完全版】 (技評SE選書)を本棚に登録しているひと

ツイートする