創造、協力、革新のためのソフトウェアエンジニアリング

ソフトウェアエンジニアリングは、反復的で、フィードバックに基づき、漸進的、実験的で、実証的でなければならない。職人技は十分ではない。エンジニアリングは増幅器であり、創造性と協力、発明を強化する。継続的デリバリはエンジニアリングの原則に根ざしている。最初から、より厳密であれば、プロダクションのバグ修正や配置、構成に時間を取られることなく、優れた革新的な解決策を作ることができる。そう主張するのは、Dave Farley氏だ。

ソフトウェアエンジニアリングという言葉は1968年のNATOカンファレンスで初めて使われた。エンジニアリングの原則に向かって進歩しているものの、ソフトウェアはまだエンジニアリングではない。とMary Shaw氏は言う。

何十年の間、ソフトウェア開発の手法には多大な労力がかけられてきました。これによって商業的な実践を支援する開発方法が確立されました。しかし、エンジニアリングの実践に必要な技術のための体系化された基礎を確立できませんでした。

独立のソフトウェア開発者でありコンサルタントであるDave Farley氏はQCon London 2018で Taking Back "Software Engineering"と題した講演をした。InfoQはこのカンファレンスをインタビューや記事で取り上げている。

InfoQは、Farley氏にインタビューし、ソフトウェアエンジニアリングの定義、その重要性、エンジニアリングとクラフトマンシップの関係、エンジニアリングの考え方を養うためにできることについて話を聞いた。

InfoQ: あなたは"ソフトウェアエンジニアリング"をどのように定義しますか。

Dave Farley: 開発者の間で、"エンジニアリング"とは何なのかについて誤解があると思います。"ソフトウェアエンジニアリング"についてはなおさらです。まず、"エンジニアリング"は"生産エンジニアリング"とは違います。初めて何かをするのと1000回も同じことを繰り返すのは全く異なることです。エンジニアリングは徹底的に創造的な分野なのです。"キュリオシティローバー"や"ファルコンヘビー"や初代iPhoneのようなものを作りだすのがエンジニアリングだと思います。

この文脈で私のエンジニアリングの定義は以下のようになります。

エンジニアリングは実証的で科学的な手法を応用して実際の課題の効率的に解決する方法を探ること。

ソフトウェアエンジニアリングでは、この"実証的で科学的な手法"を実現するために必要不可欠なことがあります。私にとって、あらゆる"ソフトウェア開発原則"の中で、その名前にふさわしいのは以下の5つです。

• 反復的であること
• フィードバックに基づくこと
• 漸進的であること
• 実験的であること
• 実証的であること

QCon Londonでの私の講演ではこれらの考え方について詳しく話しました。

InfoQ: ソフトウェアエンジニアリングが重要なのはなぜでしょうか。

Farley: ソフトウェアは重要です。奇妙なことに、今、もっとも世界を変えているのは、私たちソフトウェアエンジニアです。私たちの世界は若く、爆発的に成長してきましたし、今後も、引き続き拡大していきます。

私の認識では、ソフトウェア開発者の大半はソフトウエア開発で本当の意味での"エンジニアリング"が行われているのを見たことがありません。これらの原則を使えば、スピードも品質もかなり劇的に効率的になります。

"科学"としてはこれは驚くべきことではありません。エンジニアリングは科学に根ざしています。科学は人間にとってもっとも効率的な問題解決の手法です。私たちはソフトウェア開発のとても困難な問題にこれを使って取り組むべきです。

また、専門領域としてのソフトウェア開発の進化という見方もできます。フォルクスワーゲンの排気ガスのスキャンダルでは数人が捕まりました。ソフトウェア開発者も含まれています。私たちは自分たちの意思決定と書いたコードに対して道徳的かつ経済的な責任があます。私は、業界はこの責任についてしばしば無視している、と感じてきました。責任を把握し、コントロールしなければ、私たちは責任を背負わされてしまいます。

死亡事故が発生するような、橋や自動車、飛行機を作るエンジニアはプロとしての責任を持たされるでしょう。私たちもこの課題に直面します。テストや計測、アイディアの評価に対する効果的な原則に従わないなら、私たちの行動を何が守ってくれるのでしょうか。

最後は個人的な指摘です。エンジニアリングの原則に従って働くのは楽しいです。問題に対してより革新的な解決策を作りだせます。より原則に従って働くことで、大きな問題に取り組んだり、少ない時間でバグ修正をしたり、配置や構成で工夫をしたりできます。私の考えでは、"エンジニアリング"は、ソフトウェア開発の創造的な側面によって私の能力が損なわれることを防ぎ、能力を活用し増幅してくれます。

InfoQ: クラフトマンシップはエンジニアリングとどのように関係するでしょうか。

Farley: "ソフトウェアクラフトマンシップ"運動は"大規模な式典"、つまり、1990年代から2000年代前半のウォーターフォールスタイルのプロセスに対する恐怖への反応として生まれました。クラフトマンシップは、クラフトマンシップは事前に計画されたアプローチへ一歩近づきます。計画されたアプローチは、移ろいやすく、多くの"発見"を含んだプロセスに対しては、間違ったモデルです。

クラフトマンは正しい一歩です。しかし、これまでの経験を振り返ると、クラフトマンシップの品質は低いです。職人が作ったiPhoneやジェット戦闘機を想像してください。"職人"がリードした宇宙計画はどう思いますか。

クラフトマンシップは不十分です。エンジニアリングは増幅器です。創造性や協力、革新性を阻害しません。強化します。

ソフトウェアクラフトマンシップの考えの多くに、私は賛同します。特に徒弟スタイルのトレーニングや継続的な学習、改善は素晴らしいと思います。しかし、これらのアイディアは"ソフトウェアエンジニアリング"の原則にも適用でき、エンジニアリングの原則は、足踏みをしてしまっているときに道筋を示し、品質と生産性を向上させてくれます。

InfoQ: エンジニアリングの考え方を養うにはどうすればいいでしょうか。

Farley: 究極的には、"世代"交代だと思います。"ソフトウェアエンジニアリング"の原則に合意したら、それが、教えられ、一般的な実践になり、期待されるようになります。

私の原則は良いスタート地点だと思います。反復的で、フィードバックに基づき、漸進的、実験的で、実証的であることです。

また、多少バイアスがかかっていますが、継続的デリバリはこれらの原則の基盤だと考えています。

少なくとも、私たちの専門領域の思想的リーダーの中では、何がうまくいくかについて、今まで以上に大きな合意ができていると思います。"ソフトウェアエンジニアリング"の本当の意味を定義してみるには、今が良い機会なのかもしれません。

定義に対して広範囲な合意ができれば、教育機関や専門機関に対して正しいことを教えるようにアドバイスできるでしょう。 "コンピューターサイエンス"を学習した人の中で"科学的方法"と"実験"の重要性を学んだ人はどのくらいいるでしょうか。このような"専門性"の一部としての"倫理"を学んだ人はどのくらいいるでしょう。ほとんどのエンジニアリング原則でこれらは普通のことです。

InfoQ: 今の世代の開発者についてはどう思いますか。ソフトウェアエンジニアリングを身につけるために何をすればいいでしょうか。

Farley: 若手でもベテランでも、私がソフトウェアエンジニアに一番アドバイスするのは、より科学的な方法で問題を解決すること、そして、科学的な方法を真剣に取り扱うことです。

実験という観点で考え、データを集め、意思決定してください。アイディアを試してみましょう。最初のアイディアが正しいと思わないでください。全ての仮説が不正解と考えてください。そう考えることで自分がどの程度間違っているのかわかります。また、失敗しても大事故にはなりません。

InfoQ: "職人"と"エンジニア"の違いは何でしょうか。

Farley: "職人"は何がうまく動作するかを推測します。"エンジニア"は推測をして計測し、どこで間違ったのかを明らかにします。