こんにちは。ソフトウェアエンジニアの中田です。この記事は Goodpatch Advent Calendar 2025 16日目の記事です。技術の影響力がかつてないほど高まっている今、あらためて 「エンジニアとしての倫理と行動規範」 について共有します。
いまやソフトウェアは社会インフラそのものになり、AIやビッグデータの活用も当たり前になりました。だからこそ、私たちが日々行う「技術的な判断」が、ユーザーや社会に与える影響は以前よりずっと大きくなっています。
今回取り上げるのは ソフトウェアエンジニアリングための倫理ならびに専門職実務綱領 (第5.2版)（日本語翻訳:村田 潔） です。これは単なる「守るべきルール集」というより、迷ったときに立ち返れる判断のよりどころとして読める資料だと思っています。
原文・日本語訳ともに全文が公開されていますが、この記事ではその中から、普段の開発や意思決定で効いてくるポイントをピックアップして紹介します。
1. 公共性への責任 (Public)
正直なところ、普段は「バグを直す」とか「納期に間に合わせる」ことで頭がいっぱいで、「社会の利益」なんて大きなことは考えられていません。ですが、自分の書いたコードが誰かのデータを壊したり、生活を不便にしたりする可能性はゼロではありません。 「自分の仕事が、誰かの迷惑になっていないか？」 と、ふと立ち止まるためのチェックリストとして読んでみました。
自分の仕事にオーナーシップを持つ
自らの仕事に関し、全面的な責任を負う。(1.01)
公共利益とのバランス
ソフトウェア・エンジニア、雇用者、顧客、ユーザーの利益を、公共の利益に反しない範囲に止める。(1.02)
リスクの開示
ソフトウェア・エンジニアの理にかなった賢明な判断においてソフトウェアあるいはその関連の文書に関係すると考えられる、ユーザー、社会の人々、環境に対して現実にまたは潜在的に存在するあらゆる危険性を、適切な者あるいは権限を有する者・組織に対して公表する。(1.04)
技術を社会のために役立てる
専門職のスキルを善いことをするために進んで提供するよう、またソフトウェア・エンジニアリングという学問分野に関する公教育に貢献するよう心がける。(1.08)
2. 顧客や雇用者への誠実さ (Client and Employer)
上司やクライアントに「それは無理です」とか「リスクが高いです」って言うの、とても勇気が必要です。ですが、その場しのぎで「いけます！」と言って後で炎上するほうが、結果的にみんなを不幸にします。ここでの「誠実さ」とは、 空気を読まないで悪い知らせを早く伝える勇気 のことなのかもしれません。
自身の経験とスキルに誠実である
自らの経験と教育に関するいかなる限界についても正直かつ率直になり、自らの能力の範囲内でサービスを提供する。(2.01)
承認プロセスを大切にする
ソフトウェア・エンジニアが依拠するいかなる文書も、必要に応じて、それを承認する権限を有する者・組織によって事前に承認されたものであることを確保する。(2.04)
悪い知らせほど早く
プロジェクトが失敗する可能性が大きい、あまりに高額になることが判明しそうである、知的財産権法を犯しそうである、あるいは何か問題がありそうだと自らが考えた場合、すみやかにそれがどのようなものであるかを確認し、文書化し、証拠を集め、顧客あるいは雇用者に報告する。(2.06)
社会的なリスクを見過ごさない
ソフトウェアあるいは関連する文書に関して自らが気づいた重大な社会的懸念・関心事について、それがどのようなものであるかを確認し、文書化し、雇用者あるいは顧客に報告する。(2.07)
3. 製品品質と開発プロセス (Product)
ここは特に、現場のエンジニアにとって刺さる指針が多いパートです。「仕様が適当」「納期が無理ゲー」「テスト書いてる暇がない」。そんな開発現場の"あるある"に対して、「いや、プロとしてそれはダメでしょ」と綱領が突っ込んでくれています。
QCDのバランスをとる
高品質、受容可能なコスト、理にかなった賢明なスケジュールを追求する。このとき、これらの間の重要なトレードオフが雇用者と顧客に明確化され、受容されており、かつユーザーと社会の人々がそれについて考えることが可能であることを確保する。(3.01)
現実的なゴール設定
自らが携わる、あるいは提案するあらゆるプロジェクトに関し、適切で達成可能な目標と目的を確保する。(3.02)
様々な側面で影響を考える
作業プロジェクトに関連する倫理的、経済的、文化的、法的問題点、さらには環境に関わる問題点について、それがどのようなものであるかを確認し、定義し、取り組む。(3.03)
作るものを正しく理解
自らが携わっているソフトウェアの仕様に対する完全な理解を追求する。(3.07)
仕様の合意
自らが携わっているソフトウェアの仕様が、よく文書化され、ユーザーの要求を満たし、適切な承認を受けていることを確保する。(3.08)
テストの実施
自らが携わっているソフトウェアとそれに関連する文書に対する適切なテスト、デバッグ、検査を確実に行う。(3.10)
ドキュメント化を徹底
自らが携わるあらゆるプロジェクトについて適切な文書化を確実に行う。このとき、発見された重要な問題と、それに対して適用された解決策が文書に記載されるようにする。(3.11)
プライバシーの尊重
「ソフトウェアによって影響を受ける人々のプライバシーを尊重するようなソフトウェアの開発とそれに関連する文書の作成を行うよう努める。」(3.12)
正しいデータを正しく使う
倫理的かつ合法的手段によってもたらされた正確なデータのみを使用し、あわせてそれを正当に認められた方法でのみ使用するよう留意する。(3.13)
【重要】 見積もりの責任について
この綱領を読んでいて、印象的な発見がありました。全く同じ文章が、2つの異なる場所（3.09と5.05）に登場するのです。
自らが携わる、あるいは携わろうとするあらゆるプロジェクトについて、コスト、スケジューリング、必要人員、品質、成果に関する現実的な定量的推定を確実に行い、あわせてこれらの推定の不確実性に関する評価を行う。(3.09)
これは「製品（Product）」の章にある言葉ですが、後述する「管理（Management）」の章(5.05)にも一言一句同じことが書かれています。
つまり、現実的な見積もりと不確実性の評価は、エンジニアとマネージャー共通の責務なのです。責任を押し付け合うのではなく、双方が協力して「現実的なライン」を一緒に守っていくことが大切なのだと思います。
4. 専門家としての判断 (Judgment)
「偉い人が言ってるから」とか「流行ってるから」という理由で技術を選んで、後悔したことはないでしょうか。エンジニアとして忖度なしで 「技術的にこっちが正しい」と言い切る、そんな当たり前だけど難しいことを再確認させられます。
人を大切にする技術選定
あらゆる技術的決定を、人間的価値を支え、維持することの必要性を前提として調整する。(4.01)
納得できるものだけを承認
自らの監督・指揮下で作成された文書か、あるいは自らの能力の範囲内にあり、かつその内容に同意した文書のみを是認・推奨する。(4.02)
客観性を持って評価
評価を依頼されたいかなるソフトウェア、あるいはそれに関連するいかなる文書に対しても、専門職としての客観性を維持する。(4.03)
5. 管理者の責務 (Management)
もし自分がリーダーやマネージャーになったら、気をつけるべきことが書いてあります。マネージャーの仕事は、チケットの進捗を追うだけじゃなくて、メンバーを疲弊さないことや、リスク無視の無茶ぶりからチームを守ることなのだと思います。
品質とリスク管理
自らが携わるあらゆるプロジェクトに対し、品質の向上とリスクの削減のための効果的な処置をとるといった、よい管理を確実に行う。(5.01)
現実的な見積もり
自らが携わる、あるいは携わろうとするあらゆるプロジェクトについて、コスト、スケジューリング、必要人員、品質、成果に関する現実的な定量的推定を確実に行い、あわせてこれらの推定の不確実性に関する評価を行う。(5.05)
※3.09と同じ文章がここでも繰り返されています。管理職側にも、部下や顧客に対して「現実的な数字」を提示し続ける倫理的責任がありそうです。
6. 専門職としての振る舞い (Profession)
「エンジニアって偏屈だよね」とか「何やってるか分からない」と思われるのは悲しいです。自分一人の適当な振る舞いが、意外と「エンジニア全体」のイメージを下げてたりするかもしれません。 「自分のためにも、業界の評判を下げない仕事をしよう」 という、少し背筋が伸びるパートです。
環境づくり
倫理的に行動することに対して好意的な組織環境を作り上げるよう努める。(6.01)
学びを還元
専門職組織、会議、発表・出版への適切な参加を通じてソフトウェア・エンジニアリングの知識を拡張する。(6.03)
正しい行動を後押し
専門職の一員として、他のソフトウェア・エンジニアがこの綱領を守るよう努めることを支援する。(6.04)
誤解を招かないように伝える
自らが携わるソフトウェアの特性について正確に説明・記述する。このとき、虚偽の説明・記述を避けるだけではなく、それが読まれたときに、思惑が入っている、無意味、人を惑わせる、誤解を招く、あるいは疑わしいと当然考えられてしまうような説明・記述も行わないようにする。(6.07)
7. 同僚との協力関係 (Colleagues)
「コードレビューが怖い」「相談しづらい」という空気は、巡り巡って開発速度も品質も落としてしまいます。ここでは、感情的な対立ではなく、より良いプロダクトを作るための建設的な協力が求められています。「お互いリスペクトを持って働こう」という、シンプルですが一番大事なことが書いてあります。
良い行動を広める
他のソフトウェア・エンジニアがこの綱領を遵守するよう働きかける。(7.01)
他者の功績を認める
他のソフトウェア・エンジニアの仕事については、それが完全にその者の功績であることを認め、それを不当に自分の手柄とはしない。(7.03)
客観的で適切な批評
他のソフトウェア・エンジニアの仕事の批評は、客観的、率直、かつ適切に記録される方法で行う。(7.04)
公正に耳を傾ける
他のソフトウェア・エンジニアの意見、懸念・関心事、あるいは不満について、公正に耳を傾ける。(7.05)
詳しい人に相談
自分自身の能力の範囲外にある状況においては、そこで必要とされる能力をもつ他の専門家の意見をあおぐ。(7.08)
8. 自己研鑽 (Self)
「自己研鑽」と聞くと、ついつい新しい言語やフレームワークを覚えることばかりイメージしてしまいます。ですが、この綱領を読むと「それだけじゃないぞ」と気づかされます。自分が作ったソフトウェアが実際にどんな場所で使われるのか、どんな法律が関わってくるのか。 「コードを書く」だけでなく「コードの外側にある世界」への解像度を上げていく ことも大事なのだと感じました。
知識のアップデート
ソフトウェアとそれに関連する文書の分析、仕様決定、設計、開発、メンテナンス、テストに関する新たな知識の獲得を、そうした知識を獲得するプロセスの管理とともに推進する。(8.01)
良いものを作る力を磨く
安全で、信頼性が高く、有用で良質のソフトウェアを、受容可能かつ適切なコストで、しかも受容可能かつ適切な時間内に作成する能力を向上させる。(8.02)
伝える力を高める
正確で、有用な情報を与え、かつ適切に記述された文書を作成する能力を向上させる。(8.03)
利用シーンを想像する
自らが携わるソフトウェアならびにそれに関連する文書と、それらが使用される環境に関する理解を向上させる。(8.04)
ルールや法律を知っておく
自らが携わるソフトウェアとそれに関連する文書について規定している適切な基準ならびに法に関する知識を向上させる。(8.05)
まとめ
この綱領は「完璧な人であれ」と言っているわけではありません。むしろ、日々の開発の中で迷ったときや、チームで判断が割れたときに、立ち返れるよりどころを提供してくれます。
明日からのコードレビュー、設計、見積もり、プロジェクト計画のどこかで、ふとこの視点を思い出すだけでも、判断の質が少し上がるはずです。
引用・出典
- ソフトウェアエンジニアリングのための倫理ならびに専門職実務綱領 (第5.2版)（日本語翻訳:村田 潔）
- IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
