人生中盤から色々学ぶ(ブ)ログ_bak

しばらくの間休日出勤やら翌週準備に追われて更新出来ませんでした。

コロナ怖いですね、怖いですがオンプレ環境の運用となるとリモートワークが中々許可下りません。

さて、そんな中弊社、というか出向先の企業（本体1万人オーバーの結構な規模）では、

社内システムの大規模刷新プロジェクトが進んでいるそうです。

進んでいる、と話には聞くのですが。実際関係者はかなり忙しそうなのですが。

インフラを検討する要員は居ないそうです。ふむふむ。大変な事になりそうですね。

って他人事と思ってたら、現行システム運用に携わるメンバー、つまり私なんですが、

「この拠点のシステムの未来像を検討してくれないか？」というぼやかしたお言葉で、

お仕事が回ってきてしまいました。

未来像って、刷新後の環境が前提ですよね…

とはいえ普通に要件定義や設計をしてしまうのは契約範囲を超えるので、

プロパーの若者を主役に、私は補佐として関わる事になりました。

まずは経緯を知るために去年のトレンドがどうだったのか、と調べてみました。

いくつか読んでみて、端的でわかりやすいと思ったのが下の記事。

今後の企業におけるインフラ＆オペレーションに影響を与える10のトレンド

＠ＩＴさんは定番という感じですね。昔から随分お世話になっています。

先日ご紹介した芦屋広太氏のコラムを知ったのも＠ITさんだったと思います。

特に目を引いたのが記事冒頭の一文。

　「インフラ＆オペレーション（I＆O）で肝心なのは、もはやハードウェアやソフトウェアではない。ビジネスニーズを満たすサービスを提供することが肝心だ。インフラの未来がどこにあるかについては、あらゆる可能性がある。それを決めるのは、ビジネスでインフラをどう使うかだ」（ウィンザー氏）

私みたいな古い人間は、それこそメモリは640KBの時代を生きてきたので、

”インフラといえばハードウェア”みたいな感覚なのですが。

若者世代にとってのインフラとはどのようなものになるのでしょうね。

ネットワーク同様、実体の見えづらいベールにくるまれた何か。

何がどうなって出来上がる”モノ”なのかを意識する事なく、”何が出来る”という視点で、

サービスのように見えるのでしょうかね。

水のように、電気のように、本当は何か誰かが供給してくれているのだけど、

当たり前のように提供されるサービス。

本当の意味での”インフラ”になっていくのかも知れません。

さて、話を戻してインフラ、この先。

前述の記事中で、現在の職場にすぐ効きそうな（というか取り組み中の）ポイントを一つ。

それが、「トレンド6：デジタルダイバーシティの管理」の中で課題として挙げられている、

“分析まひ”からの脱却、正確なインベントリの維持、可視化不足による膨大な無駄の回避、資産管理

ですね。

忙しい事を理由に管理をサボる事で、更なる忙しさを招くサイクルの原点ですね。

ウェブサイトのブックマーク整理に似ていると思います。

ブックマークする時に、単にお気に入りに追加するのか、分類をその時に考えるのか、

既に分類された領域に登録するのか、ブラウザのブックマーク機能に頼らず別管理するのか、

やり方は色々あると思います。

ただ、一旦適当に扱った情報を後から整理するのは非常に非常に非常にコストが掛かるものです。

これはどなたも経験があると思います。

その為、これはこうやって管理しよう、とそれぞれに知恵を絞る訳ですし、

整理術の本がたくさん売れる訳です。

話が逸れそうなので元に戻しますと。

きちんと情報を管理出来ない事が様々な無駄を招き、

それが「情報を必要とする際の行動コスト」に跳ね返る。

場合によっては、情報の見落としによるトラブルへと発展する。

だからこそ軽視してはならない管理項目なんだと思います。

ここで何より大事だと感じるのが”決めたルール通りに行動するかどうか”です。

結局色々な管理基準を定めて運用を初めても、忙しさを理由にサボってしまっては、

全く何も意味がなくなってしまいますので。

日本人は謹厳実直、と表現されるのをよく見ますが、それなのに何故こんなことに？

答えは簡単だと思っているのですが、日本人は謹厳実直なのではなくて、

人の目を気にして見かけをつくろっているのでしょう。

だから、人の目につかない所で手を抜いたりいい加減な事をする。

縁の下の管理業務の杜撰さに、そういった側面が現れているのではないでしょうか。

未来を考えるよりも、足元をちゃんと固めるべきではないか。

そんな風に感じた「インフラ、この先」考察でした。

『プログラマーは延々プログラムだけ書いてるから人と喋らなくていい仕事』

みたいなイメージって、風聞としては耳にしたことがありますけど。

現実にそう思ってる人って居るんでしょうか。

確かに、ほぼ語らずに与えられた仕様に沿って、

黙々とコーディングしてる方もいらっしゃいますので、

そういう人がいない訳でもないですが。

仕様書だけ渡されて会話というか対話せずに仕事が完結する、

って事、有り得るのでしょうか。

完璧な仕様書とそれを作れる現場を知らないだけで、

大昔にウィザードと呼ばれたような人達が跳梁跋扈する最前線では

そういう仕事が当たり前なのでしょうか…

書きながら何となく自分の住んでる場所がぬるま湯なのかと

不安感が首をもたげてきたのですが。

別に明日明後日に住処を変えるでもなし、忘れようと思います。

言いたかったのは、仕事するのにコミュニケーション能力って大事で、

別にプログラマだからって変わらないよ！って事です。

前述したような完璧な仕様書でなければ、

製造の最中に実装について「どうあるのが正解なのか？」と

疑問が湧く事が多々あると思います。

他者は分かりませんが、私はありました。多々。

納得出来てコードに落とせるまで、

設計したSEを捕まえて延々対話してました。

コードをどのように書くか、はプログラマの力で成す事で、

コードが動いた結果がどうなる(べき)か、は設計者が決める事、

だと言う事がよく判っていなかったプログラマ時代。

忙しいSEさんに延々相手してもらう事をとても申し訳なく思ってました。

今なら「こんな適当な設計で何を作るつもり？」と突き返してますね。

そんな当時一緒の現場に居た開発者に、

「仕様書に書いてない事は何もしません」

というスタンスの方が居られました。

あのぐらい割り切れるのはすごいなと思ってました。

仕様書の内容が矛盾しててもそのまま実装して、

テストでおかしな結果になっても「仕様通り」と言い張る。

確かに仰る通りなんですけど、それで良い訳ないよね？

とSEが指摘しても

「設計を勝手に変えるのは良いんですか」と宣う。

ダメに決まってるけど、仰る通りなんですけど。

なんで「不備の仕様を放置する」か「仕様を勝手に変更する」の二択なの。

何かおかしいよ？どこ？これ。ふんふんそういうケースもあるのか。

って、５分くらいの対話で事足りる事なのに…

開発者が設計者に不備を伝えるのも、管理者が問題点を拾いあげるのも、

設計者が不要な仕様変更を怒らせずに断るのも、

コミュニケーション能力の側面なんだろうなと思います。

本当に言いたい事をうまく伝える。相手の言い分をうまく理解する。

どちらもとても難易度の高い事ではありますが。

よいコミュニケーションは仕事をうまく進めてくれて、

その時は大変でも最後には丸く収めてくれる、と感じます。

これらはいわゆる「ヒューマンスキル」と呼ばれるものですが、

若い頃にとても参考にしていたのが、＠ITというサイトで連載されていた

芦屋広太氏のコラムでした。

メールの書き方から、対話シナリオの考え方、物事の伝え方、

いろんな観点で芦屋氏の影響を受けたと思います。

古いコラムなので今読めるか分からないのですが、

こちらの書籍が同ジャンルの内容でしたので、オススメしたいと思います。

ビジネス文章クリニック 気になる「症状」治します！ [ 芦屋広太 ] 価格：1980円（税込、送料無料) (2020/3/28時点) 楽天で購入

今の現場は７時５５分出社で、なかなか朝がツライです。

毎日眠くて眠くてたまに寝過ごしながら業務に勤しんでおります。

さてメシのタネですね。。。

私自身は、良くも悪くも思うままに仕事をしています。

一応リピート案件も多いので、クライアントもサービス提供先も、

一定の満足は得て頂いているのだと思います。

ここ数年は、サービス提供先企業のIT担当者から

直接御連絡を頂く事も増えてきており、

ただただありがたいの一言ですね。。。

ともあれ、当たり前の事しかやってないのですが、

こんな高卒SE（※いきさつ）でも食っていけてるのは、

あるプロジェクトのマネージャに言われた事が、

一つのポイントなのかなと感じています。

「○○さん(=わたし)は、グレーゾーンをきっちり埋めてくれるよね」

当たり前の事しかしてないつもりなんですけどね。

分業体制という今の世の仕組がうまく自分にマッチしてるのかも知れません。

分業すれば当然自分の範囲という区切りが出来ますが、

それはあくまで「全体の一部」なのであり、

前後、最初から最後、がキチィンと繫がっていなければなりません。

こういった「全体の一部」を作っている時に生じる

疑問、不明点、そういったものを

「明示されてないから好きなようにしていい」

と考えるのか

「明文化されていない件のコンセンサスを得る必要がある」

と考えるのか、そしてそれを

「偉い人がまとめる事（であって自分の仕事ではない）」

と考えるのか。

人それぞれでしょうけど、私はそれがハッキリしていないとイヤなタチで、

こういう事で合ってるよね？こういう認識でお互い揃ってるよね？

などと、ほうぼうに聞き回る事になります。

・判っているけど自分の仕事じゃないから言わなかった、

・このままならトラブるのは当たり前だと思ってた、

みたいに嘯く人もぼちぼち見かけるのですが。

そんなにIT業界には仕事が溢れてるのでしょうか。

私は常に自分が今後も仕事が頂けるか不安で不安で・・・

分のやるべき範囲はここからここまでなのだから、

範囲外の仕事は（たとえ全体がどうなろうと）やりません、

みたいな態度で、次も仕事もらえるような気がしません。

プロジェクトが成功して、満足頂けて、

それで初めて我々SEのやる事に価値が生まれるのだ、

と考えていますし。

そもそもIT部門って、システムの導入効果が見えないと、

ただお金食うだけの部署ですしね。

仕事（≒プロジェクト）が問題なく終わるために、

それだけの仕事でいいのか？

って事です。

自分の仕事が自分の満足いくレベルに達する為に、必要な事はすべてやる。

それが、私にとっての「当たり前の仕事」だったというだけです。

余計な事までやる意味が一体何があるんだ、

と思う方も居るかも知れませんが。

昨日のエントリを見返しと、タイトルが　の　ばっかりですね…

ということで、ちょっとだけタイトルを変えてみました。

今日から仕事の話をボチボチと書いていこうかなと思います。

そもそもインフラSEって何をするのか？と言いますと。

多分、業種や立場でかなり内容に差があるのではないかと思います。

企画が必要な人は最新情報を追いかけてるでしょうし、

管理が必要な人は過去実績の把握に務めるのでしょうし、

構築が必要な人はその具体的作業を深堀りするのでしょう。

ネットワークを絡めて考える必要もあれば、

セキュリティを意識して検討する必要があったり、

現行資産を可能な限り活用できるプランニングだとか。

私は主に設計～導入までの業務に従事しています。

だいたいのパターンで考えると、

１．要件定義があって

２．稼働中システムについて調査して、

３．１と２の情報を元に環境や運用の設計を行い、

４．設計した環境を構築する。

５．出来上がった環境が設計意図通りに動作するかをテストし、

６．アプリケーションを含めたシステム全体のテストを経て、

７．本番稼働を迎える

といった流れが多いですね。

世の中にはデスマーチの話がたくさん転がっていて、

私自身も朝７時出社の深夜２時退社などを経験してきましたが、

携わったプロジェクトの本番稼働が遅れた事はありません。

運なのか巡り合わせなのか、幸せな事なんだと思います。

インフラSEに必要なスキルとしては、

ノイマン型コンピュータの構成が理解できている、

が最低限の知識レベルになるかと思います。

ここに、ネットワーク的な素養としてTCP/IPの知識であるとか、

データベース関連の素養としてRDBMSの知識であるいった、

コンピュータ上で動作するものについての理解が求められます。

開発だけやってるメンバーなんかは、

ちょっと○○を××したいから準備しておいて！

なんて軽く言ってくるのですが、

その為に必要になるバックボーンについては、

全くといっていいほど無知な事が多いです。

コンピュータは動くもの、やりたい事は出来るもの、

といった「当たり前」を提供するのが、

インフラSEに求められる仕事の一つです。

こういう無茶振り依頼をなるべく簡素に、間違いなく、

素早く完了する為の方法を編み出していく事も、

インフラSEの仕事（というより業務改善）なのでしょう。

その為には、WindowsバッチやUNIXシェルの作成も必要ですし、

あるデータを参照するのに、テキスト／Excel／DB化のどれがいいか、

判断出来る力も求められます。

管理対象となる機器だけでなく、そういった自作ツールなどの情報も、

業務の引継を意識して普段から整理・可視化する事も必要になります。

プログラマに比べて広範囲な知識を求められるケースが多い、

というのが特徴なのかも知れません。

今回は、ここまで。