約5年前にこんな記事を書いた。
ベストプラクティスに合わせるシンプルに、何かを一から設計したりするときや、問題解決の際は、ベストプラクティスにとっとりましょう、その情報を集めましょう、という話である。
その考えは今でも変わっていないが、当然5年もたつと、どこまでベストプラクティスを重視するか、という根柢の思想というよりも、気持ちの持ちようみたいなのが変わってきた。
つまり、とりあえずベストプラクティスでなくとも、必要条件を満たすならばいいじゃないか、という考え方になってきた。
逆に言えば、ベストプラクティスとは突き詰めると机上の空論になりかねず(極論であるが)、それにのっとることよりも、今目の前の課題を対処しておくことが大事だという気づきを得る経験があの時よりも多くなった。
ベストプラクティスは抽象化しやすく、つまりは共通認識が作りやすく、拡張性があることが大きな利点であるが、それにこだわると、目の前の課題を解決できないことがあるなと感じる。
具体的な経験談は出さないが、例示するとしたら、プログラミングでこういう書き方はあまりしない、コードが汚いといわれても、とりあえず目の前のことを解決するには、動くのでいいのだ、みたいな感じかな。
やや軸をそらして敷衍するならば、こうすべき論を突き詰めてそれを学んで勉強するよりも、さっさと業務で実際に起きている問題を解決してみるほうがいい。
冒頭の記事を書いた時には、そういった場面に出会ったときは、その考え方はできていたが、どうしても「その問題の解決策がその問題しか通用しそうなものに思える」ため、何かその先に問題があったときに拡張性がなさすぎるのではという不安が勝ってしまうケースが多かった。
今振り返ると、小さな問題でもその解決策およびその経験は想定しているよりもはるかに応用できることが多いということだ。
また、ベストプラクティスは思ったよりも応用が利かないといえるケースもある。抽象化されたものであればあるほど、そのケースは多いと思う。
この記事で書きたかったのは、ベストプラクティスは実は意味ないよってことではなく、どちらかというと、「目の前で起きている問題の解決策とその経験の価値」の重要性を強調したかったのであり、これがベストプラクティスかどうかに必要以上におびえなくていいのであるという話。
もっと個人的な話をいえば、私はキャリアとして何かを上司の人から教えてもらうというよりも、目の前で起きた問題を詳しい人が誰もいないから君がやって、という遊撃隊的に対応するポジションが多かった。
まさに冒頭の記事を書いたころの話。それはもう孤軍奮闘で、事実さみしさもあったし、それ以上にこれはあっているのか？ベストプラクティスにのっとっているのか？最先端で効率的な方法とは程遠いレガシーで、まったく価値のないことしてるんじゃないのか？と不安で不安で仕方なかったし、「対処はできたが、答え合わせがない」状態ばかりだった。
ただ、その経験は本当に価値があるものなんだよ、ってことを当時の私に伝えたいし、仮にこの話を当時の私にしたら、すごく安心できたはず。
そして、そのあとのキャリア観も全く違ってきただろうと思う。
以上。
© 2025 ZUUHE