スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

本当に動いてる!——「使われている現場」が教えてくれたものづくりの本質

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

本番で使われる!?——「試験はやったはずなのに」が教えてくれた本当の評価

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

これを僕が説明するんですか!?——「作る」から「伝える」へ踏み出した日

社会人2年目の終わりに気づいた、ユーザー視点という武器 うわっ!? まさか自分が“説明する側”になる日が来るとは思っていなかった。 社会人2年目も終わりに近づいた頃、私は初めて、自分の作っていたプログラムを人に説明しに行くことになった。舞台は証券系のプロジェクト。緊張感の高い業界で、失敗は許されない。そんな現場に、先輩と一緒に向かった。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       初めての「営業」に近い経験 今回説明するのは、Justwareという開発基盤。このJustwareを使ってくれるというプロジェクトへの説明だった。 お客様も含め、「開発が短くなるのであれば」という前向きな理由で、採用を検討してくれていた。その背景には、先輩がこれまで多くの信用を勝ち得てきた実績がある。プラットフォームの選定自体も、その信頼の上に成り立っていた。 初めて会う先輩、その圧倒的な熱量 同行した先輩は、実は初対面だった。しかし、その人は驚くほどやる気にあふれていた。 話し方、立ち居振る舞い、相手の反応を見る目。お客さんが気に入るのも、すぐに分かった。 「この人と一緒なら大丈夫だ」 そう思えたことが、緊張を少し和らげてくれた。 「証券系でも使える」をどう伝えるか 私にとっては、ほぼ初めての営業活動だった。 証券系という厳しい要件の中でも、しっかり使えることを、一生懸命説明した。特に力を入れたのがデータ連携の話だ。 作業がいかに簡単になるか。 考えるポイントをどれだけ単純化できるか。 仕組みを深く理解しなくても、データの理解に集中できるように設計してきたことを、丁寧に言葉にした。 「あ、これなら作れる」の一言 説明が終わったあと、先輩が言ってくれた。 「分かりやすいね」「あ、これなら作れる」 正直、胸が熱くなった。 プログラムを書くことを中心にした作りだったが、それでも認めてもらえた。 自分の作ったものを、「良い」と言ってくれる人がいる。その事実が、何より嬉しかった。 少しこしょばかったが、確かに、うれしかった。 帰り道に浮かんだ、小さな自信 打ち合わせが終わり、帰り道を歩く。 気づけば、自然に笑みがこぼれていた。 「作れる」だけでなく、「伝えられる」。 ユーザーに説明するこ...

ドキュメントって、誰のために書いてるんだっけ?

設計書とマニュアルに向き合って初めて気づいた「伝える仕事」の正体 うわっ!? ドキュメントって、誰が読むの? 画面を前に、思わずそんな独り言が漏れた。プログラムを書いているときには感じなかった種類の、じわじわとした難しさがそこにあった。     ■ プラットフォームを「作る側」に回った瞬間 プラットフォームを理解し、サーバを理解し、構築業務に携わる。 私の役割は、設計からプラットフォームを作っていく仕事だった。設計書を起点に、プログラムを自動生成する。だからこそ、設計書の出来が、そのままシステムの質になる。 フォーマットを決め、何をどう書いてもらうかを定義する。 プログラムが得意な先輩に何度もレビューしてもらいながら、少しずつ形にしていった。 ■ 「全部プログラムに落ちるの?」という葛藤 設計書は、どこまで書けばいいのか。 全部が全部、プログラムに落ちるのか。結構、時間をかけて考えた。 経験が豊富とは言えない自分が、設計者の修正を想定し、設計すべきことを考える。よくある問題は「設計漏れ」だ。だからこそ、漏れがないように設計書の項目を一つひとつ決めていった。 ■ 本当の難関は、その先にあった 一番てこずったのは、そこからのマニュアル作りだった。 考えたことを文章にすればいい、という話ではない。読む人が分かりやすいように、丁寧に、でも読みやすく。 そもそも、どうやってマニュアルを開くのかすら分からない人もいる。 そして正直に言えば――自分は、あまりマニュアルを読まないタイプだ。 ■ 「自分でも読むか?」を問い続ける そんな自分でも読むには、どうしたらいいのか。 意味のある情報は何か。知りたい情報は、きちんと読み取れるのか。 気づけば、「プログラムを書いている方が楽かもしれない」と思っていた。 こんなにもドキュメントを書くのが下手だったなんて。日本語の奥深さを、思い知らされた。 ■ 消せるから、書ける それでも、パソコンで良かったと思う。 すぐ消せる。何度でも書き直せる。難しさに苦しみながら、少しずつ仕上げていく。 ドキュメントは、単なる説明書ではない。 未来の誰かと仕事をつなぐ、静かなコミュニケーションなのだと、今なら分かる。 設計も、プログラムも、ドキュメントも。 全部つながって、...

その“使われ方”、想定外でした——15年越しに気づいた設計の本質

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

ここから自動で!?――メッセージキューイングが変えた「基盤づくり」の視点

研修担当から基盤構築へ。設計が主役になる開発の現場 うわっ、プログラムって“書かない”ところから始まるの!? そんな衝撃から、私のメッセージキューイングシステムとの出会いは始まりました。 それまで私は研修担当として、アプリケーション寄りの世界にいました。ところが次に任されたのは、サーバ基盤の構築担当。舞台は、ソフトウェア工場で作られた Cosminexus を中心とした、いわゆる「開発基盤」の世界です。     ■ 初めて触れた、メッセージキューイングの仕組み 私が作ることになったのは、メッセージキューイングシステムの 自動生成 。 サーバを呼び出すプログラムには、実はいくつかの決まったパターンがあります。そしてそのパターンは、実装段階ではなく 設計の時点 で見えてくる。 「だったら、そのパターンを設計書で指定してしまえばいい」 「決められたソースは、自動で作ってしまおう」 そんなコンセプトでした。 ■ 設計から、プログラムが生まれる 設計書に「このパターン」と書けば、対応するプログラムが自動で生成される。 今でこそAIがコードを作る時代ですが、 設計書から、設計したとおりのプログラムを作る という発想は、当時としてはかなり画期的でした。 その結果、設計と実装のズレは大幅に減り、実装ミスも少なくなる。 コンセプトは明確で、迷いがない。 ■ Justwareという基盤フレームワーク この仕組みは、 Justware というJavaのフレームワークに上書きする形で実現されていました。 単なるツールではなく、開発の考え方そのものをプラットフォームとして提供する。 「さすが大きな会社…プラットフォームまで作るのか」 そう感じた瞬間でもありました。 ■ 設計者に突きつけられる現実 この開発に関わって、強く実感したことがあります。 それは、 設計者がプログラムをどれだけ理解しているか が、すべてを左右するという事実。 設計からプログラム、そしてテストまで。 この流れがスムーズにつながってこそ、大規模システムは安定する。 それは、構築に関わる人すべての願いでもあります。 「それを実現しよう!」という本気が、この仕組みには詰まっていました。 ■ 大規模開発に効いてくる理由 人が多く、システムも...

まだ現役!?――ミドルウェア構築で触れた「基盤づくり」の深層

アプリ屋が、いきなり開発基盤に放り込まれた話 うわっ、今でもあるの!?――正直、それが最初の感想だった。 次のプロジェクトは、日立の開発基盤を構築する案件。扱うのは Justware 。 研修時代に一部使っていたとはいえ、まさか今も現役で使われ続けているとは思わなかった。 でも、長く続けてくださっていることには、素直に感謝しかない。     ■自分たちの製品を使い続けるという文化 当時から、自分たちが作っている製品を自分たちの現場で多く適用していく文化があった。 それは、とても良い文化だと思う。 一方で、「自社製品縛り」になることで、動きにくかった点が多かったのも事実だ。 今回、自分が担当したのは、Justwareの中の ある一機能 。 まず全体を理解し、その上で機能を付け加えていく役割だった。 ■アプリ屋が、いきなり基盤づくり それまで作ってきたのは、ほぼアプリケーション。 そんな人間が、いきなりミドルウェア、しかも開発基盤づくり。 なかなか簡単じゃない。 担当したのは、端っこの機能とも言える Message Queuingシステム 。 でもこれ、今ではデータ転送が当たり前になった世界では、超必須の機能だ。 ■時代の少し先を行っていた機能 当時もシステム間連携は当然行われていたが、今ほど多くはなかった。 基本は自前で構築するスタイルで、DBやWeb、機能管理がメイン。 その中で、対外システムとの接続を担うのが、この機能だった。 使い方次第では、対内システムとの接続にも使える。 でも当時は、そこまで活用されていなかった。 使われていないから、資料も少ない。 ネット上の情報もほとんどない。 ■難解な情報と、深層への入口 ソフトウェア工場から出てくる Cosminexus の資料は、正直かなり難解だった。 読めば読むほど、「これはアプリじゃない」と思わされる。 でも同時に、ソフトウェア開発の 深層に近づいていく感覚 があった。 見えないところで、システムを支える仕組み。 派手じゃないけれど、確実に効いてくる世界だ。 ■次に進むための基盤 アプリしか作ったことがなかった自分が、基盤づくりに触れた経験。 これは、確実に次につながっている。 難しい。情報も少ない。 でも、だか...