bookmark / エンジニア

• メタ,サマリー,ディテールの3点セット
• ヒアリング力強化は構造化がポイント

• ＲＦＰ・ＳＬＡドキュメント見本提供について
• 納品されたシステムに対する効果的な検収方法
• ソフトウェアの品質を数値化して確かめる
• ソフトウェアエンジニアのためのホームページ Presented by System Creates Inc.
• 川村渇真の「知性の泉」
• 気になるシステム開発の相場［企業のIT導入］All About Japan
• ＳＥに必要なマネジメントとは？［ソフトウエアエンジニア］All About Japan
• 一語一会（２００３年５月）［ソフトウエアエンジニア］All About Japan
• 自社のビジネスのスピードにITを合わせる
• 実践！図解思考法講座

• ドメイン・エンジニアリング温故知新
• ケーススタディ〜優れた「新天地デビュー」
• 必要なIT投資を経営層に認めてもらうには
• プログラミングスキルをもっと評価すべき

• 失敗しないコンサルタント利用の秘訣
• 「社内SE」に向く人、向かない人
• 「経営計画」はレビューに始まる

• フレームワーク --
• ＠IT：UnicodeとシフトJIS -- Unicode

• ITアーキテクト
  • 複雑性の総合管理能力
  • 経済情勢は後退し、市場はエンジニアの高い給料を賄うほどには成長していないのが実状です。だからといって、自分の給料を自分で減らすのはとても困難でしょう？ まじめな話、現実的には、米国のソフトウェア開発者の過剰報酬は調整の時期に入っていると思います。ソフトウェア開発者の経験しかない人間が、年棒10万ドル以上を稼ぐなんて異常ですからね。

• “職業としてのITアーキテクト”、その実態と理想とは

• 優秀なスタッフを育てる職場環境とは

• マンネリ仕事にやる気を見いだす方法
  • 　ここで簡単にまとめてみましょう。「モチベーションを上げたい！」と正面切って考えていてもなかなか難しいものです。モチベーションとは、ある意味現在と未来の「ギャップ」が原動力になりますよね。スポーツは結果が分かりやすく、すぐにフィードバックされるので、現在（実力）と未来（イメージ）のギャップが見える。だから頑張れる。とすると、仕事にも意図的にギャップを作り出し、それを埋めるサイクルを作ってみたらどうでしょうか。
  • なるほどね。どんな目標だったらいいのかな……。
  • ゲームの勝負のように具体的な結果が見えるもの。モチベーションアップが目的なわけですから、「実際に到達できそうなもの」でしょうね。あとはできれば複数あるといいんじゃないですか。「あれはダメでもこれはできた！」といえるように。

• 情報システム部門を戦略部門化できるか

• カバレッジ

• ITスキル標準（ITSS）はエンジニアに変革を迫るか --Engineer
• ハイ・パフォーマーの“知”は、移転・共有できるか？ -- 差の正体はメソドロジ 「コンセプト（概念）」「メソッド（方法）」「プロセス（手順）」「ツール」の一連のシステム（関連する組み合わせ）
• 開発環境の整理術 -- 第1回 要求仕様に関係する落とし穴
• ソフトウェア要求の詳細な分類 -- 　ここまで、ソフトウェア要求とは、外部の視点から見て、システムが何をしなければいけないかを開発者に伝えるもので、システムの入出力、機能、機能以外の属性、設計上の制約という側面から定義されることを説明しました。システムが何をしてくれるか（What）、を決めますが、システムがどのようにそれを実現するか（How）は決めないということが大切です。
• Memory -- メモリマップ,恒久変数領域,実行コード領域,スタック領域,ヒープ領域

• コストマネジメントは「時は金なり」でうまくいく

• 特定サービス産業実態調査

• 「要求」から「コード」に至る長く険しい道

もっと安くなる、賢い見積もりの取り方 †

ハードウェアにしろソフトウェアにしろ、見積もりは決して専門家にしか理解できないものであってはならず、利用者の視点でもなされるべきである。もし、業者の見積もりが理解できないのであれば、理解できるように作成してもらうべきだろう。 †

ハードウェアにおいて利用者の視点とは、要求応答時間、同時利用人数、利用回数、データ量、故障時の復旧時間などである。CPU処理能力がどうとか、ストレージの性能がどうだとかそういった専門的な説明を聞かされても、それらが直接、利用者にどのような影響を及ぼすのか分からなければ意味がない。 †

ソフトウェアにおいて利用者の視点とは、画面・帳票・ファイルなどの外部インターフェイスである。これらの要素それぞれに難易度で重み付けをした機能数（FP：ファンクションポイント）をベースにシステムの全体規模を算出し、これに単位FP当たりの単価を乗じて金額を算定するのがファンクションポイント法と呼ばれる見積もり方法だ。利点はまさに“利用者の視点で見積もりができる”ということにある。さらに、画面・帳票・ファイルを数え上げるので、成果物の漏れや忘れを発注者・受注者の双方でチェックでき、合意のうえで発注できるので、納品時に「画面が足りない！」というようなトラブルも未然に防止できる。 †

委託契約と請負契約 †

• ところで、ファンクションポイント法は、画面・帳票・ファイルなどをベースとするため、これがある程度判明しないと見積もりができない。本来は、仕様書までを作成し見積もりを取るべきであるが、どうしても不可能な場合は、まず仕様書作成までを委託契約するのがよい。その後、画面・帳票・ファイルが明確になった時点で、ソフトウェア開発を請負契約するとよいだろう。

• 画面・帳票も分からない段階で、「一式いくら」とか「何人月」とかで一括契約してしまうのは、非常に危険である。このような見積もりでは、その妥当性を検査することも交渉することもできない。「一切信じてお任せする」ならそれでよいが、最小の投資で最大の効果を生むシステムを構築するなら、このような契約は避けたい。

• そもそも請負契約とは、最終成果物が明確になっており、それに対して対価を支払うものなので、成果物が不明な場合は契約の履行／不履行さえもあいまいになってしまう恐れがある。一方、委託契約というのは、成果物ではなく知識や労働力を対象とした契約であり、必ずしも成果物を必要としない。住宅建築で設計図の作成を建築士と委託契約し、その設計図に基づいて実際に工事するのを工務店と請負契約するのと同じだ。