>>ここをクリックしてお気軽にお問い合わせください!<<

デバッグの妙

私は今、あるプロジェクトの課題対策を行っております。課題ってのは「思う通りにプログラムが動かないんだけど、どーにかせい!」と言う不具合の事を主に指したりしている訳です。

今のプロジェクトはパッケージを使って開発をしております。パッケージってのはある程度システムが出来ていて、それに手を加える形で完成させるような感じです。ある程度出来ているので、一から作るより、短期間、安価で出来たりするメリットがあります。

ただし、不具合が起こると、パッケージの中身を調査しなくてはいけなくなるのです。まったく知らない、訳のわからないプログラムの調査をしなくてはいけないのです。

僕の部署はあるメーカのパッケージを主に扱う部署ですが、プログラムが出来る人がプロパーではあんまり居なかったりします。「だって、俺プログラム読めないから。」そんな事を言うSEが平気でいたりするのです。

「お前はプログラム読めるから凄いよな。」なんて言われることもありますが、僕は嬉しくもなんともありません。「読めて当たり前」なのです。だって仮にもシステムエンジニアを名乗っているのだから。

Image 1

って事で2ヶ月位、簡単なものから難しいものまで切り分けをきちんと行ってちまちま潰していった訳です。しかし、それでも、しつこい問題が出てきました。どーしてもわからん。とみんなが言っている物です。

雇っているプログラマーも「ムズカシイデス。」(中国の人)と言ったりしてるし、パッケージ開発元に問い合わせても、「難しいので、時間がかかるかもしれません。」と平気で言ったりします。

元々、パッケージの不具合なので、そこまでの責任は我々にはないはずなのですが、プロジェクトの進め方の初動(僕が入る前)がことごとく失敗しており、顧客からの信用を失った所だったのです。

そんな折、ちょうど不具合が発生している部分を担当しているパッケージ会社のコンサルタントを1日だけ呼ぶことに成功した訳です。彼らは外資系なので、平謝りしたりはしません。「あぁ、不具合ですね。」と言う位です。お前の会社の不具合だろー!と言いたい気分になったりします。

でも、この日来たコンサルタントは凄かったです。日本にその分野の担当が1名しかいないスペシャリスト。業界的に絶対に無くならない業界ですし、物すごい給料を貰って食いっぱぐれがないうらやましい人です。

しかし、彼は「不具合ですね。ではデバッグしましょうか。」と言い始めると、黙々とプログラムを見始めました。僕は横にいて一緒に見ながら、「あ、ここでリターンコード変わりました!」とか、「別環境で同じ場所をデバッグして切り分けしませんか?」とかサポートです。

実に11時間。プログラムを追いかけ続け、無事不具合の切り分けを行うことが出来ました。数十万ステップと呼ばれるプログラムを読んだのです。

ここからは、お仕事でプログラムをやっている人への問いかけです。

他人が作ったプログラムで仕様書がない場合、どのようにデバッグするのが正しいのでしょうか?

・ある程度のあたりをつけ、その周りから見ていく。

・上から地道に見ていく。

前者は天才系、後者は努力系のプログラマーに多いですね。僕も一人で見ていた時は、ある程度のあたりをつけてそこから上に上に・・・と読んでいたのですが、キリがなくなり挫折してしまいました。

今日のコンサルタントは違いました。上から、飛ばし、飛ばし読んでいくのです。「これは関係ない、スキップ」、「これも違うなぁ、スキップ」と進めていって「あれ?おかしくなった。」と言った点を見つけ、その前にスキップした所からチェックしていきます。

関係ないと思う所を徹底的にスキップしながら上から読んでいき、おかしくなったら、どこでおかしくなったのか、またスキップしながら見ていく。これは効率的です。

「このボタンを押したらエラーになります。」なんてのは超簡単ですが、たとえば原価計算みたいに、一回流したら画面とか何もなく、最後に「終りました!」なんて出てくるパターン、これが大変なんです。

僕は、前にも書きましたが、コンサルタントではありません。強いて言えば、「コンサルもできるSE。」です。SEと呼べる人は基本的にプログラムのロジック(進め方、構造)がわかっている必要があると思っています。

今日、久々にプロの仕事を見ながら今一度、「プロとして対価を貰う事。」の大事さをしりました。

まぁ、今日来たのが、外資系コンサルなので、一日(と言うか、時給換算)で莫大なお金を請求されると言うオチはあるのですけれどね。

では。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です