ソフトウェアプロフェッショナルの倫理、価値観、行動

先日のMediumの記事で、筆者のChristiaan Verwijs氏は、ソフトウェア開発者に委託された権限は倫理的な行動規範に基づくべきか、という疑問を提起した。“A Code of Ethics for (Agile) Software Developers?”と題したその記事の中でVerwijs氏は、ソフトウェア開発者は世界に対して大きな影響力を持つと同時に、“プライバシを保護し、セキュアなアプリケーションを開発し、複雑性を克服するような製品開発を行なう責任”を負うとして、次のように説明する。

‘ソフトウェア開発者’は、弁護士や医師と同じような専門的職業であるべきです。専門的職業であることの特徴のひとつは、倫理規範を持つことです。医師にとってのヒポクラテスの誓い(訳注:実務に就く医師の倫理綱領)、(ある種の)エンジニアにとってのアルキメデスの誓いのように、です。

2015年のVolkswagenのスキャンダルは倫理失墜の顕著なケースだ。今年8月にはひとりのエンジニアが、“車両が排気ガス試験中であることを検出する目的で排気制御モジュールに実装された、巧妙かつ卑劣なアルゴリズム”によって排気ガス試験を操作したことで有罪判決を受けている。

スキャンダルが発覚した頃、IEEEのSpectrum誌での対談で、イスラエルのネゲヴ・ベン＝グリオン大学でビジネス倫理の教鞭をとるYotam Lirie氏は、この問題について次のようにコメントしている。

衝撃的なのは、Volkswagenのソフトウェアエンジニアたちがプロフェッショナルとしての受託者責任を看過した、という点です。たとえ効率性ないし経済性で劣ったとしても、安全性 – 今回の場合は環境安全性 – を確保するため、組織内で半永久的な責任を負うのがプロフェッショナルなのです。

今年初めのインタビューで、Scrum.orgのプロダクトオーナであるDave West氏は、倫理的に不明確な状況についてコメントした。

期日に間に合わせるようにプレッシャをかけられたり、生活がかかっている場合には、何が正しくて何が間違いかを導くことさえ困難になります – 倫理綱領は、プロフェッショナルが頼るべき文脈や枠組みを与えてくれるのです... 業界として標準化された倫理綱領を持つべきだ、と私は思います。職業としてのソフトウェア開発を改善するという目標に合致した、私たち自身の綱領を持つのです。

Robert C. Martin氏(Uncle Bob)は9月、InfoQのBen Lindersに、自身の提案するプログラマの誓い(Programmer’s Oath)として、“有害なコードを生み出さない”という道徳的教義から始まり、クラフトマンシップ、透明性、フィードバックループなどに言及した９つの宣言について語った。氏の説明によれば、

ソフトウェア開発者がユーザに与える可能性のある危害には2種類あります。ひとつめは最も明白で、ソフトウェアエラーの可能性です。エラーを起こさないソフトウェアの提供に最善を尽くすべきだ、という点に、異論を挟む余地はないと思います。

次に氏が挙げたのは、変更に対するアジリティを前提に構成されたソフトウェア開発における、プロフェッショナルとしての責任に関することだ。

プログラマがユーザに対して日常的に行なう危害の第２の形態は、ソフトウェアの構造を損なうことです。ユーザは、ソフトウェアが容易に変更可能であることを期待します。それでこそ“ソフト”ウエアだからです。ユーザがソフトウェアシステムを必要とするのは、社会や技術の急速な変化に対応するためなのです。ソフトウェアを“ソフト”に保つことに最善を尽くすべきだ、という点に、異論を挟む余地はないと思います。

2015年の“Professional Ethics of Software Engineers: An Ethical Framework”と題した論文で、Lurie氏は、SDLCの各フェーズにおいて提起される可能性のある、一連の倫理的問題について取り上げた。ソフトウェア開発における倫理的考慮の必要性について、Lurie氏は次のように説明する。

このケースでは、ソフトウェア開発者(専門家)とエンドユーザ(顧客)の間にある力関係に、それを規制し、乱用を避けるための倫理的チェックとバランスが何としても必要です。

Lurie氏はさらに、単なる技術的活動と見なされている活動の中にあっても、倫理的配慮が必要なものはある、と説明する。

具体的には、ソフトウェアパッケージの主な技術的特徴であると思われるもの ... 品質や有用性、信頼性、正確性、実用性、安全性といったものが、実際にはその製品が何をするもので、エンドユーザにどのように役立つのかを決定付けます ... こういったソフトウェア製品の中心的な技術的特徴こそが、実は重要な倫理的影響力を持つのです。

ソフトウェア開発の“コアバリューとプラクティス”を取り上げた先日のブログ記事で、ThoughtWorksのテクニカルプリンシパルであるEvan Bottcher氏は、“ソフトウェアの構築技法”に反映される“ソフトウェアエンジニアリングの基本的価値観”についての洞察を公開した。

Bottcher氏は次のように書いている。

価値観は信念の表明です – これが特性として存在することにより、単にユーザや顧客を喜ばせるだけではなく、短期的にも長期的にも、迅速な変更を自信を持って行なうことが可能になるのです。

Bottcher氏はXPの価値観と原則を基盤とする４つのコアバリュー、すなわち迅速なフィードバック、簡潔さ、再現性、クリーンなコードを提案する。これらの価値観は、主要な８つのエンジニアリングプラクティスを支持する。

• シンプルなデザイン
• 集団によるコード所有
• ペアプログラミング
• リファクタリング
• テスト駆動設計
• 継続的インテグレーション
• 反復タスクの自動化
• 垂直スライス

これらの価値観と原則は、MVPを含むすべての提供物に適用されなくてはならない、とBother氏は言う。

ソフトウェアの一部が本当に破棄される場合には、実施可能なトレードオフもあります。しかしながら、これらのコアバリューとプラクティスについては、例え短期間のデリバリであっても、利用継続性が不明確であっても、常に適用されなければなりません。これらのプラクティスを省略すれば、例え短期間でも、あなたのパフォーマンスを落とすことになります。

Martin氏もまた、プログラマの誓いを実践する上で、妥協をしないことの重要性を強調する。

プログラマならば誰でも、構造の悪い複雑なコードによって作業を著しく妨げられた 経験を持っています。こうしたコードを“書く”のは容易ですが、他のすべてのメンバを遅らせるような状態のシステムを後に残します。他メンバの作業が遅れれば、作業を短縮しなければならないというプレッシャが大きくなり、システムの状態はさらに悪化します。さあ、みんなで言いましょう – “速くやりたければ、正しくやること(The only way to go fast, is to go well)”。

Verwijs氏の提案したソフトウェア開発者の倫理規範は、ユーザのセキュリティとプライバシを保護する手段として、ユーザ中心主義、開発者とチームの結び付き、失敗と複雑性に対する誠実さ、透明性、品質、高速なフィードバックループなどに関連する倫理的行為を提案するもので、ひとつの叩き台としての位置付けである。ただひとつの倫理規範を採用することの難しさについて、氏は次のように説明する。

このような倫理規範で問題となるのは、開発者の大半に受け入れられ、教育トレーニングの一部となって初めて機能するものである、という点です。私たちが(まだ)、そのポイントに到達していないことは間違いありません。

VMのケースでは、エンジニアに対して40ヶ月の懲役と20万ドルの罰金の支払が課せられた。そのエンジニアはスキャンダルの首謀者ではなかったが、検察側の覚書には次のように記されている。

(そのエンジニアには)自分が悪いことをしているという意識はありましたが、自分は単なる１エンジニアであって、それが正当なものかどうかに関係なく、問題に対する実践的なソリューションを提供することが仕事なのだ、と自身に言い聞かせることで、詐欺行為に対する自身の道徳的責任感を最小限に留めていたのです。