世界の証券市場と連動、24時間365日動き続ける某証券システムは、無停止での運用が必要不可欠な条件である。
近年の急激な経済変化により発生する大量のトラフィック、大容量トラフィックに対応可能な高レスポンスのネットワークを実現するために、大規模プロジェクトが始まった。

フロント側　ネットワーク構築 H.Kのサイド

お客様の望むものを実現するために

証券の全業務システムと取引参加者、情報ベンダと外部機関などを繋ぐバックボーンネットワークの更改。 ミッションクリティカルなネットワークの構築であるがゆえに、ユーザー企業の品質へのこだわりも当然強い。 今回のプロジェクトも、基本設計の段階で、度重なる要件変更があった。

ユーザー企業がベンダに期待した「短納期・安全・確実」を実現するために、変更された要件にいかに迅速に対応し、 詳細設計をまとめあげてゆくか。それがフロント側の設計者であるH.Kの最初の腕の見せ所でもある。

現行システム＋新規技術の理解に奮闘

大規模な基幹システムのリプレースにも関わらず、与えられた開発期間は設計着手から構築開始まで4カ月しかないというハードスケジュール。 まずは現行システムを理解するところから始まった。
システムリプレース開発を請け負う側に共通する苦労だが、
「やはり自分たちが書いたドキュメントではないので、表現の違いや書式の違いもあり、なかなかうまく読み解けない。初めて扱うプロトコル等もあった」
短納期の中、現行システムがどのように動いているのかを把握し新規の要件を盛り込んでゆく。製品ベンダの協力を仰ぎ、製品の設計チームへの確認を行うことで手戻りを防いだ。

トラブル解決には「チーム力」

単体テスト後、システム全体の連動テストを行った際、通信が出来ないというトラブルが発生した。
複数チームでシステム構築作業を行っている今回のプロジェクトでは、 H.Kが携わるフロント側アクセスポイントネットワークの他にMPLSネットワーク側、 センター内ネットワーク側と構築チームが分かれているため、微妙なすれ違いが生じていたのだ。
しかしそこは、各チーム間で話し合いを行い、解決策を見出すことが出来た。 また、チーム内には個々の技術力の差はあるものの、「皆それぞれ得意分野を持っている」。
特に今回、現行システムの理解が必須だったが、現行システムのネットワーク管理ソフトに深い知識を持った人間がおり、 その知識が非常に役に立った。

設計者であると同時に、チームをまとめる立場のH.Kは、メンバーの士気にも気を配る。

「区切りを決めてここまでやれば休める、と明示して言わないと、あれの次はあれ、とエンドレスで業務が続くのでは、 と思ってみんなモチベーションが下がってしまう。当然体力も持たなくなるので、区切りをつけて、休めるときは休みましょう、と」。
また、メンバーは忍耐強く不満を口にしないので、その分不満をため込んでしまわないよう 「正直に話してもらえるよう、それとなく話を振って本音を聞き出す」などの努力もしているのだ。

また、センター側がネットワーク全体の監視、運用を行っており、フロント側とセンター側で併せて１つの経路となる部分について、 設定などはセンター側に併せる必要があった。今回はセンター側にIT働楽研究所からH.T、T.Hが参画していたため、 センター側の仕様を教えてもらうなど「違うセクションで働いていても、彼らが入っていることで助かった部分があった」。

上流工程での作り込みと品質管理に加えて、チームの士気管理にも奮闘。その結果として「動かない」といったレベルの大きなトラブルはなく、無事にプロジェクトは完了した。

連動テストを終えて…みんな成長した

規模が大きく納期が短い厳しいスケジュールの中で、10人近い人間が動き、 その統制をとりながら他社とのコミュニケーションも取る。 苦労は相当なものだったが、チームメンバーはそれぞれ、H.Kも含めて 「設計なり、技術なりで成長出来たと思う」。

リリースまでは油断出来ません！

連動テストが無事完了してまずは安堵。かと思いきや…。
「4月以降は、実際にお客様がテスト用回線を引いた上で、通信テストを行う。 そこで問題がなくて初めてリリース出来るので、まだ油断は出来ませんね」。

センター側　ネットワーク設計構築　H.Tのサイド

ユーザー企業への提案段階からベンダへのアドバイスなどを行い、実作業としてはセンター側の詳細設計から参画。 本番系環境(計100台程度)/テスト環境（計50台程度）の機械を相手に設計から構築まで3ヵ月というタイトなスケジュールでやり遂げたのは、技術力に加え、 10名前後という大型チームのメンバーを動かすH.Tの統率力、 そしてセンター側ネットワーク構築チームリーダおよびテスト実施の現場リーダやその他メンバーのチームワークがあったからに他ならない

ミッションクリティカルなシステムが決して止まらないように

「このプロジェクトは、基本設計書、詳細設計書があり、 詳細設計書の中には機械のパラメーター設定を可能にする『定数設計書』が含まれます。 基本設計、詳細設計、定数設計の３段階を踏むことで、機械の設定が作れるようになってくるんです」。
この定数設計書を見れば、機械の設定が全部出来る。
「ミッションクリティカルなお客様なので。業務システムの通信が止まってしまうと大変なことですから、 センタ内ネットワーク障害発生時のダウン時間を10秒以内になるように、この基本設計書、詳細設計書、定数設計書は非常に重要な位置づけです。 実際に定数設計書を作って、機械をお客様に納品するためには、実際に現地（お客様環境）に機械を置いてパラメーターを設定し、 動作検証テストも行います」。
しかし、定数設計書があればめでたしかというと、決してそんなことはない。さらに、
「実際テストをし終わった後に、お客様のセンターにネットワーク機器や工事部材を搬入（センター内ネットワーク分）する段階で、電源容量見積もり、ケーブル配線ルート計画など設備設計も必要になります。 ラック１個に機械を載せるだけでも、結構大きな機械なので物理的な配置を設計して、実際に置いてみる。 場合によっては別フロアに置くこともあり、その場合はパッチパネルで階渡しをし、 『このポートに繋げてください』といった指示書も作ります」

テスト、テスト、テスト！

詳細設計書を見て定数設計書を策定した後は、テストが控えている。
「テストは実際に設定するパラメーターがあっているかどうかの観点からまず行います。 同時に、基本設計書でうたっている機能を網羅的にテストします」。
手順としては、テスト計画を作り、実際のテスト項目に対しての作業手順書を書きます。 作業手順書が出来たら、現地でテストを実施。 全ケースにおいて証明出来るエビデンスとしてログを残します」。
テストの実施にあたっては、当然その計画書や基本設計、詳細設計で描かれた要件が満たされている、 というテストの合格判定基準を作り、全ケースで全員が実施します。 判定にあたっては、これならＯＫ、これはＮＧといったことを一つ一つ行い、 最終的に単体テストでの評価をして、評価報告書を作ります。評価項目が全てＯＫとなれば、単体テストは終了します」。
評価報告書を作る際、実施したテストの全ログを見直す必要がある。今回のテストは件数が多かった（なんと4,000件！）が、 漏れが出ないよう、H.Tは事前にログをチェックする機能を作っておきチームの体制も整えた。 テスト実施の現場リーダがメンバーをまとめあげ、緻密なテスト計画／人員計画により、タイトなスケジュールの中で、H.T達は全テストをやり遂げた。
「今回の案件は、参画した人たちがみな、『楽しかった』『やって良かった』という感想を言ってくれています。 きつい仕事ではあったけど、連帯感のあった現場でした。特に良かったのは、分からないことを聞ける、 相談出来る環境があったことですね。3チームあったので、作業レベルのことは各チームのリーダに聞けば確実に答えてもらえる。 問題が起きたときは相談し合って、ベンダさんに確認しましょう、こうしましょう、とか」。

百何十台の機械が一気に…構築はお祭り？？

構築作業開始時は、百何十台の機械が一気に入ってきた。「それはもう、お祭りみたいな感じですね。 業者さんとSEとで人も沢山いて大変な状態で。センターを移動する間に機械が壊れていないか、 きちんとラッキングされているかなどもチェックしました。実際に機器の移設から設定まで、１週間くらいかかりましたね。 それから全部ケーブルを接続して、いつでも他社さんを受け入れられるようになるまで1週間。 構築が終わった後、連動テストを他社さんとやるチームと、単体テストの結果をまとめるチームと、２チームに分かれました。 私たちは実際にテストの評価報告書、納品物、定数設計書、コンフィグや設備に関する資料を作り続けました。 実際にお客様が運用するための「運用手順書」なども作りました。 お互いにクロスチェックをして内容を確認して仕上げ、短いスケジュールでもなんとか納品出来ました」

SEってかっこいい…？

実際の連動テストでは、想定通りにいかなかった部分もあった。 対策を施して再度テストを行い、強化テストも行い、無事に検証テストへ進んだが、そこまでの工程では何百という資料を作成してきている。 「SEってかっこいいとか、憧れてこの業界に入る人もいますが、実際にはやっぱり辛いこともあって、幻滅する人もいるんじゃないかな？ でも与えられた仕事をきっちりこなせたとき、お客様の『本当によくやってくれた』という言葉で辛さは吹っ飛びますね」。

フロント側との人的連携

このプロジェクトはマルチベンダで、フロント側、WAN側とセンター側、3社のベンダが作業を分担しており、 情報共有を通常よりも密にしなければならず、またそれは一つの課題でもあった。 そんな中で、フロント側に、IT働楽研究所からH.Kが参画していたことは大きなメリットだった。
「同じ会社ですので、ここのパラメーターはどうしようかなど、事前にうまく情報共有が出来たんで、 接続する箇所が何か所かありましたがうまくいきました。 ここが他社の方ですと、情報をもらうために資料を作成したり、 相手側もそれを精査してから返答をするなどで数日のタイムラグが生じることもありますが、 今回のようなスケジュールの中では少しの遅延も致命的になりますからね。 事前に資料を投げて、ここはどうか、などの確認が出来たのは助かったところです」。

センター側　ネットワーク構築　T.Hのサイド

定数設計から参画したT.H。現場ならではの苦労、そして喜びも経験。

毎日、頭をフル回転

今回のプロジェクトでは、今まで使ったことのない機械を使う必要があったため、T.Hはコマンドも全部マニュアルから調べることになった。調べたコマンドも、「これを使うべきか？の判定から始まって、本当に大変でした」。
時間がない中、チームには新人が多く、パートナーも経験の浅い人員が多かった。彼らを育てながら、自分も仕事を回さなければならない…「1日24時間しかないじゃないですか。終電までには帰らなきゃいけないので、毎日、頭をフル回転させていました」

単体テストで不具合を早期発見

仕事の回し方では苦労を重ねたT.Hだが、テストは好調だった。詳細設計まではベンダが行っているが、単体テストの段階で不具合を発見。「機械が海外製で、日本時間に対応しておらず時刻同期が出来なかったり、障害試験時に想定外の経路で通信しているなど。早い段階で見つけ、不具合対策が出来ました。」

ただ、難しい不具合もあった。
「機械に入れるOSが新しく、今回のプロジェクトのためだけに策定した仕様で起きた現象は、対応が難しかった。
エラーが起きた時に、そのOS自体が未完成なのか、こちらの設定がおかしいのか、判断がつかなかったです」。
検証テスト時、開発段階のものでしかテスト出来ず、「正式版のOSが来て、またテストすることになるわけなので、開発段階のものから正式版まででどれだけ修正が加わるのか分からない。進めてきたことが全部持ちもどりになるのでは、と不安にかられることもありました」

連動テストは、複数で構築しているゆえの苦労も

MPLSネットワーク側との連動テストでは、バックボーンルータとPEルータ（プロバイダーエッジ）のOSPFインタフェースタイプが一致しておらず、実際に繋げてみたところ、通信が出来なかった。「設計の段階で接続先のベンダは、トポロジから判断して『point to point 』、センタ側担当チームは、インタフェースメディアから『Broadcast』だと思い込んで確認をおこなわなかった。こういったケースは、ベンダ間のコミュニケーションを密にしていれば防げたこと。各社、きっと『これで通じているよね』『お互いプロだから大丈夫』という思いもあったのかもしれない。今後はお互いの会社同士、信頼はしていても、本当に細かなところまですり合わせはきちんとしていくべきだと思います」。

頑張ったものが通じた

設計から構築まで３ヵ月という厳しいスケジュールをまさに全力疾走してきたT.H。今回のプロジェクトではサブリーダとなって、下を指導するだけではなく、今回初めて部下を持つ仲間へのサポートも行った。
「人を使う、人を育てる難しさを実感しました。仕事はシビアだったけれど、現場は出来るだけ笑いや、和やかな雰囲気を作りたかったので、それを強く意識した。たいしたことではないですけど、今流行りのお笑いのネタを指示の中に入れてみたり、普段から笑いが絶えないようにしてやっていたんですよ。その中で、とても良かったのは、パートナーで来てくださった方が、終わった後で『楽しかった』『今回の仕事は本当にありがとうございました』と言ってくれたことですね。頑張ったものが通じたんだ、と実感出来ました」。