私的システム開発手法

●残業しない。

　 時々残業する場合は効果があるが、恒常化すると日中の作業効率が間違いなく落ちる。付き合い残業が多すぎる。

●開発スケジュールは個人の休日を最初に決定する。

　 用事がなくても定期的に休日を取得する。

　 意図的に気分転換する。

　上司が「休め」と言うのは「ウソ」である。

　「休みます」と事前に報告すると、必ず一言いわれる。

　「休める状況か？」（上司）

　「じゃ、一体何時休めと言うのですか？」（筆者）

　「そりゃ、仕事が一段落した時だ」（上司）

　「それは、具体的にいつですか？」（筆者）

　「？？？」（上司）

　休日取得日数が一番少ない人が一番仕事をしているように評価される事がある。　「休みを取らない」と「忙しい」を同意語にしている。

●食事はどんな事があろうと定時に必ず取る。

　 一回でも取らなくなると、そこから一気に「生活のリズム」（体調）が崩れる。

　 当人が「体調不良」を認めない場合が多い。

●詳細進捗報告書には「ウソ」が多いので作らせない。

　 最初に「ウソ」をつくとその後、ずう～っと「ウソ」を続ける。

　 いつしか「如何にごまかすか」が仕事の中心になる。

　 「生産高」の表現が人々を惑わす。

　 そして、本番直前にすべてがバレる。

　 「読みもしない」「分かりもしない」報告書を沢山作成させる事は「仕事の妨げ」以外の何物でもない。

●意地で「できます！やります！」と言わない。

　 何の意味もない。己の「プレッシャー」になるだけ。

　安易に人々に期待を抱かせない。

『あの時、できます！』と言ったではないか！」と責められることはあっても褒められることはない。

●「本番データ切替」はシステム開発の最初に行う。

　 ＤＢはプログラムを作成しながら決定する。

　ＤＢのレイアウトは本番までにどんどん変化する。

　テストデータは本番データを使用する。

●スペックはプログラムが完成した時作成する。

　 プログラムスペックは他人にヒアリングしながら作成して貰う。

　 スペックは「ヘルプ」に記述する。

●プログラムはお客さんの目の前で作成する。

　パソコンを持参する。（計３台をLANで結ぶ）

（#1:お客さま用（実際に操作して貰う）　#2:コーディング用　#3:データ閲覧用）

●コーディング中でも本番データでテストする。

　 自分流のデータは極力避ける。（無ければ、お客様に作成してもらう）

　 常に本番データで行う。

●モジュール（プログラム）が「取外し易い」システムにする。

　「取り付け易い」が「取り外し難い」システムが多い。

●常時「メモ用紙」を携帯する。

　 いつ、どこで「ヒラメク」か分からない。即、書き留める。（書かないと忘れる）

　これは、すべてのシステム開発には適用されない！

あくまで一手法であり、通用するのは筆者のみである。

　そもそも、開発手法は「絶対的」ではない。

しかし「唯一無二の手法がある」と信じ込んでいる人々がいる。

ＴＰＯに合せた、そしてお客様に馴染むやり方がその時の「ベスト手法」である。

　両者の「基本的開発手法」の合意なくして物事が始まる。

システム作成側の一部の人々によって一方的に物事が進められていく。

そして、開発途中で「考え方が合わない！」と揉め出す。

「揉める」のは今じゃないでしょう！！