ソフトウェアの設計とは
設計テクノロジにフォーカスした年表です。 時代を5つに分類してみました。 １．アセンブリ時代 ２．ファームウェア時代 ３．モジュール化時代 ４．リファクタリング時代 ５．アーキテクティング時代
ソフトウェアの規模とエンジニア個人についての所感を書いてみます。
ソフトウェアの規模は、アセンブリ時代／ファームウェア時代は、一人で全体を把握できる規模でした。職人技の時代です。 その後、機器の機能が増えるに伴いモジュール化時代に推移していきました。 実装に近い設計技法が出現して、構造化手法やオブジェクト指向に取り組む動きが出てきました。 モジュール化することで、ある程度大きな規模でも、きちんと動くコードが作られました。 その後、その動くコードを改修するリファクタリング時代に入りました。 動くコードがあるため、それを部分的に修正していくという開発が横行し、コードが徐々に在庫化してしまいました。 リファクタリング時代で、実装改善や設計改善は、あまり行われなかったことが、さらに状況を悪化させています。 プロセス改善活動で品質の維持ができていますが、ソフトウェア設計の失われた15年、という印象です。 さすがに部分最適の積み上げでは、不具合のモグラたたきや開発期間の超過が目立つようになり、アーキテクティング時代に突入しつつあります。 アーキテクティング時代は、モジュール作成よりもモジュール利用に重心が移り、モジュール間のデータを定義・分析・活用して、新たな価値を生み出す時代です。 2022年現在で、部署内にソフトウェアアーキテクトが存在している組織は少ない状況です。 技術リーダーとして、ビジネスとテクノロジを繋ぎ、アーキテクチャドキュメントを使ってリーダーシップを発揮する人材の育成が鍵です。
■ソフトウェアの規模 規模１：全体が把握できる（と思ってしまう）規模 →べた書き実装でも動くコードはできる（が、徐々に肥大化） 規模２：自分の知らない部分がある規模 →きちんと設計しなければ動かない（が、全体は見渡せない） 規模３：全く異なる専門分野と繋がる規模 →問題ドメインの概念モデルが必要（だが、誰もそれを作ることができない）
規模１は、予め、システム全体が、開発しやすい単位に分割している場合です。 ・画面分割されていたり ・ハードウェア的に分割されていたり（バスでつながるアーキテクチャ） ・ソフトウェア的にコンポーネント分割されている（アーキテクチャ設計されている） その場合、動く部分から実装しても、それなりに動くプログラムができるのでしょう。 しかし、数か月後（あるいは数週間後）に見ると、作った本人も分からないコード、になってしまいます。 そして、その内部に断片的にコードを追加していくと、（以下略） そもそも設計していないから、仕方がないです。
●PCの画面系ソフトウェアの仮想ストーリ ・画面べったりでも動くものはできる ・不具合が出ないよう過剰な防衛的プログラミングをしてしまう ・その結果、意図の分からないif文が増える（冗長なif文） ・冗長なif文で不具合が起きて、そこを修正してしまう（ごみコード） その結果、 ・作った人もコードを追いかけないと動きが分からない ・コードでしか、何をしているか説明できない（意味のあるコードは、埋もれてしまう） ・コードを見るのが嫌になるのでモチベーション低下 そのコードを受け取った人は ・打つ手なし ・プロジェクトから抜け出す方策を練る
規模2は、きちんと設計しないと動かない規模です。 特に、広範囲に関わる状態やモードの設計が必要となります。 ・組込みシステム開発 ・PC上のシミュレータ開発 が相当します。 構造化手法やオブジェクト指向という技法も有効で、開発当初はそれなりの設計がなされているケースが多いです。 しかし、機能追加や不具合対応で、アドホックなフラグが増えていくと、複雑怪奇さを増してしまいます。 再現性の低い不具合が出るようになり、現象に対処するだけだと状況はますます悪化していきます。 現象→原因→（方針）→対策→対処を回し、設計のシンプルさを保つことが求められます。
規模3は、ソフトウェアを資産として活用し、さらなる進化（デジタルツインやシステムオブシステムズ）に対応することになります。 実装に近い設計技法だけでは充分ではなく、アーキテクトが全体を俯瞰して、ビジネスの変化に柔軟に対応できるアーキテクチャが不可欠になっています。 全体を俯瞰するコンポーネント構造図を作成しコミュニケーション道具として、ビジネスゴールの変化にも柔軟な対応が求められます。
規模が大きくなるにつれて、ソフトウェアエンジニアに求められる技術も ■エンジニア個人の業界参入時期 ●アセンブリ時代／ファームウェア時代から、ソフトウェア開発に従事している方。 アセンブラ言語→C言語→UMLという流れを体験している方です。 しかし、アセンブラ的C言語を書いたり、抽象化されていないクラスを作ったり、してしまうこともあり、 自分の思考とテクノロジの選択にギャップがあることがあります。 設計の思考に合うテクノロジの選択を推奨します。
●モジュール化時代からソフトウェア開発に従事している方 構造化手法やオブジェクト指向という、いわゆる設計の方法論の取り組みをされた方も多いのではないかと思います。 しかし、そのような方法論は、継続して活用していかないとうまく回りません。うまくいかなかったから、その方法論は使えない、という負の体験になってしまった方も多いのではないかと。 設計図とコードを同期させる開発を推奨します。
●リファクタリング時代からソフトウェア開発に従事している方 「動くコード」があるので、それが「是」という思考になってしまっている方も多いのではないかと。 実装改善や設計改善したくても、動いているのだから、既存部分は変更しないように、という暗黙の了解のある組織も多いようです。 コードを局所的に変更して、その影響範囲を検索で確かめる、という業務では、品質や生産性も向上しないし、何より、エンジニア本人のスキルも上がりません。 コード中心から設計中心への思考の転換を推奨します。 |
