新卒二年目からプロジェクトマネージャーの仕事をしています。
要件定義をして、お客さんと話して、エンジニアと詰める。 自分でコードを書き続けたわけではないのに、この仕事はそれなりに回りました。 最初は、たまたま向いていたのだろうと思っていました。
いま考えているのは、前の段までで手に入れたものがここに効いている、ということです。
詰められるかどうかの差#
仕様を詰めるとき、聞けることと聞けないことがあります。
「このデータはどこに置くんですか」と聞けるのは、置き場所が何通りかあると知っているからです。 一通りしかないと思っていれば、そこは質問になりません。 そのまま流れて、あとで困ります。
見積が妥当かどうかも同じです。 中身を全部読めるわけではありません。 何と何を比べてこの形にしたのか、と聞ければ、その答えの筋は判断できます。
選べるものを知っていると質問になり、知らないと素通りになります。
AIに任せているときも同じ#
いまはコードのほとんどを AI に書かせています。
任せていても困らないのは、出てきたものを見て「そこは違う」と言えるからです。 言えるのは、同じことをする方法が他にもあると知っているからでした。
逆に、選択肢を持っていない部分については、私も「はい」しか言えません。 提案を評価する材料がないので、そのまま受け取ることになります。 そうやって受け取ったものは、あとで直せなくなります。
AI に丸投げして詰まるのは、AI の性能の問題というより、こちらに差し戻す言葉がない状態を指しているのだと思います。
遠回りが効いている部分#
もう一つ、自分では意外だったことがあります。
エンジニアと話が通じないという相談を受けたとき、私はどの言葉が足りていないのかを当てられることが多いです。 これは技術に詳しいからではありません。 自分が長いこと分からなかったからだと思っています。
早く理解した人は、分からなかった状態を再現できません。 私はスクールと Progate で二度止まって、二年空けています。 そのときに何が見えていなかったかを、まだ覚えていました。
要件定義も、相手が何を持っていないかを探す作業です。 遠回りしたことが、結果としてここで効いています。
ただ、これは自分の実感であって、他の理由と切り分けられてはいません。 仕事として何年もやってきた効果や、多国籍のチームで働いた経験も混ざっているはずです。
結局のところ#
この連載で並べた順番は、コードを書けるようになるための道筋として作りました。
書き終えてみると、そこで手に入るものは、書く力よりも先に、任せたものを判断する力のほうに効いています。
選べるものを持つと、問いが立ちます。 問いが立つと、判断ができます。 判断ができると、任せても主導権が残ります。
for で眠くなっていた頃の私に足りなかったのは、この連なりの入口でした。
いまも、自分が一度も手で書いたことがない領域については、同じ場所に立っています。