エンジニアリングエッセイのススメ

Transcript

1. 2024/1/19 Nakaya Ryota エンジニアリングエッセイ のススメ
2. ギフティ入社：2019年1月 所属：技術本部 Distribution Section GiftExperience dev Unit 前職：バックオフィス系システムのパッケージベンダー (上流メイン) 言語：Go、Ruby、Java 分報：#times_nakaya 好きな4文字熟語：不労所得 自己紹介
3. 今日はおすすめのエンジニアリングエッセイを紹介します。 
 エッセイの定義はよくわからないです。 
 
 具体的な技術プラクティスではなく、エンジニアとしての働き方やマインドセットなどを中心に 書かれたものをエンジニアリングエッセイとしています。 

4. エンジニアリングエッセイを読むと... 
 • 具体的な技術プラクティスやノウハウが手に入るわけではない 
 一方で...
 • エンジニアとしてのマインドセット 
 • プロの思考プロセス 
 • 開発現場でのあるある 
 • 人間臭さ
 なんかが窺い知れたりして、自分の「働き方」に影響を与えてくれるかも...？ 

5. 読んで記憶に残っているものを何冊か紹介します 

7. • ソフトウェア開発の人月に関して書いた本
 • 有名な「銀の弾丸などない」「ブルックスの法則」
 • ソフトウェア開発の複雑性に関する内容がたくさん載っている
 人月の神話

8. • 見積もり技術は、人と月とが相互に交換可能だという過程を隠している
 • 人と月が交換可能になるのは、作業者の間でコミュニケーションを図らなくても仕事を 分担できる時だけである
 人月の神話　第2章 人月の神話

9. • 人を一人追加したとしても、ひと月で一人月分の作業が進むわけではない
 ◦ 要員追加時には教育・訓練のコストが発生する
 ◦ コミュニケーションコストも増える
 ◦ タスクの分解粒度も見直され、システム（結合）テストの工数も増える
 • 人月交換可能な見積もりに対してプロジェクトが遅延し、さらに人員を追加し、また遅れ ていく負のスパイラル
 • 遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけ （ブルックスの法則）
 人月の神話　第2章 人月の神話

10. • ハードウェアの分野ではエレクトロニクスやトランジスタ、LSI などで、生産性や信頼性 が大幅に改善された
 • ソフトウェアの領域ではそんな特効薬はなさそうに思える
 • ソフトウェアは本質的に複雑である
 人月の神話　第16章 銀の弾丸などない

11. • 本質的な複雑性と偶有的な複雑性を区別する
 ◦ 本質的な複雑性は、解決すべき問題によってもたらされるもの
 ▪ 取り除くことはできない
 ◦ 偶有的な複雑性は、目下の生産には付きまとうが、本来不必要な複雑性
 ▪ ソフトウェア開発者自身が発生させている解決可能な問題
 ▪ 例えば、クラス設計やハードウェアの性能などから生じる複雑性
 
 人月の神話　第16章 銀の弾丸などない

12. • ソフトウェアの基本的要素に含まれる固有の性質
 ◦ 複雑性
 ▪ どの二つの部分をとっても似通うことがないので、大きさの割に他のどの人工物よりも 複雑
 ▪ 夥しい数の要素と状態、組み合わせがある
 ◦ 同調性
 ▪ インターフェースを人間の社会制度やシステムへの適合を強要される
 ▪ 周りのものに従わされる運命にある
 ◦ 可変性
 ▪ 大当たりしたソフトウェアは大抵全て変更される
 ◦ 不可視性
 ▪ 目に見えないもので、具現化しようとすると一つの有向グラフでは無理
 
 人月の神話　第16章 銀の弾丸などない

13. • 本質的な複雑性は取り除くことができないが、改善はできる
 • 複雑性への対抗策
 ◦ 作るより買う
 ◦ 要件の洗練とラピッドプロトタイピング
 ◦ インクリメンタル開発
 ◦ 偉大なコンセプトデザイナーを育てる
 
 人月の神話　第16章 銀の弾丸などない

15. • ソフトウェア開発プロジェクトにおけるリアルで笑える（笑えない）エピ ソードが詰まった短編集
 • ソフトウェア開発における働き方や組織、生産性などに焦点を当てて いる
 • ソフトウェア開発で重要なのは技術よりも何よりも人
 ピープルウェア

16. • ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである
 • マネージャーの責務を果たす上で大事なのは人間中心に考えること
 ◦ しかし、これはいつも蔑ろにされがち
 ◦ なぜなら、人間同士の問題に対応するより、技術的問題を解消する方が簡単だから
 • どのように仕事するかは教えるが、どうマネジメントするかは教育しない企業が多い
 ピープルウェア　第1章 今日もどこかでトラブルが

17. • 作る側の品質理論は自尊心と強く結びついている
 ◦ プログラマを満足させる最低の基準は、今までに達成した最高の基準である
 ◦ この水準はマーケットが望み、金を払って手に入れようとするものよりずっと高い
 • ユーザーは品質ほど大事なものはないと言うが、それにお金を払う段になると品質について本当 はどう考えているかが明らかになる
 ◦ 「あと三週間あれば品質を高くできる」と聞いても、「いや三週間は待てない」という人がほ とんど
 • 早くリリースしろとせっつき、低品質の製品を受け入れてきたことを考えると、ユーザーの品質意 識はかなり低いことは明白である
 ピープルウェア　第4章 品質第一、時間さえ許せば

18. • 長期的には、市場に品質を合わせるとコストは増える
 • エンドユーザーの陽キュを遥かに超えた品質水準は、生産性をあげる一つの手段である
 • 「どの組織、文化、国家が、品質の高いことで有名か？」と問えば、ほとんどの人が日本と答える だろう
 • 「どの組織、文化、国家が、生産性の高いことで有名か？」と問えば、これもほとんどの人が日本 と答えるだろう
 • 高品質と高生産性は両立する
 ピープルウェア　第4章 品質第一、時間さえ許せば

19. • ヒステリックな楽観主義によるマネジメント
 • 部下が放っておいても組織の目標を受け入れると思うのは、未熟な楽観主義の表れ
 • 個人が組織の目標を引き受ける仕組みは遥かに複雑である
 ピープルウェア　第21章 全体は部分の和より大なり

20. • 上司であるあなたは組織の目標を心から受け入れているが、部下も同じとは限らない
 ◦ あなたの目標への情熱は単なるプロ意識を超えたところから生じている可能性 がある
 ◦ 自分の上司や経営者によって強固な動機付けをさせるための巧妙な仕掛けが 作られているかもしれない
 • しかし、平社員の動機付けはもっと複雑
 ◦ 宗教団体のような信仰でもなければ、組織の目標に対する自然な親しみを持つ ことを当てにできない
 ◦ 重役会が利益の大幅な増加で盛り上がっていても、平社員には増益などほん のつまらないものでしかない
 ピープルウェア　第21章 全体は部分の和より大なり

21. • チーム編成の目的は目標を達成することではなく、目標を一致させることである
 ◦ 方向性の一致は大きな力を生む
 • 結束する前は給料、地位、昇進ルートといったものが極めて大事だが、結束後はそん なものどうでもよくなり、退職率も下がる
 ピープルウェア　第21章 全体は部分の和より大なり

22. • 守りのマネジメント
 • 官僚主義
 • 作業場所の分散
 • 時間の分断
 • 製品の品質削減
 • ハッタリの納期
 • チーム解体の方針
 ピープルウェア　第23章 チーム殺し、7つの秘訣

24. • 伝説的な Lisp プログラマであり、Yコンビネーターの創設者でもある ポール・グレアムの自伝的エッセイ
 • オタクがモテない理由から未来のプログラミング言語、富の作り方まで 幅広く舌鋒鋭く書かれている
 ハッカーと画家

25. • ハッキングと絵を描くことにはたくさんの共通点がある
 ◦ ハッカーと画家はどちらもモノを創る人間
 • 偉大なソフトウェアも、同じように、美に対する熱狂的な没頭が必要だ
 ◦ 良いソフトウェアの中身をみてみれば、誰も見ないような箇所でさえ美しく創られている ことがわかるだろう
 ハッカーと画家　第2章 ハッカーと画家
 

26. • ハッキングには、絵を描く時と同じように、周期がある
 • ある時は新しいプロジェクトに夢中になって、1日16時間それをやり続ける
 • 別の時には何も面白いと感じられない
 ハッカーと画家　第2章 ハッカーと画家
 

27. • 絵画と同様、ソフトウェアも多くは人間が見て、使うもの
 ◦ だからハッカーも、画家と同じように、本当にすごい仕事を為すには、 共感する力が必 要
 ◦ ユーザの視点からものを見られるようにならなくちゃいけない
 ◦ 共感能力は、おそらく良いハッカーと偉大なハッカーの、 たった一つの最も重要な違い だろう
 ハッカーと画家　第2章 ハッカーと画家
 

28. • ソフトウェアビジネスは極めて競争の激しい業界
 • ある会社が他の会社より、他が同じ条件で、より良いソフトウェアをより速く書いたとしたら、他 の会社はいずれ潰れる
 ハッカーと画家　第12章 普通のやつらの上を行け
 

29. • ベンチャーは他のベンチャーと同じことをやっていてはいけない
 • 私たちは Lisp を選んだ。一つには、このマーケットで素早く開発することが重要だというのが 明らかだったからだ
 ◦ Lisp はソフトウェアを素早く書くのに良い言語だ
 ◦ 他の会社が Lisp を使いたがらなければ、それは良いことだった
 • Lisp のおかげで私たちの開発サイクルは非常に速く、相手がプレスリリースを出した1日2日 後にはもう同様の機能を作ったこともしばしばある
 ハッカーと画家　第12章 普通のやつらの上を行け
 

30. • ほかの多くの分野でも同じだが、プログラミングでも、難しいのは問題を解くことではなく、どの 問題を解くかを決めることだ
 • 想像力を測るのは難しい
 ◦ しかし、現実にはそれはコードの行数で測られるような生産性を遥かに凌駕するだろう
 • 技術は生産性の差を拡大する
 ハッカーと画家　第16章 素晴らしきハッカー
 

31. • ポールグレアムのエッセイ和訳一覧
 • https://practical-scheme.net/wiliki/wiliki.cgi?naoya_t%3A%E3%83%9D%E3%83%BC%E3%83%AB% E3%83%BB%E3%82%B0%E3%83%AC%E3%82%A2%E3%83%A0%E3%81%AE%E3%82%A8%E3%83%83%E 3%82%BB%E3%82%A4%E3%81%A8%E5%92%8C%E8%A8%B3%E4%B8%80%E8%A6%A7
 
 ハッカーと画家　余談

33. • 様々なプログラマによる短編エッセイ
 • コーディングから仕事のやり方まで色んな切り口の話が読める
 • 一個一個が短いので気軽に気になった章だけ読むとかもできる
 • 日本語版ではさらに日本人プログラマによる書き下ろしが追加で10本 収録されている
 ◦ Matzも寄稿している
 
 プログラマが知るべき97のこと

34. • 大学を出たてで、自分の能力を証明したくてしょうがなかった頃
 • 初めて仕事を任された時、担当部分の作業にこれまで自分の学んできたことをどうしても実践 してみたくなった
 • 内容が似通っているコードを出来るだけライブラリ化してみた
 • しかし、意気揚々と臨んだコードレビューでそれが失敗だったことを思い知らされる
 • コードをライブラリ化してしまったことで、それを利用する部分には依存関係が発生
 • ライブラリのコードを1行変更しただけで、その影響は複数箇所に及ぶ
 プログラマが知るべき97のこと　共有は慎重に
 

35. • 考えた結果わかったのは、「コンテキスト」が大事ということ
 • システム内に同様の処理を行う部分が2つあったとしても、それらのシステムにおける役割が 大きく異なっていれば、再利用によるメリットは小さい
 • たとえコードが4行ほどのもので、行っていることが同じだったとしても、それはたまたま一時的 にそうなっていただけのこと
 • 再利用は基本的に良いことだが、システム全体の構造がわかるまでは共有は慎重に行う
 プログラマが知るべき97のこと　共有は慎重に
 

36. • 良いコードは何の根拠もなく勝手に生まれたりはしない
 • 良いコードを書きたいと心の底から願い、努力をした人だけが本当に良いコードを書ける
 プログラマが知るべき97のこと　良いプログラマになるには
 

37. • ただ技術が優れているというだけでは良いコードは書けない
 • 素晴らしいアルゴリズムを考え出せる知性を持ち、プログラミング言語についての知識も十分 なプログラマが、実にひどいコードを書くというのは珍しくない
 • 反対に、能力は平凡でも、シンプルなコードを書こうと細心の注意を払った結果、美しく、わか りやすいコードができあがったという例がたくさんある
 プログラマが知るべき97のこと　良いプログラマになるには
 

38. • 良いプログラマとそうでないプログラマの最大の違いは「取り組む姿勢」にある
 • 良いプログラマの姿勢は、プロフェッショナルという言葉にふさわしいもの
 ◦ 常に、最大限の力を尽くして良いコードを書こうとする
 ◦ リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それで もできる限り良いコードを書こうと努力をする
 プログラマが知るべき97のこと　良いプログラマになるには
 

39. • 良いプログラマになりたいのなら、常に次のことを心がける必要がある
 ◦ どんな場合でも、「とりあえず動きそう」というだけのコードは決して書かない
 ◦ わかりやすいコード(どういうコードなのか、何をするコードなのか、他人が見てすぐに わかるコード)、保守しやすいコード(自分自身や、他のプログラマが、将来、簡単に修 正を加えることができるコード)、正しいコード(単に見かけ上、動くだけでなく、問題を間 違いなく解決できるコード)を書く
 ◦ 他のプログラマと協調する
 ◦ 自分が扱ったコードは、必ず、自分が最初に見た時よりも少しでも良いコードにする
 ◦ 絶えず積極的に新しい言語、イディオム、テクニックを学ぶ。ただし、学んだことをむや みには使わない
 プログラマが知るべき97のこと　良いプログラマになるには
 

40. • ネットで全部読める
 • https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/
 プログラマが知るべき97のこと　余談
 

42. • プログラマでありミュージシャンでもあるチャド・ファウラーのエッセイ
 • プログラマとしての生き様について書いた本
 • プログラマとしてどのようにキャリアを築いていくかや、ビジネスへの理 解の大切さを教えてくれる
 情熱プログラマー

43. • 一番の下手くそでいよう
 ◦ 自分より優れた人たちがいるチームで働く
 • GitHub に専念するためにマイクロソフトの30万ドルの仕事を断った
 ◦ 振り返って「確かにあれは安全だった」と思うより「あれは冒険だった」と思える方がい い
 • 愛せよ、さもなくば捨てよ
 ◦ 向上するには、情熱が必要
 ◦ やっている仕事に情熱を持てるかどうかがパフォーマンスに影響する
 情熱プログラマー　第1章 市場を選ぶ
 

44. • すでに時代遅れである
 • 僕らがIT業界に引き寄せられるのは、常に変化があるから
 • その反面、手に入れた技術がすぐに陳腐化する
 • 一生安泰な技術はない
 • その技術が主流に近くなればなるほど、技術の石器時代に取り残されるリスクが大きくなる
 
 情熱プログラマー　第5章 研鑽を怠らない
 

45. • 全てはタイミング
 • 今何を勉強するべきか先取りして考える
 • どの知識に投資するかはある意味ギャンブルではあるが、賭けなければ確実に負ける
 • 選択をミスすると将来の仕事確保に繋がらないスキルをせっせと学ぶことになる
 • 将来のことをよく考えてギャンブルに乗り出す
 情熱プログラマー　第5章 研鑽を怠らない
 

46. • るびまのチャドファウラーインタビュー • https://magazine.rubyist.net/articles/0033/0033-ChadFowlerOnRuby.html
 
 
 情熱プログラマー　余談
 

47. 終わりに
 自分に刺さる一節に出会うのはすごい価値がある。 
 エンジニアとしての働き方に悩んだらエッセイを読んでみよう！