トラブルシューティングの極意―達人に訊く問題解決のヒント

第10回 [ソフトウェア開発編]悪循環からの脱出―ソフトウェア開発の時短術+見極め技

この記事を読むのに必要な時間:およそ 3 分

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

技術チャレンジの是非

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

浅い解決・深い解決

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

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

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

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

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

視野を広げるほど仕事は「楽」になる

画面仕様書に「電話番号」「必須」と書かれています。Validationフレームワークを使えば,簡単に実装できそうです。

では,なぜ「必須」なのでしょうか?

答えは仕様書の中にはありません。⁠注文」を配送する時に,配送業者が不在時の連絡先に使いたいのかもしれません。⁠注文」を受け付けたのは良いが,在庫がなく出荷が遅れても良いか,それともキャンセルするか,顧客と連絡を取りたいのかもしれません。

仕様上の「必須」を,このように,仕事のやり方や業務ニーズから理解することで,ソフトウェア開発の仕事は驚くほど「楽」になります。

まず,つまらない手戻りや追加作業が減ります。機能要件や画面仕様書は,業務の関心事や業務ルールを,現実世界よりも,そうとう単純化したものです。また,残念ながら,誤記やヌケモレも多く,あちこちで整合性がとれていないことが現実です。

そして,その仕様の不備が,結果的に,開発者の手戻り作業や想定外の追加作業に直結します。

開発者が,機能要件や画面仕様書の背景にある,実際の仕事のやり方まで視野を広げて理解するようになると,仕様書の不備が早期に発見できたり,合理的な補完が自然にできるようになります。その結果,手戻り作業が起きにくくなります。

また,利用者や業務の専門家とのコミュニケーションがやりやすくなり,ちょっとした会話をするだけで,大きな勘違いを早期に発見し,設計の大幅なやり直しを予防できます。業務のやり方や業務の関心事に視野を広げることが,トラブルを予防します。

業務知識以外にも視野を広げる対象があります。大勢で仕事を分担している場合,他のメンバーや他のチームのやっていることまで視野を広げておくと,自分が見落としていること,勘違いしていることを発見する機会が増えます。

トラブルを事前に防ぎ,余計な仕事をやらなくて済むようにするには,今までよりは,ちょっとだけ視野を広げることです。

ちょっと視野を広げたら,さらにもうちょっと視野を広げる。そうやって視野を広げ続けていくと,自分の専門分野の理解も深まります。別の文脈や見方から,自分の専門分野を見直すことができるようになると,いままでは気がつかなかったレベルで,その分野が理解できるようになります。

広げながら掘り下げる。掘り下げながら広げる。これを続けることが,技術者として成長する極意です。

Software Design

本誌最新号をチェック!
Software Design 2021年7月号

2021年6月17日発売
B5判/184ページ
定価1,342円
(本体1,220円+税10%)

  • 第1特集
    先駆けに学ぶゼロトラストの現実解
    リモートワークに必須のセキュリティモデル
  • 第2特集
    IT技術の総力戦
    ISUCONで学ぶパフォーマンスチューニング
  • 特別企画
    WSL 2本格入門
    何ができるか,どこまでできるか
  • 特別企画
    5分で試す,機械学習を用いたワクチン開発の世界
    自然言語処理技術との類似と相違
  • 短期連載
    GitOpsで作るKubernetesのCI/CD環境
    [1]GitOps超入門

著者プロフィール

増田亨(ますだとおる)

ギルドワークス株式会社 取締役

業務アプリケーションのアーキテクト。ビジネスの関心事を正しく理解し,顧客に価値あるソフトウェアを届けるために,日々「ドメイン駆動設計」を実践中。専門分野:オブジェクト指向設計,エクストリームプログラミング,Java/Springフレームワーク。

Twitter ID:@masuda220

バックナンバー

トラブルシューティングの極意―達人に訊く問題解決のヒント

バックナンバー一覧