FIXER cloud.config Tech Blog

入社1年目が書く「Red Hat Summit: Connect | Japan」参加レポート

2022年11月30日 10時00分更新

文● 中山翔馬／FIXER

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「新卒が書く Red Hat Summit: Connect | Japan 参加レポート」を再編集したものです。

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

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

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

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

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

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

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

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

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

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

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

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

データのシフト（基幹データ活用）
アプリのシフト（連携強化）
開発スタイルのシフト（自動化）
運用のシフト（効率化）

　既存アプリをどんどんコンテナ化・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の原則には「顧客満足度を最優先し～」といったような非常に耳障りのいい文言がいくつか存在しますが、そればかり見てしまいアジャイル開発の難しい側面を無視してしまうとやはりどこかで無理が生じて倒れる、なるほどと思いました。

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