自動生成すりゃいいじゃん

「自動生成」という言葉を聞くだけで,過剰反応する開発者がとても多い。反対する人のほとんどは,「自動生成の有効性が明確ではない」という理由である。なぜそう考えてしまうのか,ちょっと考えてみた。 ソフトウェア開発は,設計から実装,つまり設計書からソースコードへの変換作業であることは,改めて言うまでもないことだ。ただし,多くの現場で,それは成り立たない。設計書が正しく記述され,メンテナンスが継続的に行われることは少なく,納品時に残っているものは実装だけ,なんて状況も少なくない。 この状況が発生するのはプロジェクト管理に原因があることがほとんどなのだが,設計書と実装の関係をなるべく近づけようという努力をすることを考えなかった結果であるとも言えるだろう。ただ単に顧客の業務をだらだらと文書化しただけでは,それは業務分析とは言えない。最終的な目標が「ソフトウェア開発」なのだから,ソフトウェアを開発することができる文書化を行わなければならない。つまり,顧客の業務をソフトウェアアーキテクチャで語ること,すなわち,ソフトウェア開発の都合で導き出された整理方法で業務を分解することが重要なのだ。この話は,「 第1段階のEoDのコツとは」のエントリに書いた。 ソフトウェア開発都合,言い換えると,ソフトウェアアーキテクチャ都合で分類された設計は,その内容を記述した設計書が実装の単位と一致する。内部設計もしくは詳細設計の工程であれば,各設計書には実装で採用する基盤のソフトウェアに特化した記述も含まれてくるはずだ。例えばStrutsを使っているのであれば,Webブラウザ上で発生するイベントを受け取るために,アクションの定義(パス,使用するフォーム,アクションの処理結果に対するforward先など)が記述されるだろう。そして,アーキテクチャにより規定されたモジュールごとに,その責務が仕様として文書化される。 これが,本来の詳細設計だと思う。業務の内容をただ単にダラダラ書いただけのものは,それも必要だけど,それを書いただけで設計を完了としてはいけないのだ。ダラダラ書いたものを,ソフトウェアアーキテクチャの規約に沿って分解して行かなければならない。なぜなら,ソフトウェアを開発することがゴールだからだ。 上記の設計手法が正しく遂行されれば,昔で言う関数定義書レベルにまで仕様が細分化されていることになる。設計書はソフトウェアモジュールと直結しているわけだから,がんばって書いたものから2次副産物を作りたくなるはずだ。そこで,自動生成が出てくる。せっかく書いたんだから,躊躇なくその内容を機械的に利用すればいいのだ。 設計書が実装と直結されたことで,作業の工程として,機能を追加して行く際には,実装を直接行うことはできず(自動生成でさっくり消される),必ず設計書の執筆,つまり設計が強制されることになる。これを継続的に行うことにより,終わってみたら実装だけだった,なんて状況にならないはずなのだ。保守の段階になって,設計書がいっさい残ってなくて,ソースコードをひーひー言いながら追った経験は誰でも持っていると思う。そんな状況を最初から起こさないような仕掛けが,上記のような開発方式なのだ。 ・・・というような難しいことを言うことも,本音としては必要ないと思っている。使えるものは使う,利用できるものは利用する。ただそれだけである。 しかし,自動生成を真っ向から拒否する人は,以下のようなデメリットを主張する。

  • 自動生成されたコードを変更することができないと,いざ不具合が出たときに対処できない。

  • 設計書を継続的に変更していくことなど無理だ。

  • 実装に関する細かな内容を設計書に記述するのは無駄だ。それはコーディング時に決めていけばよい。

  • 自動生成のツール作成の工数なんてかけてられない。 一つ目の「自動生成されたコードを変更することができないと,いざ不具合が出たときに対処できない。」については,そもそも自動生成を「枠」と「XMLなどの設定ファイル」のみにとどめるので,不具合が発生する原因となる「プログラムコードのミス」は自動生成とは関係のない話である。枠の構成やXMLなどの設定ファイルを直接修正したいと考えることは,プロジェクトで定めた規約に違反したことを行おうとしていることを意味する。そんなことは仕事としてのソフトウェア開発では原則許されない。 二つ目の「設計書を継続的に変更していくことなど無理だ。」という人は,いざ保守する段階になって「設計書も残ってないのかよ」と発言する傾向がある。顧客がプログラムコードをレビューできるのならそれでもよいが,そんなことはなく普通は自然言語しかわかならいため,設計書を継続的に変更することは当然の責務である。 三つ目の「実装に関する細かな内容を設計書に記述するのは無駄だ。」という人は,きっと設計者ではなく,業務コンサルタントになればよい。実装に必要な詳細な設計内容の文書化を放棄した時点で,それは仕事ではない。日曜大工程度のおもちゃ作りである。一人で把握できる規模のソフトウェア開発程度の技量しかない人の発言だ。 最後の「自動生成のツール作成の工数なんてかけてられない。」という発言をする人は,目先のコストしか見えていない(=洞察力が低い)のではないか。設計と実装を近づける手段としての自動生成が最も威力を発揮するのは,保守の段階である。多くのプロジェクトがリリース後の顧客からの機能変更要求や瑕疵対応に多くのコストをかけている現状において,設計→実装の手順が貫かれた成果物ほど心強いものはない。後々のソフトウェアに対する変更コストに比べたら,自動生成ツールの作成工数など小さいものである。現在ではEclipseなどの開発ツールが相当な勢いで進化を遂げたため,ツールの作成の敷居は従来に比べて非常に低く抑えられる。 自動生成の効能は,俗にいうXML地獄を解消してくれることもあげられる。Seasarのように,定義ファイル自体を削減するアプローチも正しいと思う。しかし,だからといって設計が削減されるかというとそんなことはなく,詳細な設計は必要だ。その上で,その成果を積極的に使っていけば,(言い方が古いけど)開発プロセスの標準化が効果を発揮する結果が出るはずだ。 使えるものは使う,利用できるものは利用する。自動生成すりゃいいじゃん。 自動生成を批判する人は,DIの適用に関しても間違った理解をしていることが多いように最近感じている。結局のところ,「最後はソースコードしか残っていない」という前提が余りにも多くのプロジェクトで発生しているために,重視する点が「如何にソースコードを追いやすくしておくか」になってしまうのだろう。確かに,

  • 「自動生成によって作られたロジックは自分で書いてないので信用ならん」

  • 「メソッド呼び出しの間に動的プロキシが挟まってしまっては,ステップ実行が非常にしにくくなってしまうじゃないか」 と言う気持ちはわからなくはない。しかし,重要なことは「そのような状況を作らないこと」である。適切な分類がされたソフトウェアは,本来「美しい」ものなのだ。それを実現するためにも,Seasarのような規約に沿った定義ファイルの削減や,自動生成による規約の実装化は,今後ますます必要性が高まるはずなのだ。

このエントリーをはてなブックマークに追加

関連記事

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます

Google I/O 2022でのGoogleアシスタント関連のセッション

Remap Organizations feature has been released