パラダイムシフトを受入れDevOpsエンジニアに進化―若手エンジニア1年の軌跡―

当社のデリバリーを下支えするDevOps関連技術の研究開発を行ったのはエンジニアの桜井裕也です。彼に与えられたミッションは「100人月超のSIプロジェクトをDevOpsで回すこと」でした。従来型であるウォーターフォールでの開発経験しかなかった彼が、DevOpsエンジニアへと変化していく軌跡を語ります
  • eight

従来型のエンジニアに与えられた近代化ミッション

C575e924bb377a59ab8f13af0e67070e0f7166e5
▲DevOpsグループエンジニアの桜井裕也

私は2018年に中途でKeepAliveに入社する以前は、中堅SIerでJavaを中心とした業務システムの開発を行っていました。仕事のスタイルは分業制のウォーターフォールで、20代の私は特定領域の基本設計~開発を担当していました。

そんな私がKeepAliveに転職を決意した理由は2つあります。1つ目は「プロジェクトの全体を見たり、要件定義などの上流工程に携わりたい」と思ったこと。Keep Aliveはコンサルティンググループで上流工程をやっているため、自分のやりたいことがかなえられる環境がありました。

そして2つ目は「DevOpsグループ」の存在です。プロジェクトのグランドデザインを先進的な技術を駆使して行う、そのテクノロジーセットはDevOps関連技術であるというところに、技術者として上流を目指せるキャリアのイメージが描けました。

こうしてKeepAliveに入社したのですが、当時のDevOpsグループは、マイクロサービスやCI/CDを実現するための要素技術を選定していた段階だったため、役割分担をして実証実験を行い、実用可能かをみんなで確認するという活動をしていました。

一方の私は前職時代、近代的な技術に触れ合うことがほとんどなかったため、DevOpsという言葉に対して持つ知識は本やネットの記事で読んだ程度のものでした。そこで、まず行ったのはDevOpsグループの既存の取り組みをキャッチアップすることでした。

こうして与えられたタスクを遂行していき、半年ほど経ったころに既存の取り組みのキャッチアップが一通り終わりました。全体として要素技術のつながり(ツールチェーン)の検証が終わり、プロジェクト適用に向けて最終的なラップアップをしていこうという段階に至ったのです。

そこで、リーダーの成田敦から最終調整のミッション、「100人月超のSIプロジェクトをDevOpsで回すこと」が課せられました。その中で最も困難だった課題は、分業型のウォーターフォール開発を脱却することでした。

チームの断絶をなくすアプリケーションアーキテクチャ

27446b0cb9461cc01f121317d839fe4928e7eb34
▲DevOpsグループのメンバーに相談しながら問題解決

私が、DevOps化を見据えた整備として行ったことは大きく2点です。

1つ目は、DevOpsの思想に照らし合わせて既存の設計技法と実装方法の直した方がいいこと、直さなくてもいいことを峻別するというものです。設計技法の中で真っ先に直すべきと判断したのは旧来のウォーターフォール的なドキュメントフローでした。

当時、画面レイアウトや複雑でない処理のフローチャート、API仕様書などはエクセルのファイルに設計内容として手入力され、実装資源とは直接つながっていない状態でした。

この原因は、業務仕様を理解する人、仕様を可視化する人、可視化された仕様に基づいて実装する人が縦割りになっているという仕組みにありました。

それまでは、クライアントと折衝するSEが業務仕様をパワーポイントにまとめる→フロントエンドエンジニアが資料に沿ってHTMLで紙芝居を書く→サーバサイドエンジニアが動的資源としてシステムに組み込む、という流れでした。

しかし、この進め方では資料・紙芝居・動的資源を都度書き直すというワンクッションが入るので、無駄な作業が発生してしまいます。そこで、これらの中間成果物を排除することで、オーバーヘッドを低減できるのではないかという仮説を立てたのです。

この仮説を受けて改善したのは、プロトタイピングツール(Adobe XD)の導入とリアクティブなフロントエンドフレームワーク (Vue.js)の導入でした。クライアント折衝するSEが、コンポーネント設計に基づいてXDで絵を書くように変更したのです。

こうすることにより、プロトタイプができあがるので紙芝居を起こす必要がなくなり、サーバサイドエンジニアはできたプロトタイプの設計情報にしたがってVue.jsでコーディングし、データ(JSON)をフロントエンドエンジニアに渡すだけという仕組みになりました。

結果として、レイアウトはクライアントと折衝するSEが担当し、フロントエンドエンジニアは描画を行い、サーバサイドエンジニアはデータを扱うという風に、XD上でシームレスに連携する状態ができたのです。

そして、2つ目はソースコードとのダブルメンテナンスになっている設計書の排除でした。当社の開発チームの悪癖として、仕様変更が発生した際にソースコードだけ直して設計書を直さないということが横行していたのです。

この課題の本質的な問題は、ウォーターフォールは遡上するのに体力を使うということです。

そのため、ドキュメントフローはソースコードの生成に寄与しないものは廃止する(設計書がないなら、ソースコードを読むべきという考え方)。逆に簡単にソースコードを生成することができ、かつテスト仕様書の生成にも流用できる残すべき設計書をAPI仕様書や画面項目定義書と決めました。

上記2点の改善によって、ウォーターフォール型の課題をある程度クリアできたと思っています。

その一方で、従来のやり方から直さなくても良いという点もありました。それは当社のサービス指向(SOA)に基づいた設計思想です。当社のアーキテクチャは以前から業務ロジックがSOAに基づきREST-API化されていました。

このため、マイクロサービスを見据えたときに従来の設計粒度がそのまま利用できました。DevOpsにおけるマイクロサービスの考え方はSOAそのものだったのです。

こうして、一連のアプリ周りの整備が整ってきたころ、プロジェクトへの導入が決まりました。しかし、そこで直面した壁がインフラだったのです。

苦手分野のインフラ -自動運転を目指してー

9597ec8db9bfeca732a9f04b22a653ba99ab7609
▲手順は一旦ビジュアライズする

プロジェクトへの展開が決まり、私の単独開拓ミッションが降りてきました。それは、インフラ・ミドルウェアレイヤの基盤整備およびその手順化にあたり、「コンテナ技術の導入」と「CI/CDの導入」、「スノーフレークサーバを排除してイミュータブルにすること(IaC)」の3つでした。

この取り組みで最も悩んだのは、「なぜ従来型ではいけないのか」で、そうすることによるメリットに理解が及ばなかった点です。

インフラはオンプレミスである300以上の画面から構成される基幹システムであるという特徴があったため、一見すると、従来型のウォーターフォールで進めたほうが良さそうな案件だと感じていました。

そうは言うものの、ミッションの達成に向けてWEBサイトや技術書を読み漁って手順を模索していきました。まずはコンテナオーケストレーションを実現するためにKubernetesを学習しました。まだ世の中で事例が少ない技術であったため調査には苦労しましたね。

次に、Gitを活用してCI/CDのしくみを構築しました。ここでは技術や仕組みの理解というより構成管理やリリース管理の考え方を体系的に理解することに苦労しました。

そして、最後にこれらに対して「手順を模索する人」と「手順をなぞって確かめる人」に分けて、確立された手順をAnsible化することでイミュータブルな状態を実現しました。

しかし、ここまでやっておいてなんですが、なぜ従来のやり方ではいけないのか、このようなやり方をすることで実際にどのようなメリットが出るのかは、まだピンと来ていませんでした。

しかし、実際に導入を開始してから、腑に落ちました。このプロジェクトに先のアセットを導入したことで、開発中から効果が実感できたのです。少しずつできあがってくるアプリケーションをコンテナに細分化してデプロイしたところ、完成のイメージがつきやすくなりました。

また、どこまでできているのかも一目瞭然になりました。それだけではなく、Kubernetesの自律運転機能のすごさを体験できました。壊れたら自動的に復旧してくれるので、開発中のサーバ群のお守りをすることはほとんどなかったのです。

このような流れで調査・実験・整備を経て実用に至り、従来型のエンジニアだった私が晴れてDevOpsエンジニアになることができました。

今つながっていない部分も全部つなげていきたい

3d827c017b3c32b4fd3101a390daed3973f76e2f
▲日々楽しみながら新しいことに取り組む

転職してからの1年間は、不安の連続でした。自分の開拓したアセットが、プロジェクトで使われることに対してなかなか自信が持てなかったのです。そんなとき、ひとつのやり方に固執して迷子になるより別のやり方をとることで解決することもありました。

仕事の進め方の肝は、「今やっているやり方が本当に正しいのかを疑うこと」です。4つくらいは試した上で最も適切なやり方をチョイスすることが迷子にならない秘訣とわかりましたね。

今後挑戦してみたいことは、設計プロセスのさらなる自動化です。現在は、世の中的にもできていないと思いますが、できればXDから画面項目定義書と画面のソースコードを自動生成したいと考えています。

それから、テストの自動化についても深掘りしたいです。現状、単体テストや結合テストの自動化はツール化されているものの、運用中システムの障害時に自律運転で自動復旧するかは未知なので、そのテストについても絶賛模索中です。

私は新しい技術に挑戦するということは、未知なるフィールドへの探検だと思っています。そこで見つけたものは宝物のようで、非常にテンションが上がります。ここKeepAliveは、いつだって知的好奇心を満足させてくれる現場だと感じています。これから、フィーリングの合う仲間がさらに増え、ともに働いていけたら最高ですね。

関連ストーリー

注目ストーリー