インフラ設計作業の属人化抑止に向けた活動と効果

一般論文

インフラ設計作業の属人化抑止に向けた活動と効果
神戸事業所

１．まえがき横浜センター 技術第３課
中村 清懇

フラ設計部分となる。
当センターで受託しているインフラ設計では、価格競争

当社神戸事業所横浜センター（以下、当センター）
では、面から低コスト化を強く要望されており、システムを構成す主に電力会社向けのシステム開発を行っており、汎用製るハードウェア、OS、及びミドルウェアの何れも、自社開発製品であるIAサーバと、商用データベースや構成制御製品品や専用製品ではなく、汎用製品を選定する必要がある。

を組み合わせ、構築するシステムインフラの各設計についそれら汎用製品を活用し、最適なインフラ設計を実施するても対応している。

ためには、製品固有の技術知識、知見を有するスキルの

本稿では、このシステムインフラ（以下、インフラ） の各（注1）

設計作業における問題点・課題と、その対策として講じたイ
ンフラ設計ドキュメント生成ツールの開発と活用について紹介する。

高い技術者が必要となるが、そのようなエキスパートは限られている。
開発工程の観点からは、インフラ設計は製品選定やサイジングなどを通じ、システム開発のグランドデザインに深く係わっており、システム開発フェーズの早い段階から要件

２．インフラ設計の問題点・課題の抽出に応じた各仕様を確定している。
しかし、システムの性能、可用性、耐障害性等の非機能要件検討や設計が完了し２．
１ インフラ設計における問題点
当センターで対応しているインフラ設計では、システムを構成する各ハードウェア、OS、及びミドルウェアについて、シていない場合があり、開発の後工程である試験フェーズで多種多様な汎用製品に関するインフラ設計の変更を余儀なくされる場合が多い。

ステム要件に応じた製品の検討、選定の企画から、システ

また、これらの汎用製品は、ライフサイクルが早いため、ム長期安定稼働を実現する最適なパラメータ設定値の決最新製品の技術知識習得、及びインフラチーム内の技術定まで、一連の作業を請け負っている。

展開が間に合わない場合が多い。

図1にシステム開発における、主なインフラ設計について示す。

このような背景から、エキスパートに負荷が集中し、更に属人化が発生しやすい。
図2にインフラ設計における問題点を示す。

図１．システム開発におけるインフラ設計作業

図1の破線部分が、当センターで主に受託しているイン(注 1 ) システムの長期安定稼働のため、信頼性、拡張性、保守性などのシステム要件を考慮し、汎用製品選定からベース環境(サーバー、OS、ミドルウェア、ストレージ、ネットワーク)の構築、試験までを実施すること。

30

図2．インフラ設計における問題点

インフラ設計作業の属人化抑止に向けた活動と効果

図2に示す通り、インフラ設計メンバーの属人化や特定メ

図3に上記2点の課題に対する分析内容を示す。

ンバーの作業負荷集中に伴い、後進の人材育成や技術伝承を妨げ、作業負荷を効率的に分散することが難しく、改善する必要があった。

２．
２ インフラ設計の問題点解消に向けてこれらインフラ設計における問題点を解消するため、インフラ設計メンバーで前述の問題点の深堀、及び要因分析を進めたところ、インフラ設計作業について以下3件の課題がある事が分かった。
（1）設計確認に時間を要する
設計した各パラメータは、対象がOS、ミドルウェアなど多岐にわたる。
また、導入製品のバージョンなどによりパラメー
タ確認方法が異なるため、手順の確認に時間を要する場

図3．インフラ設計作業に必要な対策

図3に示す通り、インフラ設計作業の作業負荷低減を合があった。

図るために、手間のかかる情報採取作業や確認作業の自（2）インフラ設計仕様の反映漏れ動化、共通化が有効と考えた。
また、設計ドキュメントを自インフラ設計の変更内容については、アプリケーション仕動生成し、反映漏れによる環境設定との差異を抑止する

様やシステム要件を理解し、設計変更によるシステム運用事で、エキスパートの技術知識、知見の共有を促進し、技に対する影響度を判断する必要があるため、エキスパート術伝承不足を解消する。

により実施する必要がある。
しかし、そのエキスパートは限

そこで、これら対策に必要となる機能を具備した、インフられており、作業負荷が集中するため、その内容が最終的ラ設計ドキュメント生成ツールを開発した。以下、
このツール

なインフラ設計資料に反映する時間がとれず、記入漏れの主な機能を示す。
なお、これらの機能は一連の動作を全が発生する場合があった。てワンアクションで実行することを前提とし、用途に応じ各（3）設計基準・規約が不十分機能の個別実行も可能となるよう、メニュー形式とした。

インフラ設計を進める上で必要となる設計基準、規約

なお、本機能はRHEL Linux、及びWindowsの各サーは、従来のアプリケーション開発向けに整備されているものバを対象とし、標準機能で動作可能となるよう、shell形式、を流用している。
このため、インフラ設計独自に検討、考慮及びbat形式で作成した。

が必要な箇所を示した規約が整備されておらず、効率的

図4にツール実行時の一連の動作イメージを示す。

な設計作業が出来ていない。
上記3点の課題を解決し、効率的なインフラ設計を実現するため、以下2点の対策を行った。
（1）インフラ設計ドキュメント生成ツール開発（2）インフラ設計ドキュメント規約整備

３．インフラ設計課題の分析と対策
３．
１ インフラ設計ドキュメント生成ツール開発
インフラ設計の作業負荷低減を図り、前節の以下2件の課題を解決するため、どのような改善を行う必要があるか分析を行った。
（1）設計確認に時間を要する

図4．インフラ設計ドキュメント生成ツール実行イメージ（2）インフラ設計仕様の反映漏れ
31

インフラ設計作業の属人化抑止に向けた活動と効果（ⅰ）サーバアクセスツール
 Windows端末、サーバより、定義ファイルに指定したファイル形式や整形すべき情報を定義可能とした。
図7にパラメータ整形ツールの動作イメージを示す。

情報取得対象となるサーバへのアクセス、及びその後の各情報採取に向けた準備を行う。
図5にサーバアクセスツールの動作イメージを示す。

図7．パラメータ整形ツール動作イメージ（ⅳ）ドキュメント整形ツール
図5．サーバアクセスツール動作イメージ（ⅱ）パラメータ取得ツール
 インフラ設計ドキュメントに記載すべき各パラメータ設

 整形された取得パラメータ情報を定義ファイルに指定した整形情報を基に加工し、Excelの設計書形式に変換する。
図8にドキュメント整形ツールの動作イメージを示す。

定値について、指定された定義ファイルを参照し、対象サーバから情報を取得する。
図6にパラメータ取得ツールの動作イメージを示す。

図8．
ドキュメント整形ツール動作イメージ

３．
２ インフラ設計ドキュメント規約整備
前節のツールを最大限活用するためには、そのインプットとなるインフラ設計項目についての定義が不可欠である。
図6．パラメータ取得ツール動作イメージ

しかし、前述のとおり、各自の技術レベルの違いや導入製品固有の情報保持量の違いから、エキスパートに依存せ（ⅲ）パラメータ整形ツールざるをえない状況となっていた。
その状況を解決するため、 取得したパラメータを設計書に変換するために必要インフラ設計メンバーの各自が実施している設計内容を振となる、ファイル形式変更や整形を行う。定義ファイルにり返り、整理した。

32

インフラ設計作業の属人化抑止に向けた活動と効果

その結果、製品固有の項目やシステム要求に依存する

表2．インフラ設計判断項目（抜粋）

部分があるものの、インフラ設計における基本的な考え方や検討項目は、共通化が可能であることが判明した。
そこで、共通化が可能な設計項目、及び汎用製品の製品選定に関する基準を整備した。
図9に設計項目基準化イメージを示す。

図10．インフラ設計項目基準イメージ（抜粋）（2）設計チェックシート
前項の設計作業について、その完了を第三者が確認
図9．設計項目基準化イメージ

また、これら基準に従い設計作業が行われているかを確認するためのチェックシートを追加し、運用として定着で可能となるよう、作業フェーズ別に各インフラ設計完了後の確認項目をチェックシート化し、第三者がチェックする運用を策定した。
図11にそのチェックシートイメージを示す。

きるよう、規約整備を行った。
以下に製品選定・設計項目基準、及び設計チェックシートの詳細を示す。
（1）製品選定、設計項目基準
各案件の担当者で決定している製品選定、及びインフラ設計項目の整理集約を行い、製品選定時に必要な検討項目、及びインフラ設計時の判断基準を決定した。
表1、表2にそれら検討、判断項目の抜粋、図10に設計判断基準のイメージを示す。
表1．製品選定、設計検討項目（抜粋）
図11．設計項目チェックシートイメージ（抜粋）

図11の通り、担当者のセルフチェックの他、第三者の照査を実施する運用を策定した。

４．ツール及び規約の活用と効果前章までのツール開発、及び設計規約の整備を行い、インフラ設計における以下3件の課題に対する効果を確認した。

33

インフラ設計作業の属人化抑止に向けた活動と効果（1）設計確認に時間を要するただいた関係者の方々に深く感謝を申し上げる。

OS、ミドルウェアなど多岐に渡る設計項目の設定確認は、本開発ツールで自動生成されたドキュメントを確認するだけで対応可能となった。各環境に対する確認コマンドの実行、及び実行結果の目視確認が不要となり、確認作業、及び確認ミスが大幅に削減できた。
（2）インフラ設計仕様の反映漏れ
外部仕様や要件変更を要因としたインフラ設計変更の反映は、本開発ツールにより設定変更内容をドキュメント反映出来るようになった。
これにより、ドキュメント修正工数が大幅に削減され、インフラ設計書への反映漏れが抑止できた。
（3）設計基準・規約が不十分
インフラ設計独自の検討項目が明確となったことで、新規要員でも基本設計書の作成が可能となり、基本設計を元にした詳細設計書、運用仕様書、及びパラメータ設計書の設計手戻りが減少した。
また、設計判断の基準やドキュメント作成後の確認運用の明確化により、エキスパートを含め設計作業工数の削減が可能となった。

５．今後の展開
当センターで受託しているシステム開発案件におけるインフラ設計では、市場トレンドに合わせた汎用製品を適用するため、汎用製品のレパートリー拡大に合わせて、各パラメータ設定値の定義をその適用製品に合わせ更新する必要がある。
そのため、今後本開発ツールの定義情報の更新を定期的に実施する運用の策定を進める。
また、本開発ツールでは対応が出来ない汎用製品についても検証を行い、適用範囲の拡充を図る予定である。

６．むすび
本稿では、インフラ設計における問題点解消に向けた対策として、当センターで開発したインフラ設計ドキュメント生成ツール、及びその活用を推進するための運用整備事
例について紹介した。開発したツールは、特定プロジェクトに依存せず、インフラ設計全般での活用が可能である。専門知識が必要となり、属人的になりやすいインフラ設計において、本ツールとその運用例が、インフラ関連業務に従事する技術者の設計作業効率と設計品質向上に寄与する事を期待する。
最後に、本開発及び執筆にあたり、様々な面で支援い
34

執筆者紹介
中村清懇

ナカムラ キヨネ

2002年入社。主に電力会社向け情報システムの設備インフラ設計、開発に従事。現在、神戸事業所横浜センター部技術第３課。