システム開発は、「具体」と「抽象」の間を行き来します。
ウォーターフォール型を例にとって、開発の段階をごく簡単に述べると「要求→設計→実装」となります。ここで問題となるのが、ユーザーと技術者とで、具体／抽象のとらえ方が異なることです。
「要求」は日常の言葉（自然言語）で書かれ、ユーザーにとっては具体的なものですが、技術者から見ればざっくりしたものであり、抽象的です。
逆に、「実装」（コード）は、技術者にとっては具体的ですが、ユーザーにはそのままでは理解できません。
ですから、開発にたずさわる技術者は、抽象化と具体化、両方の能力が求められるのです。
さて、近年「アジャイル」という開発手法が広まっているのをご存じの方も多いでしょう。
アジャイル開発は、何がアジャイル（俊敏）なのでしょうか。
ウォーターフォールは、上流が全体の「設計」を完成してから「実装」をスタートします。
抽象的な「設計」が完全なものであるという前提で、具体的な「実装」がおこなわれます。しかし、実際のところは、実装を始めてから設計の欠陥が判明することがよくあり、工程の遅れにつながります。
いっぽう、アジャイル的な開発は、要求を「ストーリー」という小さい単位にまとめ、複数のストーリーを同時並行で実装し、小刻みにテストをしながら組み合わせていきます。開発メンバー各自が、抽象化／具体化をすばやく切り替えながら進めます。ユーザーには、未完成ながらも正しく動作するシステムを、随時提供することができます。
アジャイル的なプロジェクトは、システム開発に限った話ではありません。別の分野で実績をあげている先駆的な例として、スペイン・バルセロナの建築「サグラダ・ファミリア」をとりあげたいと思います。
当初の設計を手がけたガウディが、設計図をほとんど残さないまま亡くなったため、サグラダ・ファミリア＝「終わりの見えない巨大プロジェクト」という印象が強いと思います。某メガバンクのシステム統合を揶揄する言葉としてもよく使われました。しかし、実際には、当初の予想の半分以下の工期で、2026年には完成予定となっているのです。
設計図はなくとも、コンセプトは明確です。建物の各部分に聖書の場面や登場人物を割り当て、全体で聖書のストーリーを表現する、というものです。
このコンセプトをもとに、多くの建築家・職人・彫刻家が分担して作業を進めています。その中には日本人彫刻家・外尾悦郎氏もいます。
聖書のストーリーをメンバー各自が深く理解し、みずから考え、形にすることで、分業であっても、いやむしろ分業だからこそ、順調に作業を進めることができるのです。
システム開発を建築にたとえるなら、「設計」は工事現場の足場のようなものです。技術者が作業するために必要な仮の構造ですが、建物の完成時には解体してしまいます。建物を利用する人＝ユーザーにとっては、建物が丈夫で使いやすいかどうかが重要であり、足場が立派かどうかは関係ありません。
アジャイル的開発は、抽象的な「設計」をこねくり回すのではなく、プロジェクトの具体的な問題に向き合い、具体的な答えを出すことに価値を置きます。ひとつとして同じ問題はなく、当然答えもそれぞれ異なります。抽象的な知識やスキルは、問題解決の助けにはなりますが、そのままでは答えにはならず、具体的な形にして提示しなければ意味がありません。
技術開発にかぎらず、営業も、その他どんな仕事でも、ウォーターフォール的に解決できる問題は、実はとても少ないと思います。人生についても同じことが言えるでしょう。
誰かが一般論・抽象論で考えたものを、そのまま現実にあてはめて解決できることなど、めったにないと思います。自分自身が、個々の具体的な問題に向き合い、具体的な答えを出すしかないのです。
現代は、社会のあらゆるしくみが急激に変化する時代です。抽象化／具体化のプロセスを、自分の力で、臨機応変にできる、いわばアジャイル的な考え方が、今後ますます必要になってくるでしょう。