« 業務システムとマイクロサービス(2) | トップページ | 実装について学ぶこと大杉問題 »

2020.11.18

交響曲はアジャイルに収録できない

 昔から感じていたことだが、ウォーターフォール方式(WF)とアジャイル方式の違いは、クラシック音楽とポピュラー音楽(軽音楽)での収録スタイルの違いに似ている。WFとクラシック音楽では、行き届いた仕様書(楽譜)を用意したうえで実装(収録)に臨む。いっぽうアジャイルやポピュラー音楽では、おおよその方針を決めつつも現場での発見や思いつきを生かす形で実装(収録)がなされる。

 もちろん現実には、2つのスタイルは連続していて明確に分かれるものではない。一言でポピュラー音楽と言っても、ポップス、ロック、ジャズで収録スタイルは大きく違うし、曲によってはフルスコアが用意されることも少なくない。それでもあえて2つのスタイルを想定することで、両者が目指しているものや特徴がよくわかる。

 両者のとくに目立つ違いは、実装(収録)に必要な人員数と指示のあり方だ。クラシック音楽ではたいてい少人数では済まない。オーケストラだと40名から100名といった大人数が関わる。大規模なWF型プロジェクトでもそれくらいになることはある。想像してみればわかるが、それくらいの大人数での動きを統制するには明確な指示やルール(仕様書や楽譜)が欠かせない。つまり、WFには仕様書がつきものではあるが、多人数だから必要になるという側面もある。

 いっぽう、ポピュラー音楽の収録やライブに臨む少人数バンドでは、「Cメロ譜(CはChordの略。リードシートともいう)」と呼ばれるコードとメロディのみが記された楽譜が駆使される。解釈の自由度が大きい楽譜ではあるが、経験を積んだ演奏者であれば苦もなく対応できる。編曲者による基本方針があるとしても、個々の演奏者による独自の解釈が面白い効果を生み出すことがある。むしろそれを期待しているスタイルといっていい。

▼筆者がバンドで使った楽譜の例(有名曲なのでメロディさえ書かれていない)
Flymetothemoon
 こういった楽譜はまさに「アジャイル」的な道具立てではあるが、残念ながら業務システムはポピュラー音楽のようなものではない。少なくとも50本のテーブルとその数倍のUIや複雑なロジックを含むアプリ群で構成されている。ようするに交響曲のようなソフトウエアだ。それをいくつかのブロックや楽器別のパートに切り分けて、Cメロ譜で(ときにはそれさえなしで)クライアントの反応を見ながら収録を繰り返すようなやり方では、全体性や統一性のある作品としてまとまる可能性は限りなく低い。

 では、業務システム開発はクラシック音楽の収録のようにWF的なものにならざるを得ないのだろうか。かつてはそうであったが、今では事情が違う。ポピュラー音楽の収録のように、全工程を少数精鋭だけで賄えるようになったからだ。

 音楽収録の現場では、DAW(Degital Audio Workstation,ダウ)を用いて多くのトラックに記録された音源を手軽に編集できるようになった。交響曲さえ編集できる。編集するといってもDAW上で楽譜や細かい表現を書くだけの話で、機械がそれを解釈して演奏してくれるのである。

 まったく同じことが、業務システム開発の世界でも起こりつつある。ノーコード・ローコード基盤をはじめとする技術革新のおかげで、実装作業は劇的に合理化された。すなわち、設計者が仕様書を書くだけで「動くアプリ」を用意できるようになった。それもUIだけがパカパカ動く張りボテなどではない、複雑なDBとのやりとりを伴う本格的なアプリだ。そういうものをプロトタイプとして要件定義段階から利用することで、顧客からの豊かなフィードバックを得られる。結果的に、仕様を見直すリスクや作り替えリスクが激減する。また、10名のチームで扱ったシステムを2名でじゅうぶん賄えるようになった。「オーケストラ」のようなチームではないので、指示もルールもシンプルで済んでしまう。

 ただし、こういった合理化が進行する中でも忘れてはいけない事実がある。今も昔も、プロの作曲者や設計者は、本番収録(本番実装)までに作品の全体像を確立している。完成途上の全体像をあの手この手で手早く実体化し検証することで、顧客に提供できる価値が高まっているということなのだ。言い換えれば、たたき台となる良質な全体像がなければ、どんな手法や技術を駆使しようが優れた成果は得られない。「アジャイルな作り替えがいつまでも終わらないデスマーチ」に陥るのが関の山だ。

 「明確な全体像にもとづくプロトタイプ」を基礎とする開発手法は、もはやWFでもアジャイルでもない。しかし、業務システム開発に長年携わってきて、これほど安全確実なやり方はないと私は実感している。もちろん、全体像を手早く確立するのは簡単な仕事ではない。しかしそれこそが、交響曲の作曲者や業務システム設計者に求められる高度専門性である。それをやらないこと(出来ないこと)が新技術を取り入れたゆえに許されるなどと考えてはいけない。実装(収録)は楽になったが、システム仕様(交響曲)の構想は相変わらず難しい。そしてこの事実は、実装過程が合理化されない限りなかなか気づかれない。

|

« 業務システムとマイクロサービス(2) | トップページ | 実装について学ぶこと大杉問題 »

コメント

コメントを書く



(ウェブ上には掲載しません)




« 業務システムとマイクロサービス(2) | トップページ | 実装について学ぶこと大杉問題 »