いつも「運良く」解決方法が見つかる
見かけたツイート
ぼくは仕事のトラブルがあった時でも「運良く」解決方法が見つかることが多いなと感じていました。
そんな中、「なかめのくまちゃん」さんの以下のツイートを見かけました。
これを読んだときに「なるほど！」と思い、この記事を書こうと思いました。
修羅場を切り抜けた人がよく「運良く”A“があったから助かった」って回顧するけど、仮に「運悪く」Aがなかったとしても次善の結果をもたらすBを見つけられた可能性が高いと思ってて、苦境において必要なのは「運」ではなく
— なかめのくまちゃん@質問アプリQuerie.me開発者 (@wgextra) 2021年11月6日
・思わぬ解決策を見出す視野の広さ
・立ち向かう勇気
あたりなんじゃねかと。 pic.twitter.com/RKb6UPS7Qx
自分がラッキーだと感じる
というのも僕自身つい最近、新製品開発において発生した根深いのバグの原因を「運良く」見つけることができたからです。
今回に限らず「運良く」解決策が見つかることは今までもしばしばありました。
いつも「自分はラッキーだなあ」と思っていましたが、こんなにラッキーが頻繁に起こるものでしょうか？
もしかしたらラッキーではなく必然的な結果なのでは？と感じることもありました。
では、困難な場面でいつもラッキーが訪れるのはなぜなのか、
自分なりに解釈してみたいと思います。
最近の事例
ぼくはある機械メーカーの新製品開発プロジェクトで組込ソフトウェア開発の設計リーダーをやっています。
部下は5人います。
バグの調査
ここ最近問題となっていたバグがありました。
マシンにはスキャン（走査）動作をするユニットがついているのですが、10分ほどスキャン動作をしていると急にユニットの動作が不安定になる、というものです。
このバグは致命的な不具合であり、早急に直す必要があります。
まずはぼくが現象の確認をしました（ほかのメンバーたちは別の優先度の高い作業があったので）。
現象を確認したところ、たしかにその不具合が発生します。
また、新たな発見として、スキャン動作を数分間続けてから何かパネル操作をすると同じように不具合の現象が発生することがわかりました。
整理すると以下です。
- スキャン動作中に急に動作が不安定になる
- この現象は何も操作しなくても自然に発生する
- 致命的な不具合である
- スキャン動作中にパネル操作をした場合も同じように動作が不安定になる
バグの解決方法を検討する
このバグはユーザ先での運用評価までに改修する必要がありました。
時間はあまりありません。
そこで対策をAプランとBプランの2通り検討することにしました。
Aプラン
根本の原因をさぐり、恒久対策を行う。
Bプラン
根本の原因はさぐらず、どうすれば現象の発生を抑えられるのか検討することに注力する。
時間があまりないので、Bプランから優先的に着手することにしました。
バグが発生しないマシンが1台あることに気づく
Bプランを部下の一人に着手してもらうことにしました。
そのためにまずはどんな状況でその不具合が発生するのかを、部下にインプットする必要があります。
その中で1台だけバグの現象が発生しないマシンが存在することに気がつきました。
それは古いファームウェアが入っているメカ耐久用のマシンでした。
そのマシンだけはバグの条件を満たしても現象が発生しません。
バグが混入したコミットを見つける
つまり古いファームウェアでは現象が発生しないということです。
どこかのタイミングでバグが紛れ込んだということになります。
なので今度はバグが紛れ込んだのがどのコミットなのかを探ることにしました。
メカ屋さんに頼んで、耐久用のマシンを貸してもらい、調査を実施しました。
その調査は一番若い子に頼んで実施してもらいました。
すると比較的すぐにバグが紛れ込んだファームウェア・バージョンを見つけてくれました。
そこからさらに、そのファームウェア・バージョンで組み込まれたコミットを一つずつ点検してどのコミットが問題なのかを見つけました。
原因となっていた実装は、フラッシュROMにデータを書き込む処理で、それに多くの時間がかかっていたためスキャン動作が不安定となっていたのです。
「いつも運がいいですね」と言われる
このように泥臭い方法ではありますが、やっかいなバグを見つけ出し、解決することに成功しました。
たまたまではありますが、バグが発生しないファームウェア・バージョンのマシンが存在することを発見できたことが大きかったと思います。
正攻法でAプラン（恒久対策）だけをやろうとしたら、おそらく解決までに10倍以上の時間がかかったことでしょう。
ユーザ先での評価までの改修も間に合わなかった可能性が高いと思います。
このことを仲の良い後輩に話したところ、
「普通だったらそんなやっかいなバグは長期化しちゃいますよ。いつも先輩は運がいいですよね。」
と言われました。
確かに運がよかったな、と思いつつも自分が視野を広く保てていたことで解決に至ったなと感じています。
事例の解説
この事例において早期解決することができた要因を挙げたいと思います。
Bプランを用意した
結果的に不要でしたが、短期での解決を目指すためにBプランを用意したのはよかったと思います。
「最悪の場合でもBプランがあるから全体のスケジュールに迷惑をかけることはない」
と思えば気楽に望めます。
それによって視野狭窄になることなく仕事に取り組めたのではないかと思います。
常に気持ちに余裕を持っていることはとても大切ですね。
事前の現象の分析に時間をかけた
バグがどういう条件で発生するのかを入念に調べていたことも良かったと思います。
ろくに下準備をせずにバグ修正を開始していたら、ささいなヒントに気づくことなく迷宮に迷い込んでいたと思います。
バグがどういう条件で発生するのか、しっかり確認していたからこそ、バグが発生しないマシンが存在することを把握できたのだと思います。
古いファームウェア・バージョンで動作するマシンがあった
これは実際のところラッキーだったと思います。
古いファームウェアではバグが発生しないということを簡単に確認できました。
『人月の神話』にも書いてあったことですが、長期にわたり動作していたデバッグ環境というのはいざという時に頼りになる、ということが実感できました。
一台くらいは古いファームウェア・バージョンで動作する環境を残しておいたほうがいいですね。
今回のようにバグ混入のタイミングの確認に使えます。
「運が良い」ために大事なこと
常に情報が集まるようにしておく
とくに今回のようなバグの原因調査という仕事では、ささいな情報が大切になってきます。
日ごろからチーム内や部門間でも情報共有を活発に行っておくべきでしょう。
変化に対して敏感になる
いつもと違うことがないか、毎日気をつけておく必要があります。
何かいつもと違うことがある場合、それを面倒くさがらずに注意しましょう。
もしかしたらその変化はリスクをはらんでいるものかもしれません。
もしかしたら今抱えているトラブルを解決するためのヒントであるかもしれません。
周囲の人たちとの関係をよくしておく
いざという時に他者の助力が必要となります。
自分ひとりでは時間が足りない、技術が足りない、情報が足りないというピンチに陥りかねません。
今回のケースではメカが耐久用のマシンを快く貸してくれたので、原因特定に至ることができました。
ひとつの方法に固執しない
優秀な人ほど、ひとつの方法に固執してしまいがちな気がします。
ぼくのような適当な人間は、いろんな方法を考えてみます。
あまりまっとうな方法でない場合もありますが、とにかく納期が厳しい新製品開発においては納期通りにデリバリーできることが何よりも大切な場合もあります。
臨機応変に、視野を広く保ちましょう。
おわりに
ソフトウェア開発を納期通りに終わらせることができるかどうかは、いかにリスクをつぶしていくかにかかっているといっても過言ではありません。
リスクの種は早めに注意深く観察しておきましょう。
見たくないからといって目をそらしているとどんどんリスクは大きくなっていきます。
情報収集を怠らずに、視野を広く保ちましょう。
解決のカギは思わぬところに転がっているものです。
