僕は元高校教師で、今はフリーランスのシステムエンジニアとして活動しています。
「教師からエンジニアへ」というと、全く違う仕事に思えるかもしれません。でも、この時期に新しいプロジェクトに取り組んでいて、実はすごく似ているなと感じることがあります。
それは、どちらの仕事も「問いを解く」ことから始まる、ということです。
数学の問いと、システムの問い
高校の数学教師だった頃、僕は生徒たちに日々、様々な数学の問題を解くように促していました。 「この問題、どうすれば解けるだろう？」 生徒たちは、与えられた情報から仮説を立て、様々な公式や定理を試しながら、答えにたどり着くための道筋を探します。時には、間違った道に進んでしまって、また最初からやり直すことも。
今の僕の仕事も、これと全く同じです。 クライアント様から持ち込まれるのは、「もっと業務を効率化したい」「このサービスを新しく作りたい」といった、漠然とした「問い」です。 僕はまず、この「問い」を深掘りすることから始めます。
- なぜ、その機能が必要なのか？
- 誰が、どのような状況で使うのか？
- どんなゴールを目指しているのか？
これらの問いに丁寧に向き合い、クライアント様と一緒に「本当に解くべき問題」を明らかにしていきます。
「板書」と「設計書」
数学の問題を解く時、僕は生徒たちが理解しやすいように、解法のプロセスを丁寧に板書していました。 「なぜこの式を使うのか？」「次の一手は？」と、頭の中の思考を可視化することで、皆が同じゴールに向かえるように導きました。
システム開発における「設計書」も、まさに「板書」です。 クライアント様の課題をどう解決するか、どんな技術を使って、どんな機能を作るか。頭の中にある複雑なアイデアを、誰が見てもわかるように、ロジック立てて整理していきます。 この設計書があるからこそ、クライアント様も開発メンバーも、同じビジョンを共有し、迷うことなく開発を進めることができるのです。
「答え合わせ」と「デバッグ」
数学の授業の最後には、必ず「答え合わせ」をします。答えが合っていても、解き方が遠回りだったり、もっとシンプルな方法があったり。生徒一人ひとりの解法を見て、「ここはもっとこうすればいいよ」とフィードバックしていました。
システムの開発でも、実装した機能が思い通りに動くか、「デバッグ」という作業で答え合わせをします。 コードのどこかに潜んでいるバグは、まるで生徒が解き方を間違えた時のように、システムを正しく動かなくさせてしまいます。 バグを一つひとつ見つけ出し、解決していく作業は、教師が生徒を正しい道へ導くことと、本質的に同じだと感じます。
変わらない「本質」
教師もエンジニアも、誰かの「困った」という問いに向き合い、最適な答えを導き出す仕事です。 場所は教室からオフィスに変わりましたが、目の前の人と真摯に向き合い、粘り強く課題を解決する姿勢は、あの頃から何も変わっていません。
「あなたの抱える問い、一緒に解いてみませんか？」 そんな思いで、日々仕事に取り組んでいます。
