設計を学ぶ意味と設計スキルの磨き方について考える

はじめに

この記事では以下について、

9年間現場で設計やリファクタリングをしたり、

技術書で学んだことなどをもとにまとめてみました。

• 現代の開発現場と設計の目的
• 技術負債による損失と現代のプログラマーに求められるもの
• 設計スキルの磨き方(自分やり方紹介)

現代の変化のスピードと設計の目的

システムは作ってリリースして終わりだったり、

リリースしたら変更がほとんどない。

そんな時代は確かにあったと聞くこともありますが、

今はそうではありません。

競合他社に遅れを取らないように機能追加したり、

顧客の要望も日々変わっていき、

それに対して品質高くスピード感を持って

対応していく必要があるのが現代の開発現場です。

システムは作ってリリースして終わりではなく、

その先の保守開発も非常に重要です。

自分は、

外部の開発組織が作ったプロダクトを、

保守コストがかかるためという理由で、

自社で開発組織を作って保守開発を始める。

といった現場の開発リーダーを任されたことがあります。

そのプロダクトは保守開発のことを考えて作られたわけではなく、

作って納品したら終わりくらいの作りっぱなしのプロダクトでした。

競合他社に遅れを取らないために次々機能追加が求められ、

顧客の要望も日々変化して仕様変更の対応も急ぎ求められる

状況になりました。

まともなテストコード、設計書などはなく、

同じ業務ロジックが至る所に散らばっていて、

仕様変更が危険で影響範囲が広く、

とはいえ追加機能実装が最優先で求められる。

そんな状況の中、

次々プログラマーを投入して、

その場しのぎでまた同じようなビジネスロジックを作り続けたり、

優秀なプログラマーはモチベーションが下がって

逃げて行ったり。。。

というなかなかカオスな状況でした。

しかし、

これに近いような体験をされた方は意外と多いのではないでしょうか。

では、どうすればこれを回避できたでしょう。。。

僕は、

こういう事態に陥らないために設計があるのだと思います。

設計はリリースのその先を見据えて行うのです。

技術負債による経済損失とこれからのプログラマーに求められるもの

2025年以降、

毎年の技術負債による経済的損失は12兆円とも言われています。

技術負債とそれ起因で先ほどの例のような問題が

いたるところで発生していることがこの金額からもわかると思います。

一方で、

アプリケーション全体を、

保守開発を想定してきちんと設計できる

プログラマーやエンジニアはまだまだ不足しているのかなと思っています。

最近では、

YouTubeや学習サービス、ブログ、技術本などで、

アプリケーションを開発するための、

プログラミング言語やフレームワークの

学習ハードルはかなり下がったと思います。

自分自身、

JavaやSpringが使えるプログラマーはいくらでも現場で見かけますが、

変更が安全になるように、

保守のことを考えてきちんと設計ができる人はそこまで見かけません。

ただ、

現代は変化のスピードへの対応がシステム開発には求められます。

アプリケーションアーキテクトと呼ばれるような人たちだけが、

システムに求められる要求を分析して、

変更を安全になるように保守開発を見据えた設計ができればいいのでしょうか。

もしかしたら、

今後はプログラムが書けることだけでは市場価値が低いとみなされるかもしれませんし、

プログラマーに求められる必須スキルになっていくかもしれません。

少なくとも、

設計ができるかどうかの差が、そのまま市場価値の差となるでしょう。

プログラムが書けるところで終わるのではなく、

安全に素早く保守開発し続ける設計スキルは

現代の開発現場においてかなり重要なスキルになると僕は考えています。

設計スキルをどう磨くのか(自分のやり方紹介)

自分が設計スキルをどのように磨いているかを紹介します。

現場で携わっているシステムのコードをひたすら読み込む

まずは現場で携わっているシステムのコードを読んでみるのがいいと思います。

どういう仕組みでシステムへの要求を満たしているか？？

無駄な記述はないか？？

同じような業務ロジックをあちこちに書いていないか？？

リファクタリングしていいとなった場合自分ならどうするか？？

まずは、技術書や学習サービスでいきなり答えを見るのではなく、

間違っててもいいから、

自分の頭を使って自分事として捉えるのが重要だと僕は考えます。

これを最初にすることで、

この後の技術書などを読む際に、

自分の体験と照らし合わせることができて、

自分はあーやって考えてリファクタリングしたけど、

こういうテクニックがあるんだ。

みたいな読み方や学習サービスで学習できるので、

より自分の身になります。

どうしても先に答えを見ると、

他人事になってしまったり自分の体験と比較できず

頭に入らなかったり自分の身になりません。(僕の場合はですが)

設計の初級から中級の架け橋になる本を読む

僕が2023年2月現在でオススメするのはこれらの本です。

ここでは、

自分が現場で体験したり試行錯誤したことと

比較しながら、可能であればSNSや個人ブログなどで、

自分の理解を自分の言葉でアウトプットしながら

技術書を読んだり、学習サービスで学習するのがいいです。

他の上級プログラマーの考えに触れることで、

自分の引き出しが増えたり、新しい発見や気づきに繋がります。

現場で携わっているシステムのコードをリファクタリングする

次は実践です。

現場によっては実践が却下されるかもしれないですが、、、

その場合はブランチ切ってやればいいかと。

恐らく本で読んだ内容はこのステップで何度も読み返したり、

理解不足で試行錯誤することになるかと思います。

インプットしただけでは意外と自分の身になりきっていないことが多いです。

インプットした内容を自分の身にするだけでなく、

ここで実践しておくことで、

自身が持てるようになると思います。

恐らく、今の携わっているシステムの設計を見直すというと、

いろんな反発をされて不安になったりします。

でも実践経験があるとそれを跳ね返せると自分は考えています。

学習と実践をひたすら繰り返す

ここからは、

さらに難易度の高い設計に関する技術書を読んだり、

勉強会に参加したり、

興味を持った学習サービスを利用したり・・・

そしてインプットした内容を、

ひたすら個人ブログやSNSで自分の言葉でアウトプットしたり、

現場で実践したり取り入れたりを繰り返すことで、

上を目指し続けるだけです。