ITエンジニアのための「問題解決」入門

ITエンジニアとって、設計スキルやプログラミングなどのソフトウェア開発作業に直結にする「ハードスキル」だけではなく、問題解決力、思考法、コミュニケーション能力などの「ソフトスキル」も必要とされます。

「ハードスキル」は書籍や研修などで学びさえすれば習得できますが、「ソフトスキル」はなかなかそうはいきません。日々の仕事の中で遭遇する様々な事柄を経験することで、身につけていくしかありません。また、習得すべき「ハードスキル」はテクノロジーの進化とともに変化していきますが、「ソフトスキル」は不変です。

ITエンジニアに必要なスキルと言うと、「ハードスキル」ばかりに目が行きますが、永続的にスキルのコアとなるのが「ソフトスキル」です。

「ソフトスキル」の中でも、「問題解決力」は最も重要なスキルです。問題解決ができなければ、ITプロジェクトも前進しません。

問題解決は、知識体系的に効率化、コスト、納期などのエンジニアリングの分野に属するものではなく、サイエンスの分野に属します。つまり、すでに決まっている目の前の事柄を一心不乱に実行するのではなく、発見、原因特定、対策という手順によって、試行錯誤をしながらわからないものをわかるようにしていくことです。

■　なぜ、こんなに技術的問題が出るのか？

ITプロジェクトは、ITエンジニアの集団です。人が集うところには、問題が発生します。
その理由は、以下のような理想と現実のギャップが起きやすいからです。

・想定外の要望の存在

顧客の要望の聞き取りが不十分だと、ITプロジェクトの途中で、新規要件という新しい要望が突如として出現します。顧客の要望を緻密に聞き取るには、時間と機会が必要です。しかし、十分に時間と機会を得たとしても、顧客の要望を100％聞き取れることは稀で、ある程度は、暗黙的に認識されていかざるを得ません。
問題は、認識齟齬の大きさと範囲です。

・実務の難しさ

ソフトウェアをつくることは、ロジックを考えることでもありますが、考えているだけではなく、実際にロジックをプログラミングして動作させるという”実務”が必要になります。それに付随する開発環境、テスト環境、運用環境などの構築作業も”実務”も必要です。さらに、プロジェクト内外の人とのコミュニケーションなども”実務”です。
これらの実務は、考えているほど容易ではなく、なかなか思い通りに進まず、頓挫してしまうこともあります。

・期待よりITエンジニアの能力が低い

期待したより効率が低かったり、スキルが不足しているITエンジニアが少なからずいると、遅延が発生するだけではなく、時間が経過すればするほど、少しづつ技術的な問題が埋め込まれていきます。

■　技術的問題の種類

ITプロジェクトで発生する具体的な技術的問題の種類を以下の通りです。

１）仕様齟齬
要件が違っている、要件が漏れているという問題です。

残念ながら顧客から要件をまとまった文書の形式でもらえることは稀です。打ち合わせで口頭で伝えられるか、逆に、ITエンジニアが考えて要件をまとめていくことが主流となります。
このような時、大まかでは顧客が考えていることと合っていたとしても、細部までは詰め切れないままで開発が進んでいくことは珍しくありません。

２）設計ミス、漏れ
設計が違っている、そもそも設計されていないという問題です。

ITエンジニアは、要件を解釈しながら、設計をしていきます。誤認識、考慮漏れ、あるいは、要件自体の実装を忘れてしまうことがあります。そんなバカなことがあるかと思われるかもしれませんが、ソフトウェアのロジックは細かすぎるので、このようなことは珍しくありません。

３）バグ
プログラムのロジックが間違っているという問題です。

ITエンジニアは、設計内容をコード化していきます。コンパイルの際、プログラミング言語の文法ミスは「コンパイルエラー」として検出されます。コンパイルエラーがあるとプログラムは生成されませんので、「コンパイルエラー」は取り除かれることになります。その後、テストによって動作を確認すると想定通りの結果にならないと、プログラムにバグがあることがわかります。

■　問題解決の手順

１）問題を発見する
まずは、何はともあれ問題を発見しないといけません。しかし、問題を発見するには、目の前で起こることを観察することが必要です。そして、得たいの知れない「黒い箱」（ブラックボックス）を、問題として見つけ出すのです。

現場で、変な事象に出くわしたとき、以下のいずれかの行動をとります。

　・たまたま何か偶然が重なってめったに起きないことだと思い込む。そして、見過ごす
　・何かあると考える。すぐに、調べ始める

問題を見つけることは、誰だって嫌なものです。しかし、問題を早く見つけることができれば、早く解決できるチャンスが広がります。湧き出る危機意識や焦りなどの感情を抑えて、冷静に、事象を観察し、事実を認識しなければなりません。

例えば、やらないといけない作業が目の前にたくさんある中で、突然、問題が見つかると、時間が奪われる恐怖に襲われます。特に、ITエンジニアが現場で対峙する技術的な問題は、知識やテクニックが必要となり、それらを入手し、実行するための時間が正確に見積もることができません。
そのような中で、落ち着いてデータを集め、事実から「問題」であると潔く判断しなければなりません。

問題を早く見つけることが、その後の問題解決の運命を決めることになります。しかし、問題を発見するだけで、そのまま放置されてしまうことも少なくありません。放置された問題が積み重なり、やがてプロジェクトが頓挫してしまうこともあり得ます。

よく聞かれるのは、忙しい現場の中で、どうやったら「何か変だ」と思えるのかという質問です。
それは、考えの軸を逆転させることにあります。

日ごろから問題が起きない前提で仕事をしていないでしょうか。
ITプロジェクトは、常に問題が起こるということを念頭に仕事をしなければなりません。
ネガティブ思考や悲観的に考えろということではなく、とにかく楽観的に考えることを止めることが、結局、身のためです。

２）原因を明確にする
問題には「原因」があります。原因を明確にしない限り、完全には解決することはできません。
原因を明確にしないままで、発生頻度を下げたり、あるいは、特定の条件では問題の発生を止めることができる場合もあります。しかし、いずれ問題が再現することになります。

原因を明確にするには、問題に関連する様々なデータから正しいデータを選別することが必要です。
そのためには、問題の中に入り込むことが必要です。
「黒い箱」（ブラックボックス）の蓋を開け、手を突っ込み、中に何があるかを探っていきます。この作業が「デバック」です。

デバックには、ソフトウェアの中の動作と状態がよく見えるようにする道具が必要です。それが、デバッカとロギングです。

デバッカは、プログラムの実行を手動で制御できるソフトウェアです。通常、MicroSoftのVisualStudioのように、統合開発環境（IDE）として、エディタ・コンパイラ・リンカとデバッカが一体化されています。
単純なバグであれば、デバッカで事象が発生した機能のソースコードさえ追っていけば、原因を特定することができ、それらのほとんどはプログラミングの段階で取り除かれます。

残ったバグは、常に発生するわけではなく、プログラムが動作しているときに、ある特定の条件・タイミングでしか発生しないものです。そこで、まず原因の箇所を特定するために、ロギングを使います。

ロギングとは、ソースコード内で、実行した関数名、結果、その時の変数の値などを出力することです。
ロギングの方法には以下の主に３種類があります。

　①エラーログ
　呼び出した関数の結果がエラーの時にのみ、結果（エラー番号）、 その時の変数の値やメッセージを出力する

　②通信ログ
　ネットワーク、シリアル、USBなどを経由して送受信される電文を出力する

　③トレースログ
　すべての呼び出した関数と結果を時系列に出力する

最低限、エラーログは必要であり、通信ログやトレースログは、問題が発生したときにだけ出力できる機能を実装しておきます。
これらのログを見ることで、動作している間に何が起きていたのか把握し、原因となる箇所を絞り込みます。そして、その箇所をデバッカで追うことで、原因を特定します。

バグの原因は、上記によって特定できますが、
仕様齟齬、設計ミスや漏れは、ソースコードのロジックは想定している通りであり、デバッカやロギングでは見つけることができません。したがって、アナログな手段に頼るしかありません。ITエンジニアに対するヒアリング、仕様書や設計書などの元となった資料（質疑、メール、議事録など）の調査によって、仕様や設計に関する「考え方」の矛盾を明らかにしていきます。本来、これらは、第三者による「レビュー」によって防ぐしかありません。

３）解決策案を考える

仕様齟齬、設計ミス・漏れ、バグの解決策は、いずれもソフトウェアの修正ですが、その範囲が異なります。原則、仕様齟齬→設計ミス・漏れ→バグの順で修正範囲が小さくなります。修正は、修正範囲に隣接する箇所にも、修正の影響が及び、修正範囲の大きいほど品質確認にも時間がかかることになってしまいます。

そのため、修正方法を吟味し、できる限り修正量が少なく、影響範囲を狭められるように検討します。たとえば、既存の関数を修正せずに、あえて類似の関数を新たに作ったりします。

４）解決策を選択し、実施・評価する
解決策の方針が決まれば、実際に修正を実施していきます。
修正後の評価は、修正箇所と隣接箇所のテストに加えて、回帰試験と言ってソフトウェア全体に影響がないことをざっと確認する必要があります。さらに、エージングと呼ばれる連続試験を実施することによって、修正に問題がないことを担保する必要があります。

■　まとめ「問題を小さく解決するために」

問題を適切な時期に発見するために、工程があります。いわば問題解決の旬です。
仕様齟齬は、要求定義工程～設計工程にかけて発見され解決すべきものです。設計ミス・漏れは、設計工程～プログラミング工程～結合テストにかけて発見され、解決すべきものです。

本来、ITプロジェクトは、問題解決をエンジンとして回していくもので、問題解決スキルの高いITエンジニアが集まっていれば、計画通りに進んでいきます。
しかし、管理手動でプロジェクトマネジメントだけを重要視するようなITプロジェクトでは、工程の役割が形骸化し、問題が放置され、隠蔽化されてしまいます。

問題を把握するには、ログを見るなど、現場の状況を観察し続けなければなりません。
しかし、残念ながら、ログさえ見れないITエンジニアがプロジェクトにはたくさんいます。

見ない、探さない、言わない、そして自責ではなく他責であるとの思い込みが招く先にあるのは、ITプロジェクトの死です。