サマータイムで試される要件の捉え方。運用対処若しくは相手にしない。

サマータイムで盛り上がっている様なので、時流に乗ろう。

サマータイムで検索するとこの2つがトップの検索結果で表示される。

 

www.slideshare.net

blogos.com

 

ザクっとした感想だが、1つ目のスライドは、まだまともである。しかし、2つ目のコンテンツは、ITジャーナリストの方が書かれている様だが、1ミリも同意できない。

 

この他、ネットやソーシャルネットワークでの混乱ぶり、慌てぶりを見ていると、別の視点で捉えてしまう。どの様に思ったかは以下のとおりだ。

 

「どうして、変更要望を受け付けたときに、その対処をITで全てやる前提なのか」

 

システム開発の変更要望については、進捗上での変更要求のため課題管理で受付し、変更管理委員会若しくはそれに相当する分掌を持つ会議体で行うものだ。その会議体で変更要求を受け入れる方向の場合、見積もりと具体的な仕様を決めるプロセスに入る。そこまでやると初めて見積もりができる環境が整う。既存機能若しくは開発中の仕様、コードへの影響調査及び変更要望が見積もられる。

こうした諸元の情報が整理され、判断材料を踏まえ、顧客起因の仕様変更としての対応の可否を判断する。この判断では、費用を含めて意思決定されるが、その結果は、運用対象、IT対処のいづれかの変更可か変更のリジェクトである。

これが実運用に入っているシステムの場合は、改善又は法対応などのテーマとして扱うが、いずれにしろ影響調査と費用、スケジュールを見積もり、実施判断するのは変わらない。

 

さて、五輪委のサマータイムだが、企業の立場で考えてみよう。ポイントは、法令若しくはそれに準じるもので、遵法しないと企業が何かしらペナルティを負うかどうかである。法令でサマータイム切り替え(2時間巻巻き戻し)とサマータイム終了(先伸ばし)することが求められたら企業としては対応せざるを得ない。

ここで別の切り口で企業を捉える。事業会社のITは年間予算を取り、枠の中でテーマを集め、優先順位をつけて予算を割り当て、執行する。この予算枠の中には、実運用システムの他、新規投資も含まれる。

このスキームの中にサマータイム対応が割り込んでくる。

さて、どうなるかを想像できるだろうか。事業会社のIT部門要員かそれに近いエンジニアであれば想像はつくだろう。

法対応となった場合、2020年までに企業内の全てのシステムで対応する計画を作り、完了させなければならないため、優先順位の見直しされる。さらに言えば、中期計画でのIT投資が変わる。

JUASの資料『第23回 企業IT動向調査2017(16年度調査)』によれば、法対応でも4件でしかIT投資を増やしていない。これが全ての企業に何かしら予算投資増加を増やさせる要因となる。

f:id:fumisan:20180811110325p:plain

引用 http://www.juas.or.jp/cms/media/2017/04/it17_ppt.pdf

 

 

これの対応をSIerは喜べるだろうか。本来であればしなくても良い対応である。これまで仕掛かってきた新規案件はスローダウンすることは必須である。

さらに、アウトソーシングなどで業務システムの維持管理をしている場合、IT部門から調査、見積もりなどが割り込み、維持管理への運用負荷が高まる。リスク転嫁体質が強いIT部門がカウンタの場合、考慮漏れゼロを要求されるだろう。

アウトソーシング外、つまり、IT部門でお守りしている古くサポート切れのシステム持っている場合は、IT部門の担当がその役を担わなければならないが、ITリテラシが低ければ手をつけられないで実質放置となるだろう。

 

サマータイムを正面から検討する場合に考えられるケース。

  1. 法対応の場合、影響範囲が広すぎ、影響範囲を確定するまでに時間が掛かる。
  2. 計画していた投資計画へのリソースが法対応の調査だけでも相当のリソースが奪われる。
  3. 投資計画の見直しとなる。

 

まあ、移行が始まった青い銀行の案件からリリースされたエンジニアを投入すればいいじゃないかと思いつく輩もいるかもしれないが、当事者としての発言ではないから、エンジニアがスキルマッチするかどうかまで考えていないだろう。つまり、考慮する価値はない。

 

端的に言えば、当社はサマータイムに対応しない、と企業公開サイトで宣言すればいい。

運用対処で十分と考えられるが、訴訟リスクを考慮し、限定した対策のみ行う。

  1. システムでは、外部ユーザ向けのインタフェース(伝票、メール、Webメッセージ等)以外、一切対応しない方針を定める。
  2. 社内向けには、正規の時間で運用し、サマータイムを表示する時計を設置する。
  3. 項番1の対応として、B2B、B2Cのシステムなどの電文、メッセージなどに差し込む(併記する)改修をする。
  4. 適用システム、適用時期をシステム的に記録する。

 

さて、これに類似しているケースがあるが思いつくだろうか。そう、消費税の内税、外税の考え方である。ただ、税表記は、企業全体のシステムの一部に限られるが、サマータイムの場合は時間を扱うシステム全てが対象でほいそれと一概に同じとは言えないところが面倒臭い。

サマータイムは企業として、相手にしないのが一番である。

 

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

 
エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)