分からないことを、
そのままにしない。

START

必要になったものを、
その都度覚えてきました。

最初から技術を体系的に学んできたわけではありません。

Javaのコードを見ても分からない。 エラーが出ても、 なぜそうなるのか分からない。

Windchillの案件に入れば、 BOMやAssy、オブジェクトの関係が分からない。

NetSuiteに入れば、 今度はSuiteScriptや外部連携が出てくる。

分からないものが出てくるたびに、 調べて、 コードを読んで、 実際に動かして確認してきました。

仕事を進めるために必要だったから覚えた。 そういうものの方が多いです。

HOW I APPROACH

分からないときは、
まず切り分ける。

実務で困ったときに、 いきなり正解が分かることはほとんどありません。

まず、 どこまでは想定通りなのか。

どこから違っているのか。

コードなのか、 データなのか、 設定なのか、 そもそも仕様の理解が違うのか。

一つずつ確認して、 問題の場所を狭めていく。

Tech Journeyでは、 できるだけその流れまで残したいと思っています。

FOUNDATION

基礎は、
やっぱり必要だと思う。

実務では、 知らないものを短い時間で キャッチアップする場面がよくあります。

そのときに助けになるのが、 結局は基礎でした。

Javaの型やオブジェクト、 ListやMap、 例外、 HTTP、 SQL、 JSON。

一つひとつは基本的な内容でも、 そこが分かっていると 初めて追える処理があります。

文法だけ覚えるのではなく、 「なぜこう書くのか」 「なぜこのエラーになるのか」 まで分かる状態にしておきたい。

このサイトでも、 そこは大事にしています。

AI

AIは使う。
でも、分からないままにはしない。

調べ物やコードを書くときに、 AIを使うことは増えました。

分からないことを整理したり、 実装のたたき台を作ったりするには とても便利です。

ただ、 出てきたコードを そのまま使えばいいとは思っていません。

何をしているのか読めること。 必要なら直せること。 実際に動かして確認できること。

業務システムなら、 なおさらそこは外せないと思っています。

SYSTEM TO FIELD

技術だけ見ていても、
分からないことがあった。

開発をしていると、 どうしても画面やコード、 データベースの中を見ることが中心になります。

でも、 実際の業務や現場に関わると、 それだけでは説明できないことがありました。

なぜこの仕様なのか。

なぜこの項目が必要なのか。

なぜ紙やFAXが残っているのか。

なぜ同じ機種でも、 号機や仕様によって必要な部品が変わるのか。

そういう背景を見るようになってから、 システムの見え方も少し変わりました。

PEOPLE / ORGANIZATION / WORK

仕事は、
技術だけでは進まない。

自分で調べて進めること。 キャッチアップすること。

それだけで仕事が進むわけでもありません。

人を動かすこと。 自分を動かすこと。

動機、利害、権限、責任。 承認、意思決定。

建前と本音が違うこともあります。

技術的には正しくても、 それだけでは進まないこともありました。

そういう経験を重ねるうちに、 見る範囲も少しずつ広がってきました。

技術だけでなく、 業務・現場・人まで見るようになった。