入社して初めてのオフラインイベントに参加してきたので、参加レポートという形でその一部を紹介します！

DX に向けた最適なクラウドリフト・シフトを実現するためには

富士通さんが社内で蓄積したクラウドリフト・シフトを成功させるためのポイントを解説、それらを取り入れた FJcloud の紹介をするセッションでした。

クラウドを主として仕事をしているとクラウドリフト・シフトはいつか必ず携わる機会があるだろうと思い、参考にできる部分がないか聞いていました。

まずクラウドの選定から着眼点を意識する必要があるとのことで、

• 従来のクラウド選定 : 主軸はインフラ的観点
• 理想のクラウド選定 : 主軸はアプリ的観点

このようにクラウドを選定する際はアプリ視点でマッチしているかどうかを見る必要があるようです。確かにクラウドと聞くとインフラのイメージが強いような気もしますが、実際にアプリを載せて動かすときにやりたいこととミスマッチしてしまいがちだとか。

クラウドリフトのポイント4つ

• 保守のライフサイクルを変えない
• システム構成を極力変えない
• バッチジョブを変えない
• 高信頼運用を変えない

クラウドリフトの際に陥りがちなパターンとして、「クラウド」に移行するからと既存の構成を無理くりクラウドに当てはめようとしてしまい動作することにはするがちょっとした問題が発生した際に対応に困ってしまうのだとか。

あくまでメインは「クラウド」ではなくシステムそのものですよ、というように聞こえました。

既存システムに最適な FJcloud のシフトパターン

1. データのシフト(基幹データ活用)
2. アプリのシフト(連携強化)
3. 開発スタイルのシフト(自動化)
4. 運用のシフト(効率化)

既存アプリをどんどんコンテナ化・API 化していき、アジャイル・DevOps の立ち上げにより運用を簡易化することで大規模なエンタープライズ開発に適した開発手法を作っていくことが重要ということでした。

また、このセッションで特に印象に残ったのが「既存アプリのデジタル化対応でクラウド技術者要員不足を解消」というテーマでした。

このお話の課題というのが、クラウド移行した際にコンテナ・OSS に理解のある技術者がおらず、人員確保が難しく困ってしまった…という確かにあちらこちらで起こりそうな課題でした。

そんな課題に対して、構築済みの環境を渡しアプリ移行環境をお膳立てすることで、既存の Java アプリ開発者でも対応を可能にし新たに人材を確保せずともよい状態にしたそうです。これにより想定リードタイムが 2 か月だったものをなんと 2 週間まで短縮したのだとか。確かにこれはコンテナの利点を活かしていて素晴らしいと感じました。

変わるインフラ自動化の世界

「インフラ」や「自動化」という単語が大好物な私にとってはタイトルを見るだけでワクワクしてしまいますね。業務にもすぐに応用できそうで正直なところ一番楽しみにしていたといっても過言ではありません。

話の概要としては、インフラの自動化は従来のものから「自動化 2.0」に移行していってますよ、具体的にこんなポイントがありますよ、というものでした。

そもそも自動化 2.0 とはなんぞや、という話なんですが

従来の自動化は「手順」に着目したものが多く、手順書を自動化ツールなどに置き換えて手順そのものの自動化を行うパターンがデフォルトでした。RedHat さんはこれを自動化 1.0 と呼んでいます。

それに対して自動化 2.0 は手順だけでなく、運用の始まりから終わりまで効率化を目指し「運用のサービス化」をすることでかける工数の大幅削減を狙うものだそうです。

• 自動化がない世界 : 作業の全てを人間が行う
• 自動化 1.0 の世界 : 人間が手作業で行っていたものをツールが補助する(作業の実施者は存在する)
• 自動化 2.0 の世界 : 運用の全てがサービス化されている(作業の実施者は存在しない)

まとめるとこんな感じになります。

Ansible などツールによる補助が入った自動化 1.0 では思ったよりも成果が出ていない…と感じる企業はは多いようで、その原因は自動化するべきポイントを見誤ってしまっていることにあります。実際の運用では実作業が発生する前後に必ず何かしらの「調整業務」が発生します。これは関係者に作業の説明・報告を行ったり、スケジュール調整を行ったり…というものが該当します。　

現在の複雑化・大規模化が進んだシステムにおいては実作業よりもその「調整業務」の占める割合がとても大きくなってしまっているので、実作業のみを自動化・効率化しても成果としては期待値よりも低いものになってしまいます。

自動化 2.0 では運用の全てをサービス化するので、作業者とその関係者の調整業務が発生せず、誰でもそのサービスのボタンを押すだけで運用作業を行うことができます。

そして自動化 2.0 は「自動化のセルフサービス化」から始めるとよいそうです。

自動化 1.0 による手順のツールによる補助・置換ができていれば、作業依頼先にセルフサービスのためのインターフェイスを取り付けるだけでセルフサービス化はできるので、スモールスタートで始めて仕組みをどんどん横展開していくことで自動化 2.0 を進めていきましょうということでした。

お恥ずかしい話ですが、自動化という単語が好きだと言っておきながら自動化 2.0、セルフサービス化というのは初耳でした…

初耳ながらも自動化するべき箇所の着眼点やその考え方にはとても感銘を受け、セッションを聞いていてとてもワクワクしました。この概念はできるだけ早く理解して業務に活用しなければ…！と思い翌日会社で実際の業務に当てはめて考えましたが、自分で納得できるレベルまで落とし込むのにかなり時間を費やしてしまいました…

なんとかして実業務で自動化 2.0 を進めたい気持ちはあるので、何か進展があればまたブログに書こうと思います。

アジャイルなぜ失敗する？

アジャイル開発という単語はこの業界ではとても有名で、FIXER でも基本的に採用している開発手法です。

しかしながら、アジャイル開発にチャレンジしても失敗に終わってしまうパターンも多く、なぜ失敗してしまうのか？という部分をまとめた話でした。

そもそもなぜアジャイル開発が生まれたのかというと今は VUCA の時代である、という背景があります。端的にまとめると現代はとても流動的で少し先の未来のことも誰も予想ができない、予想がとても難しいということです。そんな時代に従来のウォーターフォール開発を行っていては変動していく状況にアジャストできない…ということでどんどんアジャイル開発が主流になっていっているらしいです(そこまで考えたことなかった…)。

本題の「なぜアジャイル失敗する？」の答えは「アジャイルチックな開発」になってしまっているから。とのお話でした。

アジャイル開発には「アジャイル開発 12 の原則」というものが存在し、それに正しく則った開発を行うことで「アジャイル開発」が成立しますが、その原則に則らないような開発をしてしまうと「アジャイルチックな開発」となり、失敗します。

アジャイル開発 12 の原則には「顧客満足度を最優先し～」といったような非常に耳障りのいい文言がいくつか存在しますが、そればかり見てしまいアジャイル開発の難しい側面を無視してしまうとやはりどこかで無理が生じて倒れる、なるほどと思いました。

改めてアジャイル開発というものを意識して業務しなけば、と考えさせられるお話でした。末端のエンジニアであってもこれを意識して仕事をすることで変わることがあるのではないかと感じたので、これから頑張って落とし込んでいきたいと思います。

まとめ

今回のイベントではセッションだけでなく展示ブースも非常に充実しており、そのどれもが興味深く面白い、最高なイベントでした。

セッションでは仕事や業務に対する考え方・方針の話が多く、ブースでは実際に RedHat さんの技術者の方の説明を受けながら(ブースと直接関係のない技術の話も含めて)技術の話ができたので、知的好奇心が最大限刺激されとても楽しかったです。

どんどん今後の業務に活かしてより良いものを作れるエンジニアになりたいと思います！

Red Hat Summit: Connect | Japan のオンラインイベントもあるので気になった方はぜひ！