業務の相談がチャットで何往復も続いて、丁寧なのに話が終わらない。AIで開発そのものは速くなっても、何を作るか、誰が決めるか、相手にどう伝えるかの難しさは前と変わっていません。最近の仕事で考えたことを、エンジニアとしての仕事の優先順位という切り口で書いたエッセイです。
技術そのものより先に、伝え方、作る順番、決める人との線引きを考えた記録です。
画面の変更について質問して、返事をもらって、また別の疑問が出る。開発する側には自然な進め方でも、答える側はそのたびに前の話を思い出さないといけません。文章で完成形を想像してもらう時点で、もう結構な仕事をお願いしています。数分の画面共有か比較図が1枚あれば、一度で済んだかもしれない、という話から始まります。
吹き出しは積み上がるのに、完成形はまだ誰の目にも見えていない状態でした。
動いているシステムを新しい言語で書き直す、という技術的なアイデアが出たときのことです。長く運用されてきた業務システムには、画面に出てこない例外処理や約束ごとが積み重なっています。業務の目的があって、会社としての優先順位があって、その手段として技術を選ぶ。新しい技術を試したいなら、小さな新規案件で効果とリスクを比べる道もあります。
同じ技術でも、どの順番で選んだかで意味が変わります。
相談するときの資料を、今と変更後、事実と推測、おすすめ案と理由、やる・保留・やらないが並ぶ形に変えています。現場の担当の方が「使いやすい」と言っても、それが共通の製品全体を変えてよいという承認になるとは限りません。判断の材料を整えるのが技術者の役目で、最後に決めるのは権限を持った人です。
決める人が「整理」から始めなくて済むように、材料を揃えてから渡します。
報告を書いて、進捗表を更新して、管理する人が確認する。気づくと管理するための仕事が増えていきます。普段の会話や作業の履歴から、案件ごとの状態や返事待ち、決まったことをAIで整理できないか。ただし、AIが「承認されたらしい」と推測したものは正式な承認として扱わず、確定させるのは人に残します。
拾って並べるところまでは自動、「決まった」と扱うかどうかは人が確かめます。
先の問題が見えていても、説明したことと相手が納得することは別です。教わった「引っ張るだけでなく、伴走することも必要だ」という言葉と、稲盛和夫オフィシャルサイトの「利他の心を判断基準にする」という考え方から、相手のために動くことは言われたことを何でも引き受けることとは違う、と考えました。役職に関係なく事実をきちんと伝えて、相手が判断しやすい状態をつくることです。
少し先を歩いていても、振り返って相手の歩く速さに合わせる。そんな伴走のイメージです。