インフラSEのぼちぼち備忘録

非登録セキスぺの情シスがMicrosoft関連技術(Azure、Windows、Exchange、SystemCenter、SQL、Powershell)を中心とした備忘録を残していきます。圧倒的にインフラよりです。たまにネットワークのことも書きます。※本アカウントの発信内容、その他は所属する組織の見解ではありません。

SaaSを使いこなすために

さてクラウドサービスを使いこなすと言った際に、IaaS、PaaS、SaaSと言うものがありますが 手っ取り早く一人のユーザーとして価値を得られるのはSaaSかと思います。

IaaSやPaaS、もう少し拡大するとKubernetesやOpenShiftも凄く便利ではあるんですけど アプリの開発やインフラのメンテは必要ですので敷居が高い。

一方、SaaSは価値が得られるまでの期間が短い、敷居が低いのがメリットだと思います。

ただし敷居があまりにも低いので悩ましい状況も発生していて 何故導入するのか?と言う議論、得たい利便性についてはどうしても、 著名なプロダクトが有する機能の紹介に止まっているのでは?と感じています。

例えばOffice365やGSuiteです。 以前から言われていることですが、クラウドの比較表を作るのは不毛だなと思います。

著名ツールの実力をしるのは良いことですし、情シス担当者間のコミュニケーションとして へーそうなんだ!今度試してみようかな!と言うコミュニティでの情報交換は有益だと思います。

Aさん:GSuiteのスプレッドシートだと複数ユーザーで同時共同編集ができて便利だからGSuiteにしました!! Bさん:いやいやOffice365のExcelもそれでますよ!

みたいな。

でも実際に現場に、どっち入れる?どう使わせる?というオーナーシップをとる際に あまりにも便利な機能が多い故にHowにばかり思考が集中する傾向があるなと感じています。

ユーザーストーリーやユーザーイベントを検証しなくても結構つかえてしまうので、 コミュニケーションや意思決定と言ったWhyがブラックボックス化するのを感じます。

便利なツールを知ることは大切ですが、多機能だから、とか、流行ってたから!とか やめた方がいいですね。

デメリットとして顕著に現れるのは、グループウェアの導入を推進した人がいなくなった 引き継がれた後任を任命する時です。

何故導入されたのか、腹落ちしない担当者が地獄を見ます。 如何せん現場に導入してしまっているので、今更ツールの変更や廃止もできない状況になりがちです。

じゃあどうすればいいと考えているのか?ですが

基本的に、著名な機能を知ると同時にやユーザーのペルソナを考えて、 便利に利用できるイベントストームの仮説を立てましょう。

例えばとてもザックリですが。 私はユーザー会でのプレゼンテーションを作ろうと思っているAです。

1.ライセンスを気にしなくて良くかつソコソコ使い勝手のいいテンプレート豊富なサンプルから選んで利用したい。 2.構成図とかを描きたいので人やパソコンなどの基本的なアイコンセットが充実していると作りやすい方がいい。 3.プレゼン会場にはパソコンを持ち込んでプロジェクターに写すことになるが回線状況が直前までわからないのでローカル端末に資料を準備しておきたい。

などです。

アイコンセットが標準で用意されているか?などは機能的には大したことないですが Aさんのユーザービリティとしては大切です。

プロダクト開発ではユーザーストーリーマッピングと言う手法があります。 SaaSなので機能開発は必要ありませんが、SaaSを組織で有効活用するため、改めてなぜ既存のSaaSが導入されているのかを整理するために 以下のような手法を参考にしてみるは有益だと思います^^

https://www.amazon.co.jp/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AA%E3%83%BC%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0-Jeff-Patton/dp/4873117321

今後、いわゆるプログラミングによるプロダクト開発以外の場面にアジャイル開発のエッセンスを取り入れる推進活動を実施していきたいと考えています。

”サポートを使いこなす技術”を身につけるために

あけましておめでとうございます。今年もよろしくお願いいたします。

2019年末に 2つの記事を書きました。

1.(ITベンダー)サポート使いこなし宣言

tech-okzk.hatenablog.com

2.(ITベンダー)サポート使いこなし宣言の背後にある原則

tech-okzk.hatenablog.com


経緯

f:id:kurone810:20191231234324p:plain


クリスマスの日に宇田センセーのツイートに書いてみようかな?と思ったのが始まり。

TLにあつまる議論を確認

f:id:kurone810:20191231234627p:plain


どんな事を書いても、読む人は元々ひどい人じゃないので・・・というあきらめに近い意見。一理ある。

f:id:kurone810:20191231234946p:plain


当事者意識がない人、とか、本質じゃないことに固執する。

このあたりの感覚も共感するとともにサポートにおける”本質”とは何か? 認識のズレは議論すべき価値がありそうだなと思いました。

技術的なHow toについてはある程度既存のドキュメントが充実している

aws.amazon.com

技術的なサポートを円滑に進めるHow toについてはTLでよだれいぬさんが紹介しているAWSのサイトとか参考になるなと思いました。 若干AWS特有な表現や事情もありますが、 読み替え可能な一般的な注意点だとおもいます。

正直、これ読んどけば良いという感はある。

具体的なHow toではなく、ユーザー側の価値基準や心構えを書きたい

ぼんやりと、以下のようなことを考えながら書きました。

  • 物事迅速に進めるための心構えとしてアジャイルソフトウェア開発宣言は参考になるし、開発者以外にもぜひ一度読んでもらいたい。
  • 参考にはなるが、読み替えた方がはまりやすい表現も多いので少し手を入れよう



興味がある人は以下も読んでみてください。

私は大手インフラ系ユーザー情シスとして、またはパートナー企業として様々なITベンダーと取引してきました。

割と早めにテクニカルリード的なポジションになったことから技術的な相談窓口となり、 大小さまざまな課題に対してITベンダーのサポートの力もお借りしつつ解決してきました。

結果として、私の不勉強、時には製品のバグ等原因は様々でしたが、 チームとして取り組む際に嫌なコミュニケーションをする人が多かった。

1.エンドユーザーからのクレームをサポートに伝え、どうしてくれるんだとプレッシャーをかける人
2.復旧に時間がかかっているのをサポートの回答が遅いからだと責任転嫁の言い訳をする人
3.既存の運用手順に無いログの取得などは出来ないとサポートへのログ提供依頼に非協力な人
4.とりあえず直せ!と怒鳴る人

もちろん私たちユーザー企業もIT製品、ITサービスを導入して提供しているサービスの担当者であり、そこにはエンドユーザーがおり、一刻も早く状況を改善しないといけないわけで、むしろエンドユーザーからは怒号が飛んだりするわけで・・・。

怒り、焦り、憤り、など感情が出てくることはあります。

が、そこはぐっとこらえ。 エンドユーザーに一刻も早く、サービスを再開するために まず冷静に優先して解決すべき課題は何かを整理したうえでサポートエンジニアに共有した方が結果として迅速に課題が解決される。

また優先度に応じた適切なサポートプランや体制を整え、 必要に応じてステークホルダーの協力を仰ぐのが依頼側の最良だと考えています。

これまでのサポート活用の経験からサポートを使いこなす上では 報・連・相の”相談”ができる関係を築くことが迅速な課題解決、 サポートを使いこなす技術の根幹だと考えています。

本来複雑な課題をシンプルに整理して、サポートに解決を依頼すべきです。 その場合は、課題の報告、状況の連絡だけで1ターン回答が得られる場合も多いです。

しかし、どうしても複雑な課題の解決の場合は、サポートエンジニアと”相談”し課題を整理することから高度な製品知識が必要な場合もあります。

そもそも複雑な事象の場合は課題の"本質"について共通認識を形成することすら容易ではありません。

サポートエンジニアに対して威圧的なコミュニケーションを行うと”相談”ができなくなり、結果として課題解決が遅れます。または、”本質”の認識のズレが後々大きな不満となります。

"相談"というのは非常に高度なコミュニケーションだと考えています。

課題解決まではサポートエンジニアも含めてOne Teamであることが大切であり、 不信をもってサポートに依頼するのは避けた方がよいです。 むしろ、率先してサポートエンジニアの心理的安全を確保するくらいがちょうどよい。

原因が製品バグで不利益を被っているかもしれません。 「そういう謝罪とか、今はどうでもいいから状況の改善に集中しましょう。」

ただ、間違ってほしくないのは過剰にITベンダーの肩を持つわけではないですし、 原因究明や責任追及が無駄だと言っているわけではないです。

心理的安全を確保したのにサポートの品質が良くないだとか、 そもそもお粗末な製品バグが多発するとか、バグではないかもしれないけど製品の理解が難しすぎるとか。

我々ユーザー企業はエンドユーザーにより良いサービスを低価格で提供する 手段としてIT製品やサポートサービスを利用しているのです。目的を見失わないようしましょう。

もし自分たちに適したサービス、製品じゃないと感じたら、 目の前の課題が落ち着いたのちに保証や賠償、製品やサービスの乗り換えを実施すればいいのです。

それはそれ、これはこれ。

私は去年の11月から渋谷のメガベンチャーの情シスとして働いています。

今後も様々なベンダー様にお世話になるかと思いますが、 その際はよろしくお願いいたします。

(ITベンダー)サポート使いこなし宣言の背後にある原則

私たちは以下の原則に従う

顧客(エンドユーザー)へのサービス支障の回避を最優先し、 課題解決の優先順位をコントロールします。

サポートエンジニアからの調査依頼については、たとえ手順書の作成や 前例の無い調査ツールの導入承認など社内手続きが手間であっても歓迎します。

サポートエンジニアを味方につけることによって、迅速な課題解決と 社内の技術力を引き揚げます。

ログの提供依頼があった際はできるだけ短い時間で取得し提供します。 すぐに提供できない場合は提供予定の時期を伝えます。

ビジネス側のインパクトや課題認識については共有し 適切な緊急度、サポートプランによる対応を依頼します。

課題解決の意欲に満ちた人々で社内側の体制をととのえます。 担当者にはサポートエンジニアの提案を検証する環境や支援を与え 課題が無事解決されるまで彼らを信頼します。

サポートエンジニアに情報を伝える最も効率的で現実的な方法は 電話です。ただし苛立ち、怒り、といった感情を伝えるのは避けるようにします。

効率的かつ迅速な課題解決こそが最も重要な目的です。

過去にサポートに問い合わせた内容を 社内のナレッジマネジメントに組み込むことでサポートエンジニアを 使いこなす技術の持続可能な改善を促進します。

技術的卓越性と優れたコミュニケーションへの不断の注意が 課題解決への機敏さを高めます。

シンプルさ(ムダなく最優先の課題をサポートエンジニアに依頼する)が本質です。

最良のサポートリクエストから課題解決に至るプロセスは、 サポートエンジニア、社内担当者、ステークホルダーの協調から生み出されます。

もっと効率を高めることができるかを定期的に振り返り それに基づいて自分たちとサポートエンジニア間のやり方を最適に調整します。

<参考>

アジャイル宣言の背後にある原則

技術的なお問い合わせに関するガイドライン - AWS サポート | AWS

(ITベンダー)サポート使いこなし宣言

私たちはITプロダクトの運用における課題解決、 あるいは課題解決を手助けする活動を通じて より良いサポートの使いこなす方法を見つけ出そうとしている。 この活動を通して、私たちは以下の価値に至った。


  • 技術的プライドよりもサポートエンジニアとの対話を、
  • エンドユーザーからの苦情詳細よりもログの提供を、
  • SLA違反の指摘よりもステークホルダーとの協調を、
  • 過去の言質よりも変化への対応を、


価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。


<参考>

アジャイルソフトウェア開発宣言

技術的なお問い合わせに関するガイドライン - AWS サポート | AWS

CampusNetwork-laboの構築 その1 構成検討

前から構想はしていたのですが、少し心に余裕ができたので Hyper-V上にCampusNetworkのラボ環境を作っては消してを繰り返せるように整備していきたいと考えました。

以下の構成を作成してくれるスクリプトを作ってGitHubに公開予定。

f:id:kurone810:20190918022811p:plain
CampusNetwork-labo

とりあえず、ブログを書く癖をつけたいので小出しにしていきたい。

CISSP取得を目指して:コントロールフレームワークについて

ちょこちょこ勉強した内容を残しておこう。

以下の本を試し読み中。なかなか実務にも使えそうな体系だった知識が得られそう。 https://www.amazon.co.jp/dp/475710376X/ref=cm_sw_em_r_mt_dp_U_GfSwDb7G152EH

セキュリティフレームワークにつて

組織でセキュリティ要件を満たすためにコントロールフレームワークを採用することになるよ。

セキュリティフレームワークはISO27001やNIST SP 800-53 Revision4 があるけれども いずれにしても次の性質がある。 1.一貫性 2.測定可能 3.標準化 4.包括的 5.モジュール化

NIST SP 800-53 Revision4 は19のファミリーと285のコントロールで構成される。

個人的に逆に避けた方がいいんだなと解釈したアンチパターン

1.一貫性がなく、特定の手法や声の大きい人によってセキュリティ対策が変わる。 2.測定ができないためにルールが守られているのか、ルールを策定した有用性もわからない 3.標準化がなされておらず比較ができない。指針がないので差を検知できない 4.包括的範囲が考慮されておらず組織固有の拡張性がない 5.モジュール化されておらず、部分的な変更ができない

ユーザー企業によるDX推進エンジニアがエンジニアの処遇改善を目指して経営層に色々と打ち込みに行ってる話。

  • クビを覚悟で上の人に色々と意見をぶつけることで見えてきた色々について書いてみよう。
  • 個人としての処遇を改善したいだけなら改善できそうな会社に転職がおすすめ。チームの処遇を改善したいなら経営層に特攻するしかないかな思ったのがきっかけ。

非エンジニアな管理職が思っているほどコードを書くことだけに興味を持っているわけではない。

  • エンジニアは割と経営層がちゃんと経営をしているかを見ている。所属しているチームのビジョンが明確化されていること、WhyやWhatが重要
  • 自分の技術力で課題解決をしたいと思っているエンジニアは多いけれど、エンジニアにしかわからない課題への取り組みを非エンジニアのマネージャーに説明するのは難しい。(技術的負債とか)

非エンジニアの経営層は技術者のキャリアアップ指標を考える際に資格、知名度などを重視しすぎる。

  • 資格取得は技術力の客観的指標ではあるけれど、技術力を利用してどれだけ会社やチームに貢献したか?を評価されないとモヤモヤする。
  • 資格取得の是非は賛否両論だけれども、少なくとも高度な資格取得には攻略のために時間を費やすことが求められるので、実務課題とは少しズレたところに時間を使うことになる
  • メディア、SNSなどの対外露出がおおいエンジニアは確かに評価しやすいけど黙々とプロダクトを作っているエンジニアと優劣をつけないでほしいし、プロダクトを作ってるエンジニアの処遇の改善を課題として認識してほしい

非エンジニアの経営層が欲しいのは実はエンジニアではなく、広く浅い有識者だったりする。

  • それはエンジニアが考えているエンジニアじゃない可能性が高い。
  • 認識のミスマッチはエンジニアのモチベーションを極端に下げる。
  • 技術力を発揮できる仕事がないのにとりあえずエンジニアを確保しようとすると、確保されたエンジニアとしてもしんどくなる。
  • なんだかんだで結局外部ベンダーに委託前提で話が来るのでエンジニアリングさせてもらえない。

エンジニアが生産性を発揮するためのツールの必要性について、非エンジニアな経営層にもわかる資料作成を要求しがち。

  • エンジニアリング力より資料作成能力とプレゼン能力が重要?
  • それはエンジニアの一部ではあるけど、見落とされるエンジニアが多い。

専門以外の業務を依頼される。

  • 話が違うじゃないか。でも断ると評価が下がるんでしょ?

小さな費用で大きな効果を得られたエンジニアリングより、大規模プロジェクトを大規模な費用で遂行したPMが評価されがち。

  • 炎上しなかったプロジェクトより、炎上して火消しに成功したほうが評価されるマッチポンプ
  • 長期間障害が発生しなかったサービスより、障害が発生したけど復旧に超人的活躍をみせた方が評価されるマッチポンプ

エンジニアを大企業の枠組みで個人評価するとつらい。

  • DBエンジニア、ネットワークエンジニア、WEBエンジニア、クラウドのエンジニア、AIエンジニア、、、流行りはあるけど個人評価で優劣を付けるのは慎重に

もう少し、しっかりとエンジニアが戦っている課題の理解に歩み寄ってほしい。

  • エンジニアの言葉は非エンジニアには習得していない外国語に聞こえるかもしれないけれども先ずは自社のエンジニアと対話してほしい
  • ただエンジニアは目の前の課題をできるだけ早くソフトウェアをリリースしようと頑張っているので、まず対話の重要性を明確に

他社事例を参考にするのはいいけど社内の実情に合うように継続的改善は必要

  • 他社の成功事例を参考にするのはいいと思う。失敗事例からの学びからも目を背けないで
  • 時代はAIだ!ビッグデータだ!IoTだ!とか流行り"だけ"でエンジニアを確保すると碌なことないですよ。