プログラミングルール
世の中にはたくさんのルールがあります。
ルールの多くは、何か問題があってから、
それを繰り返さないために定められるものだと思います。
以前働いていたIT企業でもいろんなルールがありました。
私が働いていたシステム開発の現場でも
プログラミングルールというものがありました。
プログラミングルールは何故できたでしょうか？
実はよくわかりません。
私が入社した時にはすでに存在していまして、周知されることもなく、
現場でも形骸化していましたので。残念ながら。
想像すると、
・プログラミングの最低品質を担保するため
・保守の効率を上げるため
であったのではないかと思います。
その企業の親会社は
銀行や鉄道の基幹系システムを開発した経験がありました。
その昔、
・一人一台のパソコンが夢の話だったころ、
・プログラムが紙テープに記録されていたころ、
システム開発用のコンピュータは、部署ごとに時間を区切って使っていました。
＃私も話で聞いた時代です。
コンピュータを使える時間が限られていたので、
机上でプログラムを見直して不具合を見つけるのに多くの時間が割かれました。
そんな経緯で、プログラム品質を保つため、
プログラミングルールができたのではないかと思います。
書いてみたらいろいろふくらんできた。
もう少しまとめてメルマガに書きなおそう。
読んでみたい方、こちらから。
「メルマガ希望」と書いてくださいね。
やることリスト
PROMISED
1．同友会打合せ2件 (月曜日)
2．探究セミナー (水曜日)
3．お客様打合せ (木曜日)
4．同友会勉強会 (木曜日)
5．お客様訪問 (金曜日)
6．日報の確認とコメント (毎日)
7．歯医者 (火曜日)
8．お客様訪問 (水曜日)
9．同友会打合せ (木曜日)
MUST
1．評価制度の検討
2．自社の指針検討
2.1 お客様の5年後を聞く (水曜日、木曜日、金曜日)
3．セミナーのイベント作成
4．メルマガ
5．セミナーの検討
自社方針は、お客様方針を実現すること。自社の結果は後から。
僕らしくてやる気が出てくる。