#業界あるある
情シスがやりがちな失敗を書いてみる
失敗には必ず原因がある この考え方はわりと大事だと思っております。ちなみにこの本は良書。
私も大なり小なり失敗を繰り返して生きていますが(´;ω;｀)、振り返ることがチョー大事。
右から左に流していたら大事故になっていた これは結構ありますね。障害系で、傷口が広がって大惨事になっていたということは結構あるのです。
こういうのって、最初のうちは大したことなくて、上司に報告しても「ふーん、まあ
レスポンスを早くするためのビジネスメールの工夫
返事が返ってこないことが遅延につながる 情シスって、メールが多い部署だと思います。バックログなんかも使いますけど、連絡やら相談やら、チャットで済まない案件はそこそこある。
しかし、大事なメールほど返事が返ってこないことってありませんか。
返ってきたらこちらの想定と大きく違っていたりしてね。
「こちら都合」で送るのはＮＧ 割と大事なメールの返事が返ってこなくてマネージャー（私）がフォローするこ
どれくらいの勝算をもって行動するのか、それが問題だ
勝算を意識して行動するのは社会人の基本 先日こんな記事を書きましたが、もちろん失敗したいなんて思っていないわけで、勝算を意識して行動するようにしています。
「ヒト・カネ・技術」の３つの要素で考えてみる 課題の内容によりますが、私はこうしています。
情シスタスクで発生してくる課題の多くは「ヒト・カネ・技術」の問題になってくるかと思っています。
めんどうくさいのは、一つだけではなく、この３つの
情シスマネージャー、高ストレスが続くときの気分転換方法を考える
情シスマネージャーは誰もやりたがらない？ これはずっと思ってまして、つぶれる人多いんですよ。ぶっちゃけ。
そもそもタスクが多くて、常に高負荷的な感じというかね。
だから弊社の場合、情シスマネージャーをやりたがる人が少ない。
万年の人手不足であります…！
私のように「なりたい」と思ってなるケースは割と珍しい、超久しぶりだったらしい。
しかしまあ、いろいろとやってみて正直「合っているな」とは
標準化と情シス（その２）
以前、こんな記事を書きましたが、このときはインフラ環境面のところの標準化をしていましたが、もう少し広い話をし始めています。
標準環境の整備 弊社の場合、ずっと大型機がメインだったこともあり、ハードウェアの環境を標準化するという考え方がありませんでした。
人によっては、
「環境？知らねーよ、ベンダーに聞けよ」
という感じ。
これではいけませんので、クラウド移行とあわせて下記のようなプロ
情シスでやりがいのある仕事って何だろう？と考えてみる
#はたらいて笑顔になれた瞬間 の参加記事です。
大規模システムリリース時の達成感はすごいぞ なんといってもここです。苦労しただけ達成感がある感じ。
以前お客様向けサービスを一斉に刷新したことがあって、いろいろとえらい目にあったのですが、リリース時の達成感はすごかったです。
ドーパミンでまくり。
そして、利用しているお客様の声が聞こえると、さらに上がります。
きれいごとばかりじゃない
40代情シス女子、プロジェクト炎上の火消しに走るの巻
山ばかり登っていても始まりませんので、火消しに走ってみたぞ。
意思決定しないといけないポイントをまとめる まずやったのはこれ。
かなり大きな意思決定をしないといけないのに数か月ユーザ側が「できない！」と止まってしまっていたので、これを何とかしないといけません。
こうなってしまうとマネージャーではなく、プロジェクトオーナーの出番であります…！
やったことは下記。
さあ、決めよう！ 今
直観って割と大事だよねという話
判断には直感を大事にしています ここに書きましたが、わりと大規模事象を経験しています。
とくにこのAWS障害ではしんどい判断を迫られました。やったことないし、うまくいかなかったときの影響が大きい。
しかしこれは絶対にやらなければならないと思っていたので、説明をもらったうえで判断をしました。ほぼ直感。
直感を覆す要素がないかを会議で確認する 上の障害では、すべてが終わったあと、インフラチ
マルチベンダーでやっていくことの利点と欠点について
以前ちらっとベンダーコントロールについて書きましたが、一社に委託するというのは先方の力が強くなってしまうという問題があります。
となると、マルチベンダーという考え方が出てくるわけですが、これもこれでなかなかに大変です。
情シスが専門性を持つ必要がある ベンダー決まってないので、何かを導入するときには、ある程度の構成を考えて「この部分はこのベンダーに」といった形で相見積を取っていくわけですね。