プロジェクト管理ツールの導入と活用基盤の整備

インフラ設計作業の属人化抑止に向けた活動と効果
１．まえがき
当社神戸事業所横浜センター（以下、当センター）では、主に電力会社向けのシステム開発を行っており、汎用製品であるIAサーバと、商用データベースや構成制御製品を組み合わせ、構築するシステムインフラの各設計についても対応している。本稿では、このシステムインフラ（以下、インフラ）（注1）の各設計作業における問題点・課題と、その対策として講じたインフラ設計ドキュメント生成ツールの開発と活用について紹介する。
２．インフラ設計の問題点・課題の抽出
２．１　インフラ設計における問題点当センターで対応しているインフラ設計では、システムを構成する各ハードウェア、OS、及びミドルウェアについて、システム要件に応じた製品の検討、選定の企画から、システム長期安定稼働を実現する最適なパラメータ設定値の決定まで、一連の作業を請け負っている。図1にシステム開発における、主なインフラ設計について示す。図１．システム開発におけるインフラ設計作業図1の破線部分が、当センターで主に受託しているインフラ設計部分となる。当センターで受託しているインフラ設計では、価格競争面から低コスト化を強く要望されており、システムを構成するハードウェア、OS、及びミドルウェアの何れも、自社開発製品や専用製品ではなく、汎用製品を選定する必要がある。それら汎用製品を活用し、最適なインフラ設計を実施するためには、製品固有の技術知識、知見を有するスキルの高い技術者が必要となるが、そのようなエキスパートは限られている。開発工程の観点からは、インフラ設計は製品選定やサイジングなどを通じ、システム開発のグランドデザインに深く係わっており、システム開発フェーズの早い段階から要件に応じた各仕様を確定している。しかし、システムの性能、可用性、耐障害性等の非機能要件検討や設計が完了していない場合があり、開発の後工程である試験フェーズで多種多様な汎用製品に関するインフラ設計の変更を余儀なくされる場合が多い。また、これらの汎用製品は、ライフサイクルが早いため、最新製品の技術知識習得、及びインフラチーム内の技術展開が間に合わない場合が多い。このような背景から、エキスパートに負荷が集中し、更に属人化が発生しやすい。図2にインフラ設計における問題点を示す。図2．インフラ設計における問題点インフラ設計作業の属人化抑止に向けた活動と効果神戸事業所　横浜センター　技術第３課中村　清懇(注1 ) システムの長期安定稼働のため、信頼性、拡張性、保守性などのシステム要件を考慮し、汎用製品選定からベース環境(サーバー、OS、ミドルウェア、ストレージ、ネットワーク)の構築、試験までを実施すること。30インフラ設計作業の属人化抑止に向けた活動と効果一般論文図2に示す通り、インフラ設計メンバーの属人化や特定メンバーの作業負荷集中に伴い、後進の人材育成や技術伝承を妨げ、作業負荷を効率的に分散することが難しく、改善する必要があった。２．２　インフラ設計の問題点解消に向けてこれらインフラ設計における問題点を解消するため、インフラ設計メンバーで前述の問題点の深堀、及び要因分析を進めたところ、インフラ設計作業について以下3件の課題がある事が分かった。（1） 設計確認に時間を要する設計した各パラメータは、対象がOS、ミドルウェアなど多岐にわたる。また、導入製品のバージョンなどによりパラメータ確認方法が異なるため、手順の確認に時間を要する場合があった。（2） インフラ設計仕様の反映漏れインフラ設計の変更内容については、アプリケーション仕様やシステム要件を理解し、設計変更によるシステム運用に対する影響度を判断する必要があるため、エキスパートにより実施する必要がある。しかし、そのエキスパートは限られており、作業負荷が集中するため、その内容が最終的なインフラ設計資料に反映する時間がとれず、記入漏れが発生する場合があった。（3） 設計基準・規約が不十分インフラ設計を進める上で必要となる設計基準、規約は、従来のアプリケーション開発向けに整備されているものを流用している。このため、インフラ設計独自に検討、考慮が必要な箇所を示した規約が整備されておらず、効率的な設計作業が出来ていない。上記3点の課題を解決し、効率的なインフラ設計を実現するため、以下2点の対策を行った。（1） インフラ設計ドキュメント生成ツール開発（2） インフラ設計ドキュメント規約整備３．インフラ設計課題の分析と対策３．１　インフラ設計ドキュメント生成ツール開発インフラ設計の作業負荷低減を図り、前節の以下2件の課題を解決するため、どのような改善を行う必要があるか分析を行った。（1） 設計確認に時間を要する（2） インフラ設計仕様の反映漏れ図3に上記2点の課題に対する分析内容を示す。図3．インフラ設計作業に必要な対策図3に示す通り、インフラ設計作業の作業負荷低減を図るために、手間のかかる情報採取作業や確認作業の自動化、共通化が有効と考えた。また、設計ドキュメントを自動生成し、反映漏れによる環境設定との差異を抑止する事で、エキスパートの技術知識、知見の共有を促進し、技術伝承不足を解消する。そこで、これら対策に必要となる機能を具備した、インフラ設計ドキュメント生成ツールを開発した。以下、このツールの主な機能を示す。なお、これらの機能は一連の動作を全てワンアクションで実行することを前提とし、用途に応じ各機能の個別実行も可能となるよう、メニュー形式とした。なお、本機能はRHEL Linux、及びWindowsの各サーバを対象とし、標準機能で動作可能となるよう、shell形式、及びbat形式で作成した。図4にツール実行時の一連の動作イメージを示す。図4．インフラ設計ドキュメント生成ツール実行イメージ31インフラ設計作業の属人化抑止に向けた活動と効果　（ⅰ） サーバアクセスツール　Windows端末、サーバより、定義ファイルに指定した情報取得対象となるサーバへのアクセス、及びその後の各情報採取に向けた準備を行う。　図5にサーバアクセスツールの動作イメージを示す。図5．サーバアクセスツール動作イメージ（ⅱ） パラメータ取得ツール　インフラ設計ドキュメントに記載すべき各パラメータ設定値について、指定された定義ファイルを参照し、対象サーバから情報を取得する。　図6にパラメータ取得ツールの動作イメージを示す。図6．パラメータ取得ツール動作イメージ（ⅲ） パラメータ整形ツール　取得したパラメータを設計書に変換するために必要となる、ファイル形式変更や整形を行う。定義ファイルにファイル形式や整形すべき情報を定義可能とした。　図7にパラメータ整形ツールの動作イメージを示す。図7．パラメータ整形ツール動作イメージ（ⅳ） ドキュメント整形ツール　整形された取得パラメータ情報を定義ファイルに指定した整形情報を基に加工し、Excelの設計書形式に変換する。　図8にドキュメント整形ツールの動作イメージを示す。図8．ドキュメント整形ツール動作イメージ３．２　インフラ設計ドキュメント規約整備前節のツールを最大限活用するためには、そのインプットとなるインフラ設計項目についての定義が不可欠である。しかし、前述のとおり、各自の技術レベルの違いや導入製品固有の情報保持量の違いから、エキスパートに依存せざるをえない状況となっていた。その状況を解決するため、インフラ設計メンバーの各自が実施している設計内容を振り返り、整理した。32インフラ設計作業の属人化抑止に向けた活動と効果その結果、製品固有の項目やシステム要求に依存する部分があるものの、インフラ設計における基本的な考え方や検討項目は、共通化が可能であることが判明した。そこで、共通化が可能な設計項目、及び汎用製品の製品選定に関する基準を整備した。図9に設計項目基準化イメージを示す。図9．設計項目基準化イメージまた、これら基準に従い設計作業が行われているかを確認するためのチェックシートを追加し、運用として定着できるよう、規約整備を行った。以下に製品選定・設計項目基準、及び設計チェックシートの詳細を示す。（1） 製品選定、設計項目基準各案件の担当者で決定している製品選定、及びインフラ設計項目の整理集約を行い、製品選定時に必要な検討項目、及びインフラ設計時の判断基準を決定した。表1、表2にそれら検討、判断項目の抜粋、図10に設計判断基準のイメージを示す。表1．製品選定、設計検討項目（抜粋）表2．インフラ設計判断項目（抜粋）図10．インフラ設計項目基準イメージ（抜粋）（2） 設計チェックシート前項の設計作業について、その完了を第三者が確認可能となるよう、作業フェーズ別に各インフラ設計完了後の確認項目をチェックシート化し、第三者がチェックする運用を策定した。図11にそのチェックシートイメージを示す。図11．設計項目チェックシートイメージ（抜粋）図11の通り、担当者のセルフチェックの他、第三者の照査を実施する運用を策定した。４．ツール及び規約の活用と効果前章までのツール開発、及び設計規約の整備を行い、インフラ設計における以下3件の課題に対する効果を確認した。33インフラ設計作業の属人化抑止に向けた活動と効果（1） 設計確認に時間を要するOS、ミドルウェアなど多岐に渡る設計項目の設定確認は、本開発ツールで自動生成されたドキュメントを確認するだけで対応可能となった。各環境に対する確認コマンドの実行、及び実行結果の目視確認が不要となり、確認作業、及び確認ミスが大幅に削減できた。（2） インフラ設計仕様の反映漏れ外部仕様や要件変更を要因としたインフラ設計変更の反映は、本開発ツールにより設定変更内容をドキュメント反映出来るようになった。これにより、ドキュメント修正工数が大幅に削減され、インフラ設計書への反映漏れが抑止できた。（3） 設計基準・規約が不十分インフラ設計独自の検討項目が明確となったことで、新規要員でも基本設計書の作成が可能となり、基本設計を元にした詳細設計書、運用仕様書、及びパラメータ設計書の設計手戻りが減少した。また、設計判断の基準やドキュメント作成後の確認運用の明確化により、エキスパートを含め設計作業工数の削減が可能となった。５．今後の展開当センターで受託しているシステム開発案件におけるインフラ設計では、市場トレンドに合わせた汎用製品を適用するため、汎用製品のレパートリー拡大に合わせて、各パラメータ設定値の定義をその適用製品に合わせ更新する必要がある。そのため、今後本開発ツールの定義情報の更新を定期的に実施する運用の策定を進める。また、本開発ツールでは対応が出来ない汎用製品についても検証を行い、適用範囲の拡充を図る予定である。６．むすび本稿では、インフラ設計における問題点解消に向けた対策として、当センターで開発したインフラ設計ドキュメント生成ツール、及びその活用を推進するための運用整備事例について紹介した。開発したツールは、特定プロジェクトに依存せず、インフラ設計全般での活用が可能である。専門知識が必要となり、属人的になりやすいインフラ設計において、本ツールとその運用例が、インフラ関連業務に従事する技術者の設計作業効率と設計品質向上に寄与する事を期待する。　最後に、本開発及び執筆にあたり、様々な面で支援いただいた関係者の方々に深く感謝を申し上げる。執筆者紹介中村　清懇 ナカムラ　キヨネ2002年入社。主に電力会社向け情報システムの設備インフラ設計、開発に従事。現在、神戸事業所横浜センター部技術第３課。34インフラ設計作業の属人化抑止に向けた活動と効果