SE のためのカレンダー学

…てな学問は冗談にしても、雑誌連載くらいあっていい気がします。
私が知らないだけでもしかしたらあるのかも知れません。

意外とカレンダーや時計関連のバグや不具合って多くないですか？
社会問題にまでなった 2000 年問題はあまりにも有名ですが、
週またぎや月またぎのタイミングで発症する週次処理の不具合や、
時差やサマータイムへの配慮が不十分なために出るバグ、
連携先のマシンの時刻設定に依存した処理、
処理日付と対象データ日付がくい違うと途端に挙動が一定しなくなる夜間バッチ郡などです。

最近の環境なら閏年の扱いなどは API や標準クラスなどが隠蔽してくれるのであまり気にする必要はないですが、日付をどう解釈し利用するかは設計によりマチマチです。
また、起算日とは何かとか、民法における年齢の計算方法などはある種の業務知識として体系化してまとめられてもいいと思います。
上記のようなキナ臭いポイントの他、日付にまつわる要件やテスト項目の注意点や、製品の仕様でここは確認しておこう、なんてのもまとめられたら役立ちそうです。

浮動少数演算の誤差のように、ほぼすべてのエンジニアが一度は直面する問題のように思えるのですが、どうでしょうか。

肩書きを疑う。成果を信じる。

あなたの会社ではどんな肩書きがあるでしょうか。あるいはどんな肩書きであなたは仕事をしているでしょうか。

ここでいう肩書きとはクラスとか職位のことです。

一般的な会社では部長や課長という肩書きがあるでしょう。
またこの業界ではプログラマ、システムエンジニア、アプリケーションエンジニア、リーダー SE、テクニカルプロフェッショナル、アナリスト、システムアナリスト、プロジェクトマネージャー、IT コンサルタント、ソリューションエンジニア、テクニカルアーキテクト、……とまぁ、いろいろな肩書きが存在します。

この手の肩書きには注意が必要です。
これらは会社の考えるキャリアパスにマッピングされた用語であり、個人の責任と役割を必ずしも表明しないからです。かつて５級社員、４級社員と呼んでいたものにプログラマやシステムエンジニアなんて言葉をマッピングしていたがために、なぜか基盤系のプロがアプリケーションエンジニアと呼ばれていたり、「経理の同期はシニアアカウンタントになる頃だから、君もそろそろ職位表上同列のシステムアナリストだね」なんてことが実際にあったりします。
大きな会社だと議事録と提案書を書き続け、コードは自分用のツールのために Excel/VBA しか書いたことのない人間がプログラマを卒業して SE に、なんて事もあります。入社 n 年経って n 千ステップ以上のコードを書いたので要件をクリアしているためです。（メインフレーマ系では日常的な風景のように思えますがどうでしょうか）

この手の肩書きには注意が必要です。疑いましょう。

実際、何をマネジメントすべきかを考えていない「マネージャー」や、基礎的な論理思考能力がなかったり知識を右から左へ伝えるだけで付加価値への情熱がない「 IT コンサルタント」や、ビジネスレイヤーでしか議論のできない「システムエンジニア」は多くいます。


我々の仕事を定義づけるのは、まず何よりも成果であり、次に付随する責任と、さらにその次にこれらを果たすための権限です。

これら、特に成果について、自分がどれだけのモノを引き受けられるかが、自分の仕事を測るほぼ唯一の尺度のはずです。