Digital Heroes: Guide to IT World

動くシステムはある。でも未来のJava版をどう描くか？ ああっ、まるでパズルのピースが逆さまに飛んでくるようだ！ 私が任されたのは、金融システムのCobolからJavaへの変換プロジェクトでの構成管理だ。 すでにCobolで動いているシステムがあり、設計書も残っている。 だが、それを最新のJava設計書に書き換え、プログラムとして組み上げなければならない。     多様なチーム、複雑な利害 プロジェクトには、日立製作所を1次受けとして、5社ほどの2次受けが参加していた。 各社、Cobolが分かるエンジニア、Javaが分かるエンジニア、そして金融分野に精通した設計者を揃えている。 優秀な2次受けベンダーの方々からの圧も相当で、緊張感は増すばかりだ。 Cobolの常識とJavaの自由度 Cobolの世界では、プログラムの作り方や書く環境はほぼ決まっている。 構成管理といえば、ソースの管理だ。 見出し部、環境部、データ部、手続き部などを決め、各チームの書き方を揃えるのが定石だった。 しかし、Javaとなると話は複雑になる。 書き方のルールだけでなく、パッケージ基準やソース構成、オブジェクト指向を活用した共通クラス構成まで考慮する必要がある。 設計書からDebug、バージョン管理まで まず着手したのは、Java設計書の整理だ。 Cobol設計書を参照しつつ、Javaのクラス構成やパッケージ体系に落とし込む作業。 各チームがバラバラに動くと、後々のDebugやテストで混乱する。 だからこそ、Debug順序も先に決めておく。 構成管理の肝は、バージョン管理だ。 Javaのように複雑な環境では、少しのずれが全体の破綻につながる。 GitやSVNを使い、各チームのコミットルールを統一する。 コミット単位、ブランチ戦略、マージ方針まで細かく定め、2次受け全体で共有する。 学びと挑戦の統合 一方で、Cobol時代の常識は無視できない。 既存の環境・手続き・データ部は大きな制約条件だ。 それを踏まえつつ、Javaのモダンな書き方を適用する。 オブジェクト指向の利点を活かし、共通クラスやライブラリの再利用も進める。 毎日の会議では、5社の代表者が設計書とコードの違いを詰める。 Cobol出身者の意見、Javaエン...

設計書の行間に宿る、日本のシステム開発の底力 うわっ、設計書にない機能が入ってる!? エンジニアとして最初に配属されたプロジェクトで、私は少し戸惑いながら画面を眺めていた。 ■ 初めての現場は「銀行×Web」 私が日立で最初に配属されたのは、銀行プロジェクトだった。 銀行の基幹システムをWebブラウザから操作するシステムで、作ったWebページは最終的に行内全体へ公開されていく。新人にとっては、なかなかの緊張感がある現場だ。 最初は日立システムズの先輩社員について、設計書を作るところから一つひとつ確認していった。 すでに要件定義は完了しており、工程は基本設計、そして詳細設計へ。私は一部の機能担当を割り振られ、Excelで設計書を書き、先輩のレビューを受ける毎日だった。 ■ 口数は少ないが、技術は確か その先輩は、とにかく優しい人だった。 口下手で、あまり多くを語らない。いわゆる「もくもくタイプ」。でも技術力は確かで、質問すると、少し間を置いてから独特で面白い回答を返してくれる。 設計書も、私が書いたものに先輩が手を加えながら一緒に仕上げていく。否定されることはほとんどなく、「ここ、こうした方がいいかな」と静かに示してくれる。新人にとって、これ以上ない環境だったと思う。 ■ 設計書にない“親切” ある日、先輩が担当している機能をレビューしていて、気づいた。 「あれ、この機能、設計書に書いてない…」 正直に聞いてみた。 「先輩、これ、設計書にないっすよ？」 返ってきた答えは、拍子抜けするほどあっさりしていた。 「あ、サービスで付けときました。」 理由を聞くと、こう続いた。 「これ、指摘して確認して、変更要件定義して…ってやると面倒でしょ。どうせ必要になるから、付けときました。」 ■ 今なら分かる、その凄さ そのときは「そんなことしていいんだ」と驚いただけだった。 でも今思うと、これは業務を深く理解し、利用者のことを本気で考えていないとできない判断だ。 その事業分野や業務に精通した人の感覚が、開発者レベルまで浸透している。 個別に細かく指示しなくても、自然と“忖度”がシステムに組み込まれていく。これこそが、日本の大企業が持つ構造的な強みなのだと、後になって気づいた。 業界を知っていることは、単なる知識ではない。 ...