ssmjp 2019/11 運用設計ガチ会にいってきた話

はじめに

11月のアウトプットが12月開催日直前となってしまい申し訳ありません

クラウド時代の運用設計（鄭昌浩さん）

ちゃんほさんの資料

開始時間に間に合わず、ちゃんほさんのLTは途中から…
制御システム工学の例が出てきたのはとても分かりやすく、クラウド時代は運用業務設計が大事、というのは頷くことばかりでした。

運用エンジニアにとって大事な視点（波田野さん）

はたのさんの資料

AS-ISとTO-BEを考える、TO-BEでどういうアウトカムを得るか、は運用カイゼンのIoTサービスを検討するときも常に考える内容で、相変わらずとても参考になりました。

属人化される部分＝その企業の強み、一般化される部分＝カイゼンの対象
と考えることで、そのままIoTサービスのPoCを回すことができたりします。

ITILの考え方を他業種に適用することで、体系化されたカイゼンを回していけるはずなのですが、はたのさんのおっしゃるとおり、あくまで自らの手の内でやることが良いかなあ、と思います。外部監査になったとたん、縛られるものになってしまうので…

ライフサイクルマネジメント（沢渡あまねさん）

あまねさんの資料

さわやかはいいぞ。
さすがさわやかエヴァンジェリスト。

「おはよう」から「おやすみ」までを想定してデザインする

というキーメッセージでしたが、私のいたハードウェアな会社では、

「ゆりかご」から「墓場」まで　が事業

だったため、共感する部分が多々ありました。

「現在地説明能力」が大切、というのがまたそのとおりで、これはそのまま、どこでどう稼ぐか、という話になり得ると思っています。

全体を通して

運用設計の話、ITだとみんな悩む話なのがすごく伝わってくるんですが、ハードウェア屋だった人間としては、運用設計は一番最初に事業デザインをする段階でやるもの、なので、なぜ「運用でカバー」が発生するのか、それが若干もやもやするところでした。

ハードウェアは、それこそヨーロッパとかで販売する場合、WEEEのように、市場でどうゴミを回収するか、までを確定しないとそもそも上市できない規制があるので、兎にも角にも運用設計、とくに運用業務設計が第一、になります。

この差が何から生まれるのか、それはコストかなあ、と漠然と考えていました。ハードウェアは、保守に行く人間の費用まできっちり考えておかないと、最悪直しに来いと言われたらそこまで物理的に行く必要が出てくるため、コストインパクトがとんでもないことになります。

そこがIT、とくにWebだと見えにくいため、後工程に先送りされていってしまうんでしょう…私はハードウェア屋をやったあとにWeb屋をやりましたが、運用方式設計が整った会社だったため、これはまあしょうがないよね、といったレベルのところが運用になっていたイメージですが、設計がされてない状況だったら、目もあてられない状況になっていたんだろうと考えると、ゾッとしてしまいますね…

はたのさんのおっしゃっていた属人性についても、少し思うところがあり、属人化の果てに何があるのかな、と考えたとき、それはそのまま個人の職務経歴書になるのかな、とフワッと思っています。TO-BEを目指して、お金を産む、それが運用なのかなあ、と。
運用設計されるかた、IoTサービスバンバンつくってほしいなあ…まさにそれが運用…