実装者への安心感という難しさ

実装者は常に不安である。

この言語でいいのか

このFWでよかったのか

このディレクトリにこれを書いていいのか

この関数の責務はこれでいいのか

こんな書き方してあとからとんでもない負債にならないか

この外部リソースはどういうエラーを返すのか

自分の考えは他のエンジニアに伝わっているか

誰か「大丈夫だ」と言ってくれ！

という悲痛な叫びを常に心の底に抱えている。

解決方法も様々だ

集合知で正当化しよう

リーダーとレビューだ

lintだ

testだ

型だ

ドッグフィーディングだ

カナリアリリースだ

ドキュメントだ

設計思想に名前をつけてしまえ

定期的な確認だ

最後はAdaptorだ

これを丁寧に丁寧に仕分けして、不安を構造化し、局所的または横断的なソリューションを当てはめてきた歴史があるんだろう。右往左往や繰り返す同じテーマとかはありそうだが、しかし、螺旋階段のように「進化」していっているんだと信じるに足りる証拠や肌感覚はあるんじゃなかろうか。つまり別に絶望しなくても良い。

しかし、それでも実装者は「永遠の不安」を抱えているように見える。

まぁどの職種、どの現場でも不安との隣合わせなんだろうが、殊更それが強い「気がしている」。（※あくまで俺が）

適当な仮説でその理由を探ってみよう。

結果の定義が市場から与えられていないから

「なにをすべきか」の定義が「売上」付近の話じゃなくなると途端に話は複雑になる。会社としてはすべて売上や利益に表現されるべきなのだが、バリューチェーンは後ろへ行けば行くほど依存関係が激しく、最終収益の正当な原因配分を受けにくくなる。

しかしまぁこれはあらゆるコストセンターにありがちな話なんじゃないだろうか。

こういうケースは目標や現場の意思決定における優先度を明瞭化しておくのが恐らくいいだろうと思われるが、まぁまさにそこに合意を取ることが激しく困難なんだろう。さらにアプリケーションの場合は資産とも負債ともなりうるものなので、優先度に時間軸を入れたときの柔軟さが「ダブスタ感」を演出して、事態はどんどん不明瞭で曖昧なものだと感じるようになろうだろう。

結果、実装者があらゆる複雑な事象に対して「得ようと思う結果」の意思決定しなきゃいけなくなり、わかりやすくいうと下記の態度のどれかに回収される。