人は自分の価値観に合ったことをする時が最も力を発揮しやすい。その人が何に重きを置いているのかによって、仕事のさせ方が変わってくる。人それぞれ価値観は異なるが、大きくは次のように分類できるのではないだろうか。 ・知識や技術を得たい。 ・地位や…

・目的を見失わず、メンバーを導く。 ・決断力がある。 ・責任感が強い。 ・交渉力がある。 ・統率力がある。 ・機動力がある。 ・コミュニケーション能力がある。 ・情報をうまく活用する。 ・適時に適切な手が打てる。 ・意志が強い。 ・熱意がある。 ・人…

気のせいか、公徳心のある人が減っているように思う。例えばエレベーター。先に乗った人が自分の行きたい階のボタンを押して、さっさと奥へ行ってしまう。何故自分が他人のために開くボタンを押してやらなきゃならないんだと言いたげな態度だ。特におやじが…

きっと明日はいい一日になると思いながら寝る。きっと今日は楽しい一日になると思いながら出かける。通勤途中で嫌な目にあっても後でいいことがあると思い直す。そうすると大抵いい一日になる。

■ユーザ側の責任 ・ユーザ要件から漏れていた。 ・ビジネス環境が変わってしまった。 ・法律や制度が変わってしまった。 ・経営方針が変わってしまった。 ・ユーザの組織が変わってしまった。 ・ビジネスモデルが変わってしまった。 ・ビジネスルールが変わ…

ユーザの要件定義が済んだら、それを実現するために行うべき作業を漏れなく洗い出す。さらに洗い出した作業を実現可能な大きさになるまで細分化する。これを構造化したものがWBSである。WBSがないと、プロジェクト全体にかかる工数が見積もれない。それに伴…

と言いたいところだが、粘っていろいろと思いを巡らせば、何かと思い付く。結構頭の体操になる。一所懸命考えれば、何らかの答が出る。人間の脳みそはそのように出来ているらしい。今日はそれが言いたかった。 ↓ 家人曰く「理屈と膏薬はどこへでも付く」 我…

ネット上の読者はせっかちである。私もその一人である。ひとつのページに止まる時間は極めて短い。電子媒体という特質から長文を読むのは辛いと感じる。どんなにためになる記事であっても、スクロールをしないと読み切れないものは敬遠してしまう。本や雑誌…

システム開発のプロジェクトを進める上で必要な会議体を列挙してみる。 ・プロジェクト発足(キックオフ)会 ・要件確認会議 ・仕様確認会議 ・ユーザ進捗報告会 ・内部進捗会議 ・ユーザレビュー会 ・内部レビュー会 ・サブシステム間仕様調整会議 ・課題解決…

一日の終わりに反省する。精一杯働いたか、悔いが残ることはないか。新しい発見はあったか、何を学んだのか。辛かったことは何か、楽しかったことは何か。明日はどんな一日にしたいか。善き日も悪しき日も、味わい尽くさなければもったいない。

要件定義がプロジェクトの成否の鍵を握ると何度も書いてきた。要件定義はユーザ中心の仕事になるので、彼らにその能力がどれだけあるかによって変わってくる。その不確定要素を無くすには、こちらが業務分析やシステム分析等を含めた要件定義以上の工程に関…

要件定義にはふたつの種類がある。機能に関する要件と機能以外の要件である。機能に関する要件は業務をどのようにシステム化したいのかを記述する。機能以外に関する要件はパフォーマンスやセキュリティ等、業務には直接関係のないことについて記述する。最…

要件(要求)定義はユーザの仕事である。システム化したいことを明確に定義し、開発者に漏れなく伝えなければならない。開発者はシステムに関する専門知識でユーザの要件定義作業を支援することはできるが、どの業務をどのようにシステム化したいのかというこ…

まずは業務経歴書の裏付け確認から。 ・過去に携わった業務の説明(最近のものから)。 ・各プロジェクトの期間。 ・各プロジェクトの規模(総工数、在籍時の人数等)。 ・各プロジェクトにおける立場、役割。 ・各プロジェクトで担当した工程(設計、プログラミ…

ユーザ要件が決まっていないのに請負契約を結ぶのは請負側にとって非常に危険である。要件が決まっていないということは開発の範囲も決まっていないということである。開発規模の見積もりそのものができないし、見積もったとしてもいくら増えるのか見当もつ…

不確定要素の多い段階で設計書やプロトタイプを作らなければならないときがある。それを上司やユーザがレビューすると、必ずああだこうだと修正を言いつけられる。そういう状況で100%の力を出し切るのは愚の骨頂だ。こちらの思い違いで一からやり直しという…

プロジェクトに入って来た新しいメンバーに教えるべきことをマニュアル化しておこう。 就業時間 昼休み時間 昼食の場所 休憩時間 最終退出の仕方 残業申請の仕方 休日出勤申請の仕方 基本的なマナー 施設の使い方 席の場所 会議体 電話の使い方 連絡方法 月…

プロジェクトが進んでいるかどうかは予定していた成果物の完成度で判断すべきだ。進捗会議でメンバーから各自の作業状況を聞くのは当然だが、鵜呑みは禁物である。設計書やプログラムソース等の成果物を実際に見るまで信じてはならない。設計書はレビューで…

プロジェクトが佳境になると残業や休日出勤が増えてくる。睡眠時間が不足し、疲労が溜まる。そんな状態で良い仕事はできない。疲れていると物事を深く考えることができなくなり、間違いを犯しやすくなる。仕事の効率が悪くなるので、いくら忙しくても休ませ…

プロジェクトの真っ最中でも夏期休暇くらいは取らないとメンバーの士気が下がってしまう。ソフトウェア開発の業界では会社が休みの日程を指定する例は少なく、大抵は決まった日数の範囲で業務調整しながら休みを取らせるケースが多い。となると、プロジェク…

考えを数多く書き出すことは次のような効果を生み出す。 ・視野が広がる。 ・多面的に考えるようになる。 ・アイデアがアイデアを呼ぶ。 ・頭を刺激し、活性化する。 ・考えが偏らない。 ・不可能に思えていたことが可能になる。 ・前向きに考えられるように…

システム開発において成果物を管理することを構成管理という。成果物には設計書やプログラムソース等がある。成果物は常に最新で、かつ全体が整合性の取れた状態に維持されていなければならない。よって、成果物がいつ誰によって作成され、更新されたのかを…

「面白い話は書けないの？」と私のブログを読んだ家族に言われた。プロジェクト管理というお堅いテーマで通しているのにエンターテイメントを望まれても今更変えられない。「同じような話が何度も出てくるけれど、何が違うの？」と聞かれたが、「よく読めば…

仕様変更、仕様追加の依頼を受ける時は変更依頼書等の文書でやりとりすべきである。決して口頭でやりとりしてはならない。その依頼文書を受け取ったとしてもSEの判断で対応してはならない。然るべき会議で検討し、プロジェクトマネージャがどのように対応す…

過去に書いたブログは時々読み返した方が良い。時間をおくと忘れてしまって、同じネタで書いてしまう。ネタを被らせないようにすることと、過去のネタを見直し、さらに発展させて新しいネタにするという理由で過去に書いたブログを読み返すことは有益である…

設計というのは、答えがひとつだけとは限らないので、あれこれと悩み、時間がかかる作業である。しかし、設計方針を先に立てておけば、ある程度の枠組の中で設計することになるので、それほど悩まずに設計を進めることができる。プロジェクト全体で使う言葉…

システム開発を行う時は将来のことも考えてできる限り汎用性を持たせた構造設計をすべきである。そのシステム特有の機能を追加する前の状態を保存しておけば、別のシステムに流用できる。部品化しておけば、さらに用途は広がるだろう。実績のある資産を再利…

・寝る。 ・笑う。 ・運動する。 ・音楽を聴く。 ・歌を歌う。 ・大きな声を出す。 ・入浴する。 ・マッサージしてもらう。 ・酒を飲む。 ・おいしい料理を食べる。 ・楽しいことをする。 ・海や山で過ごす。 ・旅行に出かける。 ・買物をする。 ・趣味に没…

「プロジェクト管理者の道具箱」というサイトを運営している。記事はこのブログで書いたことを整理して使うことが多い。ブログは以前にも書いたように携帯電話を使って投稿している。携帯電話だとアイデアが浮かんだ時に書くことができる。一旦メール作成機…

プロジェクトは生き物である。過去に成功したからといって、次に成功するとは限らない。ユーザが変わるとプロジェクトも変わる。ユーザが変わらなくても、要件やこちらの体制が変われば、同じことが言える。プロジェクトマネージャはプロジェクトマネジメン…