「できるか！」な設計書に、どう立ち向かう？：システム開発プロジェクトの現場から（7）（1/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

　プログラムをやっていて、腹の立つことってどんなことがありますか？

　今回は設計と設計書、特にコーディングするためのインプットとなるいわゆる詳細設計書について、私が感じたこと・思っていること・学んだことをお話ししようと思います。

初めてのクライアント／サーバ型システム

　社会人2年目か3年目のころのことです。当時、在籍していた会社では、プロジェクトの多くはホスト型でした。そんな中で私は、はやりの言葉だった「クライアント／サーバ型」システムの開発プロジェクトに配属となりました。

　そのプロジェクトは、会社が始まって以来初めて、基幹系システムをクライアント／サーバ型で構築するというものでした。もともとホスト系の会社でしたので、リレーショナルデータベースに精通した技術者はいません。というよりむしろ、経験者自体が存在しない、そんな中でスタートしたプロジェクトでした。

　そこでの私の役割は、「プログラマ兼技術調査係」という、なんともイヤな予感のするものでした。

プログラミングで、プライドを捨てた瞬間

　まぁ予想どおり、このプロジェクトではいろいろなことがありました。中でも特に奇怪だった現象が、あるバッチ系プログラムが、数十件処理するとなぜか落ちるというもの。最初はまったくわけが分かりませんでした。しかしいろいろと調べた結果、50件くらいまでの処理には耐えられること、その段階で一度プログラムからデータベースとのセッションを切って接続し直せば大丈夫なことが分かりました。

　悩み抜いた揚げ句、「処理50回ごとにデータベースとのセッションの切断・接続を繰り返す」というカルトなプログラムにすることに決めました。正直、ITエンジニアとしてのプライドを捨てた瞬間でした。

　結果、なんとシステムは安定稼働を始めました。

　この決断が正しかったのかどうか、いまでもよく分かりませんが（というかおそらく技術的には正しくありませんが）、ユーザー側の視点からは正しいことをしたと確信できました。私はこのとき、理屈ではなく、とにかく解決しなければならないこともあることを学んだのです（これも正しいかどうかは分かりませんが、共感してくれる人がいれば非常にうれしいです）。

　そんな不確定要素が満載だったからなのか、このプロジェクトが終わるころには、私は設計書に対して不満を抱くようになっていました。……というか、常に仕様書を疑いながらコーディングをするようになってしまっていました。

　社会人1年目ではコーディングすることだけで精いっぱいでしたが、このころになるとそれなりにコーディングもできるようになり、「結構できるんじゃない？」なんて勘違いをし始めていました。これも理由の1つだったかもしれません。

　余談ですが、ITエンジニアというのは経験年数が増えていくにつれ、そして技術力がついていくにつれ、生意気になっていくのかなぁと思います……。あまり悪い意味ではなく、いろいろと意見を述べることができるようになってくるという意味です。

設計者に確認に行ったら、その場で仕様変更……

　さて、当時の私が設計・設計書に対して不満を抱いたのは、だいたい以下のようなときでした。

1. 設計書の記述内容がおかしく、設計者に確認に行ったら、その場で仕様が変わってしまった
2. 設計書の記述内容があいまいで、設計者に確認に行ったら、まだ仕様が決まっておらずペンディングになってしまった
3. 設計書の記述内容があいまいで、設計者に確認に行ったら、逆に自分が設計することになってしまった
4. 設計書を読んでも何をしたいのかよく分からなかった
5. 複雑怪奇としかいいようのない設計書を見てしまった
6. 「そんなことできません！」と突っ込みたくなるほどアクロバティックな設計を見つけてしまった

　やっぱり、不満を抱きながら仕事をするのは、楽しいことではありません。

　当時の私にできたのは、それでも前向きに仕事をするよう努力することくらいでした。しかしこの経験は、自分が実際に設計するようになったとき、「どうすれば意図をきちんと伝えられるのか」を考えるきっかけとなりました。どうせなら不満を発生させる要素は取り除き、楽しく仕事をしたいですよね。