よく出るエンジニアの原則・法則

Transcript

1. エンジニアの 原則・法則
 ～個人的見解を添えて～

2. 愚者は経験に学び、賢者は歴史に学ぶ
 ※ドイツの初代宰相ビスマルクの言葉とされる 
 

3. エンジニアにとっての歴史とは、
 先人が経験や失敗から導き出した法則

4. ①怠惰（Laziness） …効率や再利用性の重視
 ②短気（Impatience） …処理速度の追求
 ③傲慢（Hubris）…品質にかける自尊心
 
 【個人の見解】
 適用範囲を広めると下記のようにも捉えられる 
 ①怠惰 …無駄なタスクの削減
 ②短気 …コミュニケーションの効率化、ツールの活用 
 ③傲慢 …ドキュメント・成果物・製品の保守の継続 
 
 三大美徳を知らなくても大体上記のことは意識している人が多いかと思われる 
 個人的には傲慢さが不足しているので気をつけたい 
 【プログラマの三大美徳】

5. ①Keep it simple stupid.（シンプルで愚鈍にしろ） 　※Keep it simple, stupid.で「シンプルにしろ、バカめ」とも 
 ②Keep it short and simple.（簡潔で単純にしろ） 
 一般に①が原典とされる。
 設計の簡潔性を保つべきであり、不必要な複雑性は避けるべきという意 
 
 【個人の見解】
 ソフトウェアにおいてユーザー目線でもエンジニア目線でも重要 
 無駄に複雑なものは使いづらく、保守しづらく、使いまわしづらく、端的に言うとダサい 
 また、ドキュメントにおいても不要な装飾、書式設定（セル結合とか）は迷惑になりがち 
 
 【例外】
 考えつかない
 
 【類語】
 a. アインシュタイン　「何事もできるだけ単純なほうがいい。ただし単純にしすぎてはならない」 
 b. ダ・ヴィンチ　「単純であることは究極の洗練」 
 c. サン＝テグジュペリ　「完璧とは、これ以上加えられないときではなく、これ以上削り取れないときに達成されるようだ」 
 【KISS】

6. ①You ain’t gonna need it.（それ必要にならないって） 
 現時点でいらない機能は実装しない。必要になった時に考えろ、の意 
 
 【個人の見解】
 KISSの演繹的な原則
 では必要な機能は何か、はユーザー目線で分析・調査が必要 
 設計・実装をサボる言い訳にしてはならない 
 
 【例外】
 a. 「必要ではないが、あとから変更するにはコストがかかる部分」は先に着手すべき 
 b. 「必要な機能さえあれば設計・実装がスパゲティでいい」わけではない 
 
 【YAGNI】

7. ①Don’t repeat yourself. （同じことを重複させるな） 
 全ての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない 
 （邦題：「達人プログラマー」）
 
 【個人の見解】
 情報が重複していると、最新で正しい情報の参照先が分からなくなる 
 それにぜｔｔｔｔｔｔｔｔｔｔｔｔｔったい、直す時に漏れが発生する 
 また、単に「同じコードを書いてはいけない」というだけではなく、 
 ソフトウェア／プロジェクトで同一の情報を重複／分散させてはいけないという広い意味で、 
 例えばドキュメントのファイル名に日付をつけたり、「最終版」みたいに差分管理したりするのもよく非難される 
 
 【例外】
 a. 似た機能でも、分ける意味のあるコードやDBテーブルがある場合もある 
 b. 冗長性の確保
 【DRY】

8. ①遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ 
 a. 新たに投入された開発者が生産性の向上に貢献するまでには時間がかかる 
 b. 人員の投下は、チーム内のコミュニケーションコストを増大させる 
 c. タスクの分解可能性には限界がある 
 （邦題：「人月の神話」）
 
 【個人の見解】
 投入された人員への説明、教育、マネジメントで既存メンバーの負担が増加するのは理解しやすい 
 一方で、タスクの分解可能性（ある機能の実装は手分けしたところでかえって面倒になるなど）については、 開発に携わる既存メンバーでなければ分からないので、エンジニアが声をあげる必要がある 
 
 【例外】
 a. ドキュメントが整備されている、追加要員のスキルが高い、一度離れたメンバーの再追加、などコストが 比較的に低い場合は問題ない場合もある 
 【ブルックスの法則】

9. ①仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する 
 ②支出の額は、収入の額に達するまで膨張する　③拡大は複雑化を意味し、組織を腐敗させる 
 エンジニアリングにおいては①がよく引用される 
 
 【個人の見解】
 言うほどか？という法則
 夏休みの宿題を初日に終わらせる派にはあまり刺さらない法則 
 ただし、トム・デマルコ、ティモシー・リスターが著書「Peopleware」で「仕事にやりがいがない場合に発生する 法則」としており、エンジニアにその人が納得していない仕事を任せると発生しやすい感覚はある 
 
 【例外】
 a. エンジニアがエンジニアの仕事をしている時はあまり発生しないかも 
 b. 炎上しているとき
 
 【類語】
 a. ホフスタッターの法則　「いつでも予測以上の時間がかかるものである。たとえこの法則を計算に入れても」 
 【パーキンソンの法則】

10. ①ソフトウェアは、ハードウェアが高速化するより急速に低速化する 
 
 【個人の見解】
 昔家にあったWindows Meからマシンは圧倒的に進化しているのに、 
 今家にあるWindows 10はマシンほど速くはなっていない 
 先述のパーキンソンの法則を引用すると、「ソフトウェアが使うリソースは、マシンのすべてを使うまで膨張す る」のが原因の一つではないかと思う。 
 
 【類語】
 a. ムーアの法則　「集積回路におけるトランジスタの集積密度は、約18ヶ月ごとに倍になる」 
 b. ゲイツの法則　「ソフトウェアのスピードは18ヶ月で半分になる」 
 c. メイの法則　「ソフトウェアの効率は18ヶ月で半減し、ムーアの法則を相殺する」 
 【ヴィルトの法則】

11. 他の法則も読み物として
 調べてみると面白いので是非

12. さいごに

13. 【個人の見解】
 正直経験の方が簡単だし忘れづらいので有用 
 また、知識がある人よりは経験している人に仕事を任せたいことが多い 
 歴史（法則）からは効率的に学べるかもしれないが、 
 たくさん経験したほうがポートフォリオになるしなにより楽しい 
 
 【例外】
 a. エンジニア
 【愚者は経験に学び、賢者は歴史に学ぶ】
 タロットのアルカナ「愚者」
 正位置で「可能性・発想力・天才」の意味もある