はじめに
この記事では
- ソフトウェア設計がなぜ必要なのか??
- 設計スキルをなぜ身につけるのか??
- 技術負債による損失と現代のプログラマーに求められるもの
- 設計スキルの磨き方(自分がやってきた方法をご紹介)
について10年間プログラマーとして、
現場で設計やリファクタリングをする中で、
感じたことや
技術書や勉強会を通じて学んだことをもとに
まとめてみました。
動画にもまとめてたので是非ご覧ください。
現代の変化のスピードと設計の目的
システムは作ってリリースして終わりだったり、
リリースしたら変更がほとんどない。
そんな時代は確かにあったと聞くこともありますが、
今はそうではありません。
競合他社に遅れないように機能追加したり、
顧客の要望も日々変わっていき、
それに対して品質高くスピード感を持って
対応していく必要があるのが現代の開発現場です。
システムは作ってリリースして終わりではなく、
その先の保守開発も非常に重要です。
自分は、
外部の開発組織が作ったプロダクトを、
保守コストがかかるためという理由で、
自社で開発組織を作って内製化する現場の
開発リーダーを任されたことがあります。
そのプロダクトは保守開発のことを考えて作られたわけではなく、
作って納品したら終わりくらいの作りっぱなしのプロダクトでした。
そのため変更に弱く、危険な状態だったのですが、
競合他社に遅れを取らないために次々機能追加が求められ、
顧客の要望も日々変化して仕様変更の対応も急ぎ求められる
状況でした。
まともなテストコードもなく、
同じ業務ロジックが至る所に散らばっていて、
仕様変更が危険で変更の影響範囲が広く、
とはいえ追加機能実装が最優先で求められる。
そんな状況の中、
次々プログラマーを投入して、
その場しのぎでまた同じようなビジネスロジックを作り続けたり、
優秀なプログラマーはモチベーションが下がって
逃げて行ったり。。。
というなかなかカオスな状況でした。
しかし、
これに近いような体験をされた方は意外と多いのではないでしょうか。
では、どうすればこれを回避できたでしょう。。。
僕は、
こういう事態に陥らないために設計が必要です。
設計はリリースのその先を見据えて
機能性、保守性を考慮して行います。
技術負債による経済損失とこれからのプログラマーに求められるもの
2025年以降、
毎年の技術負債による経済的損失は12兆円とも言われています。
技術負債とそれ起因で先ほど紹介した例のような問題が
いたるところで発生していることがこの金額からもわかると思います。
アプリケーション全体を、
保守開発を想定してきちんと設計できて、
技術負債をなんとかできる
プログラマーはまだまだ不足しており、
市場価値も高い印象です。
一方で、
YouTubeや学習サービス、ブログ、技術本などで、
アプリケーションを開発するための、
プログラミング言語やフレームワークの
学習ハードルはかなり下がり、
小学生でもプログラミングが普通にできるような時代です。
さらにAIもサンプルコードなどを作ってくれます。
そのため、プログラムが書けるだけでは、
いくらでも代わりはいるので、
市場価値は今後一気に下がると僕は予想しています。
プログラムが書けるところで終わるのではなく、
安全に素早く保守開発し続ける設計スキルは
現代のプログラマーが生き残っていくために
必須とも言えるスキルだと思います。
設計スキルをどう磨くか??|僕がやってきたことを一部ご紹介
自分が設計スキルを磨くために、
やってきたこととやっていることを少しご紹介します。
現場で携わっているシステムのコードと要件定義書を読んでみる
まずは現場で携わっているシステムのコードを読んでみるのがいいと思います。
どういう仕組みでシステムへの要求を満たしているか??
無駄な記述はないか??
同じような業務ロジックをあちこちに書いていないか??
リファクタリングしていいとなった場合自分ならどうするか??
まずは、技術書や学習サービスでいきなり答えを見るのではなく、
間違っててもいいから、
自分の頭を使って試行錯誤することが重要です。
これを最初にすることで、
この後の技術書などを読む際に、
自分はあーやって考えてリファクタリングしたけど、
こういうテクニックがあるんだ。
といったように自分の体験と照らし合わせることができて、
より自分の身になったり深い理解が得られたりします。
どうしても先に答えを見ると、
他人事になってしまったり自分の体験と比較できず
頭に入らなかったり自分の身になりません。
(僕の場合はですが・・・)
また、可能であれば、
コードだけではなく、
要検定義書のようなものがあれば、
それも合わせて読むことをお勧めします。
要件や要求事項をどのように自分ならシステムに落とし込むか??
このシステムでどういった課題を解決したいのか??
本当にその解決方法は正しいのか??効率がいいのか??
別の解決方法はないのか??
という観点を養うことはプログラマーがこれからの時代を生き抜くために、
非常に大切なことだと最近現場で働いていて感じています。
設計の初級から中級に行くための本を読む
なんでもそうですが設計も基本が大切です。
いきなりリファクタリングやドメイン駆動設計、
マイクロサービスなどの難しめの本を読んでも
設計の基礎や基本的な考え方が身についていなければ、
深い理解が得られたり、使える知識にはならないでしょう。
なのでまずは、
設計を基礎を固める必要があります。
僕が読んできた設計に関する本の中で、
おすすめの本は以下の3冊です。
本を読む際に自分がよくやるのは、
- 現場での体験と照らし合わせながら試行錯誤する
- 現場のコードに学んだテクニックを適用してみる
- SNSで章毎、節毎に自分の理解を自分の言葉で短くまとめて発信してみる
- 個人ブログで自分の理解を図にしたりサンプルコードにしながらまとめてみる
このあたりですが、
自分のようにインプットだけでは頭に入らない人には
オススメです。
他の上級プログラマーの考え方や
伝統的な設計テクニックに触れることで、
自分の引き出しが増えたり、新しい発見や気づきに繋がります。
現場で携わっているシステムのコードをリファクタリングする
可能であれば、
同じ志を持ってリファクタリングをしてくれる仲間を2、3人作って、
開発プロジェクトやプロダクト責任者にリファクタリングの効果を説明して
正式にやれると(泥臭い部分も経験できていろんな意味で)いいのですが、
現場によってはそうもいかないかもしれないので、、、
機能追加や仕様変更時など自分が対応する範囲の中で
手を動かしてみましょう。
恐らく本で読んだ内容の理解が不十分で
何度も読み返したり、
試行錯誤する場面が多々ありますが、
そこが一番理解を深められるポイントだと思います。
また、
小さな改善でも実践できると、
少しずつ自身が持てるようになるので、
そういう意味でもこの活動は重要だと僕は考えています。
学習と実践をひたすら繰り返す
ここからは、
さらに難易度の高い設計に関する技術書を読んだり、
勉強会に参加したり、
興味を持った学習サービスを利用したり・・・
また、
インプットした内容を何かしらの形でアウトプットしたり、
現場で実践したりを繰り返して
設計スキルを磨き続けましょう!!
今回は以上です。
初めてソフトウェア設計をする方に向けて
自分が現場で意識しているポイントなどまとめました。
是非ご覧ください。
初めてソフトウェア設計をする方に向けて|新人プログラマー時代の自分に伝えたいこと