この目的には 「高品質のソフトウェアをより短い時間で生み出すことが事業成果と社会的価値の両方を生む」 という前提条件があるものとする （※ もしこの前提が崩れた場合は、目的自体の見直しが発生する）
チームが、より高い品質のソフトウェアを生み出せるようになり、より意欲的でストレスレスに仕事を進められ、仕事の充実が生活の充実に繋がり、それがまたよい仕事を生むという好循環を生み出すこと
ソフトウェアエンジニアとして心がけることを知る前に、ソフトウェアエンジニアたるものが社会においてどういう存在かを揃える
社会全般において中心的な役割を拡大しているソフトウェアシステムの分析、仕様策定、設計、開発、認証、メンテナンス、およびテストに直接的に関与および、その指導を行うことによって貢献する専門家である。
そのようなソフトウェアシステムを開発する役割を担っているソフトウェアエンジニアには、善をなすことも害をなすこともできる多大なる機会がありまた、他者が善をなすことも害をなすことも可能にする大きな機会がある。
自分たちの努力ができる限り善のために使われるよう、ソフトウェアエンジニアを社会にとって有益で尊敬される職業にすることを約束しなければならない。（ACM and IEEE）
Software Engineering Code of Ethics and Professional Practice
保守性、拡張性、ビジネス価値を考慮しながらソフトウェアを通じて問題を解決する専門家である（Martin Fowler） 技術的知識とエンジニアリングの原則を組み合わせて信頼性の高いソフトウェア・システムを構築する実務家である（Steve MacConnell）
これらは社会における この職種のあるべき姿（ToBe） と言える
エンジニアとして価値をおく（⼤切にする）こと
価値は上位が優先される
プロダクトにおける成果が何かをプロダクト全員で共通認識をもち、成果を突き詰めること
価値を生むための振る舞いの指針となるのが原則
（特に内部）品質に責任をもつ職業はソフトウェアエンジニア以外にいない つまり、品質責任を負うことは我々の存在意義そのものである
品質を満たすための複雑さは増してきており、エンジニア以外といかに、早く協力するかが品質を大きく左右する（昨今だと機能適合性がとくに該当する）
ソフトウェア品質知識体系（SQuBOK）における
を特に重視する（※プロダクト特性によって順序は前後し、互換性や移植性が入ってくることもある）
→ チームとして守るべき品質基準をもっているかもっていないか
あるプロダクトにはサードパーティ開発者向けに提供していたAPIがあり、最重要KPIは「プロダクトの成長」と「開発者エコシステムの拡大」であった。エンジニアリングチームは、外部開発者がどんどんAPI利用を拡充したくなるようなAPIの設計を求められていた。
そのため、APIは本質的に寛容で、悪用されやすい機能を持つような設計になっており、プライベートなメッセージのやりとりも連絡相手との同意なく取得できていた。「外部開発者とその関係者がAPIで取得したデータを広告に利用するなどが可能なこと」に、チームは薄々気づいていたが、API及びエコシステムの利用拡大が進んでいる状況のため即座の対応を先送りにした。
「Move Fast and Break Things」（素早く動き、破壊せよ） は、初期のスローガンで、迅速な開発とイノベーションを奨励するカルチャーを醸成するためだった。
迅速な機能のリリースを優先し、完璧でなくてもまずは市場に出して改善していくという考え方を浸透させたが、後に 「Move Fast with a Stable Infrastructure」（安定したインフラで素早く動け） へと変更された。
従来の技術的問い：
新たな倫理的問い：
エンジニアにとって知識は資産であり、学習活動は仕入れ
プラグマティズムは「理想は捨てず」に、「現実的な制約の中で最適な解決策を見つける」ということを意味する
細かい業務工程部分
能力の有無はあくまでスキルや行動として表出しているかどうかでしか判断できない
何時間でも夢中になって作業したり調べたりできる対象 → 自分が楽しんでできること
* 誇りの話
「いや、そんなんやらんやろ」と思うかもしれない 「成長がすべて」と言われたときに本当に抗えますか？ 抗えるのが技術者の矜持 かつ、根拠を示せるのが技術に責任をもつということ
## 原則 ### 全体の最大利益性を求める - ユーザー - チーム - ステークホルダー すべての相互利益の最大化を追求しなければならない ### どういったときにどうやって原則を適用すべきか -