今の職場はコアタイム無しのスーパーフレックスなのですが、さらにフレックス休暇というものがあります。
７．５時間の残業を、休みに変えることができるのです。
私は電車の乗り継ぎの都合で、毎朝始業時刻の３０分前に着いているので、１５日勤務すると１日休めることになります。
先月までは残業代にしていましたが、今月、はじめてフレックス休暇にしてみました。
残業代もいいけれど、休みが増えるのもうれしいです。
今週のお題「ホワイトデー」
以前勤めていた会社ではじめて管理職になったとき、部下の一人に乙女男子がいました。
見た目は草食系の美男子で（実は肉食系）、バレンタインデーに手作りチョコを男女問わず配りまくり、ホワイトデーには男女問わず、大量のお返しをもらっていました。
私も乙女男子に手作りチョコをもらったり（とても美味しい）、誕生日にプレゼントをもらったりしていました。
そんな乙女男子、私が退職して１０年くらい経った後、そろそろ管理職にならないかと言われたらしいのですが、私の名前を出して、管理職は大変そうだからと断ったとのこと。
確かに当時は、はじめての管理職で気負いもあって、いろいろ大変だった記憶があります。私ははたして今、楽しそうに仕事をしているでしょうか。そして乙女男子は今でも、ホワイトデーで持ちきれないほどのお返しをもらっているでしょうか。
今では年賀状のやり取りだけの関係ですが、いつまでも変わらず、乙女男子のままでいてくれたらいいなと思います。
2019年度評価
2019年度の評価面談。
上司から、中途入社して間もないのに良く頑張ったと評価されました！！！
それはそれとして、今の会社の目標管理、かなり緩いです。
事業会社のコスト部門はどの会社も同じなのか、そうでないのかは分かりませんが、前職や前々職のIT企業時代の目標管理と比べると、かなり緩い。
今回、私はA評価をいただきましたが、いろいろ周りの話を聞くと、基本はみんなB評価らしいです（Bが標準）。
IT企業時代もBの標準が一番多かったとはいえ、AとかCもそれなりにいたし、稀にSやDもいました。それは売上を上げる部門だったからなのか、単に会社の違いなだけなのか。
一人の力で成果が出せるわけでないという考えが、どこか奥底にありそうで、雰囲気的には官公庁に似ています。
まあ実務はシステム子会社がやるので、自分が頑張っても、頑張らなくても、QCDに大きく影響しないということが、一因かもしれません。
何にしても、楽なのはいいことです。
開発工程（要件定義）
開発工程の中の要件定義の説明です。
１．要求定義との違い
要件定義のINPUTは要求定義書です。要件定義書は、要求定義に記載された「やりたいこと」に対して、「やること」を決める工程です。
夢を見ていた人たちを現実に戻す作業が要件定義です。
要求定義と要件定義の違いって、実は難しいです。両者の間のグレーゾーンは非常に広大です。でも実際のプロジェクトでは、この違いはほとんど気になりません。
何故か？
要求定義と要件定義の違いは、現実のプロジェクトでは、単に作った人の立場の違いだからです。事業会社のシステム部門やシステム子会社が作れば要求定義書で、受託したベンダーが作れば要件定義書です。もっと言えば、要件定義工程で作ったドキュメントが要件定義書で、それより前の工程で作ったドキュメントが要求定義書なのです。中身には関係なく・・・。
要求定義は「やりたいこと」、要件定義は「やること」をどちらも「ユーザー」と決めていくので、実際のところたいした違いはありません。
スキルの高いシステム部門やシステム子会社が作った要求定義書は、ほとんど要件定義書とイコールなので、その場合のベンダーの要件定義は「お勉強」のような感じになります。もっと言えば、システム部門やシステム子会社が内製で開発するのであれば、要求定義をやる必要はありません。
要求定義が不十分であれば、要件定義の受託者であるベンダーはリスクを大きく乗せますし、要求定義がきちんとしていれば要件定義のコストを抑えられます。要求定義＋要件定義のトータルのコストは、実はあまり変わりません。強いて言えば、要求定義をきっちりやればキャッシュアウトを減らせますが、そのためには、それなりに強いシステム部門あるいはシステム子会社が必要です。ベンダー丸投げがいいのか、内製強化がいいのか、正解は無いので、システム部門やシステム子会社は、振り子のように外注と内製の間を行ったり来たりします。
２．要件定義でやること
要件定義で作成する成果物は、基本的には「要件定義書」と呼ばれる「要求定義書」と似たようなフリーフォーマットのドキュメントです。
非機能の要件定義を実施する場合には、以下のような標準化されている非機能要件の項目があり、機能の要件定義よりも定型化されています。
・可用性
・性能、拡張性
・運用、保守性
・移行性
・セキュリティー
・環境
一般的に多くのプロジェクトでは、要件定義は準委任でベンダーと契約をして、要件定義が終わった後、基本設計以降の工程を請負で契約をします。そのためユーザー部門としっかり要件の合意をして、基本設計以降に仕様変更が発生しないようにすることが重要です。
３．スクラッチ開発とパッケージ利用の違い
スクラッチ開発とパッケージ利用では、要件定義の進め方が異なります。
スクラッチ開発の場合には、ストレートにユーザー部門と要件を決めていけばいいのですが、パッケージ利用の場合には、パッケージと要求内容とのFit&Gapを実施します。
パッケージの機能をユーザー部門に紹介しながら、「パッケージの標準機能で実現できる要求」と「実現できない要求」を整理していきます。実現できない要求に対しては、
・要求を少し変更して実現するもの
・パッケージをカスタマイズして実現するもの
・パッケージとは別でアドオンで開発をして実現するもの
・要求を取り下げるもの
といった整理をします。
パッケージによってはカスタマイズが一切できないものもありますし、方針として極力、カスタマイズをしないプロジェクトもあります。一般的にはパッケージのカスタマイズをすると、パッケージのバージョンアップ時に費用が増えると言われていますが、カスタマイズ可能なパッケージの場合には、カスタマイズの有無でバージョンアップの費用に差が出ることは少ないです。
またパッケージ利用の場合、企画や要求定義の段階で複数のパッケージとFit&Gapを実施して、パッケージを選定済みの場合が多いです。この時のFit&Gapが中途半端だと、要件定義のFit&Gapで致命的なGapが出て、ユーザー部門の不満が高まることもあります。
４．要件定義の例
紙で回付している稟議書のワークフロー化の要求をもとに要件定義を考えてみます。
要求①
「社外秘は、同じ部署の人は全員が参照、ダウンロード、印刷が可能」
ここでのキモは、「同じ部署」です。会社の組織体系は複雑です。「部、課、係」「部、担当、チーム」といった呼び方があったり、部と室の関係も複雑です。
経営企画室の下にシステム企画部がある会社もあれば、システム企画部と経営企画室が同列にある会社もあれば、システム企画部の下に調達室がある会社もあります。
要件定義では、人事システムで管理している組織の階層が、要求を満たす階層構造になっているかを確認します。例えば「部、課、係」という組織階層の会社で、例外的に「室」があって、この「室」は「部」と同列で、「室」の下には組織が無い場合があったとします。このときの「同じ部署」が「部」や「室」であればいいのですが、「課」や「室」だと、「課」は第二階層、「室」は第一階層なので、権限を与える際に工夫が必要になります。
要求②
「厳秘は、稟議を回付した人だけが参照のみ可能で、ダウンロードや印刷は不可」
この要求は厄介です。ダウンロードや印刷の制御はアプリケーションでは不可能です。パソコンでの制御も全社的な影響が出てしまうため、一つのアプリケーションの要求で対応するには現実的ではありません。
そのため要件定義では、システム対応はせず運用ルールでの対応で合意形成を図ります。単に「運用で対応して下さい」だけだと難色を示されることもあるので、利用者への牽制や事後での追跡が可能なように、稟議書へのアクセスの記録を保存するシステム対応の提案をします。
要求③
「稟議を起案したタイミングで稟議番号を発番する」
ここでは稟議番号の体系を確認します。総務部の稟議番号であれば、「総務-2020-001」とか「総-2020-厳-001」とか。稟議番号に厳秘等の機密区分が含まれる場合には、機密区分ごとに連番を振るのか、機密区分は関係なく連番を振るのか等も確認します。
この稟議番号の体系などは、業務ルールなのでスキルの高いシステム部門やシステム子会社であれば、要求定義書に予め記載しているので、要件定義を省略することができます。このような感じで、要求定義書と要件定義書は境界が曖昧で、要求定義書に記載されていないことを要件定義で補ったりします。
要求④
「起案した稟議は稟議整理簿で、年度ごとに管理できる」
ここでは、稟議整理簿の出力方法や保存期間を確認します。画面での表示以外にCSVでのダウンロード機能があると便利です。ダウンロードができれば、保存期間は長くなくても問題ありません。３年度分はシステムで参照できるようにするけど、それ以降は自分でCSVダウンロードして保存して下さい、といった提案をします。
要求⑤
「回付ルートは、起案者の所属と決裁者によって自動で決まる」
ここで重要なのは、組織改正や異動時のメンテナンスです。人事システムから異動の情報が連携されれば、回付ルートにいた人を自動で除外することはできます。でも誰が代わりの人なのかはシステムでは判断がつきません。
メンテナンスは人手でやってもらう必要があること、予約機能が必要か、回付ルートに設定された人が異動した場合にお知らせ通知が必要か、仕掛かり中（回付中）の稟議の扱い等を決めていきます。
【振り返り】
今回は要件定義の説明でした。次回は基本設計の説明をしていきたいと思います。
今週のお題「卒業」
小、中、高、大、といくつもの卒業を経験したけれど、本当の意味で卒業をしたのは、４０代で転職した時だったのかもしれません。
高校や大学は成績で自動で決まったようなものだし、就職先も内定をもらえた数社の中から選んだだけ。そもそも卒業なんてしたくなくて、居心地のいい場所にずっといたかったのに、無理矢理追い出された、といった感じでした。
新卒で入社した会社も不満がなかったわけではないけれど、居心地は良くて卒業なんて考えてもいませんでした。
それが２０年経って、このまま居心地のいいところで仕事をしていて、自分のスキルって伸びるのかなあと、ふと感じるようになって。あれよあれよという間に転職をしました。
今思うと、あの時が本当に自分にとっての卒業だったのかもしれません。４０代になって、遅過ぎたかもしれないけど、ようやく自分の意志で自分の道を歩くことができた気がします。
今週のお題「うるう年」
うるう年と言えば、プログラムロジックです。職業病ですね・・・。
西暦4桁が4で割れる年はうるう年ですが、100で割れる年はうるう年ではありません。でも400で割れる年はうるう年です。
例えば、2100年、2200年、2300年は4で割れても、うるう年ではありません。でも2000年や2400年はうるう年です。このルールを理解していないと、2100年2月29日なんて存在しない日付がエラーにならず、システムが誤作動を起こしてしまうことになります。私は2100年には、すでに死んでいますが。
そして、この「うるう年」よりも厄介なのが「うるう秒」。
うるう秒、知ってますか？
通常、時刻は58,59,00,01秒と時を刻みますが、うるう秒の時には58,59,60,00,01と1分が61秒になります。コンピュータは、うるう秒なんて知らないので、「現実の時間」よりも「コンピューターの時間」の方が1秒早く進むことになります。
たった1秒早く進むことで、システムが誤作動を起こす可能性があります。最近では、2015年7月1日8時59分60秒、2017年1月1日8時59分60秒がうるう秒でした。次はいつかは分かりません。ITのエンジニアたちは、不意に訪れるうるう秒に、毎回頭を悩ませます。
神の摂理を、人間の物差しで測ろうとした罰なのかもしれません。
