１．自己紹介

2014年キャリア入社、TIG（Technology Innovation Group）所属の二木です。読み方は「フタキ」ではなく「ニキ」と読みます。メンバーからは「N i K i」といった雰囲気で呼ばれています。入社後は、流通・小売業界の案件にて、インフラ全体を設計/構築/運用するチームに所属し、日々成長を実感しながら過ごしています。

本記事では、フューチャーにおける インフラ設計技法の知財化 を進める活動について報告します。

ちなみに、タイトルの「俺の～」は、二木が整理した内容を中心にまとめるよという意思表示と、目を惹くようなタイトルにしたかったための命名です。

２．はじめに

早速ですが、システム構築におけるインフラとは何を指すでしょうか？
色々な解釈が可能かと思いますが、フューチャーにおけるインフラとは、以下のように定義されています。

『!!!!!! ソースコード以外は全てインフラ領域である !!!!!!』
- ※詳細はこちらの記事をどうぞ

もう一度いいます。「ソースコード以外は全てインフラ領域である」です。
この無限大にスコープが広がりそうな定義のため、私の入社当初は、カバー範囲の広さ・その影響力の大きさに振り回され、プロジェクト規模の大きさもあいまって、うまく立ち回れない日々もありました。

もちろん、フューチャーではこのカバー範囲の広さに対抗するため、多くのシステム開発PJで培った設計成果物が、テンプレートのような形で、だれでも利用可能な形で存在します。

では、すでに過去の成果物が存在するにも関わらず、なぜインフラ設計技法の知財化を進めるかについては、次章で説明します。

３．インフラ知財の整備に取り組むきっかけ

2019年8月時点で、私が対応中のプロジェクトは2019年秋にリリースです。

日々品質向上に取り組んでいますが、その中で反省すべきことがありました。

過去プロジェクトのインフラ知財（設計書、ツールなど）を活用して、高品質なシステムを短納期で構築する予定でしたが、その設計背景・意図を読み解くことをしなかったため、後々の工程で手戻りが発生してしまいました。

３−１．あるべきディレクトリ設計

一例として、オンプレミス環境のディレクトリ設計構築で発生した問題を簡単に説明します。
インフラ知財では、Tomcatディレクトリ配下に、環境・システム種別のディレクトリを作成しています。

図1:インフラ知財のディレクトリ構成

プロジェクト過渡期の環境維持や、運用・保守まで見据えたホスピタリティのある設計になっていました。

３−２．手戻りが発生したディレクトリ設計

インフラ知財をプロジェクトで利用する際、構成をシンプルにしようと、不要と思った環境・システム種別のディレクトリを削除しました。

図2:プロジェクトで設計構築したディレクトリ構成

Tomcatディレクトリ配下に、環境・システム種別のディレクトリがないため、環境維持を行うには非常に分かりづらい設計となっていました。

プロジェクト過渡期にテスト環境が複数面必要となり、現行のディレクトリ構成では環境維持が困難になりました。
結果、本来あるべきディレクトリ構成に変更が必要と気付き、以下のような手戻りが発生しました。

ローカルディレクトリの再作成
NFS領域のディレクトリの再作成
アプリケーションのデプロイ先変更
アプリケーション、ミドルウェア、スクリプトのログ出力先変更
アプリケーション、ミドルウェア、スクリプトの環境変数の設定変更
アプリケーション、ミドルウェア、スクリプトのリリース処理の変更
ジョブ定義の設定変更
監視定義の設定変更
ログ収集の設定変更
ログ参照の設定変更

さくっと書きましたが、それぞれがそこそこ時間が掛かる作業だったので大変な思いをしました。

４．本活動のゴール

現在、同じ失敗繰り返さないために、 利用者が設計背景・意図をしっかりと理解できる よう、インフラ知財の整備を進めています。

タイトルにあるようにインフラデザインパターンのパターンとは、「状況」「問題」「解決」「名前」の4要素で構成されているかと思います ²。ここでいう「解決」「名前」の部分は過去資産でまとまっていましたが、「状況」「問題」の部分も、その設計背景や意図をキチンと明文化することで整理していきます。

この活動により、インフラ知財を誰がどのプロジェクトで利用しても、一定の品質を担保し、かつ、設計・構築やレビューの工数を削減することを実現します。

４−１．対象技術要素

フューチャーでは、オープンな技術を要素別に整理した技術マップがあり、Winners‘ Circleと呼んでいます。

図3:Winners‘ Circle

※全く見せられなくてすいません…

ボカシが強めですが、Winners‘ Circleは以下のような構成になっています。

内側ほどプロジェクトでの利用実績が多数あるMainカテゴリ
- 現時点で顧客への導入実績・ノウハウともに充実しているフューチャーにおける主要技術です
外側ほど今後の利用を前提に技術検証を進めていくWatchカテゴリ
- 導入実績がなく、品質担保の手法や非機能要件がまだ把握できていない技術要素です

Watchカテゴリにあるような、新技術の検証ってわくわくしますし、最先端の技術導入をするような取り組みは、時代を切り開いているようでドヤ顔したくなりますよね。

しかし、本活動ではプロジェクトで利用することを想定しているので、Winners‘ CircleにおけるMainカテゴリを対象としています。

まずは、直近のプロジェクトで扱った技術要素からスタートします。

４−２．実施計画

Winners‘ CircleのMainカテゴリにはまだまだ多数の技術要素が存在するので、以下のようなサイクルを通して、インフラ知財のカバー範囲を拡大していき、全社で利用できるインフラ知財へと発展させて行きたいと考えています。

図4:インフラ知財整備活動の計画

インフラ知財の整備を行う（β版）
インフラエンジニアの興味を引きそうな内容をフューチャー技術ブログに投稿する（仲間を見つける）
2019年を目途にインフラ知財β版を完成させ、正式版ver1.0にする
各プロジェクトにインフラ知財を展開し一緒に育てる
各プロジェクトで育ったインフラ知財をmasterにマージし、バージョンアップしていく

社員の皆さまも、興味がある方はぜひ声をかけてください！一緒にやりましょう。

５．記事掲載予定

本活動を通して、フューチャーのインフラエンジニアがどう品質を高めているか、ニッチな領域を題材として記事を書いていこうと思います。

俺の『ユーザ管理・ディレクトリ管理』
俺の『スクリプト設計・ジョブ管理』
俺の『ログ管理』
俺の『運用監視』

６．おわりに

最後まで読んでいただきありがとうございます。インフラエンジニアとして頑張っている方に共感いただければ幸いです。

そして、俺のシリーズの記事を見て、一緒に働いてみたいと思っていただければ、是非このあたりの職種でエントリーお願いします！

ご意見、ご感想を頂戴できますと、執筆者のモチベーションが上がります。（褒めてください笑）
また、こんな内容を記事に取り上げてほしいなどあればお気軽にご連絡お願いします。

俺のインフラデザインパターン 過去の失敗に学ぶニッチなインフラの話～