一連の記事は「開発プロセス」というカテゴリを設定することにします。
1つ前の記事は、現在の開発ではアジャイルが前提である、あるいは勝手にアジャイルになるということも多々あるということで、アジャイルのプロセスに少し踏み込み、そこでドキュメントは不要なのではなく、いかに負荷をかけずにドキュメントを作るかという視点が必要であるということを説明しました。
実際にシステムを作る場合、当然ながら最初は100点を目指して作りますが、それを実現するためのいろいろな品質基準があります。例えば、ISO/IEC 25010:2011を基にしたJIS 25010:2013などがあります。製品品質モデルの上位カテゴリを見ると、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性という項目が並んでおり、これらを一定以上のレベルで実現することで、品質を確保することにつながります。つまり、品質を高めるために具体的に何を行うのかを検討する材料はすでに工業規格となっています。
最近ではWebアプリケーションやスマホで稼働するアプリケーションを作る機会は多くなっています。開発時には、機能適合性、性能効率性、使用性という点について、すべての開発に関わる人が多少なりとも意識しやすところです。これらに関わる内容は、開発を進める上で、常に話題としてチームの中に流れ、また、チェックもされるということになります。信頼性は最も重視されることであるのですが、対策を具体的に行い結果をきちんと出すのはなかなか難しい領域でもあります。一般論で進めた結果、完成したシステムが不安定だったということは多くの開発関係者は体験しているでしょう。セキュリティや保守性は、どちらかといえば、当たり前的な意識がまずあって、場合によっては「常識」ということで、議論されない可能性もあります。極端な例ですが、システム請負会社はセキュリティ対策は仕様に入れなくてもやっていて当たり前という判決も出ています。当たり前なので議論の俎上に上がらないというのは、実は誰も気づかず、あるいは気づいても実装はしていないということにつながります。セキュリティへの注目が集まる一方で、臭いものには蓋をする的な意識が共有化されていないでしょうか？ また、保守については、初期開発ではそこまで頭が回らないという切羽詰まった状況も日常化していないでしょうか。
機能や仕様を考える上で意識に上りやすい「機能適合性、性能効率性、使用性」、重要性は意識しているが実現が難しい「信頼性」、いくぶん消極的な方向に行きがちな「セキュリティや保守性」という傾向があるように感じます。「互換性、移植性」については要件や利用状況に絡むことであり、他の項目と傾向が違うように感じます。信頼性については、様々な手法やプラクティスがあることもあって、マネジメント上で注力すれば、それなりにやり方はある方法です。こうした分類から、セキュリティと保守性にテコ入れが必要なのではないかと考えます。
現在、多くの開発は保守開発である事は、多くの人が指摘するところです。IT関連費用のうち、運用コストが45%、新規開発24%、保守開発31%となったという調査もあります。開発関係者と話をしていても、実際、データベーステーブルがないところから開発ができるような機会はあまりなく、誰かが昔作ったシステムの改修といった仕事が増えていることが話題になります。また、従来からの開発手法では、新規開発と保守開発は明確に「契約」段階での分離があったかもしれませんが、アジャイル開発や、あるいは顧客のニーズが変化するような場合は、現実には初期開発の途中からでも保守開発の側面が強くなります。
事実上保守開発を普段から定常的にやっているのだとすれば、機能実装をスムーズにする仕様書という考え方に加えて、保守開発、つまり改変する箇所が明確になるような仕様書である必要があると考えます。そのためには、抽象度の低い具体的な機能のモデル内での明確化と、フレームワークやライブラリを利用する前提の上での境界線の明確化であると考えます。抽象度の高い記述方法で、自由に実装をしてしまうと、別の人がモデルを見たときに大まかなコンセプトは伝わりますが実装の上で考えたことはコードと突き合わせて解析しなければなりません。また、フレームワークの機能をどこまで利用しているのかが明確でないと、フレームワークの仕組みを保守するのか、独自に作ったプログラムを保守するのかも、やはりプログラムを読み解かないとわからないことになります。この点を踏まえて、どのようなドキュメントを作るのかを考えます。
なお、前述のJIS 20010では、保守性の項目に対する細目として、モジュール性、再利用性、解析性、修正性、試験性が挙げられています。「モジュール性と再利用性」は、適切な設計かどうかという点に大きく依存しますし、「試験性」も試験が可能なように作ってあるかどうかという点に依存します。一方、「解析性、修正性」について、開発プロセス上でより重視できるような仕組みを組み込むというのが大きな目的です。
保守開発の最も大きな問題点は、目の前で動いているコードしかないという状況で、改良にかからないといけない点です。また、巨大な既存システムの全貌はわかりません。全貌がわからないと保守できないというのは却下されべき言い訳としか理解されません。わからないけど改良しないといけません。その場合でも、改修対象の機能に絞って初期開発と同様のモデリングをすべきです。ただし、変更結果の波及範囲は検証すべきでしょうし、不明な箇所の扱いにも配慮は必要です。ここで、ドキュメントを書いている時間がないとか、費用がないといったことが言われて、それでもなんとかしたいという要望があることも事実です。時間や費用がなくても、最低限のドキュメントを揃えることが、まずは改修箇所の把握には必要です。その場合は、ボトムアップに解析をして、関連するデータベース内部のスキーマからER図を作ったり、特定の処理に限定してクラス図を作るなどすることで、効率化は図れます。一連の説明では、困難な場合でドキュメントは作るという前提で話を進めます。
次回から具体的に何を作ればいいかということを説明します。