Digital Heroes: Guide to IT World

ロンドンのシステムを追いかけて、見つけた「地図」 「うわっ、システム構成図って、こんなに面白いのか！」 そう思った瞬間のことを、今でも覚えている。 当時、私はロンドンで開発されたシステムを日本へ導入していくプロジェクトに参加していた。 私のメインタスクは、先方から渡される大量のドキュメントを、英語から日本語へ翻訳すること。 もちろん、単なる翻訳作業ではない。 システムのことも理解しながら翻訳する必要がある。 だから、英語のドキュメントを読み進めるほど、「最先端のシステムの中に入り込んでいく」ような感覚があった。 翻訳しているのに、金融ビジネスまで見えてくる 面白かったのは、システムドキュメントだけではなかった。 プロジェクトでは、ビジネスに関するドキュメントも非常に多かった。 そこで私は、システムだけではなく、金融ビジネスについても勉強するようになった。 日本の金融ビジネスについても調べた。 それまでに取得していたいくつかの資格の知識も、思いがけず役に立った。 「なるほど。この業務があるから、このシステムが必要なのか」 そうやって、業務とシステムが少しずつつながっていった。 翻訳しているはずなのに、気づけば金融の仕組みを勉強している。 そして、その金融ビジネスを支えるシステムの構造まで見えてくる。 これは、とても贅沢な勉強の時間だった。 コード、サーバ、そして増えていく役割 システムドキュメントを読み込んでいくと、コードもいくつか出てくる。 サーバ構成も書かれている。 最初は、 「こんなにサーバがあるのか？」 と思った。 でも、よく見てみると、それぞれ役割が違う。 ログを扱うサーバ。 バッチ処理を行うサーバ。 それぞれの機能を担当するサーバ。 そこで、ふと気づいた。 「なるほど。ものすごく高機能な一つのアプリケーションを作っているというより、少しずつ役割を持った多くのシステムを組み合わせているんだ」 一つひとつの役割を持ったシステムが集まり、大きなサービスを作っている。 そう考えると、システム全体が少しずつ理解できるようになっていった。 そして、A3一枚の「地図」に出会った そんな中で、私が一番目を見張ったのが「システム構成図」だった。 たくさんのシステムが存在している。 サーバもたくさんある。 それぞれが複雑につながっている。 それなのに、それらが A3一枚 に収...

設計書の先にあった“リアルな価値”を見た日 うわっ、これ……本当に自分が作ったやつだ！ 画面の向こうで、エンジニアの方々が当たり前のように操作しているその仕組みを見た瞬間、胸の奥がじんわりと熱くなりました。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 初めて「使われる現場」を見に行った日 それは、私が関わって作ったプラットフォームが、初めて実プロジェクトで使われた証券会社様の案件でした。 プロジェクトリーダーは、人を引っ張る力が本当に強い先輩。迷いなく前に進み、周囲を自然と巻き込んでいく姿が印象的な方です。その先輩から「一度、現場を見に来たらいいよ」と声をかけてもらい、私はプロジェクトの現場を訪れました。 ■ 設計書が“動く瞬間” そこでは、私が作ったプラットフォームを使い、エンジニアの方々が実際に設計書を書き、そこからプログラムを自動生成し、システムを構築していました。 扱っているのは、システム間連携に関わるプログラム。頻繁に作られるものではありませんが、重要なシステム同士をつなぐ、いわば要の部分です。 ■ 今とは違う、当時のシステム連携 今でこそAPI連携は当たり前で、システム同士は軽やかにつながります。しかし当時は違いました。 まずはサーバ間でシェイクハンズ。 その後、データをメッセージに乗せて送信する。 ヘッダーとフッターを持ち、ペイロードに重要なデータが詰め込まれる——そんなデータ構造が“普通”の時代です。 私は、その「基本のキ」をしっかりと実現できるプラットフォームを目指し、必要な考え方や仕組みを詰め込みました。 ■ 「よく分かってるね」の一言 現場で使っていたプログラマーの方々は、さすがでした。 自由度を高めた私の設計意図をすぐに理解し、柔軟に使いこなしてくれていたのです。 そして、ふとした会話の中で言われました。 「これ、すごく使いやすいですね」 その言葉は、先日、例の先輩が私に伝えてくれた言葉とまったく同じでした。 胸の奥で、何かがストンと落ちた気がしました。 ■ お客様に認められるということ ああ、これが“お客様に認められる”ということなのか。 自分の作ったものが、誰かの仕事を支え、自然に使われ、価値として受け取られる。その瞬間に立ち会えたことが、...

作った瞬間から始まる、エンジニア最大の緊張 うわっ……本当に、これ使われるの!? 試験は何度もやった。テストケースも用意した。動作確認もした。それでも、胸の奥のザワザワは消えなかった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ お客様プロジェクトに組み込まれた“自分の一部” 今回、自分が作ったのは「完成したWebアプリケーション」ではない。 その上に、プロのプログラムが乗ってくる“プラットフォーム”だ。 つまり、自分のコードは裏方。 でも、その裏方が崩れたら、すべてが止まる。 お客様プロジェクトの中で、自分の作ったプラットフォームの一部を使ってもらう。 それは、想像以上にプレッシャーのかかる瞬間だった。 ■ たくさんテストした。用意もしてきた ユニットテスト、結合テスト、想定外ケース。 「ここまでやれば大丈夫」と言えるくらい、叩いた。 先輩も言ってくれた。 「大丈夫ですよ。ここまでやっていれば問題ないです」 理屈では分かっている。 本番で使っても、ちゃんと動くはずだ。 でも—— 頭と心は、必ずしも一致しない。 ■ プロに“叩かれる”という緊張 このプラットフォームは、たくさんのエンジニアに叩いてもらう前提だ。 それも、現場で鍛えられてきたプロたちに。 「どんな評価をもらうんだろう」 「使いにくいって言われたらどうしよう」 完全版じゃない。 でも、だからこそ“設計”と“考え方”がそのまま評価される。 いっぱいテストしたはずなのに、緊張は止まらなかった。 ■ 使われているかどうかも分からない時間 もちろん、目の前で使ってもらうわけではない。 これからの開発で使ってもらい、感想をもらう形だ。 でも—— 1週間、2週間。 どのタイミングで「OK」なのか分からない。 そもそも、もう使われているのかも分からない。 特に大きな連絡もなく、時間だけが過ぎていく。 最初の2週間は、本当に緊張した。 「呼び出されたらどうしよう」 「うまく使えなかったらどうしよう」 ■ 廊下ですれ違った、その一言 2カ月後。 先輩と廊下ですれ違った。 何気ない瞬間に、声をかけてもらった。 「あれ、使えてるよ。使いやすいし、分かりやすい」 一瞬、言葉の意味が...

プラットフォームを作っていたのに、連携を“深く”考えていなかった頃の話 うわっ！まさか、そこから使われるとは——！ システム屋をやっていると、ふと立ち止まって過去を振り返る瞬間が、何度も訪れる。「あの時、どうしておけばよかったんだろう」「今の自分なら、こう設計するのに」。そんな後悔にも似た問いが、頭をよぎる。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 振り返りは、改修のたびにやってくる システムは一度作って終わりではない。改修され、拡張され、想定外の使われ方をしながら成長していく。そのたびに、「あの設計、甘かったな」「ここ、もう一段考えるべきだったな」と、新しい視点が生まれる。そして不思議なことに、自分自身も同時に進化している。学び続けることで、見える景色が確実に変わっていく。 ■ プラットフォームを作っていたのに 今だから正直に言える。 当時、プラットフォームを作っていながら、 システム間連携の本当の大切さが分かっていなかった 。単体としては完成度が高くても、他システムとどう“シェイクハンズ”するのか。その握手が弱ければ、全体は簡単に崩れる。 ■ データが欠損した瞬間に、すべてが分かる 特に痛感したのが、データ欠損時の設計だ。 「落ちない」ことよりも、「落ちたときにどう振る舞うか」。 今ならはっきり分かる。 ここ、めっちゃ大切。 銀行間連携、会社間連携、さらにはグローバルシステムと日本独自システムの橋渡し。日々、その違いに悩まされながら、当時の自分に言いたくなる。「もっと連携を意識しろ」と。 ■ 今このタスクをやるなら、見える景色が違う もし今、同じタスクを任されたら。 きっと、まったく違う設計をするだろう。 その背景には、 メッセージキューイングシステム の経験がある。非同期、疎結合、耐障害性。これをやっていたからこそ、グローバルのエンジニアとも同じ言語で語れた。 ■ 15年以上経って、原点に戻る 気づけば15年以上が経ち、MQシステムのプロダクトオーナーまでやらせていただいた。今の判断軸は、すべてあの頃の経験が基になっている。 システムは進化していく。でも、過去の思想や技術を、きちんと引き継いでいくことが、次の進化を支える。 振り返ることは、後悔じゃない。 未来の精...

新人研修の終盤で見えた、設計と現場のリアル うわっ、マジかよ!? 画面が固まり、次の瞬間、サーバは静かに沈黙した。 「何回サーバ落とせば気が済むの？」——その言葉が、頭の中でぐるぐる回っていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       新人研修も、いよいよ大詰め 新人研修は終盤戦。 30人の新人が、6チームに分かれてプログラムを作る。 ここまで来れば、あとは“動かしてみる”フェーズだ。 前回はApacheのサーバを使い、各グループのリーダーのPCにサーバを立てて進めていた。 多少不安定でも、なんとか回っていた。 今回は「Cosminexus」という選択 今回は日立の製品、 Cosminexus を使うことになった。 企業向けのミドルウェア。響きは頼もしい。 ……が、現実は甘くない。 ライセンスの関係上、全員に配れない。 手元にあるのは、 1台のPCにインストールできるCDが1枚だけ 。 そう、まだソフトウェアはCDからインストールする時代。 選択肢はほぼなかった。 苦渋の決断、その内容は… 悩んだ末の決断。 自分に与えられている 開発用PCにサーバを立てる 。 しかも、 1サーバで6グループ分のインスタンス を動かす。 つまり、30人全員が、同じPCにアクセスしてテストする。 今思えば、なかなか攻めた構成だ。 「ちょっと触るだけ」のはずだった 正直、そこまで影響が出るとは思っていなかった。 画面を少し表示するだけ。 画像もほとんどなく、機能確認が中心。 「ある程度は動くだろう」 そう、完全に油断していた。 異変は、静かに始まった 3チーム目、4チーム目までは、なんとかDeploy完了。 しかし、5チーム目あたりから様子がおかしい。 画面表示が、じわじわ遅くなる。 レスポンスが、明らかに重い。 そして6チーム目。 数人が同時にアクセスした、その瞬間——。 あれ？……落ちた サーバが、 一気に落ちた 。 PC本体は無事。 落ちたのは、サーバのインスタンスだけ。 「……うーん」 これが、性能問題か。 まさか、目の前で、自分が引き起こすとは思っていなかった。 仕様がない、という現実 問題は、 対応の仕様がないこと だった...

24時間365日、止まらない幻想が生む“ぷすんぷすん”の危機 驚きの出発点 「えっ！？システムに休みなんているの？」 そう思ったあなた、ちょっと立ち止まって考えてみてください。 多くの人がこう考えます。 ――システムだから24時間365日動いていいんでしょ？問題ないんでしょ？ でも実際は、そんな安易な発想で作られたシステムが世の中には山ほどあるのです。 システムが休むときとは？ システム設計で重要なことのひとつに、「休む時間を考えてあげる」ことがあります。 「働き続けるわけです。休みなく」。 するとどうなるか？ どこかで必ず限界がやってきます。 ある日突然、煙を出して「ぷすんぷすん……」と止まってしまう。 ――まあ、それは冗談ですが（笑）。 本当の問題は、 アップデートやチェック、クールダウンをするタイミングがなくなる ことです。 動きっぱなしのシステムには、これらを行う余白がありません。 そして「止められないから」という理由で後回しにした結果、ある日突然大きなトラブルに直面するのです。 バスのドライバーに学べ 今はシステムを二重化して、交代させながら運用するという考え方も広がっています。 ですが、交代するなら交代できるように設計をしておかなくてはなりません。 ほら、バスのドライバーだって走行中にいきなり別の人に変わったりしませんよね？ 必ず車庫に戻って、引き継ぎをして、安全に交代します。 システム間でも、同じように“スムーズな交代”ができる仕組みを作る必要があるのです。 「勝手に動かしておけばいい」の末路 「システムは勝手に動かしておけばいい」――そんな設計思想で痛い目を見ている企業は少なくありません。 実際に私も数多くの現場を見てきましたが、ほとんどの場合「休息設計」を意識していないことが原因でした。 人間だって働き続ければ倒れるように、システムにも休息が必要なのです。 みんなにやさしい設計を システムにも休息を！ それは単にメンテナンスの都合ではなく、利用する人、運用する人、そして未来の利用者すべてにやさしい設計へとつながります。 「システム＝常に動くもの」という固定観念を一度壊し、どうすれば健全に長く働けるのかを考えること。 それこそがこれからの時代に求められるエンジニアの姿勢だと思いま...