.png&w=1920&q=75)
こんにちは。物件王でリードエンジニアをしている佐藤です。
この肩書きをもらったのが2024年の9月なので、まもなく2年になります。
とはいえ「リードエンジニア」と言われても、ピンとこない方がほとんどだと思います。私自身、最初に聞いたときは「何をする人なんだろう」という感じでした。せいぜい「コードを書く人たちをまとめる役割かな」くらいです。
しかも、その2年のあいだに仕事の中身がかなり変わりました。ここ1、2年でAIがプログラムを書けるようになり、システム開発の現場は作業の配分そのものが変わってきています。
今回は専門用語をなるべく使わずに、今のリードエンジニアが何をしているのかを書いてみます。
ひとことで言うと、現場監督に近い
システムを作る流れは、建物を建てる流れとよく似ています。
- 要望を聞いて図面を引く（何をどう作るか決める）
- 職人が手を動かして施工する（プログラムを書く）
- 検査をして引き渡す（きちんと動くか確認して公開する）
このうち、図面を引く役と検査をする役、そして工程全体に目を配る役を兼ねているのがリードエンジニアです。
そして今、この真ん中の「施工」が大きく変わっています。
手配できる職人の数が急に増えて、しかもものすごく速い。
そういう状態です。速くなること自体はありがたい話です。
ただ、実際に起きたのはそれだけではありませんでした。
図面が甘いまま施工が始まると、間違ったものが今まで以上の速さで積み上がります。
上がってくる量が増えれば、検査する側は追いつかなくなります。
施工が速くなるほど、図面と検査の重みが増す。
この2年で私の仕事が寄っていったのも、まさにその2つでした。
1. 図面を引く
最初にやるのは、どんな構造で作るかを決めることです。
ここで見ているのは、今できるかどうかよりも、1年後2年後に困らないかどうかです。
目の前の要望だけを見て作ると、あとから機能を足したいときに「その造りだと増築できません」という話になります。担当者が変わった瞬間に誰も手を入れられなくなる、というのもよくある失敗です。
以前は、この判断を間違えても、作り直しに時間がかかる分だけ途中で気づく余地がありました。
今は着工から形になるまでが速い。
方向を間違えたことに気づくのが、以前より後になります。
作るのが速くなったからこそ、何を作るかを決める前の時間は削れなくなりました。
もうひとつ大事にしているのが、決めた理由を書き残しておくことです。
「なぜこの造りにしたのか」が残っていないと、半年後には自分でも判断を見直せません。出てきたものが良いのか悪いのかは、何を目指していたかがはっきりしていないと決められないからです。
2. 検査する
この2年で、一番比重が上がったのがここでした。
出てくる量が増えると、見た目には問題なさそうなものが増えます。
動いているように見えるけれど、想定していない入力で止まる。直したい場所は直っているけれど、関係ない別の場所が一緒に壊れている。ざっと眺めるだけでは、まず見つかりません。
なので、確かめ方のほうを仕組みにしています。
- 合否の基準を先に決めて、感覚で判断しないようにする
- 完成検査にあたる確認を自動化して、別の場所を壊していないか毎回チェックする
- 公開の手順と、公開後に異常が出ていないかを見張る仕組みを整える
地味な作業です。
ただ、ここが整っているかどうかで、公開直前の緊張感がまったく変わります。
「たぶん大丈夫だから出す」から「壊れていないと確認できたから出す」へ。
もうひとつ、差し戻すべきものを差し戻す、というのも仕事のうちです。
速く上がってくると、つい「まあ動いているし」で通したくなります。ただ、一度通すと、次からは同じ水準で上がってきます。
基準は、下がるときは静かに下がります。
3. 育て方が変わった
以前は、書き方をひとつずつ教えるのが中心でした。
今は、わからないことがあればまずAIに聞いてもらう、というところから始めています。
調べ方を教えるより、そのほうが早く自分で動けるようになるからです。
その代わり、伝える内容が変わりました。
今よく言っているのは、思い込みのまま進めないでほしい、ということです。
AIは聞けば必ず答えを返してくれるので、それらしい答えが手に入った時点で手が動き始めます。
そこで前提を確認しないまま進むと、そもそも要件が違っていた、という形で後から戻ってきます。
なので、着手する前に質問してほしい、と繰り返し伝えています。
そして上がってきたものについては、「なぜこうしたのか」を自分の言葉で説明できるかを見ています。
説明できないものは、たとえ動いていても本人のものになっていません。次に似たことが起きたとき、また同じところで止まります。
教えることが減ったわけではありません。教える中身が「やり方」から「疑い方」に移った、という感じです。
2年やって、一番効いたこと
振り返ってみると、プログラムを書く力よりも、決めて言葉にする力のほうが求められた2年でした。
技術的に難しい問題より、「どちらでもいいが、どちらかに決めないと進まない」場面のほうが圧倒的に多いです。
そこで判断を止めないこと。決めた理由を残しておくこと。
この2つの重みは、AIが手を動かすようになって、むしろ増したと感じています。
作る速さが上がるほど、方向を決める人と、出てきたものを見極める人が要るからです。
おわりに
加盟店様に使っていただいているホームページや、物件・顧客の管理システム「BKマネージャー」もそうですが、不動産や建築の現場でシステムを使う場面は年々増えています。
そして、AIのおかげで「作ること自体」のハードルは確かに下がりました。
ただ、システムは作って終わりではなく、直しながら長く使っていくものです。
速く作れることと、長く使えるものになっていることは別の話です。
そこを分けて見る人がいるかどうかで、使い勝手や直しやすさが変わってきます。
その役を引き受けるのが、リードエンジニアの仕事だと思っています。
これらのシステムも、そうやって少しずつ土台を整えているところです。
使っていて困ったところがあれば、遠慮なく声をかけてください。