社内システムと障害対応
お疲れ様です。
障害対応について
いろいろ、正しい復旧方法とか、どうしたらよいかとか、相手先のシステムが絡むと難しいときがあります。
データ連携方式はいろいろあるかと思いますが、特に問題になるのがリカバリについてです。
単純に過去分ふくめてどーんとやっていいのか、その次のバッチとの兼ね合いをみなければならないのか
どうしたらいいのかわからないときはあります。
結局、相手先のシステムのことがある程度、業務ベースでイメージできないと正しい判断ができないこともあるかと思います。
量がおおいと、画面単位でいちいち影響なんて出してられません
なんか、こういうのいちいち考えるのたいへんだから、誰かがベストプラクティスをまとめたりしていないかなと思って、chatt gpt にも聞いてみたのですが、あんまりまとまってなさそう。
そりゃそう。 それぞれに100% 正解はないのだから。
結局そのシステム画になう役割に応じて正しい方法をとらないといけないし、はたまた、システム的な成約があるかもしれない。
最近、外部バッチ、内部バッチ が大量に各システム事に乱立していて、これらを取りまとめるのがむずかしいなと感じたりする
基本的に、各システムはそれぞれの業務的な役割からそれらを自動化するために出来上がっている。
その、別の目的でできた情報というところに、実は欲しいデータがあると、システムが出来上がってから、その情報がほしいとなり、それらを取りに行きたくなるというところ
想像で話すと、
・商品の入荷出荷管理システム
・商品の価格調査システム（入荷先検討用）
・POSシステム（会計システム）
みたいなものが、あったとすると、chatgptの回答は
-
入荷出荷管理システムと価格調査システム
-
入荷出荷管理システムとPOSシステム
- 入荷データがPOSに送られ、販売可能な商品の情報を更新
- 出荷・販売された商品がPOSに登録されると、入荷出荷システム側の在庫が減少
-
POSシステムと価格調査システム
- POSの販売価格データと競合の販売価格を比較し、価格調査システムが「適正価格か」を分析
- 必要に応じて販売価格の調整を提案
課題（障害発生時の影響）
-
価格調査システムがダウンすると
-
入荷出荷管理システムがダウンすると
- POS側の在庫データが更新されず、在庫切れや過剰販売のリスク
- 仕入れの情報が価格調査システムに反映されず、正確な分析ができない
-
POSシステムがダウンすると
- 店舗での販売が停止し、売上が失われる
- 販売データが入荷出荷管理システムに送られず、在庫の正確な管理が難しくなる
こんな感じのシステム間のつながりが想像できて、ダウンの影響はそうだが、リカバリ方式は複雑になる。
そして、大体の社内システムがこれの何倍も複雑になっているだろう。
ここらへんで、思うのは、
ある程度真面目にならずに、どうやってリカバリできるか、とうより、どうやって諦めるか。
みたいなところ何だと思う。
まあ構成をもっとわかりやすくしたらいいんだろうけどね。
ようは考えても仕方ないし、何をどう判断したって、結局はシステム担当者のせいになるんだよね。
だって、このときに、すくうための手段を講じてなかったの？
なんで？
となってしまう。
これが自システムのみの問題であれば対策は簡単なんだろうが、複数システムが絡むとシステム間の仕様の整合性を取るのは至難なのだ。
だからあれだ、どうせ個々の課題解決で、ふわふわ想像だけで、結果論ではなく、AI判断で60点か、65点かの評価（期待値理論なので、最終的には10点かもしれないし90点かもしれない）をせっせと頭使うのではなく、自分のスキルを上げていって、他の場所で評価されたりしたほうがいいということだろう
かんがえるのはいいけどある程度、限られた時間は自分のために使ったほうがいい。
最終的に10点だったとしても、複雑化したシステム、見えている情報限られた時間内で期待値計算しなければいけないときはある。
時間が無限ならよいが、経済はシステムのために待ってくれないし業務も回らない
以上！
やる気を保つのは難しい
昨日はずーっとひまーでー1日満喫してましたー
という歌詞が頭をよぎるくらい、昨日はずっと暇でした。
友達とそろそろのむかーとも思ったところでしたが、予定があるとのことでした。
ほんとうに、疲れた。
特に、月曜も休日にしようかと思っていたのに、金曜は、22時くらいまで、全然忙しくて、22時以降は働いちゃだめなんだけど上長からも少し許可もらって働いたりして。
でもまあ、普通に考えたら、22時は絶対に過ぎてはならない境界だよねという文化が根づいているは素晴らしいことだと思う。
あれだ、でも、昨日とかもう、最初っから、今日は一日だらけよーと思ってだらけていたから後悔があるわけではない。
どちらかというとそうしないと無理なくらい働いてしまっているのが問題かもしれない。
なんか、1秒も無駄にしている気はしないんだけど、終わらん。
普通にタスクを洗い出してみても多すぎるんだと思う。
やりたいことはたくさんある。
誰かに任せてしまうとうまくいかないかもしれないし、仕様をどうせ把握しなきゃいけないとなると、自分でやってしまいたくなる。
しょうがない。のかもしれない。
ここの仕様ちゃんとわかって作ってる？？
と聞かれたときに答えられないのが何よりも悔しいとおもってしまう。
ただ、ビジネス面→仕様に落とし込むところの仕立てとかに、課題はあるからそこに結構介入してしまうことは、かなり力使う。
まあいいや。
ようは、デジタル面をうまくまわすことも大事だけど、それ以上に、自分のCICDをうまく回して、どこに向かっているのか明確にして、少しづつ良くなっていくことで自分の自尊心みたいなの高めていくことが大切だと思う。
もう少し頑張ってみようと思う
業務効率化みたいなところだと、最近、そもそもタイピング速度をあげてしまうことこそが、近道何じゃないかと思い始めた。
今のところ、平均120,000円位で、頑張って13,000円くらいでる。
ここをなるべく、普段から、15,000円くらいは出るみたいなところまで将来的に持っていきたいなと思う。
多分これを超えるとなるとキー配列云々の話になりそうなきがするけど、
それに関しては、仕事のパソコンの配列弄りたくないから、そこまで極めたいとは思わない。
ちょっとずつ前に進もう
あと、やっぱりこの記事も毎週上げるようにしよう
振り返りという感じで。
集中力を保つ方法
はい。
土曜日も、日曜日もなかなか勉強が手につかず、いまになって、カフェに来て少しやる気が出てきた人です。
なんか、目標を定めることはとても大切なのと同じくらいには、平日に疲れを溜めないためにどうするかということは大切な気がする
勉強したいなとは思う
が、あまり、にも疲れていて、SNSを見てしまう。
最近SNSをある程度制限したほうがいいかなと思い始めた反面、
制限した分、たまに見るとめちゃくちゃ面白いな！！って思うことが多い
クイズノックとかヨビノリとか日常でんがんとか、なんか微妙に勉強になりそうなところとか、変に正当化してこれは見ていてもいいか～～ なんて思って、見てしまう時がある。
本当によいのだろうか？？
なんか、鶴崎さんのストレス解消法みたいなのが、ネタではあると思うけど、”プログラミング” と話していて、確かにそれは、ありだなと思った。
難しいかもしれない
でも勉強もいま、好きな分野を勉強していいと言われているのだkら、すきなところ集中して勉強している分にはそんなに普通に楽しめるはずなんだ
コンフォートゾーン的なのに最近入れていない気がする
もっと集中して行きたい。
あと、一日例えば遅く起きてしまったから今日はいいやみたいな感じのなんか。完璧主義的なところは減らしていきたいと思う。
とりあえずやってみて、これは趣味だと思って、ストレス発散だと思って、とりあえず集中してなくてもやってみる
なんか、あんまり集中してなかったとき用に、一番簡単で、何度も解いたことがある問題を解いてみる。というのもいいと思う。
そんなにむづかしいことじゃないSNSは消耗してしまう。。 時間も、なにも
IF THEN プランニングというがこういうときに良いらしい。
と、望月さん著書の本の中で出てたりする。というか色んな本でよく出てくる。
自分の場合、SNSを見てしまうときどうしたらいいのだろうか。
ひとつあるとして、基本的に家の中で見ていることが多いというところだ。
一人暮らしはまずい。制限がない。もっと、こう、しっかりしなきゃな。
最近、朝早く起きれていない。
８時の起きられているかすら怪しい・・・
そのせいか、よるベッドの中で、ずっとながめてしまう。
しかも、その時間が中毒性高く楽しいと思ってしまっている
これはなんとかしなきゃな。。
よる何とかしなきゃというよりは、朝早くおきるべきなんだろうなと思うところです
社内SEってある意味自由
社内SEを経験して、色々と思うところがある。
裁量と仕事量、適正について
まずは、誰でもできるというところ。
これは、誰でもできるというより、その人のスキル、性格、志向、美徳感覚
こういったものに、そのシステムや方針は大きく傾いて、みんなが合わせることになるというところ。
できるというのは、決められた期待値から、ボーダーがあって、ボーダーを満たせるか満たせないかというところになるが、社内SEだと、そのボーダーを決める事自体が自分自身になったりする。
何が言いたいかというと、今まで、何もシステムがわからなかった人が、そのシステムの社内SEをやっていたとすると、そこに求められる期待値もさがり、それなりに回さざるを得ないことがある。
じゃあ、もっとできるようにと、誰かを投入したとき、期待値があがる。
結局そこに向けてみんなが期待することになる。
なんというか、裁量が多いといえばその通りなのかもしれない。
自分の仕事量も、本気を出せばコントロールできる。
裁量と仕事量、適正については一旦終わり
技術-システムが抱える苦悩ついて
これも、似ている。その人の期待感によって、求められる技術料も上がる。
正直、ソースコードを書くような時間もないので、やりながら、仕事中にスキルが上がることは期待しないほうがいい。
問題は、ITエンジニアから流入してきたときに、前職ですべてやっているからなんとかなるよね？？
っと、期待されたパターンだ。
これは、非常に多いと思うし、エンジニア経験枠で入ってきたならば仕方ないかもしれない。
しかし、そんな、やりながらじゃないとわからないし、ここのこういう操作したときに、ここって、どういうふうな制御になるの？ というところが、ある程度規模も大きくなると即答できなくなってくる。
ましてや、もともとは別のシステムをくっつけたり、話したり、他システムからデータを受け取ったり、整合性を保つために、自身で内部バッチを実行したり
そんなことをしていると、よくわからなくなる。 どんどん複雑になっていく。
しかし、事業部にとって、そこは、興味がない。 こういう施策を投入して、こういう売上をだしたい。 からやりたい。 やりたいという意味と、投資対効果 そういった意味では、ある意味間違っていない。
ただ、資源の投資先として、このシステムでは限界を迎えているかもしれない。そこについて、訴えるのは情シスの責任になるだろう。
だからといって、ここまで複雑化して、綱渡りで、しかし、ぎりぎり整合性を保っているシステムを、「じゃあ新しいのでスッキリ作って」
と言われても、それあ、何が？
となる。
どこまで、次システムで再現するつもりですか？
と。
そうすると、当然、今いる使っているユーザーに影響のない範囲で
と返ってくる。
当たり前のコミュニュケーションに思えて、とても難易度が高いのだ。
この気持ちを理解してはくれるだろう。
だが、そこで具体的にネクストアクションどうしたらよいですか？
と聞かれると、みなだまってしまう。
何が問題かというと、システムの複雑さに対応して、業務も複雑に最適化されてしまっていて、この複雑さを解決するには、業務フローを再定義しなければならないのだ。
一般論
これは、どこの会社でも当たり前に起こり得ることだと思う。
特に、1990年代、ただただ、手作業でやっていたものを、システム化しようとして奮闘して成功してきた会社によくあるだろう
その手作業は、自動化できたとしても、隣で作られたシステムと整合性というところまではあまり考えられていなかった
IPAではサイロ化されたシステムなどと読んでいる。
解決するためにEAなどのフレームワークもでてきたが・・・（詳しくはIPA参照）
まあ、IPAでこういうの書いてるからきっと同じ悩みはあるんだろうなと思ってる。
きっと、ここの解決に乗り出すにはまだ早い気がするから、自分のシステムでとにかく、責任持って進めるというところにフォーカスして地盤固めたい
進捗
やっと、応用情報というか、なんというか勉強にやる気出てきた
別に、応用情報が大切とは思ってない。最近は、SQLも学びたいし、コミュニケーションライン（特に事業部と、開発部）とかしっかり整理したいなと思っている
あとは、ファイルサーバー系の知識がわりと薄いなと感じている
LinuXとかもなんだかんだわかってない。
最近は、Springで開発されていそうなものを、なんとなく携わっているものの、そもそもローカルにSpringすら入っていない
自分が、過去に見てきたところだと、ばりばり、開発に参画してる人が、ソースコードをみながら、なんとなく、事業的な話題にも入ってきて、方針決めたりしていて、ここってどうなってましたっけ？
っていう事業からの問いかけにスムーズに回答していて、いいなあお手本だなあと感じたりしていたところはあっった。
でも、そこは事業会社のなかでも、実際に社内で制作しているからそれができていたのかもしれない
いまのところ、私の会社では、開発はベンダーに任せる風潮があり事実そうだ
開発している暇はななんとなくなさそう
だが、その理由にも、開発部という立ち位置ながらあまり、アプリの仕様がわかっていない
仕様書がないのもそうかもしれんが、やはり、実際に開発してみないとなんとなく、イメージが沸かないところも正直ある。
なるべく、噛み砕いてロジックを聞こうとするものの、結局わからんくなる
もっと、言いたいことはあるなあ
でも、文句ばかり言って、あまり進められない人にもなりたくないから、ある程度自分にある知識だけでしっかり成果だしていきたい
成果主義らしいから、なんか成果出してみたいもんだが、性質上、情シスって感じなわけで、ここって、そんなに成果だせない
まあ、なんかやる気出てきたね。おめでとうって感じです
久々の更新
まあ個人ブログでも久々に更新しようかなと
もう寝るので、ちょっとだけ、てはじめにかいてみるというより、
そもそもこのはてなブログが使えたのかどうかという確認作業。
まあでも、ここにブログを書こうかなと少し思えただけでも、成長なわけです。
最近は、何故か紆余曲折あり、なりたかった社内SEになれました。
やっぱり、自分的にもいいなー と思うところがたくさんさります。
まず、ベンダー側にいたときより、気が楽だと感じています。
納期に追われて、次から次へと依頼されて、よくわからんけど、影響調査してと言われて、ほんとに、影響がないかどうか、自身がなくて、調べに調べまくった結果、遅い何していたんだと言われて、まあなんか、じゃあ多分、AWS側でよしなにやるから、影響なんてないっしょ、と適当に答えるしかないか。となったり。エラーが発生したら、ログから、調査したり、それも、結局、すぐに答えられなくて、サービス停止時間について、説明を求められたりして苦しい言い訳したり。。
でもまあ、それもこれも仕方ないわけでした。必要な作業でした。
ただ、気持ちは重かった。
今は、依頼する側になって、ちょっと、無理な依頼～結構無理な依頼をたくさんしつつ、社内で調整。 でも、まあ自分は考える余裕ができたのかな。
あんまり技術的なことをかけないけど、今も色々、まあやることはある。
少しづつ慣れていこうかなと思いつつ、自分でも開発しないと、なんか、感覚薄れていくし、何より、開発へのマインドが薄れていっている気がする。
今は、絶対に内製化はしない方が良いと思っているこの頃
でも個人的なスキルの観点では、なんか作ってたほうが絶対にいい
おやすみなさい
最強のエンジニアになるための話し方の教科書
今回、気になっていた「最強のエンジニアになるための話し方の教科書」を読みました。
気をつけたいのが、ここで出てくる”エンジニア”というのはITエンジニアではないということです。
たくさんのケーススタディが出てきますが、ITというよりは、他の機械系技術者が遭遇する場面が多いイメージです。
しかし、ITエンジニアでも、プロマネや、上流工程をやっている人にはよく刺さる内容だと思います。
この本の内容を実践することで、話し方の工夫で、かなりの課題をより効率よく解決できると感じましたし、おそらく、残業の低減にもつながると思います。（筆者のツイッタープロフィールから伝わります。）
エンジニアの残業時間が伸びたり、課題が解決しないのは、話し方にあることがほとんどなケースが多いと思うので、気になる方は是非読んでみてください。
CCNA取得しました
一応ご報告です。ネットワークエンジニアでもインフラエンジニアでもないですが、低レイヤーの技術に興味があって、取得しました。
Cisco機器自体触ったことないですが、2ヶ月弱くらいで取得できました。
多分、範囲がとても広いし、合格点数も高いので大変かと思いますが、実際のテストでは、そんなに幅広く細かいとこまで聞かれない印象でした。
点数は960/1000 くらいでした。
攻略法としては、あまり、ネット出でてくる攻略法を信じたりせずに、実際に受けたことがある人の意見をなるべく聞くのが良いと思います。
ping-t をやるのはよいですが、実際のテストはだいぶ雰囲気が違います。
なるべく実際のテストに近い模試を早めに受けてみて何を勉強すべきなのか知っておいたほうが楽でしょう。
TOEIC 600点取得しました
※筆者は、2021年11月時点での英語レベルは中学英語文法が少し怪しいレベルです
最初に筆者を救った本↓↓
いったん、ここはおさえておかないと、後で振り返るのが大変なので、まずやるのがおすすめです。
中学時代に一旦英文法やったことあるひとであれば、一気に進められて復習できるので良いと思います。
2022年 1月30日のTOEICの結果・・・600点でした！！
12月に受けた人生初TOEIC585点だったので微差だけど、嬉しい！
リスニング重視でやったからリスニングの点数50点くらい伸びた！
その代わり今回リーディングが全然だめでした
速読練習全くしてなかったというか、英文ほとんど読んでなかったので、リスニングの問題文すらなかなか読みきれませんでした。
リスニングの点数を上げるためいにも次はリーディング頑張ればもっとスコア伸びそうですね！！
2021年11月中旬にabceedで受けたTOEIC模試が365点だったので、
2021/11 365点
2021/12 585点
2022/1 600点
みたいな感じです！
今はCCNAの勉強が優先だけど、落ち着いたら700点超え狙いたい！
