システムを作る側から、システムを「つなぐ側」へ
「えっ、今回はアプリを作らないの？」
今回のシステム開発プロジェクトが始まったとき、少し意外な展開になった。
実は、今回のシステム開発では、自分の部署はそれほど出番がなかった。
というのも、今回導入するシステムは、すでに完成している。ゼロからアプリケーションを開発するのではなく、完成したシステムを日本のビジネス環境に合わせて導入していくプロジェクトだった。
もちろん、話はそんなに簡単ではない。
新しいシステムが突然やってくれば、それまで使っていた周辺システムとの間に「Interface」という問題が発生する。
当然、各周辺システムには改修が必要になる。
「システムは完成しています」
そう言われても、周りのシステムからすれば、
「いやいや、急に新しいものが来たんですけど……」
という話だ。
こうして、Interfaceに四苦八苦するプロジェクトが始まった。
「作る」より「理解する」が仕事になった
その周辺システムを作っているのが、私の部署だ。
最初は、今回のシステム導入でも、当然アプリケーション構築が必要になると想定していた。
ところが、システムを理解していくと、少しずつ見え方が変わってきた。
そのシステムは、想像以上に柔軟だった。
Config、つまり設定によって、多彩な調整ができる。
つまり、プログラムそのものを書き換えなくても、多くの要求に対応できる仕様になっていた。
さらに、今回はビジネス側も新しいシステムに合わせて業務を作り込んでいく。
そのため、「日本のビジネスに合わせてシステムを大幅改修する」という場面も、当初想定していたほど多くはなかった。
では、大規模アプリケーション製造部隊にいる自分に、何ができるのか。
そこで役立ったのが、これまで身につけてきた「英語」と「システム」の両方だった。
フルスタックを超える人には、まだかなわない
もちろん、世の中には、システムを深く理解し、設計し、実装し、英語でコミュニケーションまで完結できる「フルスタックを超える」ようなメンバーがいる。
正直、そこにはまだかなわない。
でも、自分にはできることがある。
システムの仕様を理解しながら、英語のドキュメントを読み込む。
技術的な意味を理解する。
そして、それを日本のメンバーが理解できる形に翻訳する。
気がつけば、今回の主な作業は「翻訳」になっていた。
しかも、数ページではない。
何百ページにも及ぶシステムドキュメント。
それが、自分のメインタスクになった。
大量の翻訳作業。ならば、受けてたとう
これをどう捉えるかは、人それぞれだと思う。
「大量の翻訳作業か……」
そう思う人もいるだろう。
でも、私は違う捉え方をした。
これは、単なる翻訳ではない。
翻訳するためには、システムを理解しなければならない。
理解すればするほど、システムの構造が見えてくる。
そして、翻訳を通じて、英語の技術ドキュメントそのものが自分の知識になる。
つまり、翻訳という作業そのものが、次の自分を作る学習になっている。
だから、大量の翻訳作業。
受けてたとう。
目の前のドキュメントを一枚ずつ読み込む。
知らない仕様を理解する。
英語を日本語に変える。
そして、また一つシステムを理解する。
今回のプロジェクトで、自分の部署が大規模なアプリを作る機会は、思ったほど多くなかった。
でも、その代わりに「システムを理解し、言語とビジネスの間をつなぐ」という、自分にしかできない役割が見えてきた。
フルスタックを目指す。
そして、その先へ。
「作れる人」だけではなく、「理解し、つなぎ、伝えられる人」になる。
コメント
コメントを投稿