2005-10-01から1ヶ月間の記事一覧

災害対策グッズ

飲料水 非常食 毛布 薬 包帯 ラジオ 懐中電灯 マッチ・ライター ロウソク 携帯電話 充電器 ティッシュ ウェットティッシュ ナイフ ロープ ガムテープ 身分証明書

要求定義の基本と仕組み

この本の特徴は、経営者や部門等の利害関係者の特性に応じて要求の獲得方法を選択すべきであると論じているところ。図解入門よくわかる最新システム開発者のための要求定義の基本と仕組み (How‐nual Visual Guide Book)作者: 佐川博樹出版社/メーカー: 秀和…

要件定義の基になる資料

中長期事業計画書。 業務内部資料(業務マニュアル/業務定義書/業務フロー等)。 業務課題一覧。 現行システムがあれば、現行システムの各種資料(出力帳票/操作マニュアル/設計書/仕様書等)。 ヒアリングシート。 アンケート用紙。 打ち合わせ議事録。

要件定義の変更管理

必ず文書にすること。 変更の理由や背景が明確であること。 関係者の合意が取れていること。 他の要件との整合性が取れていること。 工数や費用を見積もり、周知すること。 技術的な裏付けを取ること。 優先度と実現する時期を確認すること。 効果を試算する…

手を抜いても仕方のないこと

http://www.h6.dion.ne.jp/~akn/pm/Forms.html でリンク切れがあったのをMIZOMIZOさんに見つけていただいた。普段なら変更した後で確認するのだが、その基本動作が抜けていたようだ。別に手を抜いたつもりはなかったのだが、慣れてくるといい加減になってし…

駄目なSE

ユーザーと話ができない。敬語も使えない。コミュニケーションを取るのが苦手。 文章が書けない。書いても意味がわからない。 設計ができない。設計書が作れない。 コンサルタント気取りで、口は達者だが、教科書的なことしか言えない。具体的な問題解決がで…

敵に回すよりも味方に付ける

相手を敵に回し、勝つことができれば、多くの利得が得られるかもしれないが、負ければ、失うものも多い。また、勝負にかけるエネルギーも相当必要であり、感じるストレスも大きい。相手とは、喧嘩をせずに、味方として共存共栄していけば、利得は少ないかも…

まず結果から考える。

何にしても、結果から考え始めると、最速で到達する道筋が見えてくる。ゴールを見ずに、闇雲に突き進むのは無駄が多く、愚かである。人に何かを説明するときも、結論から話し、後でその理由や背景について話をすれば、相手も知りたい情報が先に入り、理解が…

基本設計で行うべきこと

要件定義に基づき、システムの目的を明確にすること。 システムの範囲を明確にすること。 システムの前提条件を明確にすること。 システムのハードウェア構成、ソフトウェア構成、ネットワーク構成は、インフラ設計で行う。 サブシステムを洗い出し、アプリ…

早寝早起き

早寝早起きというと、年寄りじみているが、疲れて眠い時は早く寝てしまって、朝早く起きて活動する方が健康的で、効率的だと考える今日この頃である。

メンバーの話を聞く

プロジェクトメンバーの中には、必ず悩みや不満を持つ者が出てくる。プロジェクトマネージャはそういう人達を見逃してはならない。面談とまではいかなくても、メンバーに声をかけ、ちょっとした話をしながら、様子を窺うことが大事である。解決策が無くても…

静かに考える時間を持つ

現代人は、仕事や遊びに忙しい。昼と夜が明確に別れていた時代では、夜は闇の世界であり、内省するか眠るしかなかった。現代では、寝る間も惜しんで、働き、遊ぶ。必然的に他人と関わる時間も増える。静かに自分自身を見つめ直す時間などない。気持ちにゆと…

多少の無理はした方が良い

人間(生物)は環境に適応しようとする。運動をすれば、それに耐えうるよう筋力がつく。頭脳も使えば使うほど賢くなる。逆に怠けると筋力も頭脳も衰える。インドの学校では2桁のかけ算を覚えさせるとのこと。一見無理なことでも、やればできるようになるもの…

打ち合わせは複数の人間で

顧客との重要な打ち合わせには、余程のことがない限り、複数の人間が出た方が良い。 その理由として、 聞き漏らしを防ぐことができる。 相手の態度や反応を複数の目で確認することができる。 参加者全員が状況を共通認識しているので、対策を立てやすい。 何…

書いて頼もう

他者、もしくは他社に仕事を頼む時は文書にして依頼すべきである。 いつまでに 何処で 誰に 何を どのように してほしいのかを明記すると良い。目的も忘れずに書いておくこと。

ありがたい部下

昨日、休日出勤した。午前は病院だったので、午後から出社した。納期が迫っているプロジェクトのために否応なく出たが、担当の3人の部下も当然の如く来ていた。というよりも昨夜からいた。昨日着けていたネクタイやシャツを脱ぎ捨て、スーツのズボンもヨレヨ…

ブログを続ける方法

Web

携帯電話で投稿する(いつでもどこでも書ける)。 興味あるテーマをいくつか用意しておく。 書きたいキーワードを一覧にしておく。 書ける時に書き溜めておく。 トラックバックを利用する。 過去に書いたことをヒントにする。 大作を書かない。 毎日書こうと無…

平常心

焦ったり、慌てたりするとろくな結果にならない。「大変だ!」、「困った!」と思っても、焦る心をぐっと堪え、「本当に大変なのか?」、「本当に困るのか?」と自問自答する。突き詰めて考えれば、大抵のことは困らない。どんな時でも平常心でいたいものだ。

人材の重要性

システム開発の成否を左右するのは、メンバーの能力と各々のモチベーションの高さである。人数が少なくても、できる人達を集めれば、仕事は進む。できない人達を多数集めても時間を取るばかりで捗らない。教育するという考えもあるが、期間が決められたプロ…

久しぶりの作業

久しぶりにテスト作業を手伝った。しばらく現場を離れていたので、役に立てるかどうか不安であったが、すぐに勘は戻り、期待に応えられた。環境の設定から、データベースのダンプリストの出力まで、忘れかけていたことも、糸をたぐるように思い出せた。楽し…

要求の種類

機能 品質 性能 効率 容量 時間 拠点 操作性 拡張性 安全性 費用 体制 運用 保守 リスク セキュリティ ヘルプデスク

要件定義書の項目

項番 部門 部門担当者 業務名 課題 課題分類コード(経営戦略、情報戦略、業務上の問題等) 対応方法 対応方法分類コード(業務プロセス変更、業務廃止、システム変更、新規システム化等) 優先度 実施期限 備考

標準テスト項目

テスト仕様書を作成する時、下記のような標準テスト項目を参照するとテスト項目の漏れを少なくすることができる。 範囲チェック(日付、時間、長さ、重さ、量、金額等) 属性チェック(英数字、英字、数字、カナ文字、全角文字、特殊文字) 桁数チェック(文字数…

品質管理の管理指標

設計書レビュー指摘項目数 仕様変更追加件数 機能数とテスト項目数 単体テスト終了後バグ発生件数 結合テスト終了後バグ発生件数 総合テスト終了後バグ発生件数 性能目標達成率 本番稼動後バグ発生件数

進捗管理の管理指標

WBSの作業項目件数と完了件数 課題発生件数と解決件数 機能要件の件数 プログラム設計書の作成件数 プログラム製造件数 プログラムの実装機能件数 テストケースの件数と消化件数 バグ発生件数と解決件数

精神的苦痛から逃げるには

精神的苦痛から逃げたければ、逃げるのをやめ、苦痛の原因を取り除くことに頭を使うべきである。良い考えが浮かばなければ、とにかく人に相談し、突破口を見つけること。決して逃げ回ってはならない。苦痛が酷くなるだけだ。

徳を積む

謙虚で素直になる。 感謝する。 正しい考えを持つ。 正しい行いする。 常に正道を行く。 人に譲る。 人に与える。 何があっても平常心でいる。 欲張らない。 足るを知る。 人を不快にさせない。 過度を慎む。 腹を立てない。 身の回りをきれいにする。 整理…

弱者を犠牲にする社会

今、日本は、弱者を犠牲にして、強者だけが幸せになれる社会を目指している。小さな政府、合理化、リストラとはそういうことである。弱肉強食が自然の摂理だと言っても、それを乗り越えて良い社会にするのが人間の英知ではないか。所詮人間も動物だと諦めず…

業務上の課題

情報が共有されていない。 自社の強みが生かされていない。 全社的な統制管理ができていない。 情報が古く、活用できない。 競争力がない。 利益が上がらない 顧客のニーズに柔軟に対応できない。 部門間で業務要件が異なり、矛盾がある。

業務の理解

用語とその概念を統一し、関係者の間で共有する。 同じ業務でも部門や担当者で認識が異なることがあるので、その差異を調べて、業務を再定義する。その際、不完全さを補完し、矛盾を解決しておくこと。 事実を集め、誤りや曖昧さを無くす。 業務を理解するた…