作れないものは、設計できないという話

はじめに

※ この記事は、僕個人の経験に基づく話しのため、その他の人の考えや経験について言及するものではありません。ご理解いただけると幸いです。

ソフトウェアを作るときには、「設計」という工程があります。これはソフトウェアに限らず、ハードウェアでもその他製造でも必ず存在する工程と言っても良いかもしれません。今日は「ソフトウェア開発をするときの設計書」について、書きたいと思います。

設計書をいつから書き始めた?

ソフトウェアの開発では、工程によって「設計書」というものを書くことがあります。設計書の内容は工程によって異なりますが、大規模システムなどものによっては数百ページの設計書を書くこともあるかもしれません。(この規模は未経験なので僕の想像ですが。。)

皆さんはエンジニアとして働き始める時、この「設計書」を初めて書いたのはいつか覚えていますか？僕は新卒1年目で、初めて設計書というものを書きました。

僕が新卒で入社した会社は、いわゆるSierという事業形態に近いもので、案件によっては、請負契約で、要件定義 > 基本設計 > 詳細設計 > 製造 > テスト >納品までを一貫してやっており、各工程の納品で設計書を納品していました。

記憶はおぼろげですが、僕が初めて入ったお客様の案件で、基本設計書と詳細設計書を書いたのですが、この時僕は率直に「何書いたらいいのか全然わからね〜」と思いました。1から10まで自分がやっていることがよくわからず、とりあえず想像で書いて、先輩にレビュー何度もしてもらい修正しながらなんとか納品したことは覚えています。

そしていざ製造工程(プログラミング)に入ると、設計書はほぼ見ずにプログラムを書いていました。この時に「この設計書って何か意味あるのかな？」と思っていたことは今でもはっきり覚えています。(この時僕のプログラムスキルは新卒の研修上がりでよちよちプログラマーくらいです)

その後もとりあえず、書くことができない不安から設計書の書き方についての参考書を結構読んだりしました。ですが、振り返ると結局転職するまで上手く書くことはできなかったように思います。

設計を覚えた時期

そんなこんなで1社目では、設計書の意味??状態で3年ほど働いた後、Web系の比較的小規模な会社へ転職します。

ここでは、自社サービスチームのエンジニアとして配属されました。初めての自社サービス運用で色々と新鮮でしたが、最も新鮮だったのはそのチームでは「設計書」と呼ばれるものはほとんどありませんでした。

誤解を生まないために補足しておくと、サーバとのIF仕様書や必要最低限のシーケンス図などは合った気がします。それ以外は、その時のチームメンバーいわく「仕様はコードを読めばわかる。コードから読み取れ。」(みたいなニュアンス笑)だった気がします。

『おお。これがWeb系ベンチャーか。』と肌身で感じながら3年半、開発や保守・運用業務に明け暮れました。この間、前職のようにエクセルで数十ページに渡る設計書を書くことは一度もありませんでしたが、機能開発を行う時には、画面設計、データ設計、IF設計等、最低限の設計はしていました。(設計書を書いたかと言われると微妙ですが、マークダウン等でgithubのwikiに貼り付けたりはしてました。)

前職では、実装するときにほとんど設計書を見ていなかったと書きましたが、新しい職場では普通にみてました。むしろ機能を作るためには、周辺の影響機能のコードを読み、サーバー担当と必要データについてすり合わせ、デザイナーとUIについて検討し、それを共通認識のためにアウトプットをすることが作るために必要でした。

僕は、ここではじめて「作るために必要だから設計をするのか」とめちゃくちゃ当たり前のことを学んだのです。つまりようやく設計することを覚えたとも言えます。

また、チームでの年次が上がるにつれて、自分の作ったことのある機能や読んだことのあるコードについては精度の高い設計ができるが、作ったことのない機能の設計については、いくら事前調査をしても精度が下がることも学びました。

もう一度、設計書を書いてみる

その後、フリーランスになり、縁あってか設計書を納品するようなお仕事をもう一度手伝うことがありました。

1社目を辞めてから3,4年の間、設計はしていたとはいえお客様に納品するような設計書というものは書いたことがなく、若干の不安もありました。

要件定義から入って基本設計の工程で設計書を書き始めたのですが、なんとも不思議な話で、案外すんなりスラスラと書けました。レビューでも対した指摘もなかったため、少なくともその案件でのクオリティは問題ないものだったのだと思っています。その後、詳細設計書も書きましたが、そちらも特に問題ありませんでした。

製造フェーズに入ってからは、普通に設計書を見てプログラミングしました。事前に意味のあることを設計しているので当然ですが、設計書がある方が実装が捗ったと思います。

分かったこと

新卒の時は、設計書がいつまでも書くことができず不安でした。しかし、これはそもそも「ソフトウェアをどうやって作ればいいのかわからなかった」からです。自分自身に作る力がついてからようやくそれに気づき、「自分が作れないものは、設計できない」だなという当たり前のことに気付いたという話でした。

設計とは作るために必要なプロセスや要素を明文化したものであり、どういうものをどうやって作るのかが想像できなければ、書くことは難しいです。もちろん「作ったことはないけれど設計は出来る」という人はいるかもしれませんが、精度は下がると思います。

設計書を書けないと思っている人へ

プログラミングを習いたての人で「設計書の書き方がわからない」とか新卒で入ったチームで「設計書が書けなくて怒られる」といった経験をしている人がもしいたら『作ることを続けていれば、そのうち書けるようになるよ』ということをまず伝えたいです。

それでも早く設計書を早く書けるようになりたいと思っている人へ僕なりのアドバイスをするとしたら「ともかく多くのものを作ること」かなと思います。

設計書の書き方をいくら学んだところで、きれいなグラフが書けるようになるだけで意味のある設計には直結しないと思います。それよりもともかく自分のスキルの幅を広くするようにものを作っていくと自然に設計書も書けるようになると思います。

以上、読んでいただきありがとうございました。