社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

歩数が・・・

会社で、テレワークにおける健康促進の記事の紹介がありました。

その記事によるとテレワークの人の一日の平均歩数は2000〜3000歩で、国の推奨の8000歩を大きく下回っているとのこと。

あれ?

テレワークで一日2000歩って、多くない?

自分のテレワークの歩数を数えてみると・・・

「仕事部屋兼リビング兼ダイニング兼寝室」と「トイレ」の往復20歩程度、「キッチン」との往復20歩程度、「風呂」との往復20歩程度。つまり半径10歩程度が私の生活圏。

週5日勤務のうち3日くらいは一歩も外に出ないので、どんなに頑張っても一日300歩程度しか歩いてません・・・。外に買い物や食事に出る時も自転車なので、1000歩も歩いていないような・・・。

みんな意外と歩いているんだと衝撃を受けました。

今週のお題「おじいちゃん・おばあちゃん」

はてなブログ今週のお題「おじいちゃん・おばあちゃん」

3年前の大神島で、おじいの敬老の日パーティーに参加しました。

島で唯一の宿に泊まった日が偶然にも敬老の日で、宿の食堂におじいたちが集合して、勝手気ままに宴会がはじまりました。

何故かおばあが一人もいない食堂で、おじいたちの昔話を聞きながら、おじいたちが持ち寄った料理とオリオンビール泡盛を飲みながらの楽しいひととき。

戦争で放置された手榴弾を拾って、海で爆発させて魚を獲った話しとか、昔の綺麗だった海の話し、島の神様の話し。

自分が体験したわけではないのに、なぜか懐かしい気持ちでいっぱいに。

私がおじいたちと同じ年齢になったとき、若い人たちにどんな話しをしてあげられるのだろう。楽しい話しをいっぱい聞かせてあげるために、今を楽しく生きねばと思いました。

f:id:SystemEngineers:20200920102811j:plain

非機能要件(運用保守:後編)

非機能要件の中の運用保守の説明(後編)です。

運用と保守は、会社によって境界が異なるので、ここでは境界を気にせず記載します。

4.障害対応

障害を検知した後の運用フローを関係者で合意します。

運用フローは大きくは、営業時間中と営業時間外で分かれます。

特に営業時間外については、ベンダーとの合意に苦戦することが多いです。営業時間外であっても障害対応を正攻法で要求すると、保守費用が非常に高額になります。そもそもベンダーによっては会社として引き受けてくれない場合もあります。

実態は営業時間外の障害でも、駆けつけて対応してくれるベンダーが多いのですが、契約レベルでは営業時間外はサポート対象外となる場合が多く、公式にはサポートしていないのに、非公式でサポートしているという、現場泣かせの要件です。

ベンダーだけでなくユーザーの所管部署も、営業時間外の連絡は嫌がります。エンドユーザーへの連絡は、ユーザーの所管部署が担うことが多いのですが、営業時間外に障害が発生した場合、ユーザーの所管部署は連絡を受けることを嫌がることが多いです。

また障害の種類によって、どこまで連絡をするかが変わるので、これも明確にします。エンドユーザー全員に周知が必要が障害もあれば、システム部門内だけの周知で済ませる障害もあります。それらを分類して、運用フローに反映します。

ステークホルダーとの連絡ルート以外にも、手続きのフローも必要です。品質部門への連絡や上司へのエスカレーション等です。

これらはシステムの実装に影響のあるものではありませんが、保守の費用に直結する要件でもあり、また関係者での合意が不十分だと、実際に障害が発生した際に連絡が不十分だとクレームを受けやすくなります。クレームを受けてから、慌ててフローを決めようとしても、事前に決めておかなかった負い目があるため、ユーザー部門優位のフローになってしまうことがあるので、対等に交渉できる要求定義や要件定義の段階で合意することが重要です。

5.製品保守

クラッチ開発したアプリケーション以外の製品保守について、ベンダーとの役割分担を合意します。

対象は、サーバーのOS、IISTomcatOracle等のミドルウェア、アプリケーションのパッケージ等、全てのソフトウェアを洗い出し、一つ一つに対して保守の役割を明確にします。

ソフトウェアのアップデートやアップグレードは実施するか?実施する場合には有償か、保守費用に含まれるのか、特にセキュリティーパッチは、情報の入手先や入手頻度、パッチ適用のタイミングまで関係者で合意をします。

また導入した製品のライフサイクルにも注意が必要です。

通常、最新バージョンのソフトウェアは導入せず、品質の安定した一つ前くらいのバージョンのものを導入します。場合によっては諸処の事情でもっと古いバージョンを導入することもあります。その場合、稀にEOLが1年後のような製品を導入しようとするベンダーがいるので、注意が必要です。

ソフトウェア以外にも、ハードウェアも導入しているのであれば、ハードウェアについても保守の役割の整理が必要となります。

6.環境

本番環境以外の環境が必要な場合には、その環境に対しての要件もまとめます。

例えばステージング環境を用意する場合、一日一回、本番環境から全データをコピーする仕組みを作ったり、開発環境もマスターデータだけは本番環境からコピーする仕組みを作ったり、といった要件が考えられます。

特に重要なのは、その環境の用途を明確にすることです。

例えばステージング環境がなく、開発環境だけがある場合、本番開始後は性能試験が困難になります。また本番環境が冗長構成の場合、開発環境はシングル構成の場合が多いので、その場合にも冗長構成に関係するテストはできなくなり、基本的にはアプリケーションのテスト用途だけになります。

そのように本番稼働後にできないことを明確にして、関係者で合意をすることが重要です。

7.その他

時刻同期の方法やサービス提供時間外の画面についても、どのような対応とするか決める必要があります。

サーバーの時刻同期は、どのNTPサーバーを利用するのか、あるいは利用しないのか。OracleRACのようにデータベースのクラスタリングを利用する場合には、クラスタリングのサーバー間での時刻一致が大前提のことが多いので、より慎重な検討が必要です。

また時刻同期の方法が、ミドルウェアやアプリケーションにどのような影響を及ぼすのかも事前に確認し、時刻差によって時刻同期の方法が異なる場合(stepモード/slewモード)には、チューニングも実施します。

うるう秒の扱いについても整理しておくと、本番後に慌てて調査をしなくて済みます。特にタイムスタンプを取得するようなシステムは、時刻認証局側のうるう秒の対応を把握しておく必要があります。

サービス提供時間外にユーザーがアクセスした場合の、応答画面についても考慮が必要です。メンテナンス画面をロードバランサーで出すのか、Webサーバーで出すのか、後者の場合で冗長構成でない場合には、Webサーバーをメンテナンスする場合には、メンテナンス画面はどうするのか、等を決めていきます。

【振り返り】

運用保守の説明(後編)は以上で終了となります。次回は移行の説明をしていきたいと思います。

①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ/アクセシビリティ
⑧システム環境

今週のお題「ごはんのお供」

はてなブログ今週のお題「ごはんのお供」

私のごはんのお供は、牛乳です。

小さい頃から背の低かった私は、身長を伸ばすため食事の時には欠かさず牛乳を飲んでいました。

その習慣が今でも続き、家で食事をする時には必ず牛乳。在宅勤務になって、昼も家で食事をするようになったので、1日1リットル近く飲んでいます。

友人にそのことを話すと、ごはんに牛乳って気持ち悪いと言われます。

牛さんに失礼です。

f:id:SystemEngineers:20200914110241j:plain

2月決算になかなか慣れない

うちの会社は2月決算なので、9月は下期です。

前々職と前職は3月決算で、学生時代を含めれば、40年以上も4月が新しい年度という感覚で過ごしてきました。

それなので、なかなか9月は下期と言われても、頭では理解しても気持ちが追いつきません。

そして目標管理。

どうしても夏休みの宿題と同じで、9月が追い込みの月の気分でいたので、すでに上期が終わっていたことを忘れてました。

締め切りが1ヶ月早いなら、ボーナスも1ヶ月早くくれればいいのにと思います。

今週のお題「もしもの備え」

はてなブログ今週のお題「もしもの備え」

もしもの備えで、福沢諭吉先生が3人、財布に忍んでいます。

行き当たりばったりが信条の私は、災害の備蓄はしていないのですが、もしものときのために財布に諭吉先生が3人。

クレジットカードを持たず、何とかPayも使わず、電子マネーも千円ずつチャージして電車に乗る時にしか使わない現金決済の鑑のような私は、もしもの備えも現金です。

3万円の根拠は特にないですが、枚数が多いと財布が膨らんでしまうので、忍んでいる感のある3枚で落ち着いています。

そんな3人の諭吉先生。今まで役に立ったことがあるのか?というと、意外と役に立っています。

超現金決済派のくせに、財布には数千円しか入れていないことが多く、買い物をしてお金が足りないこともしばしば。その度に3人の諭吉先生のうちの一人が助けてくれます。

そして助けてくれた後、諭吉先生の補充を忘れることもしばしば。

仕事ではコンティンジェンシープランとか偉そうに作っているのに、自分のコンチプランは穴だらけです。

f:id:SystemEngineers:20200906173525j:plain

納品代行を見学

1ヶ月ぶりに会社に出社して、物流担当の人に納品代行業者を案内してもらいました。

自社から歩いて15分のところにある会社で、平日の日中なのでほとんど商品は残っていなかったのが残念でしたが、先方のシステムも見せてもらうことができました。

うちのシステムも相当古いと思っていましたが、先方のシステムはさらに古く、ホストコンピューターの画面。おそらく30年くらい同じシステムを使い続けているのではと思います。

それはつまり、30年くらい仕事内容が変わっていないということ・・・。もっと言えば、ずっと効率化などの改善をせずに今に至っているということです。

その分の無駄なコストを一昔前までは消費者が支払っていたわけですが、今は消費者にそっぽを向かれ、サプライチェーン全体がシュリンク状態に。

今までも何度かサプライチェーン全体の改革プロジェクトっぽいものが立ち上がりましたが、なかなか総論賛成各論反対状態から抜け出せず、いつも取り組みが中途半端で終わっていました。

私がリタイアするまでに、救世主が現れてサプライチェーン全体が改革されるといいのですが。