初級ソフトウェアエンジニア · 業務ごと
分析の単位は職種名ではなく業務である。以下の一つひとつが、その方向、判断が証拠に基づくのかプラットフォームの推論なのか、その理由、そして何を立証していないかを伴っている。
このページのすべての業務#
定型的なコードを書く
自動化されつつある✓ 証拠に基づくCRUDのエンドポイント、フォーム、標準的な連携、既知のパターンに対するテスト。
仕様がはっきりしていて、学習データに大量に含まれていて、走らせればすぐ確かめられる。コード生成にとって最も強い筋書きであり、そして偶然にも、若手が雇われてやっていた仕事の大半がこれである。
生成することと、それを引き受けることは同じではない。誰かが「これは正しい」と判断しなければならず、そしてその誰かは歴史的に、まず自分で書くことによって判断できるようになってきた。
よく知らないシステムのデバッグ
増強されつつある≈ 本サイトの推定症状のある場所に原因がないときに、なぜ壊れたのかを突き止める。
ツールは仮説を出すこととスタックトレースを読むことが本当に得意である。弱いのは、特定のシステムの模型を頭の中に保ち、どの観測が決定的になるかが分かる部分である。
生成コードの天井が最もはっきり現れるのがここであり、そしてこれこそ、若手と「一人にしておける人」を分ける技能である。
生成されたコードをレビューする
新しい業務✓ 証拠に基づくもっともらしいコードを、自信を持って間違っている箇所を捕まえられるだけ丁寧に読む。
作られるコードの量が急に増え、それを検証する必要も一緒に増えた。流暢なのに間違っているコードをレビューすることは、独立した、そして新たに中心となった技能である。
うまくレビューするには、レビュー対象を自分で書いたことが要る。その判断力を育てていた「書く仕事」こそが自動化されている仕事なのだから、この業務は数年のうちに供給の問題を抱える。
曖昧な要望を仕様に変える
いまも人が主導≈ 本サイトの推定本当は何を作るべきなのかを明らかにする問いを立てる。
利用者、事業、そして既に試されたことについての文脈が要る。生成はこれより下流にあり、間違った仕様を、人がやるより速く増幅する。
これは通常は上級者の責務である。それを若手の業務として挙げているのは、この職が今どこにあるかではなく、どこへ向かっているかを描いているからである。消えたのは、そのあいだにあった中間の段のほうである。
部品どうしの組み合わせ方を決める
いまも人が主導≈ 本サイトの推定二年後にもまだ成り立っている構造とトレードオフを選ぶ。
トレードオフの判断は、コードベースの外にある制約 —— チームの人数、期限、事業が次に必要とするもの —— に依存する。それが「上級」という言葉の中身であり、そして若手が二年間定型的なコードを書くことで到達していた目的地でもある。
上級者は安全だと言うことは、入口についての言明ではない。上級への道は二年分の定型コードを通っており、その道に代わるものは何も現れていない。