表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
0/400
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
4/10

改善案

 次の日、私は夜明け前に会社へ着いた。作業に没頭するためだ。現場の状況次第で勤務時間はよく変わるが、今回のように勤務時間に制約のない場合、私は朝起きてからを大事に使う。オフィスに人が集まる頃には、脳はすでに疲弊している。午後には集中が必要な作業は諦めて、反復や実験、あるいは人との会話に使うのが良いと思っていた。

 最初に何本かのレポートをプログラム解析をしながら読み込む。二つを付き合わせて気になる所があればダミーデータを使って実際に処理を行わせてみた。

 気になることをいくつか見つける。一つのプログラムに踏み込み過ぎると、すぐに一日、二日は経ってしまう。時間がかかりそうな確認は、明日朝の自分に引き継ぎのメモを書いて終了する。同じ時間を使うなら日を分けた方が良い。私の経験則だ。

 そうした作業を進めているうちに、二週間ほど前に提出されたナダイケのレポートに目が止まった。各処理ごとの経過時間を詳細に記録したもので、さらには処理の複雑さと処理時間の関係が考察されていた。

 複雑なら処理に時間がかかる、大量でも処理に時間がかかる、それは感覚的に分かりやすいが、数字は必ずしもそうはなっていない。ナダイケのレポートは問題がありそうな部分を羅列し、問題の可能性の投げかけで終わっていた。コオオルとナナミの試験は、このレポートを受けて行ったんだろう。ただ、ナダイケのレポートへの答えとしては、不十分かもしれない。

 この計測結果をもう少し分析すべきじゃないか。何か深く関係しているものはないか。私は作りかけていたデータ図に目をやる。入力されたデータがどのように処理されていくか、処理への流れを順番に図示化したものだ。それとナダイケの計測結果を見比べる。しばらくして私はIDに注目して処理を遡ることを思いついた。

 何かの処理が終わるとIDが再定義されることがある、その上書きされたIDによって次の処理が変わる。再分岐や繰り返し処理が多い。随分と効率が悪そうだ。

 データ一つ一つに振られているID。それと別に分類されたIDがいくつかある。セキュリティ用の分類ID、セキュリティIDもその一つだ。それぞれ違う目的で作られたIDは、システム全体が作られた後に確認すると、やはり重複していたり不必要に処理を複雑にしていた。私はIDそれぞれの意味を追うことする。


 データID・・。

 タイプID・・。

 ネットワークID・・。

 セキュリティID・・。


 ・・・やはりこの四つだ。これ以外にもIDと名のつくデータ項目はあったが、構造的にはこの四つ以外は他項目と同じ扱いで良い。登録遅延に関係なさそうだ。私は過去資料でIDの名称の読み替えに注意しながら整理を続ける。


 データID

  NzN1yv9ULbB5D_2SWZrsd3Dsd_1S455gdgsfZx_2g6Dhts_kddMMK_EffdagVd

dNzULc0eo1Q3Y_ClK59dIUZTW_1S44GfW7AeUy_1g4Gczd_5dsYIP_9hc2aVR4

  ・・・

 データ一つ一つに振られている。ユニーク、重複しないだけだ。


 タイプID

  A01

  A05

  B03

  ・・・

 データの入力項目にはタイプがあり、これで登録すべき項目が分かる。


 ネットワークID

  AGAB

  CNCR

  ・・・

 他のIDと比べて種類が少なく有限で考えてよい点は扱いやすい。入力経路ごとに傾向は異なるが重複があり。このあたりは利用者が入力する環境が大きく偏っているせいかもしれない。システムでは、ほぼ同じは違うものと考えるか、例外扱いするかの二択でしかない。


 セキュリティID

  ACAB

  AGAB

  AGAK

  CNCA

  CNCR

  ・・・

 これがよく分からない。ネットワークIDにもある程度の依存関係はある。ただ種類はネットワークIDより多く、出現頻度の低いIDがかなりの割合だ。これが暗号化とその解読に関わっているから処理が厄介になる。


 ID体系はかなり複雑なことだけは分かった。今回のデータシステム構築で、元々のシステムから拡張した部分にID追加はない。構築したのは同じ会社の人間なので詳細な資料が残っていた。

 昔のインフラチームによる開発、その初期設計からネットワークIDとセキュリティIDは存在していた。今回のプロジェクトでのIDの扱いは基本的に変わっていないが、順番や回数が今の方がさらに複雑になっている。

 IDは基本無意味であるべきだ。そこに依存関係があると、呆気なくデータは体系化できなくなり、やがては外部との関係が崩壊しシステムは孤立する。それはサイロ化と呼ばれるものだ。データが折り重なって手がつけられない時によく使う表現だが、まさにこのシステムにぴったりだった。その混沌としたシステムの中へ、深く沈んでいく必要が私たちにはあった。

 作られたプログラムを正しく理解せずに、無造作に処理を後ろに足したのかもしれない。手前を直せばいいのに、そこには手を出していない。なにか理由があったのだろうか。一見無駄に見える処理、その意図を見極めるのはプログラムを修正するよりはるかに時間を要する作業だ。

 設計変更なしの機能追加、その繰り返しはただ複雑になっていくだけ。あくまで仮で追加したデータ、それを他で流用してしまい、本流には還元できない理由があって身動きとれなくなった。そしてまた別の処理を足す。必要に迫られて、不定形なデータが上流の処理に戻されて、処理の見通しはいよいよ悪くなっていく。美しくないと表現されるプログラムだ。

 原理を理解しないなら使うべきではない、極端な人はそう言う。でも納期に間に合わなくては意味がない。結局はいったりきたりだ。人や立場により簡単に変質する。

 このデータベースの最初の基本設計はどうだったんだろう。設計には思想がある、でも、この思想が読めない。インフラチームが抜けるまでは、設計思想が崩されていないはずだ。そこで手抜きをするとは思えなかった。

『セキュリティIDがネットワークIDとある程度連動している、ネットワーク環境に応じたセキュリティが必要なので、この繋がりに合理性はありそうだ。』

『ただしセキュリティIDには例外が多い。この例外が問題を発生させている可能性が高い。つまりセキュリティIDがもっと規則的ならシステムは最も性能を発揮する。』

『セキュリティIDはデータのセキュリティを高めるもの。外部からのセキュリティだけに備えるなら、こんな内部にあるデータシステムでセキュリティ関連の処理が多い意味が分からない。』

 一時間ほど費やして私には一つの仮説が浮かんだ。

『これ、もともとは侵入やデータ改ざんへの対応をやり過ぎた設計だったのではないかな。セキュリティIDの処理だけわざと複雑にして、そうしないと暗号解読がうまく出来ないようにしている。』

 それだと現状とつじつまが合う。であれば単純にそのセキュリティIDを全部無効にしてしまえばいい。いや、出力時に定義されているからダメだ。セキュリティIDが暗号解読のキモになっている。ここが高速処理を担保している可能性が高い。それに変更時のルールまで定義されているから、ここは守る必要がある。

 ナダイケのレポートをもう一度見る。セキュリティIDに関わる処理の時間が不安定だ。セキュリティIDが内部的に付け替えが行われる。この変化が全体の処理時間を早くも遅くもしている。たぶんそうだ。

 セキュリティIDをなくすことは出来ないか。フォーマットに関しては他の要素で代替可能。ただ、暗号化の処理はどうなるか。セキュリティIDをなくす影響を見積もるには、暗号化処理の時間を見積もる必要がある。あるいは多少なりとも最適化できればネットワークIDごとの処理もシンプルになるはずだ。上がっているレポートを見る限り、その作業はまだ誰もやっていないように見えた。いや、シオヤあたりが試している可能性は十分にあるか。

 システムの挙動を考えていたら、いつの間にか関わっている技術者の嗜好から動きを推定していた。それで行き過ぎると良いことがないから、私はそこで立ち止まった。

「おはよう、早いな。」

 気がつけばちらほらとメンバーが出社し始めている。もうそんな時間だ。

「おはようございます。コオオルさん、朝の時間は大事に使いたいので。」

「はい、分かってますよ。邪魔はしません。」

 コオオルはそう言って、私の席から遠ざかる。何かに没頭している時、私は話しかけられるのが苦手だ。近くの席で何年か過ごしているので、コオオルはそれを十分に分かってくれていた。有難い話だ。

「おはよう、ユキさん。今日は何から始める気だい?」

「おはようございます。」

 コオオルはフロアのメンバーに順番に話しかけていく。プロジェクトに入るとコオオルがよくやる行動だ。朝の挨拶の後にひとしきり会話を続ける。それは雑談か仕事の話か、どちらとも分からない。

 無駄話を毎日決まった時間にする、それで新たな仕事が始まることもある。スタイルは人それぞれだ。私みたいなタイプにも夕方に多く話しかけてくるので、全体の進捗を一番把握しているのは結局コオオルだったりする。そして些細な頼み事はすごくスムーズだ。こういうコミュニケーションに特化したアプローチもあるのだろう。私の得意なのは違うアプローチで、だから私とコオオルを一緒にプロジェクトに合流させたのは有効な手段というわけだ。

 オフィスにおおむね人が揃った段階で、私はナナミに話しかけた。

「進捗会議ですが、新しい議題はありそうですか?」

「いいえ。ちょうど今日の進捗会議の議題を書き出していたんですが、昨日と何も変わらなそうです。」

「そうですか。皆さんに分類IDの名称統一を提案しておきたいので、この後送っておきます。ただ、それだけで会議をするのもなんなので、今日は各チームごとに個別の進捗確認にしませんか? それに十時は私はシオヤさんと直接話したいので。」

「その方が効率が良いなら、そうしましょう。シオヤさんの予定を確認しておきますね。」

「すいません、ありがとうございます。」

「何の話だい?」

 わきで聞いていたコオオルが私に質問してきた。

「ちょっと細かいことを聞きたいんです。」

「そうか。」

「あ、私一人で大丈夫です。その方がシオヤさんも話しやすいと思うので。」

 私はコオオルとナナミにそう伝える。まずは、考えてきたことをシオヤと一対一で話してみたかった。

「好きにしたらいいさ。ミヤマさんが思うやり方が一番近道なんだろう。」

「いや、そんなことじゃないです。私があまりに初歩的な質問をするのを、あまり人に見られたくないだけでして。」

 そう言って私は笑った。半分本音だったが、シオヤの本音を最も聞きやすい方法を考えてのことだ。


 午前十時を昨日とは違った心持ちで待ち構える。やるべきことが見えている方が私は気楽だ。たとえ攻略方法がまるで分かっていなくとも。今朝作った資料を見直しつつ、私はシオヤに確認したいことを頭の中でもう一度整理する。

 時間ちょうどにシオヤが画面上に現れた。私はすぐにネットごしにシオヤに声をかける。

「すいませんね、シオヤさん。いろいろ伺いたくて。」

「もともと進捗会の時間だから構わんですよ。」

 新しく加わったばかりの責任者に気をつかってか、私に話す時はたまに敬語だ。

「昨日から資料をいろいろ見ていたんですが、シオヤさんに話を聞くのが一番早そうですから。」

「このシステムは私が組んだわけではないので、そんなに詳しくはないですがね。」

 警戒しているのか、シオヤは慎重な物言いだ。だがナギが復帰していない今、システムの中身を一番深く理解している、あるいは理解する可能性が高いのはシオヤだと私は思っていた。

「まず確認させて下さい。」

 挨拶もそこそこに私は今朝作った資料を見せた。データとIDの流れを図示化したものだ。私が理解したことを一通り説明する。間違いがあれば、その場で資料を直すつもりだったが、シオヤからはなんの指摘も出ない。そこで私は一つの疑問を口にした。

「セキュリティIDがどうデータ登録に効いているか調べた方がいいと思うんですよ。」

 それに対してシオヤがまず定義の確認をしてきた。

「セキュリティIDとかネットワークIDとかは、朝にプロジェクトメンバーに流していた新しい定義ですかな?」

「はい。そうです。」

 ID名称の統一の連絡は、すでにメンバー全員に届いているはずなので、あくまで確認だ。たぶん今、シオヤは慎重に思考している最中なのだ。

「そうか。そうだな・・。」

「セキュリティIDについては、もう少し詳細に追っていますので、その資料も見て下さい。」

 用意していた別の資料を私を示した。先ほどより詳細だが、その分、範囲をセキュリティID関連のみに絞っている。

「三か所ほど詳しく遡ってみたんですが、一つはネットワークIDごとの処理の途中でセキュリティIDを解読して、また暗号解読の直前に正規化していました。データ整形時に要素が一つ変わるだけでも、セキュリティIDが内部的に変更になる可能性がある。だから、その度に二度手間、三度手間をしているんです。」

 資料を次々に進めて、辿ったIDの流れの説明を私は続けた。

「他の二つも処理のやり直しが多かったんですよね。処理の上流側でやればいいのに、下流側でわざわざ複雑なやり方でセキュリティIDをつけかえて、その後の処理を増やしていました。セキュリティ以外のIDの流れもざっと見たんですが、そんな処理はありません。」

 最後まで資料を説明した後に、私は考えた仮説をシオヤに投げかけた。一番確認したかったことだ。

「つまりは、わざわざ複雑に処理をしています。まるで、途中でセキュリティIDの頻繁な変更に備えるように最後に間接的に結果を足している。でも、今のシステムでは、そんな必要はないはずと思いまして。」

 そこで私は言葉を切った。お互い無言になって沈黙がしばらく続く。私は辛抱強くシオヤの答えを待った。

「やっぱり、こんなことになっていたとは。ひどいもんです。」

 ようやくシオヤが口を開く。頭の中で考察が終わったのだろう。

「IDの流れのうち、ミヤマさんが今示したのは最も処理が重い部分だ。辻褄は合っている。この資料を見て、なんであんな作りになっているのか合点がいきましたよ。」

「そうなんですか。」

「コオオルさんに言われて、経路ごとの処理を記録できるプログラムの改修を今やっていましてな。ついでにソースを追っていて、セキュリティIDが必要以上に複雑で、私もその処理を調べてました。」

「なるほど。」

 やはりシオヤの方でも、問題点の調査は進んでいたようだ。

「最近は足腰の悪いシステムが多く、その典型みたいでしたよ。そして、私のたどりつく結論はたぶん同じでしょう。」

 そう言って、昨日同様に毒づいてみせる。

「サイロ化があまりにひどいので解析する気にならなかったが、この資料はいいですな。どう紐解いていくか、良い道標になりそうだ。」

「セキュリティIDの処理を紐解くのは大変でしょうが、やる意味はありますかね?」

「まあ、あるでしょう。」

 その言葉を聞いて、私は少しだけ安堵した。今のところ進む方向はたぶん間違っていない。

「シオヤさんと合意できて良かったです。」

 私がそう言うと、手放しで同意したと思われたくないのか、シオヤは少しだけ話題をかえた。

「それにしても昨日、今日でよくここまで調べましたな。いや、その前にどこまで正確かが大事ですが。」

「元になったのは、ナダイケさんのレポートですよ。」

「ああ、彼は数字の扱いが丁寧だ。それに主観が入らないから信用できる。」

「ええ、機会があったら褒めて上げて下さい。私はそういうのが苦手なので。」

「私の方が苦手のはずだが。」

「いえ、ぜひお願いします。」

 そこで少し議論が止まってしまったが、私たちは資料に視線を戻した。

「・・この資料を見る限りだが、後から躊躇なく機能追加を繰り返したんだろう。そして不必要になる処理は精査しなかった。中身を中途半端にしか把握してないから、より根本的な修正をしない。暫定対応のような処理を増やすばかりで結局は短絡的だ。そんなところでしょう。処理を整理すればもっと早くなるのに、それを避けたわけだ。」

「まあ、そうでしょうね。」

「こういう処理はよく見る。理由は簡単だ。時間がないので、すぐ見えるとこだけで改修を終わらせたんだろう。ID管理を増やしたくないから安易に既存IDを部分的に使ってみて、さらに機能の追加が必要になって取り返しがつかなくなったか。」

「シオヤさんなら、このIDが絡み合った処理をほぐす作業はできます?」

 私は主語を入れた聞いかけをしてみる。やる意義はすでに合意済みだ。

「・・・。」

 すぐには返事をしないシオヤだったが、興味を持っているのはその表情からも理解できた。

「ソースをしっかり追うのは、まだ誰もやっていないらしくて、それはよくないと思うんですよね。」

「ああ、まったくその通りだ。この資料で、私が思っていた通りだと分かったからな。効率良く修正はできるでしょう。」

 シオヤからの返事に主語はなかったが、おそらくは作業を引き受けたということだ。

「そうですか。よかった。」

「ソースの中身ですけどな、昔、我々のチームが作った部分が全部ズタズタにされていた。コマンドだけ、いやデータベース用の書式だけ切り取ったのも目立つ。あきれたものだ。高度化しないように修正している。技術力の問題、というか致命的な問題です。」

 シオヤらしい指摘だ。それは安定して動くことを優先させたせいかもしれない。高度化すれば処理は短く美しくなるが、新たな制約も生まれる。

「シオヤさんから見て許せないレベルですか?」

「私ならこんなの作らない。ただ、どこまで許せるかより、正しく理解して使っているかが大事ですな。」

「このデータシステムはシオヤさんから見ても、ブラックボックスですか。」

「いや、ここ数日でだいぶ分かってきましたよ。キモの部分に手を入れるのを避けて、ずいぶん遠回りの処理をしている。キモの部分をどういじるか、これはずいぶん骨が折れそうだ。」

「処理そのものが巨大ですからね。納期も決して余裕はなかったでしょうし。」

「それが分かったとして新しい変換ルールが必要になる。そして削る処理の見極めも面倒です。ただ、それが高速化の近道になる、のかもしれない。」

 シオヤの説明がだんだんと具体的になってきた。

「ぜひ、すぐに進めて下さい。」

「もう少しソースを追ってみたいところだ。」

 さらにシオヤは笑って言う。

「コオオルさんに頼まれている調査がある。それを他の人に任せてもいいですかな?」

「たぶん大丈夫だと思いますが、どんな調査ですか?」

「なあに、力技でもなんでもいいから原因を見つけるって話です。処理の全部に細かなログを出す。あまりこの調査は気が進まないのでね。」

 ログとは、その時の処理内容や一時記録されている情報を、特別なファイルに残しておくことだ。プログラムに問題が発生している場合は、このログ情報が役に立つことが多い。

「全部のログを残す作業でバグが出そうですね。それにログを出すことでプログラムの挙動自体が変わる可能性があるんじゃないかな。」

「その通り。何かを測定したら、測定をする行為の影響が出て、結局は厳密な真実の測定は出来ない。観察者効果か不確定原理か、まあそれと同じ話さ。」

「システム関連の用語じゃないですよね。やっぱりシオヤさんは教養がある。」

 たしか物理の用語だったか、そんな言葉は私にはすぐには出てこない。頼る記憶もかなり怪しい。

「まあ、厳密な意味で同じかは知らんが、ID整理の方が効果がある気がする。じゃあ、コオオルさんにはうまく伝えておいて下さい。」

 たぶんシオヤは技術的に面白いことをしたいのだ。その気持ちがよく分かったので私も笑う。

「分かってますよ。コオオルさんには話しておきます。ユキさんにもね。」

「さすが。話が早い。」

「では明日の同じ時間で、また話しましょうか。それまでで分かったことを教えて下さい。」

「いいな。進捗会がまた流れる。みなも喜ぶだろう。」

 シオヤの機嫌が良くなったのを確認したところで、私はリモートでのやりとりを終えた。


 まだ慣れないプロジェクトのフロアを見回す。考えたもう一つのこと、それを話すのはきっとユキがいいだろう。私はフロアの中央へ向かった。顔を上げたユキと目が合うと、すぐに私は話しかける。

「リンクチームの進捗はいかがですか? 今日は進捗会はなしですので、気になる所を別々に聞いておこうと思いまして。」

 ユキは軽く会釈をしながら返事をする。

「さっきまで部内でミーティングしてました。まあ、進捗はほとんどありません。この後は何をするかの議論に時間を使ったんですが、全く成果なしでした。」

「高速化はもう限界って言ってましたっけ?」

「ええ、ここからは誰がやったって性能が上がるのはほんの少しだと思ってます。」

 気まずそうにユキは言った。たぶんそれは誠実な答えだ。

「そういえば、シオヤさんが何か調べなくてはいけないと言ってましたが。」

「ああ、それはコオオルさんが頼んだ全部のログ取りですね・・。私としてはもうお手上げだとは思ってますが。」

 ユキからは諦めぎみな発言が続いている。でも、その方が私は頼み事をしやすかった。

「じゃあ、シオヤさんには別のことを頼んでおこうと思います。コオオルさんには言っておきますね。」

「はい、承知しました。ログ調査は無理に進めなくてもいいかなとは、私も思ってましたし。」

 返事が早くて軽い。もともと興味がなかったのか、あるいはシオヤに頼む仕事でないと前から思っていたのだろうか。

「ところで、このシステムの例外処理で、データの上書き方法は何が一番速いですか?」

「え? 一種類しかないですよ。」

 なんでそんなことを聞くのかと、訝しげな顔をユキはした。

「すいません、登録時に出す命令の話とかでなくて、登録する時の状態の話です。」

「ええと、登録時のシステム状態で性能が変わるなんてなかったと思いますが。問題は例外処理に入るかどうかだけで。」

「その登録は何種類か試しました?」

「何種類って一つずつ処理する場合と、並列で処理した場合、後はデータ種類との組み合わせですかね。」

「そうですか。そこをもう少し調べた方がいいかもしれませんよ。」

「どういうことですか?」

 やや困惑したようにユキは言ったので、私は自分なりに調べたことを伝える。

「理由がよく分かっていないのですが、このシステム、セキュリティ確認のプログラムを常駐させた方が処理が遅かったんです。」

 通常のプログラムは必要な時に呼び出され処理を終えると終了するが、常駐するプログラムは常に動いていて何らかの変化を待っている。

「え? でもセキュリティ確認のプログラムなんて、データ登録のプログラムとは一切やりとりしてませんよ。」

「そうなんですよね。でも、何度か試してみたんですが、セキュリティ確認のプログラムが常駐しているかいないかで、数字が変わりました。同じように常駐させる、させないで性能に影響するものがないかと思いまして。」

 それは今朝気づいたことの一つだ。計測結果でわずかに不自然な変化をしている所、それを詳しく調べて見つけたことだ。

「ちょっと試しただけですが、なんとも不思議な動きなので。」

「本当ですか? 手分けして調べてみようかしら。」

「皆さんの時間を使っていいものか分かりません。もしユキさんが調べてみて手応えありそうなら、やってみてもいいかもしれませんね。」

「とにかく少しやってみます。ありがとうございます。ミヤマさん。」

 それからフロアをゆっくり歩いて自分のデスクに戻る。近くにいたコオオルとナナミに私はすぐに話しかけた。

「明日の進捗会も個別にしたいと思います。シオヤさんとユキさんに別々の調べものをお願いしたので、それに時間がかかるでしょうから。」

「しばらく進捗会はなしにするかい?」

 私の考えを察したのか、コオオルは深い説明を求めずに合わせてくれる。気心の知れた仲間はこういう所が有り難い。一方、全体把握を第一とするナナミは別の反応を示した。

「調べものってなんですか? 何かいいアイデアが見つかりました?」

「いや、そうでもないんですが、可能性の話です。明後日には全体で調査結果を聞きましょう。それくらいあれば何か分かるかもしれないので。」

「詳しく知りたいわ。どんな調べもの?」

 シオヤとユキに話したことを、私はかいつまんで説明する。

「そんなわけで、コオオルさんがシオヤさんに頼んでいたログ出力の調査は、遅れてもいいと言ってしまいましたが、大丈夫ですか?」

「他に可能性の高いものがあったなら全く問題ない。他に手がなくての依頼だったからな。別で突破口がありそうなら、そっちにかけるさ。」

 プロジェクトの新たな動き、これで二つの種を蒔いた。だが、それだけだ。今のところ他に手をつけられそうな所はないのだ。私にはまだやるべきことがある。


 その日の午後、私はこの建物のお気に入りの一つに向かった。地下にある資料室だ。そこには過去に開発されたものの膨大な記録がある。私はそれらを読むのが好きだった。

 資料室には特別な許可なしでは読めない資料も多い。今はプロジェクトの問題解決のためという大義名分があるので、特に制限されたものを除いて閲覧可能だ。データ登録が遅延する事例がいくつかあるのを知っていたので、それをしっかり読んでおこうと思った。朝の調査とその後にメンバーと話し込んだことで、私の頭はやや疲れていた。そういう時に向いた仕事だ。

 いくつかの資料を漁る。デジタル化された資料は認証を通すだけでいいが、紙でしか残っていない資料は、背の高いラックから取り出す必要があった。目録と実際の資料を見比べつつ、時間をかけるべき材料を見極めていく。

 ボトルネックがあって、それを改善した事例はいくつか見つけた。何かヒントはないかと資料を読み込む。登録方法の些細な所を間違えていたパターンやデータシステムを選び直して作り直した事例、これは大変な労力だ。

 大きなデータを効率よく登録するなら、一つのデータを部分的に編集できた方がいい。小さいデータを高頻度で処理するなら並列処理が得意なものが向いている。取り出す時の検索方法の柔軟性によっても最適な方法は大きく変わる。

 データリンクのシステムでは、元となるシステムの基本的な選択は合っている。その中の最速を出そうとしての失敗、だいたいは長所が原因に関連している。今回の場合はID変更の複雑さ、これが加わったことで処理が混沌としてしまった。しかし、それが要件だ。ID変更の複雑さの回避、それが問題の本質だろうか。

 窓のないところに数時間いたので、屋上に出る。すでに日が暮れて、夜空が広がっていた。今日はここまでにしよう、明日早くからやった方がずっと効率的だ。すぐに私は帰り支度を始めた。


 翌朝、私は朝日が昇るより先に会社へ着いた。まずは昨日の続き、後回しにしていたレポートとプログラム解析の付き合わせを進める。次にシオヤに見せたデータフローの見直し、今日は少しだけプログラム解析と付き合わせる。この部分はシオヤが何か見つけているかもしれないが、その説明を受ける上でも多少は知っておかないと理解が追いつかない。

 朝の時間はあっという間だ。気がつけばメンバーのほとんどが出社していた。もうシオヤとのミーティングの時間になる。今日も進捗会は個別確認に切り替えてもらっていた。私は一人でモニターの前に着く。

 今日も時間ぴったりにシオヤが現れ、画面ごしににこやかに手を上げてくる。

「シオヤさん、調子はどうですか?」

「どうってことはないですね。」

 今日のシオヤは機嫌がいい、たぶん何か見つけたのだ。私はすぐに本題に入ることにした。

「調査の状況としては、どうでしょう?」

「まだ全体を見れていない。ただ奇妙な処理をいくつも見つけた。」

「奇妙な処理?」

「見落としていた、というか隠されていた処理を見つけた。その処理を通してみると全くわけが分からんことをしている。」

「詳しく教えて下さいよ。」

 シオヤは画面にプログラムを見せた。彼にとってはそれが一番分かりやすく、誠実な説明になるのだろう。だが、面食らってしまう人も多そうだ。私はシオヤの説明についていけるよう、まず呼吸を整えた。

「裏で別の常駐プログラムとやりとりをしている。それがなんと独自のソケット通信だ。」

「独自のソケット通信?」

 各プログラムごとのやりとりに使うソケット通信があるのは私も知っていたが、それは定番の手法が存在する。独自のものなど聞いたことがなかった。

「独自で実装できることを、もはや知らない奴がほとんどだろうな。一見するとログを記録している処理で、私だって最初は見逃していた。ただ、なんというか懐かしい感じがして、昔似たような処理を見たのを思い出した。」

「でも一体なんで?」

「記憶が曖昧だが、五年前にこれをメインで作っていた担当がぼやいていた。先方のセキュリティ担当者のこだわりで、めちゃくちゃな制約があると。たぶんこれだったのかもしれない。機密性の高い情報は別通信で行わせるなんて、外部からの侵入があったら意味はあるかもしれないが、私にはとても有効とは思えない。」

「確かに。実際そうだったんですか?」

「どんな制約か興味があったんで当時聞いてみたが、詳しいことは教えてくれなかった。文章化するのも先方にいちいち許可をとらなきゃいけない取り決めだとかで。」

 昔の資料を読んでも気づかなかったのはそういうことか。顧客合意に基づく隠蔽だ。もう一度当時の資料を別の意味で読み直す必要がある。

 シオヤの説明は続く。新発見で興奮ぎみなせいか、言葉づかいなど気にしていない。

「独自の通信はかなり速い。全体の処理速度にも貢献しているだろう。その一方で、その見えない処理による問題がいくつかある。正しく動きはするが非効率的なんだ。表と裏で二重処理がいくつか。表でひっくり返して、裏でまたひっくり返して辻褄を合わせている。そうしないと常駐プロセスに強制的に処理を中断されてしまうから。裏側の処理が終わっているのを気にせず、いや気づかずに表側だけ見て高速化しているのさ。セキュリティIDに関わる処理の変更はオリジナルと変わっていないから動きはする。」

「その処理はプログラム動作の記録用だと思っていました。」

 同じプログラムを読んでいても、私は全く気づいていなかった。

「まあ、だいたいは誤解するだろうな。それに独自通信が原因で処理が失敗しても、データシステム側が高負荷で処理が止まったのと同じだったろうから。」

「なるほど。その処理は変更できますか?」

「もちろん。例えばこの部分。登録直前の処理、セキュリティIDを最後に判定させている。これと同じ処理が前にもある。かと言って、この両方の処理がないとプログラムが停止してしまう。停止する理由から遡っていけば良い。」

 必要な行に色づけをしながらシオヤの話は続く。私は解析したプログラムのそれぞれの処理を思い出して、シオヤの説明を頭の中で再構成していく。

「ここでセキュリティレベルを判定できなかった場合は、ネットワークの分類IDをリセットしている。でも、これはネットワークの分類IDによってはあり得ることだ。次のプロセスに渡した後なら処理は可能。」

 シオヤは次第に早口になって、言葉の定義が乱れてきた。ただ、まだ認識違いの発生しない範囲内だ。

「ネットワークIDをつける順序がそこで関わっているですね。」

「セキュリティIDを最後に判定させていたのは、割り込み処理に対応させるためだと私は思うね。このデータシステムを作った時のプロジェクトは、割り込み処理が複雑だった。リリースされた当初のプログラムも見てみた。」

 シオヤは画面を二分割にして話を続ける。

「元のシステムの割り込み処理が、ほら、この通り十以上ある。今回のシステムではそんな割り込み処理は必要ないから、この部分はほとんど削除されている。これはナギさんがやったんだろう。」

「なるほど。」

「だから、セキュリティIDの判定を先に入れてしまえばいい。データ登録直前の判定は削除しても問題はない。データ登録までの処理は軽くなるし、今の登録頻度を調整する機能も、より効果的になるだろう。二倍にはならないが、それなりに上がる。」

「へえ、ちょっと実験してみたいですね。」

「ところがそう簡単じゃない。ひょっとしたらリンクチームの誰かが試して挫折したのかもな。」

「どういうことですか? 処理順序の入れ替えは出来ない?」

「この裏の通信に関わるものを削除すると動かなくなる場合がある。なので片っ端から無効化できるか確認していく。見落としがあってはマズいからな。くまなくやるには手間が要る。それにセキュリティの分類IDを前に処理するなら、データ分類IDの判定も移動させる必要がある。」

「セキュリティID、タイプIDですね。」

「失敬、その通り。タイプIDの判定は三段階になっているが、最初の判定で、中途半端なセキュリティIDが使われている。昨日も言ったが、ID処理の流れに還流がある。環流をさらに環流、ダメプログラムのお手本だよ。」

「処理の修正範囲が広いってことですか。」

「まだ細かい処理は追いきれていないから、他にも同じような問題があるかもしれない。あのごちゃごちゃしたデータ分類ID・・、でなくセキュリティIDも、ネットワークIDもタイプIDも全部を見直し、やり直しですな。」

「なるほど。」

 シオヤの頭の中には、プログラムの改修範囲が見えているのだろう。行けるかもしれない、私は心の中でそう呟いた。ただ、今は目指す道が見えてきただけ。それをやり抜くの困難さはまだ見積もれてはいない。それに今は時間との勝負でもあるのだ。


 その日の午後、私は再び地下の資料室に引きこもった。五年前に納品されたシステムの記録を、静かな所でもう一度見直すためだ。

 残っている資料に全て目を通す。ほぼ私たちが把握している内容だったが、気になる一文を見つけた。前に読んだ時はプログラム処理に関係ないだろうと気にしていなかった箇所だ。

 『セキュリティに関する資料は別途提示』との記載だ。その別資料は見つからない。おそらく顧客側の要請だったのだろう。それでも残っている資料から自分なりにシオヤの解析結果を遡っていく。検討に数時間かかったが、シオヤの指摘と矛盾はない。その説明は信用できると納得することができた。

 プロジェクトのフロアに戻ると、次に私は常駐プロセスとID変更の関係をもう一度調べ直す。シオヤの指摘が正しいとすれば、処理全体への影響はID変更が一番大きいと思えたからだ。IDの入れ替えの後作業で、整合性をとるために常駐プロセスが他の処理へ情報を渡す、それを起点に新たな処理が生まれる。その流れを追っていくと、不必要な処理を何度もしている。常駐プロセスが間接的にずいぶんと処理を効率悪くしているのだ。ナギたちがプログラムを更新した時に、常駐プロセスの実行判定を見直すべきだったが、見逃していたのかもしれない。ユキがやっているプロセスごとの常駐を定義し直すことで効率良くなるが、シオヤが見つけた独自通信を含むID処理の流れを再整理するのが根本的な解決方法だ。

 気がつけば夜が更けてしまった。悪いくせだ。明日は早く起きれそうにない。最終的には効率が悪いのに、問題が見えてくる面白さにその日は勝てなかった。


 三日ぶりに全員が揃った進捗会、心なしか会議室の空気が少し軽くなっている気がした。

「今日の進捗確認は、インフラチームとリンクチームのそれぞれで、新しい報告があるそうですね。」

 会議で確認することは事前にナナミと私で打ち合わせ済みだ。

「はい、そうです。最初にちょっと私の方から事前説明をしますね。」

 そう言って、ナナミの発言を私は引き取った。

「二つの新しいアプローチが見つかっています。ユキさん達リンクチームは常駐プロセスが性能に影響するかを考察中です。シオヤさん達インフラチームの調査では、セキュリティIDに関わる不必要な処理が見つかっています。今日はこの二つを時間を使って吟味する予定です。」

「どっちから行きますか?」

「そうですね。シオヤさんからお願いできますか?」

 気まぐれな人が会議に飽きないようにと、私はシオヤを指名した。

「じゃあ、こっちから行くかな。」

 今日のシオヤは積極的だ。そこからの説明の前半は、私が昨日聞いたのと同じ内容だった。そして後半は処理を変更した時の性能予想だ。切り取れる範囲で今の処理を小さいシステムにして、修正前後で時間を測定している。

 新しいプログラムの応答速度は、今までより二割ほど向上していた。なによりセキュリティIDの割合調整をしていないのにエラーが発生していない。

「想定通りだ。全体に処理を変更すれば性能は改善する。」

 シオヤは評価プログラムもユキたちが使っているのと違い、自前で用意していた。こういう所が効率が悪いのだが、シオヤなりのこだわりだろう。

「いや、いいですね。」

 その成果を、私はしっかり褒めたたえる。シオヤはさらに饒舌に話を続けた。

「根本的な問題として、この裏側の処理がセキュリティIDごとに最適化されている。セキュリティIDごとの暗号を解く部分で処理に時間差があるから、それを基準に最適化しているのは極めて合理的だ。なので、この処理は抜くのではなくて活かす、ひょっとしたら、それでさらに処理がまだ早くなるかもしれない。」

「本当ですか?」

「まあ、まだ分からんがな。」

 そう言いながらも、やはり自信がありそうな口ぶりだ。

「まあ、まずはやってみるさ。」

「ではこれでお願いします。まずはシオヤさん達で進めて下さい。リンクチームはこの後に別の改善案があるそうなので。」

「そっちは何か役に立つのかね。」

「どちらの提案も有用だと私は思っています。ただ、より効果的な方はどっちか分からないので、現段階では並行した方がいいと。」

 戦力は集中して投下した方がいい場合と分散した方がいい場合がある。今回は後者だろう。

「では、ユキさんお願いします。」

「はい、これはミヤマさんから最初にヒントをもらったアプローチです。」

 そう言ってから説明に入るのは、ユキらしいと私は思った。ここ数日で各人のアプローチやアウトプットへの勘が多少は働くようになっている。

「最初に二つの処理時間の違いをお見せします。この違いはセキュリティ確認用のプロセスが常駐している場合と、ネットワークID切り替えのたびに立ち上げ直しをしている場合です。」

「セキュリティ確認用のプロセスを常駐させた方が処理量がぐっと上がるのが分かりました。ただ、ネットワークIDが変わった時に必ず上がるわけではない。直近のデータによるみたいです。一括処理をしなければ問題はないのですが、性能を上げるためにデータを溜め込んで処理しているので、これが今とはなっては問題です。」

「単純なバグじゃないな。環境を変えた時に最適化しなきゃいけない所が残っていたわけか。」

 シオヤの発言に、私は言葉を加える。

「たぶんシオヤさんが見つけた問題が影響していると思います。」

「だろうな。ID変更の処理で考慮がなさすぎだったんだろう。」

 それを行なっていたのは主にナギとユキだったはずで、この場ではユキに対する嫌味ということになる。ただそれに気づいているのは何人もいないだろう。

「直近のデータ一つだけを読んで処理するように、このプログラムは変更します。」

「ふうん、そんな修正はすぐに終わりそうだな。」

 シオヤのつぶやきに、ユキは正面を向いたまま淡々と返事をする。

「はい。ただ、同じように効率の悪い処理が他にも隠れている可能性が高いです。ですので、それも同時に調べていく予定です。」

「そりゃあそうだ。前提が変わったら全部を見直す、当たり前のことをやってなかっただけだな。」

 その言葉を聞いて、ユキは今度はシオヤに向かって返事をした。

「それを詰めようと思います。シオヤさんにも納得して頂けるように。」

 今日のユキはシオヤの嫌味によく付き合っている。むしろシオヤを挑発しているようだ。すでに性能改善の手応えがあるのだろう、そんなユキを初めて見て私は嬉しく思った。

「納期までの時間がない、どうでしょう。次の進捗会は来週月曜にしませんか。そこまでの成果を二つのチームに持ち寄ってもらいます。」

「いいんじゃないか。」

「ええ。」

 私の提案にコオオルとナナミがすぐに賛同した。

「月曜にはどっちのアプローチがより効果的かも明らかになるでしょう。」

 私の最後の言葉で、少しだけ空気が変わったようだ。物事を急ぐ場合、こうした感情もきっと必要だ。

評価をするにはログインしてください。
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
このエピソードに感想はまだ書かれていません。
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。

↑ページトップへ