2020.02.13

パラメトリック・ボイス　　　　　　　　　　  　　　　清水建設　丹野貴一郎

このコラムを書いている時に2019年のコラム人気記事ランキングが発表されていましたが、
1位が石津さんの記事となっており、石津さんのような経験、能力に注目が集まっている事の
象徴のような気がします。

現在のような仕事を始めてから、何の仕事をしているの？という質問に対して一言で”○○屋
さん”という答えができずに困っているのですが、建築業界でデジタルに関わっている人は少
なからず同じような経験をしているかもしれません。
建築に限らず、これまでの”仕事カテゴリー”に収まらない分野が増えていると思います。それ
らの多くはデジタルテクノロジーにより、分野を横断した業務を行っているのではないでしょ
うか。

これは建築業界に限った話ではありませんが、このようにデジタルテクノロジーに関わる中で
は、いわゆる横文字の技術や考え方を取り入れることで”新しい”を感じる人が多いように感じ
ます。皆さんも「AIを使って業務改善しなくては」や「私たちもDX(Digital Transformation)
に取り組まなくては」と聞いた経験がありませんか。
AIのようなテクノロジーは道具であり、道具は人の発展を支え、人の発展が道具を発展させる
という文明の進歩はおそらくこれからも変わらないと思います。そして進歩のなかでデジタル
テクノロジーを道具として使う事がDXであり、これまでのやり方にとらわれず道具とともに進
歩していけば自然とイノベーションが起きるのだと思います（そのような組織を作って新規事
業計画書を作ることがイノベーションではありません）。

とはいえ、道具の価値を理解しなければちゃんと使うこともできないので、とりあえず試して
みることや、使いながら方法や道具を改良することは非常に重要なことです。
このように、まずはやってみる、やりながら考えていく開発手法で、これまた横文字ですが、
PoCとAgile開発というものがあります。
ご存じの方も多いと思いますが、私なりに簡単に説明すると、PoC(Proof Of Concept)とはま
ずはプロトタイプを作ってみて理解を深めてから本格開発をしましょうというもので、Agile
開発とは大まかにやることを決めたらとりあえず始めて、あとはやりながら考えるというもの
です。
このように横文字で書かれると新しい手法のようですが、例えば建設工程では本設の前にモッ
クアップを作って検証をすることは珍しいことではありませんし、工事がはじまってから出来
高や状況に合わせて次の判断をすることは日常です。設計に関しても契約時点ですべてが決
まっていることの方が少ないのではないでしょうか。
建築ではこれまでの歴史の中で自然とこのようなやり方になってきたのかもしれませんが、逆
になぜそうしているかを明確に答えられる人はすくないと思います。

Agile開発は、短納期が求められるようになったIT開発において、全体の設計を終えてから実装
する従来のやり方（これをWaterfall開発といいます）では着手までに時間がかかるうえ途中
の変更が困難となるため注目された手法です。
建築はほとんどが一品生産であり毎回条件が異なるため変更に適応できることが必須だったの
だと思います。

以前もこのコラムでITのプロジェクトマネジメントは建設から学んだという話を取り上げまし
たが、ITの開発手法は他業種の手法を分析して取り入れていることが多いので、なぜそうする
かの理由付けがされています。
手法の分析は目先の生産性は上がりませんが、後々必ず重要になってきますので、IT業界が分
析してくれた手法を学ぶとわかりやすいかもしれません（横文字ばかりで中身が無い場合も多
いので気をつけてください）。

日常業務がAgile型なのにそれに伴う開発が組織という理由だけでWaterfall型になっていませ
んか？

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
•