前回のふりかえり

こんにちは、豆蔵の武田 知久です。『プロジェクトマネジメント 現場でのプラクティス』ということで、当社のお客様である株式会社マネーパートナーズソリューションズ(以下、MPSと省略いたします)の証券システムプロジェクトをすすめるなかで得られました、さまざまなプラクティスを紹介する連載の第2回目となります。

前回第1回は、『朝会、はずかしいんですが』というタイトルで、プロジェクトを円滑にすすめるためには、「コミュニケーションがとても大切」です、ということをプラクティスとして紹介いたしました。

今回は、プロジェクトをすすめるにあたってコミュニケーションする相手は、「ヒト」だけとは限らない、ということについてプラクティスを紹介いたします。第1回の最後で、MPSのHさんとSさんが「ステージング環境(※1)のアプリケーションサーバとデータベースサーバが疎通できないんだけど・・・」と、なにやら話しているところで終わりました。今回は、その続きとなります。

※1 擬似本番環境。本番運用環境と同一の構成。総合テストやユーザの受け入れ検証をおこなう。

インフラとおしゃべりできましたか?

HさんとSさんが話していた内容は、結合テストを前にアプリケーションをステージング環境にリリースしたけれど、アプリケーションサーバとデータベースサーバが疎通できず、アプリケーションが例外を発生させていた、というものでした。原因は、サーバ間のネットワークの疎通を許可するためのACL(アクセス制御リスト)設定申請が、MPSから株式会社マネーパートナーズ(以下、MPと省略いたします)のIT統括部門に提出されておらず、ネットワークが開放されていなかったためでした。

「申請をだせばすぐ開放されるだろう」と思ったのですが、MP社で管理されるすべてのインフラは、データセンターで厳重に管理されております。そして、たとえステージング環境のインフラ変更であっても、すぐ変更できるというものではありませんでした。

このときは、たまたま週末の定期メンテナンスに変更作業を割り込ませてもらい、事なきをえたのですが、今後もインフラまわりで、さらなるトラブルや手違いが発生するおそれがあります。

そのため、わたしはUMLの配置図を利用して「システム構成全体図」を使って、システム(とりわけインフラまわり)の可視化をおこなうことの必要性を伝えました。そして、本プロジェクトでは、この「システム構成全体図」をもとに、サーバ内のアプリケーションやミドルウェアなどのプロセスが「誰と(相手プロセス)」「どんな手段で(プロトコル)」通信しているのかを洗いだすため、みんなで確認を行いました。

その結果、いろいろな立場の人からの指摘もあり、通信できないプロセスを山のように確認することができました。2週間後の結合テストに間にあわせるため、すぐ申請をだしたのはいうまでもありません。

(システム構成全体図のサンプルは、図1を参照してください)

図1:システム構成全体図の例
図1:システム構成全体図の例

また、「システム構成全体図」を作成したことで、システム構成の欠落の発見に役立ったほか、プロジェクト内のアプリケーション開発メンバーがインフラを含めたシステム構成全体を理解するスピードが向上しました。その結果、本番環境への移行や、トラブル発生における原因の究明も、大変スムーズに対処できるようになりました。

システム構成全体図で、インフラがおしゃべりできるか確認しましょう。

この取り組みののち、MPSにはインフラチームというものが設立されました。同チームでは、本プロジェクトで考案した成果物をベースに、インフラ関連のリポジトリを管理するようになったという事実もお伝えしておきます。

運用監視ツールとおしゃべりできましたか?

さて、結合テストや総合テストでは、アプリケーションの仕様を確認するだけではありません。「Nagios」「Swatch」「OpManager」などの、あらゆる運用監視ツールともおしゃべりできるか、確認する必要があります。結合テストでは、アプリケーションプロセスと各監視ツールが疎通できるかを確認することが必要です。そして、総合テストでは、障害運用の確認のため、アプリケーションのプロセスと各監視ツールが、テスト仕様で想定したアラートを通知することができるか、確認することが必要です。

これらの確認が漏れると、アプリケーションプロセスが停止していることに気づくことが遅れたり、FATALやERRORログが出力されていても感知できなかったりするため、障害を放置することにつながります。ひいては、顧客に対して取引機会の損失を与えてしまうという、とんでもないリスクとなります。

そこで、本プロジェクトでは、運用監視に対する配慮が漏れないように、プロジェクトの早い段階から、以下の2点を意識する取りくみをおこないました。

  1. 基本設計の段階から運用監視チームのメンバーに参加してもらう。
  2. アプリケーションサーバにどのようなプロセスが配置されるかを示す、「サーバ構成定義書」を作成して、運用監視チームやインフラチームと共有する。(サーバ構成定義書のサンプルは、図2を参照してください)

前述の「システム構成全体図」と、この「サーバ構成定義書」との関係は、「システム構成全体図」は、文字どおりそのシステムを構成する要素の全体配置を鳥瞰するもので、「サーバ構成定義書」は、「システム構成全体図」に配置された個別の要素の内部を定義するものとなります。

図2:サーバ構成定義書の例 図2:サーバ構成定義書の例

この取りくみの結果、本プロジェクトを終えたメンバーのひとりひとりから、インフラや監視ツールを意識した発言が聞かれるようになりました。とりわけ、アプリケーションの死活監視結果の把握や、適切なアプリケーションログを出力することについて、これまでよりも開発メンバーの意識が向けられるようになったのです。

設計の段階から、チームとして運用監視のことを意識しましょう。

ソフト+インフラ=「システム」

一般的に、業務系アプリケーションでは、ハードウェアや運用監視ツールなどのインフラとくらべて、業務を実現するためのプログラムの設計や開発に主眼がおかれている傾向にあります。そのため、開発現場では「システム=ソフトウェア」であるという意識が強いように思えてなりません。組み込み系に比較すると、ソフトウェアとハードウェアの責務は明確に切りわけやすく、それぞれの対象もモデリングしやすいのですが、なぜかハードウェアを含めた「インフラ」のモデリングはあとまわしにされているケースが多いのではないでしょうか。

こうした意識を、プロジェクトの現場から払しょくさせるためには、プロジェクトチーム全体が、以下の2点について常に意識をする必要があります。

  1. そのソフトウェアは、いつ、どこに入れるのか。(ハードウェアなどのインフラ認識と、その調達時期の認識)
  2. そのソフトウェアは、いつ、誰とおしゃべりするのか。(ソフトウェアも含めた、他のプロセスの認識)
図3:システムには、ソフトだけでなくインフラも必要
図3:システムには、ソフトだけでなくインフラも必要

こうした意識を、プロジェクトチームで常にもつことで、「ソフトウェア」だけではなく、「インフラ」も考慮した「システム」の完成に導くことができます。とくに、新規開発のプロジェクトでは、継続開発のプロジェクトと比較すると、ハードウェアなどのインフラに関する作業や準備が、クリティカルパスに占める比重が多くなる傾向にありますので、充分に注意をはらう必要があります。


プロジェクト全体で、「ソフト+インフラ=システム」の意識を持つことが大切。

教訓

さて、前回と同様、今回の話から得られた教訓をまとめたいと思います。

  1. ソフトウェアがインフラとおしゃべりできることを確認しましょう。
  2. プロジェクトの早期から、運用監視を意識したプロジェクト運営を心掛けましょう。
  3. 「システム」は、「ソフトウェア」だけではなく、「インフラ」もモデリングしましょう。

くりかえしになりますが、業務アプリケーションではソフトウェアのモデリングに力を注ぎがちになります。しかし、ハードウェアを含めた「インフラ」のモデリングも忘れることができない、大切な設計要素となります。

さて、証券プロジェクトもいよいよ本番環境へのリリースまで、1か月をきりました。総合テストも順調に消化して、MP社業務部門へのトレーニングもほぼ終了しておりました。

そんなとき、MP社IT統括部門のIさんから指摘がありました。

「あれ? このシステムって、財務会計データが発生しますよね?説明する部門が足りないんじゃないですか?」

「え? そんなことはないはずですが・・・業務フロー上の部門には説明はすんでいるはずですよ」といったそばから、わたしが業務フローをあらためて見直しはじめたのは、いうまでもありません。

(続く)

―謝辞-
この記事は、MPS社の証券プロジェクトをすすめていくなかでの実体験をもとに記述されております。同プロジェクトにおいて、わたしたちプロジェクトメンバーを支えていただいたK部長こと風間淳一郎様、代表取締役社長の小西啓太様、そしてプロジェクトを一緒にすすめてくれた多くの皆さまのご協力なくしては、無事完遂することはできなかったと思っております。皆さまのご協力に心より感謝申しあげます。