ＩＢＭ　ＡＳ４００とパソコンを愛するＳＥのブログ

今朝の会議でベンダー側プロジェクトリーダーの口から出てくる言葉
様々な不具合が出て、ベンダー側も都度都度対応してくれているので
不安材料はないと言えばうそになるんですが・・・

いや、あり過ぎて困ってるんですが・・・
私の会社に導入されたらどうなるんだろう？
上がってくる課題に、運用でカバーって対応も散見されます。

散見？
散見ってどのくらいの割合？
私の感じている散見という頻度が正しければ、散見どころでは・・・

なんだろう？
新しいシステムを導入したら、今まで自動的に実行されていた機能が
手作業

●新築マンション

皆さん、イメージしてみてください。
今住んでいるマンションが老朽化し
新築マンションに引っ越すことになりました。

今まで住んでいたところでは、お風呂のお湯張りは自動
スイッチ　ポンで、設定した湯量まで自動的に給湯してくれていた。

ところが、新築マンションでは、蛇口をひねってお湯を出し、適度なところで止めなければ
ジャバジャバジャバ

また、今まで住んでいたところでは、ウォシュレットのふたは近づけば自動的に開いた。

ところが、新築マンションのトイレは洋式ではあるものの、ウォシュレットがついていない

そして、今まで住んでいたところでは、ウォークスルークローゼットが付いていたけれど

新築マンションでは、押し入れがあるだけ

こーんな新築マンションに胸躍らせて尚且つ喜べますか？

まるで、トプ画のように、天国から地獄って気分ですよ

●切替検証とは？

今まで構築してきたグループ統合システム
今運用テストを絶賛実施中
まぁ、いろんな不具合がでているものの
先週金曜日の定例会では予定通り進んでいる・・・と

さて、残りは・・・

現行システムから新グループ統合システムへ切り替えを行う必要があります
その切替手順を計画して、
その計画通りに切替が出来るかどうか確認する工程

それが切替検証

●最小拠点で２回

最小拠点で新システムを稼働させるので
そこで、切替検証が行われます。

まず第一回は次の日曜日
第二回は、4月の第四日曜日だったか・・・

うまく行けば

●5月本番稼働

となります。
その後は、最小拠点で新システムが稼働し続けると言う事になります。
うまく・・・いけば・・・ですが

●いよいよ

あと一か月でリリース
そうです！　時間をかけて構築してきたグループ統合システム
リリース直前に行うべきことは

稼働判定

これは、新システムを稼働させて、従来の運用が全て滞りなく行えるかを確認すること
折角、稼働させても、あれができない、これができないでは
業務そのものが実行できないことになりますから

●稼働判定

稼働判定をどのようにするかということを検討する会議
今日行われました。
その中でめっちゃ不安を煽る言葉が

●いろいろなこと

稼働判定を行うためには
全ての運用を把握し、
それらの一つ一つが、
１．新システムで実現できていなければならない
２．新システムで一部出来ていない場合、出来ていない機能が運用でカバーできること
３．実現できていなくても問題ない
のどれに当たるかということと
出来ているというのは、どのように判定するか
を決定しなければなりません。

でも、ここで、上司から耳を疑う言葉が・・・
何がわからないのか分からない
えっ？うそっ？

●あれれ

この段階で・・・その言葉
大丈夫だろうか？
チェックポイントが特定できていないなんて・・・

●いよいよ来月

昨年１月に、大丈夫？　新システム・・・＿|￣|○で投稿したんですが・・・
コメントが一件・・・えらく微妙な内容でドキッとしました

●稼働判定会議

はてさて、残すところあと一か月となった今
稼働判定会議が本日開かれます。
第二回だそうです。

えっ？
第一回目が有ったの？
知らされていないけど・・・

まっ！私のような下っ端には通知する必要もないということね
知らないところで、運用の細部を知らない人たちが判定する・・・

新幹線の新型車両が出来て、初回の試運転をして
200 km/h で走行して
何の問題も無かったから

300 km/h で営業運転しよっか

みたいなイメージが沸き上がります。
（もちろん、比喩として挙げた例はあくまで創作であり、実際には新幹線車両の試験は途方もない試験を繰り返しておられることは言うまでもありません）

●稼働判定結果

Go or Stop
どちらでしょうか？
何となく、Goと判定される気が大です。
現時点の試験結果がいかようでも・・・

何故なら、Stopとなれば誰かが責任を取らなければなりません。
そして、Goが出来るようにするために全精力を傾けなければなりません。
そんな責任を取る責任感のある人が見まわしてみても・・・居ません

●犠牲？

Goと判定された結果
グループで一番小さい拠点で
来月にリリースとなります。

上手く稼働すればいいのですが・・・
私が、そこの拠点の責任者であったなら、
本番テストを休業日に行い、そこの拠点の部門責任者全員がＯｋを出したら

Goですよね。

●一日停止

今日、朝の会議で、ベンダーさんから重大な報告がありました。
開発環境及びテストで使用していた環境と
本番環境で一部異なる設定があったと・・・・

●テスト期間中だから

本番環境でテストを始めて約一か月
そこで分かったらしい
何が違うかと言うと

文字コード体系
まぁ、些細な違いみたいですが
開発環境で使えていた ~ (チルダ) が

本番環境では使用できない・・・
これが同問題かというと
テスト環境でデータ中に 【~】が格納されていた場合に
画面に表示はできる
でも、入力しようとしたときにエラーではじかれる

えっ？入力できない？
いやいや、【~】が使用されている時だけ

●なぜこのような事が

なぜ、一流のベンダーさんがこのようなケアレスミスをしたのか？
それはやはりあの一点に尽きるだろう・・・と私は思う

リリース期限は決まっているのに仕様決定がめちゃくちゃ遅い

そりゃ、だれでもミスるわなー
私としてはベンダーさんに同情

●一抹の不安

しかし、開発環境の設定を本番環境に引き継ぐのは、常識的な線・・・・
その処理を行うときにチェックリストなどを作って実行するはずなのに
文字コード体系を違えて設定しちゃうとは

一事が万事

すこーし不安が・・・

本日の会議で、ベンダーさんがボソッと

報告書を出力する方式で、帳票サーバーを何台設置して、
報告書印刷用データをどのように振り分けるかで、
ベンダーさんと我々グループで意見がバッティングしちゃって

ベンダーさんの今日のリーダーが
【どのように進めたらいいのか分からなくなっちゃった・・・】

こっわー

●厳しいパスワードポリシー

当社のホストコンピューターにログオンする時
当然、ユーザーとパスワードを入力する必要があります。
現在では、パスワードは10文字までなんですが、設定によれば
128文字まで使用することが出来るようには変更できます。
でも・・・
128桁も覚えられるわけねーじゃん

なので、10桁に抑えて、
パスワードの常とう手段
●他人に推測されにくく
●覚えやすく
というのをパスワードポリシーに含めるとともに、
●３種類の文字種
●８文字以上
●過去14回以内に設定したパスワードは再利用できない
と言うのを追加して運用しています。

また、60日経過後は強制的にパスワードを変更させるようにしてあります。

これね・・・結構厳しいですよ(笑)
プライバシーマーク認証機関の審査員に
『かなり厳しいルールで運用されてますね』
って言われました

●そんなん言うか〜

その時、私は胸の奥で
『えっ？　そないせーって言ってるの、認証機関のお宅の認定指針やん！』
って叫んでいました

たまに、パスワードの有効期限が来て、
特に急いでいる時にパスワードを再設定してくださいとか聞いてくる・・・
さすがに自分で作ったポリシーとは言え、鬱陶しい

●なんとかならないかなー

ホスト系でもユーザー認証に
バイオメトリクス認証が使えないかなー？
こんな風に（笑）

●日曜礼拝

今日は日曜日
私たちクリスチャンにとって聖なる日
日曜日には、神様に礼拝を捧げます。

私は、車があるので、教会に集っています。

●コロナで

ただ、コロナ禍のせいで、
それまで公共交通機関で来られていた方々は
特に高齢者の方や、医療従事者の方は
感染予防のために、教会に来られることを控えておられます。

●Facebook

そんな中、教会では、教会に集えない方々のために
礼拝の様子をライブ配信しています。
昨年までは、LINEライブで配信していましたが、
その後Youtubeライブと、Facebookライブに切り替えました。

高齢者が多い中、Youtubeライブは、視聴用リンクを送れば
誰でも簡単に視聴できます。
（ちなみに、ライブ配信視聴者は、専用のLINEグループに参加しており
ここに、Youtubeライブ視聴用URLを送るようにしています。）
完全に クローズド な運用です。

現在では、Youtubeライブ視聴者は 30 名ぐらいおられますが、 Facebookライブ視聴者は 若干名 となっています。　そして、Facebook の方は若者（20代や30代）しかいません。

これは、Facebookの方はアカウント登録とライブ配信グループへの参加が必要なので、高齢者の方にはいささか敷居が高いみたいでした。

●こんなに・・・

そこで、Facebookへのアカウント登録からライブ配信視聴まで・・・というマニュアルを作成しました。
先週作成し、教会で一緒に会計をしておられる方に、
『マニュアルでチャレンジして』みてとお願いしたところ、
数日後に『無事できました』ってメッセージが届いていました。

その時に渡したのは、約15 ページぐらいでした。
このマニュアルの目的で 15ページは 大作です。

でも、アカウント登録方法を、ネット上のＨＰへのリンクを提示し、ここを見といて方式にしていました。
これが不評で、途中で見るのが嫌になった・・・って言われてしまいました。

そこで、本日、マニュアルをリニューアルし、
その手順通りに進めれば誰でも出来るようにしました。

また、視力が弱くなられている方も多いので、大きなフォントで、添付画像も大きく(1.5倍）したマニュアルも作成しました。


このマニュアル、普通サイズは 19 ページ、　大フォント版は 35ページとなりました。

私としては、Youtubeライブより Facebook ライブの方が、画質も良く、音質も良いので
Facebookライブに誘導していきたいと願って作りました。
が、こんなに対策になるとは思いませんでした（笑）

◎大きなシステムを構築する時には・・・

●質問１：どの形式がいいと思いますか？
�@能力１００のコンピュータシステム単体で構築されたシステム
�A能力１０のコンピュータシステムが１２個合わさったシステム
�B能力５０のコンピュータシステム１つと、能力５のコンピュータシステム２０個

●質問２：どちらがコストがかからないと思いますか？
�@能力１００のコンピュータシステム単体で構築されたシステム
�A能力１０のコンピュータシステムが１２個合わさったシステム
�B能力５０のコンピュータシステム１つと、能力５のコンピュータシステム２０個

●質問３：採用する場合、選択する基準は何ですか？
�@可用性　（システムを利用できる割合が高い方が良いとされる）
�A拡張性　（企業の発展に従って処理性能をアップできる方が良いですよね。）
�B保守性　（放っておいても動き続けるなら、もう神レベル）
�CＴＣＯ (Total Cost of Ownership)
　（保守や電気代など、全てを含めた費用・・・安い方が良いですよね。）

これらは、新規システムを構築しようとするときに避けては通れない選択です。
まず、機能要件を決定します。
そして、システム要件を決定します。
それを実現するためのコンピュータシステム構成を決定します。
それを可能とするコンピューターハードウェアを決定します。

質問１の答えは、私は�@です。
当然質問２の答えも、私は�@です。
なぜか？
合計なら�Aの方か、それよりも�Bの方が大きくなります。
ただ、考えてみてください。

あなたが能力１００の要員だったらどうでしょう？
能力５０の要員で能力５の部下が２０人いたら・・・
あなたが能力１０の要員１２人のうちの1人だったら？

どの場合が一番効率よく仕事が出来るでしょうか？

そして、要員が多ければ多いほど・・・
病気で休む人が発生する確率が高くなります。
病気で休む人が出たら、その部分の仕事が停まってしまって、部署全体の仕事が進まなくなりますよね。
そうならないように、冗長化します。
すると、その分だけ要員が多く要ります。

コンピューターでもそうです。
多くなればなるほど故障する確率が増えます。
一年に一回の確率で故障するコンピューター３６５台を稼働させている場合、
そこのシステムエンジニアは毎日故障対応

そんなの嫌ですよねー！

質問�Bに至っては、優劣を決めることがなかなかできません・・・
そのシステムの用途によって重要要素が変わってくるからです。

ちなみに、私の会社で使用しているこんなピューターは、
�@〜�Cを全て満たしています。
特に�Bなんて、放置プレイマシンってメーカー代理店の営業マンが言ってて
うまいって思いましたもんちなみに・・・・

●グループ統合システム

先ほどもOT朝会って言う会議がありました。

この会議は毎朝あるんですが
各システムでOT (Operation Test = 運用テスト) を行った結果を報告するんですが・・・

いっぱい


どうなることやら・・・
見切り発車をすれば、その結末はどうなるかは

●グループ方針

当社では、グループ統合システムで出来ることは全て出来ていて、しかもそれ以上の機能も実現できているのに・・・グループ方針によって、当社のシステムを廃棄し、グループ統合システムを導入することに・・・

なんでやろ？
作ってきたシステムをわけわからん理由で廃棄されるって
システムエンジニアにとって我が子を殺されるに等しい感覚

辛すぎるよー