上級者が陥りやすい「ワナ」

技術チャレンジの是非

経験を積み，技術力に自信がついてくると，バグや不具合をより高いレベルで解決したくなります。あちこちに重複した似たようなコードをリファクタリングして，きれいに除去したり，不必要に複雑化した分岐を多態やデザインパターンを使ってすっきりさせたくなります。

既存のフレームワークではうまくいかない部分を独自に拡張したり，パターン化できる退屈な作業は自動化したくなります。

技術者として，正しい姿勢です。しかし，その方向が，目の前にあるトラブルを解決する最善の選択肢とは限りません。とくに「一定時間」で解決することが要求される状況では，技術的なチャレンジには，泥沼にはまり込む危険が常につきまといます。

より良くしたい「幻想」のワナ

技術的にチャレンジしたくなるトラブルは，巧妙に仕組まれた「ワナ」です。そこにはまり込むつもりがなくても，気がつくと何時間もチャレンジして，結局，解決ができないまま時間切れ，という恐ろしい「ワナ」です。

なかでも特別に怖い「ワナ」は「もう少しで，できそうだ」「⁠ここだけ解決すれば，一挙に解決する」という，すばらしいゴールが近くに見える「幻想」です。

私自身，何度もこの「幻想」の「ワナ」にはまって痛い目にあってきました。技術的なチャレンジは，一種の麻薬です。やっているときは時間を忘れて集中できますが，気がつくと，貴重な開発時間をまる1日つぶしていたり，一晩徹夜して，翌日の作業の効率を大幅に落としたりしたことが何度もあります。

時間を見極めていますか？

技術者としてそのチャレンジをやめる必要はありません。しかし，一定時間内に結果を出さなければいけないソフトウェア開発で，ましてや想定外のトラブルの解消のために，消費して良い時間は限られています。

プロの開発者としてやるべきことは，チャレンジする「時間」の限度を設定して，それを超えたチャレンジはやらないことです。

短時間で確実にトラブルを解消できる方法がわかっているなら，技術的に泥臭いやり方であっても，そのやり方でいったんはトラブルを解消しておくことが最優先です。

その解決策を確保したうえで，より良い解決策へのチャレンジに使ってもよい時間を逆算します。その時間内でのみ，チャレンジを行います。１時間と決めたら，きっちり１時間だけ技術チャレンジをします。

引き返す勇気と受け入れる力

チャレンジに当たって，泥沼に陥らないために，2つのことをいつも自分に言い聞かせます。

第一は，頂上の直前で「引き返す勇気」です。許された時間を使ってしまったら，「⁠もうちょっとでできる」とどんなに思っても，そこでチャレンジをストップしなければいけません。「⁠引き返す勇気」が，泥沼化を防ぎ「幻想」のワナから抜け出すために，絶対に必要です。

第二に，「⁠中途半端」を受け入れることです。ソフトウェア開発は，すべて「道半ば」（⁠中途）であり，いつも「半端」（⁠未完成）なのです。限られた時間では，コードをきれいにできる範囲は限られています。そのときに「すべて直す」か「まったく直さない」か，という二者択一が良い判断とは限りません。「⁠許された時間内で，できるところまでは改善しておく」ことも有力な選択肢です。結果は「中途半端」かもしれません。しかし，なにもしないよりは，状況が改善するなら，その時間の中で，できる範囲のところまではやるべきです。

上級者として腕の見せどころは，いわゆる技術力ではなく，「⁠頂上の直前」でも引き返せる決断力であり，「⁠中途半端」であるが，ここまではやっておいたほうが全体としては改善する，という俯瞰的な判断力なのです。

浅い解決・深い解決

トラブルを解決したときに「動いた」「⁠ああよかった」でおしまいにすると，成長の機会を失います。それが「浅い解決」なのか「深い解決」なのか，自問してみましょう。

「浅い解決」とは，「⁠なぜそうなるかはわからないが，いちおう解決した」とか「そのやり方しか思いつかなかった」という解決です。

「深い解決」とは「しくみ」や「原理」をきちんと理解し，「⁠そうかわかった」と納得できた解決です。また，複数の選択肢をいろいろな角度から検討し，トレードオフに迷いながら選んだ解決策です。

トラブルシューティングは時間との戦いです。いつも「深い解決」ができるわけではありません。しかし「浅い解決」であることを自覚しておくと，後から，なにかのきっかけで「深い解決」に出会える機会が増えます。逆に「動いたよかった」で済ませている限り「深い解決」との出会いは起きません。

問題を解決した後で，それが「浅い解決」か「深い解決」か，自問してみることを習慣にすると，技術者として成長の機会が確実に増えるものなのです。