「人月の神話」を読んだ

本の基本情報

本の基本情報について紹介する。

• 著者名：Jr. ブルックス,フレデリック・P
• 書籍名：人月の神話[新装版]―狼人間を撃つ銀の弾はない
• 出版社：アジソンウェスレイパブリッシャーズジャパン
• 発売日：2002/11/15
• 頁　数：321ページ

本の目次

以下は本書の目次です。

• 第1章　タール沼
• 第2章　人月の神話
• 第3章　外科手術チーム
• 第4章　貴族政治、民主政治、そしてシステムデザイン
• 第5章　セカンドシステム症候群
• 第6章　命令を伝える
• 第7章　バベルの塔は、なぜ失敗に終わったのか
• 第8章　予告宣言する
• 第9章　五ポンド袋に詰め込んだ十ポンド
• 第10章　文書の前提
• 第11章　一つは捨て石にするつもりで
• 第12章　切れ味のいい道具
• 第13章　全体と部分
• 第14章　破局を生み出すこと
• 第15章　もう一つの顔
• 第16章　銀の弾などない　ーー本質と偶有
• 第17章　「銀の弾などない」再発射
• 第18章　「人月の神話」の命題　ーー真か偽か
• 第19章　「人月の神話」から二十年を経て

概要

1975年に書かれた本だが、今でも読まれているバイブル的な本。

正直、下の記事によく纏められている（長いけど..）

www.gixo.jp

なので概要と自分の思ったことをさらっと書いていく

第1章　タール沼

• 個人使用目的で書かれたコンポーネントプログラム → 3倍 → 製品化
• 個人使用目的で書かれたコンポーネントプログラム → 3倍 → 各コンポーネントをデザイン・統合化・テスト
• 個人使用目的で書かれたコンポーネントプログラム → 9倍 → プログラミングシステム製品

個人で作られたものが、企業で作られた奴より何倍も早く完成したという話があるが、実際に企業のプログラミングシステム製品にするには約9倍の労力がかかる。 これを忘れて見積もると大変なことになる。

タール沼については、プログラムを作ることは喜びもあるが、沼のような苦しみもあるぞということだと解釈した。

第2章　人月の神話

「人」と「月」は交換できない。人が増えるほど、コミュニケーションの労力をもたらし一人当たりの進捗は遅くなる。

著者の目安では、全体の半分がテストに充てられる。現在は、CI/CDやテスト駆動開発などでてきてマシにはなったものの、概ね当たっていると思う。

第3章　外科手術チーム

非常に優秀なプログラマは、経験二年目の人の何十倍の生産性をもつ。 外科手術チームのように、1人の優秀な執刀医（プログラマ）を支えるようにしてプロジェクトを進めるのが良いという話。

これは古い話なので参考にしなくても良いかなと感じた。（別の書籍の方で勉強しよう！アジャイルなど...）

第4章　貴族政治、民主政治、そしてシステムデザイン

コンセプトの完全性こそ、システムデザインにおいて最も重要な考慮点と主張している。

これは綿密にドメイン設計をすることが重要ということと解釈した。1975年でもドメインに焦点が当てられており、やるべきことはドメイン駆動設計だなと感じた。

第5章　セカンドシステム症候群

セカンドシステム症候群とは、MVPの後、二度目の開発（セカンドシステム）のデザインしすぎてしまう傾向がある。

MVP（Minimum Viable Produc）という名前は出していないが、MVP出した次のフェーズで開発しすぎてしまう問題を指摘している。 提案された改善点を率先して受け入れるためにも、変更容易性が大事とも書かれている。これにより自分の目指すべきは、やはり設計だなとも感じた。

第6章　命令を伝える

この章は設計書の話が主だった。内容が難しく、古さを感じるので参考にしなくてよさそう。

第7章　バベルの塔は、なぜ失敗に終わったのか

バベルの塔の失敗した原因は、コミュニケーションとそれから生まれる組織がなかったため。 チームは可能な限り多くの方法で互いにコミュニケーションを図るべきだ。つまり、非公式の会話や技術的な概要報告を行う定期的なプロジェクトミーティング、共用の正式なプロジェクト手引書などを通してだと主張している。

この本の時代はウォータフォールでの開発ではあるが、頻繁にコミュニケーションをとることはアジャイルじゃなくても必要なんだと再認識した。（当たり前だが、できていないので...）

この章で組織についての話は面白かった。 組織の目的は、必要になるコミュニケーションと調整作業の量を減らすことだ（中略）。 コミュニケーションを不要にする手段は、作業の分割と機能の専門化である。

自分は大企業にいて入社した時からもちろん組織・チームに分かれていた。 この分かれている目的を特に意識していなかったが、必要になるコミュニケーションを減らすことと考えると色々と組織構造に変だと思う部分があったり、無駄にコミュニケーションを増やしているケースなども見受けられたりする。 なので、これから先いかに他部署とのコミュニケーションを減らしてプロジェクトを進めていけるかなどの指針となりそうだ。

第8章　予告宣言する

コーディングの部分だけから見積もり、それからそれぞれ2章で出ていた比率を適用し、全体の作業を見積もるということは決してしないと誓う必要がある。 コーディングはせいぜい6分の1に過ぎないから。

• 投下工数の半分くらいは、プログラミングやデバッグ”以外”の作業に費やされる（書類作成や打ち合わせなど）
• 他者とのコミュニケーションが発生しないとしても、プログラムの規模に応じて、必要工数は累乗で増加する
• 相互作用（≒コミュニケーションの必要性）があると、プログラマの生産性は簡単に1/7くらいまで落ちてしまう

上記のような話があった。実際に体感とあっているので、工数を見積もる際には多めにバッファを用意しておく必要があると感じた。

第9章　五ポンド袋に詰め込んだ十ポンド

タイトルの意味は、金額にだけ気を取られるのではなく、それが「何をしてくれるものなのか」ということも併せて考えなくてはならない。つまり、それまでかけたお金と引き換えに、使い勝手やパフォーマンスがどれだけ得られるかということであり、このお金は他のアプリケーションに使ったほうが、もっと有効であったのではないだろうかということである。

自分たちで作らないで、他所から買うという選択もあるぞ！ということを言っている。 「トレードオフ」を理解し、何をどの程度優先するかという”考え方”が重要。そして、それに則った”意思決定（をするという姿勢）”が大切。もちろん、世の中には様々な選択肢があり、さらに厄介なことに、似たようなシチュエーションであっても、実際には、都度都度、微細な条件が変化している。そんな中で「どのように考え、どのように意思決定するか」ということが、物事を正しい方向に進ませるためには欠かせない。

第10章　文書の前提

文書を書く意味について語っている。

以下は、第15回：メモリが安くなったからといって「無限」だとは思わない方が良い｜本気で読み解く”人月の神話”（第9章「5ポンド袋に詰め込んだ10ポンド」） - GiXo Ltd.　の引用。

大抵の場合、その経験則に従って行動すれば物事はうまくいきます。ただ、その経験則も「きちんとデータで検証されるべき」であったり、「最新情報に更新されるべき」であったりすると思うのです。 勘と経験が悪いのではありません。勘と経験を最新化しないことが問題なのです。そしてそれは、現場を離れて管理職・経営者となった後には「データを用いて最新化するしか選択肢がない」のです。本章で論じられた3つのシチュエーションには含まれていませんが、「経営」というシチュエーションにおける「文書」には経営分析レポート・事業分析レポートなどが含まれていてしかるべきだ、ということになるでしょうね。

文書化により、自分の思考（また、他のメンバーの知識）をアップデートすることが目的。記憶なんて、ほとんど忘れてしまうからね...

第11章　一つは捨て石にするつもりで

この章は、19章（20年後）で、間違っていたと言っているので、参考にしなくて良い。

第12章　切れ味のいい道具

プロジェクトの共通ツールを作ることは良いことだ。プログラマ個人用のツールは、各個が違うツールを使うことによりコミュニケーションの妨げになるので、汎用的なツールは共同で開発・メンテナンスするのが効率的。

後半は、古い話で参考にならなそうだった。チームのツール（botや自動生成など）を作るのは、やっていきたい。

第13章　全体と部分

多くのバグはサブシステム間のデータの受け渡しに関するもの。製品のコンセプト（サブシステム間のインタフェースや受け渡されるデータ構造の設計指針をシステムとして統一する)をはっきりさせることにより、サブシステム間のデータの受け渡しに関するバグを減らすことができる。あとは、デバッグのためにダミーを作るなどの話をしている。

古い話も多かったが、今でも話の内容は間違っていないと感じる。上の話があるので、マイクロサービスやAWS Lambdaなどのサーバレスアプリケーションが流行っているのだと理解した。

第14章　破局を生み出すこと

• プロジェクトは突発的な不運が起こって遅れているわけではない、一日ごとに徐々に遅れている
• マイルストーンは具体的かつ明確で測定可能なイベントとして定義しなければならない。そして、進捗をごまかしてはならない
• スケジュールは直前になるまで変更されないのがほとんどである
• ハッスルプレイ（求められている以上に速く走ったり、機敏に動いたり、一生懸命になるといったもの＝一日の遅れにもやっきになる）は、プログラミングチームにも必要不可欠だ。
• クリティカルパススケジューリングが、どの遅延がどのくらい問題なのか理解するのに役立つ

もちろん遅延は起こるものです。しかし、それは「まあいいや」ではなく、「起こるべからざることが起こっている」という認識で、周囲に共有され、必要に応じ、然るべき対策が講じられるべきなのです。 というわけで、大事なのは「遅延を隠さない」ということです。

上の話は肝に銘じたい。「風通しの良い組織」を作ることが、情報隠匿を排除し、結果的に、致命的な遅延を防ぐことに繋がるのだろう。

第15章　もう一つの顔

プログラムには、機械に対する命令の羅列という顔の他に、人間が理解するためのドキュメントとしての顔がある。

kotsutsumi.hatenablog.com

上の書籍では、コードを文書化するという話があった。あんまり納得はできなかったが、アリなのかもな。という気になってきた。

第16章　銀の弾などない　ーー本質と偶有

ソフトウェア開発における「むずかしさ」は、本質的なものと偶有的なものに分けられる、とブルックス氏は述べる。

• 本質的なむずかしさとは、ソフトウェア開発に固有のものです。
  • 複雑性（ややこしい）
    • ソフトウェアの大きさに従って、非線形に複雑性が増加する
    • これにより、問題が多発する
  • 同調性（他と合わせる必要がある）
    • 他のインターフェースに従うことにより、複雑性は増加する
  • 可変性（常に変化することが求められる）
    • 絶えず変化し続けるもの。その変化がソフトウェアに変更を強制する。
  • 不可視性（リアルなものとして捉えられない
    • ソフトウェアは目には見えない。
• 偶有的なむずかしさとは、事象としては実際に難しいものの、別にソフトウェア開発だから難しいってわけではない、というような事象です。 これは、ソフトウェア開発の歴史の中で、少しずつ解決されてきました。（もちろん、この”偶有的むずかしさ”さえも、まだ完全に解決していないが故に「銀の弾がない」という結論に至っているわけですが）
• その解決の歴史として3つ述べられている
  • 高水準言語（機械語からの脱却による”概念”の世界でのプログラミングの実現）
  • タイムシェアリング（リアルタイム処理による”思考を妨げない”）
  • 統一されたプログラミング環境（統合ライブラリ等によって”概念構造体”としてプログラムを捉えることができるようになった）

現在は偶有的な難しさはどんどん解決されてきているので、本質的難しさに目を向けるべき。これは、ドメイン駆動設計やアジャイルの考え方が効いてくるのでは？と思った。

第17章　「銀の弾などない」再発射

第3回：反論に対する反論｜本気で読み解く"人月の神話"（第17章：前半） - GiXo Ltd.

第4回：再利用って口で言うほど簡単じゃないんだよね｜本気で読み解く"人月の神話"（第17章：後半） - GiXo Ltd.

この記事に書いてあることがほとんど書きたかったこと。その中でも良いところをピックアップする。

「インプリじゃなくて、設計段階・構想段階なんだよ、難しいのは」ってことです。「何を作るのか」が一番難しい、と。

偶有的（副次的）な問題が数多く解決されてきた今、本質的な問題に取り組むべきだ

• 複雑性（ややこしい）
• 同調性（他と合わせる必要がある）
• 可変性（常に変化することが求められる）
• 不可視性（リアルなものとして捉えられない

これはドメイン駆動設計でいうモデリングのこと。設計力をつける必要があると感じた。

第18章　「人月の神話」の命題　ーー真か偽か

ここは各章のまとめが書かれている。初めて読む人は、この章から読むことで大体の話を掴むことができるので、最初に読むのが良いだろう。

第19章　「人月の神話」から二十年を経て

• 正しかったのは、以下がが挙げられます。

  • コンセプトの完全性が成功の鍵であること
  • その、コンセプトをしっかりと構築するために、アーキテクトを任命し、アーキテクチャとインプリメンテーションを分離すること
  • セカンドシステム症候群、すなわち、「後継システムの開発」には、大きなリスクがあること
  • そして、もっとも重要な命題である「人月の神話」は、やはり神話であったこと
    • 新たな要員を追加すると、キャッチアップに数週間の時間を要することから、「要員を追加しても、納期短縮にはつながらない」と述べます。もちろん、「遅延しているプロジェクトにさらに要員を追加することは、つねにコストがより高くつくことにはなるが、完了をつねに遅らせるわけではない」という話は持ち出すものの、そのためには「プロジェクトの初期段階で要員を追加するべき」と述べています。

• 一方、自己反省として、正しくなかったこととして挙げられるのは、以下です

  • 一つは捨石にする、という発想（前提としていたウォーターフォール型開発そのものに限界があったため）
    • 少しずつ加えていく改良（漸増的構築）が良い
  • 情報公開・共有こそ是である、という考え方（カプセル化は非常に有効だと分かったため）
    • パッケージソフトは、すでにテストされており、詳細なドキュメントが添付された上に、完全に「情報隠匿」もなされています。再利用性という意味で「完璧」です。「つくらなくていいものは、つくらない」「すでにあるものは、そのままつかう」という基本思想に基づけば、パッケージソフトこそ、生産性向上の鍵です。

最後に

ドメイン駆動設計のようにドメインの複雑さをいかに分かりやすくするかが肝になってくると感じた。

つまり、設計の重要性をより一層感じることができ、ドメイン駆動設計の有用性がわかった。

今後やっていくべきは、ソフトウェア問題の本質（複雑性、不可視性、同調性、可変性）に取り組むこと。ドメイン駆動設計が解決できると思うので、実際に手を動かしてみる。

20代はお金を使おう

  自分は25才だ。大企業で働いており、それなりに貯金している。貯金をして将来に備えることが正解だと思っていた。しかし、最近その考えを改め直した。

前提として自分はドケチである。どれほどかと言うと、ラーメンのトッピングはケチるし、コンビニは無駄なもの買いそうだから行きたくないし、10円でも安いもの買いたい。 そして、積立NISAもしているし、自社株も買っているし、財形貯蓄もしている。 つまり、必要以上にお金を使っていない状態である。

今までなんとなく、将来お金はあればあるだけ困らないしな、みたいな感覚で特に具体的な目的もなくお金を貯めてきました。 しかし、ふと今の楽しみを犠牲にしてるなと思った。 お金があることで幸せにはなれず、しっかり使わなければ幸福感を感じられないのではないか。 このまま、貯め続けて40歳になったとき、このお金によって「安心できる未来」が本当に待っている？ 40まで仕事をしていれば、それなりのスキルとキャリアを手にしているだろうし、今よりも稼いでいることは想像がつく。 そんなとき、20代のころの貯金を見て、その頃は大金に思えていたけれど簡単に稼げる額になっているだろう。 退職後の生活などに気にかけて人生を歩んでいるなら、今すぐやめたほうがいい。 自分のお金を楽しむ贅沢ができないなら、稼ぐ意味はもうないんじゃないか？ これまでできなかった経験や、会えなかった人たちと出会えるほうが、むしろ未来の財産になっていたはず。 きっと、若さを楽しめなかったことを悔やむのが想像つく。 「過去の自分は、未来について気にし過ぎていた」そう気づくには、あまりにも遅すぎる。

しかし、自分を飾り立てるためにブランド物を買うのは違うとも思う。 先ほどあげたように、これまでできなかった経験や、会えなかった人たちと出会うなど、経験にお金を使うのが良いと思う。 同じ海外旅行でも 10代、20代、30代 、40代では全く感覚が違う。 経験にお金を使うべきだ。これも自己投資と言えるだろう。   貯金をするなと言っているわけでは無い。自分のように必要以上にお金は貯める必要はないと言いたい。 これからも、積立NISA、自社株、財形貯蓄はやめるつもりはない。 これらの投資で十分貯蓄できているので、他のお金は経験や本など自己投資、また自分の好きな物に使おう。 そう考えた。なので、Canonのミラーレスカメラ RPを買います！！

「転職と副業のかけ算」を読んだ

本の基本情報

本の基本情報について紹介する。

• 著者名：moto(戸塚俊介)
• 書籍名：転職と副業のかけ算 生涯年収を最大化する生き方
• 出版社：扶桑社
• 発売日：2019/8/9
• 頁　数：239ページ

本の目次

以下は本書の目次です。

• 序章 「個人で稼ぐ」サラリーマンが本当の安定を手に入れる時代
• 第1章 年収240万円の地方ホームセンターを選んだ理由
• 第2章 地方ホームセンターやリクルートで学んだ「成果」に繋がる働き方
• 第3章 4度の転職で年収を上げ続けた「転職術」
• 第4章 本業を活かして稼ぐ「サラリーマンの副業」
• 第5章 生涯年収を最大化する生き方

概要

序章 「個人で稼ぐ」サラリーマンが本当の安定を手に入れる時代

大企業でもリストラが敢行されており終身雇用がなくなるなど、働き方、子育て、教育など全てに"正解"がなくなった現代社会を生き抜くためには「個人で稼ぐ力を持つ」必要がある。 そのためにも企業に依存しない生き方。つまり、いつでも乗り換えられる状態にしておくことが大切。

所属している企業特有の技術に依存してしまっては、別の企業に行ったときに使い物にならないことがある。市場価値を

第1章 年収240万円の地方ホームセンターを選んだ理由

この章はmotoさんが地方ホームセンターを選ぶまでの考えが書かれており、普通の人では選択しないような行動の背景が書かれており新鮮だった。

• 「トップにアプローチする」という考え方
• 自分がやるべきことが””解像度高く”描けるか

この二つは自分でも出来ることなので、挑戦していきたい。

第2章 地方ホームセンターやリクルートで学んだ「成果」に繋がる働き方

年収を上げる転職には「今いる会社」で成果を出す ことが必要です。
特に 20 代のうちは、高い給料を追い求めるより「自分のスキル」を貯めたほうが長い目では大きな価値になります。 　
僕も行く先々の会社で成果を出すために頭と体に汗をかいて働いてきました。
その過程で得た経験や知見こそが、転職で年収を上げる大きな要素なのです。

機会を待つのではなく、機会を取りにいき、その機会に全力を尽くしたことが自分の経験値や成果に繋がる。

仕事に慣れてくると、どうしても〝すでにできる仕事〟ばかりをしがちになる。そうではなく、やったことのないことに挑戦する機会をもらい、そこで成果を出す。これが次のキャリアに進むうえで大切な姿勢だ。

「何をしても同じ給料なら、ムダに働かないほうがいい」という同期が多かったですが、
僕は「自分の経験値」を優先して働くことを意識し続け、 誰よりも「自分を成長させる機会」をもらう努力をした のです。
ホームセンターに入社した僕がまず取り組んだのは、「自分が目指す姿」や「やりたいこと」を周りの人に言い続けることです。

馬鹿にされても「自分が目指す姿」を伝えることが大事。疎まれる可能性もあるが、それでも一度宣言したらやり続ける、そうすると、段々と印象も変わってくる。

「リクルート事件があった当時、明日にも会社が潰れそうな状況で俺たちが採用したかったヤツは
『活躍できるエリート学生』とか『前職で優秀だったヤツ』なんかじゃない。
明日潰れるかもしれないリクルートという会社で、会社を潰さないために一生懸命努力できる人間だ。
そういうスタンスのある人間はどんな会社でも、活躍できる。
どこで働くかじゃない、自分のスタンスの問題だ」
大切なのはスキルじゃない。目の前のことに一生懸命になるとか、
絶対にやりきるという「考え方」や「姿勢（スタンス）」、「目線」なのだ、と。

組織を成長させられる人こそが、どこでも活躍できる人。自分が今の会社、事業部、チームに何が出来るのかを考えて、成長に貢献していくことが大切。

「自分という会社を経営する目線を持て」 　
僕はこの考え方を「自分株式会社」 と呼んでいます。 　
自分株式会社というのは、自分自身を会社に見立てて考える思考のことです。 　
僕が「株式会社ｍｏｔｏ」という会社を経営していて、売り上げは在籍している会社からの報酬と副業収入の５０００万円。
そこに家賃や食事代、通信費という経費がかかり、手元に残った金額が利益になる、という考え方

普通、経営者視点とは「会社の売り上げを伸ばす視点」を持ちながら「目の前の仕事の成果にこだわる」ことを指す。 motoさんは自分株式会社を経営する視点を持ちながら仕事をしている。この考え方は今からでも出来るし、自分事として見えるので実践している最中だ。

第3章 4度の転職で年収を上げ続けた「転職術」

自分の仕事を「わかりやすく」伝える能力が求められている

そのためには「全体像」を把握することです。
「今、自分の会社にはどんな課題があるか？」を説明する際にも
「そもそも、なぜそれが問題になっているのか？」という背景を伝えないと、相手には本意の２割も伝わらないからです。
背景まできっちり伝えるためには、自分が置かれた状況を「上流から下流まで」知っておく必要があります。

【業界の状況→会社の課題→部署の役割→自分のミッション】

と、広い視点で見る。そのうえで課題を把握し、解決策を考えて、自分で行動する。
この能力が、年収に比例して求められるようになります。

日々の業務では、自分の目の前の仕事で精一杯になってしまいがちですが、目の前にある木だけを見るのではなく、
その後ろにある森を見て、今度は遠くからそれが山であることを把握して、究極的には「山を見ている自分を、その隣で見ている状態」を目指す
と、今の仕事の捉え方も大きく変わります。そして、考えるだけでなく、行動してください。

エッセンシャル思考でもあるように、「本当に重要であるか？」「なぜ自分がやるのか？」を自分で考える必要がある。

この章では「市場価値」について多くのことが書かれている。その中で転職エージェントを活用する事例も挙げられている。 そこで、自分も転職エージェントに登録して自分が目指すべき年収に近づくにはどうすれば良いか聞いてみた。

自分は30歳で年収800万を狙っている。そのためには、どういう業界、仕事が良いのか回答が貰えた。 結論から言うと、年収800万目指すには、今からでもSIerなどで上流の仕事をこなす必要があると言われた。 また、コンサルを目指すのも良いと言われた。 しかし、自分の中での結論は、今の会社でキャリアアップを狙いつつ、副業をする方が現実的だと感じた。

こんな自分の話は置いといて、転職でのポイントを細かく書いてあった。ここは転職を考えている人にとっては非常に参考になるのではないかと思う。

第4章 本業を活かして稼ぐ「サラリーマンの副業」

「個のブランド化」や「時間を切り売りしない」や「本業や過去の経験をお金に換える」などの話があった。

以下の内容は、なるほどなと思った。

リクルートが展開している、ゼクシィ（恋愛・結婚）、リクナビ（就職・転職）、ＳＵＵＭＯ（賃貸・住宅購入）、
カーセンサー（車） などの領域は、人生における重要な意思決定シーンであるため、情報収集をする人が多いのです。
そしてリクルートはそのマッチングで稼ぎ、時価総額は６兆円を超えています。明らかにお金が動く分野なのです。 

しかも、この分野は「喉元すぎれば」という、情報過疎な領域です。
就活も転職も、家を買うのも結婚も、そのときはいろいろ考えますが、喉元をすぎて、自分が就職したり、転職できればそこで完結します。
「就活は、なんか大変だった気がする」と思い返すくらいで、その苦労を人の役に立つかたちで発信しないのです。
発信したとしても、ＳＮＳで「就職が決まりました」「転職しました」と報告する程度で、悩んだ経験やそこで得た知見は広く共有されません。
しかし、同じように苦労をして、情報を求めている人はたくさんいるのです。

自分もエンジニアで学ぶ上での知見を共有していきたいと感じた。

第5章 生涯年収を最大化する生き方

一時期、「サラリーマンという働き方は搾取されている、社畜にならないほうがいい」という風潮がありました。
しかし、個人的には、サラリーマンという形態が社畜なのではなく、働くうえでの「スタンス」が問題なのだと思っています。
いつまでも会社に依存している人は社畜かもしれませんが、会社に依存せず、
副業や社外活動を通じて活躍しているサラリーマンは、社畜ではありません。 　
逆に、フリーランスになっても、クライアントの言いなりになった仕事をしているようでは、社畜と変わりません。 
働く形態を問題視するのではなく、自分がどう働くかを議論の的に据えるべきです。

motoさんのサラリーマンやって、週二日は自分で好きな時間を過ごすことで、人とのつながりや社会との接点を持ち続けるという意見に凄く共感した。

本業で得た知見と副業で得た知見を相乗効果で自分の価値を高めていきたいと感じた。

最後に

正直ここまで出来る人は数少ないし、特に最初にホームセンターを選んだり短大を選ぶと言うのは、下手したら年収は低いままになってしまうので、再現性は低いと感じた。

しかし、著書であるmotoさんの考え方は、自分は全くしていなかったので感銘を受けた。motoさんの行動力を知れる本。自分もこれだけ考えて行動できるようになりたい。 自分は全く転職する気はなかったが、市場価値という視点を得られただけでもこの本を読む価値はあったかなと思った。

意識高い系みたいな、文章もまとまりなく、変になってしまいましたが、この本おすすめです。

「Webを支える技術」を読んだ

本の基本情報

本の基本情報について紹介する。

• 著者名：山本陽平
• 書籍名：Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS
• 出版社：技術評論社
• 発売日：2018/11/14
• 頁　数：641ページ

本の目次

以下は本書の目次です。

• 第1部 Web概論
  • 第1章　Webとは何か
  • 第2章　Webの歴史
  • 第3章　REST -- Webのアーキテクチャスタイル
• 第2部 URI
  • 第4章　URIの仕様
  • 第5章　URIの設計
• 第3部 HTTP
  • 第6章　HTTPの基本
  • 第7章　HTTPメソッド
  • 第8章　ステータスコード
  • 第9章　HTTPヘッダ
• 第4部 ハイパーメディアフォーマット
  • 第10章　HTML
  • 第11章　microformats
  • 第12章　Atom
  • 第13章　Atom Publishing Protocol
  • 第14章　JSON
• 第5部 Webサービスの設計
  • 第15章　読み取り専用のWebサービスの設計
  • 第16章　書き込み可能なWebサービスの設計
  • 第17章　リソースの設計

概要

第1部 Web概論

Webの基本的な知識や歴史があったのは、どういう経緯でRESTになっていったのかが知れて良かった。

自分はRESTは、GraphQL or RESTのようにAPIの取得の仕方の一種だと思っていた。しかし、RESTはアーキテクチャスタイルであることが理解できた。

RESTfulに設計されたAPIこそが自分が認識していたものだった。勘違いしている人も多いと思うので、ネットで調べてみることをオススメする。

第2部 URI

URIは URL + URN のこと。

URNはリソースにドメイン名とは別に独立した名前が付けられる。これによって、サーバーが何らかの障害で変更になったり、ドメインを更新してアクセスできなくなるという問題を解決した。 しかし、URLが永続的にアクセスできるようにするべきという考えが普及したため、URNを使うまでもないことが多くなり普及していない。

このことを自分は知らなかったので、勉強になり時代背景も知ることができた。 また、URI設計のテックニックの話などもあり、とても興味深かった。

ここでWeb開発者の言葉を。（書籍にも載っています）

「Cool URIs don't change (クールなURIは変わらない)」

URIは変わらないべきである。変わらないURIこそ最上のURIである。

つまり、いかにURIを変わりにくく設計するかが大事になってくる。肝に命じたい。

第3部 HTTP

HTTP/1.1までしか載っていない。現在は、HTTP/3なので少し内容は古い。 しかし、HTTP/1.1は現在でも使われているし、APIを使う際は変わらずHTTP/1.1なのである。

そのため、APIの使い分けからリクエスト・レスポンス、HTTPヘッダの内容はかなり詳しく書かれているので、とても勉強になった。 HTTPヘッダとかは自分は普段気にしたことがなかったが、ここで内部構造を知れたので今後に

特にHTTPメソッドの「べき等性と安全性」の話は参考になった。

第4部 ハイパーメディアフォーマット

HTMLやXML、JSONについては知識はあったが、microformats, Atomは何がなんだかわからなかった。

自分の趣味でやっている競技プログラミングで使われている拡張機能 Greasemonkey は microformats を利用していることがわかった。 しかし、新規にマイクロフォーマットを実装しようという話はほとんどないみたいだ。

Atomはブログなどの更新情報を配信するためのフィードとして知られているらしい（自分は全く知らなかった）

現在は、RSSの方が使われているのでATOMもそこまで使われていない(?)。情報ください。

qiita.com

第4部は、HTML, JSONだけ見れば良いのかという印象だった。

第5部 Webサービスの設計

読み取り専用のWebサービスの設計 (リソース指向アーキテクチャ)は以下の設計アプローチをとる

• Webサービスで提供するデータを特定する
• データをリソースに分ける

そして、各リソースに対して次の作業を行う。

• リソースにURIで名前をつける
• クライアントに提供するリソースの表現を設計する
• リンクとフォームを利用してリソース同士を結びつける
• イベントの標準的なコースを検討する
• エラーについて検討する

この章では、上の流れをもとに郵便番号リソースにXML, JSONのどちらを使うかなど解説をしているので参考になる。

書き込み可能のWebサービスの設計に関しても郵便番号リソースをもとに、CRUD操作、トランザクションの話など参考になる。

参考になるとしか書いていないが、本当に参考になる。

この書籍で何回も出てきたのが、「WebサービスとWeb APIを分けて考えない」ということだ。 リソース設計で最も重要な考え方である。

最後に

非常に読みやすく、スラスラ読めた。 組み込み開発からWeb開発になった自分でも知らない単語はちょくちょくあったものの、理解することができた。

とてもおすすめです。

「現場で役立つシステム設計の原則」を読んだ

本の基本情報

本の基本情報について紹介する。

• 著者名：増田 亨
• 書籍名：現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
• 出版社：技術評論社
• 発売日：2017/7/5
• 頁　数：422ページ

本の目次

以下は本書の目次です。

• Chapter1 小さくまとめてわかりやすくする
• Chapter2 場合分けのロジックを整理する
• Chapter3 業務ロジックをわかりやすく整理する
• Chapter4 ドメインモデルの考え方で設計する
• Chapter5 アプリケーション機能を組み立てる
• Chapter6 データベースの設計とドメインオブジェクト
• Chapter7 画面とドメインオブジェクトの設計を連動させる
• Chapter8 アプリケーション間の連携
• Chapter9 オブジェクト指向の開発プロセス
• Chapter10 オブジェクト指向設計の学び方と教え方

概要

Chapter1 小さくまとめてわかりやすくする

タイトル通り、小さくまとめてわかりやすくするためのテクニックが紹介されている。

この章のテクニックは、マーチンファウラーの「リファクタリング」にも書かれているものが多いので、知っている人もいるだろう。 改めて、今回復習することができた。特にオブジェクトは、自分も含めて作らない人（知らない人）が多いと思う。 自分はC言語とC++をメインに使ってきたので、毎回インスタンスを返す考えがなかった。（ガベージコレクションがない = newしたらdeleteしないといけないため） 今後、PythonやJavaを使っていくことになりそうなので、これを知れるだけでもこの本を読む価値があった。

コレクションオブジェクト/ファーストクラスコレクションは、初めて聞いた。コレクション操作の結果を同じ型のコレクションオブジェクトを作って返すことは、ガベージコレクションがない言語を使ってきた自分にとっては、違和感しかなかった。 しかし、不変にするという考え方を知る/知らないでクラス設計に大きく差ができるとも感じた。早いうちに知ることができてよかった。

Chapter2 場合分けのロジックを整理する

ガード節などでelse節を無くす、ポリモーフィズムでif/switch分を無くすなどの話は、有名なので知っていた。

しかし、Javaのenumで状態遷移をうまく表現できる話は全く知らなかった。Java使う人には参考になるだろうが、他の言語使う人はできるか怪しい内容。

Chapter3 業務ロジックをわかりやすく整理する

Chapter2まではオブジェクト指向のテクニックが多かったが、この章辺りからドメイン駆動設計という言葉は出ていないけれど考え方を説明している。

３層アーキテクチャ（プレゼンテーション層、アプリケーション層、データソース層）＋ドメイン（業務ロジック）で関心事を分かりやすく分離しようといった内容を説明している。

Chapter4 ドメインモデルの考え方で設計する

ドメイン駆動設計を基に、ドメインモデルをどう設計するか説明している。

• 小さい部品（機能分割して定義した下位クラス）から作っていき、それを業務ロジックと合わせて組み合わせていく
• コト（予約、注文、支払、出荷などの事象）に注目して関係を整理する
• 業務の理解がドメインモデルを洗練させる

上記あたりは参考になった。特に、自分はモデリングがうまくできないので、コトに注目するという具体例があったのは良かった。

しかし、実際に手を動かして作ってはいないので、自分で作ってみて自分の中に落とし込む必要があると感じた。

Chapter5 アプリケーション機能を組み立てる

アプリケーション層の説明。アプリケーション層に業務ロジックを書いてしまいがちだが、アプリケーション層の役割は進行役であり調整役。

さまざまな関心事の交差点になり、ごちゃごちゃしやすい。逆に言えば、アプリケーション層をシンプルに保つことで、システム全体が見通しが良くなり、変更のやりやすさにつながる。

Chapter6 データベースの設計とドメインオブジェクト

データソース層の話。データベースについて自分はあまり詳しくないので、ここはかなり難しかった。

良いテーブル設計の話があるが、まずテーブル設計をしたことがないので、実際にデータベース弄るようになったらもう一度読み直したい。

Chapter7 画面とドメインオブジェクトの設計を連動させる

プレゼンテーション層の話。画面と一致させるという話が多かった印象。

画面の関心事を小さく分けて独立させるなど参考になる部分は多かった。 自分はVue.jsでフロントを描くことが多いが、.vueファイルに業務ロジックを書くことが多かった。 今後、業務ロジックは分離させてドメインである.jsファイルからインポートさせていくのが良いんだなと理解した。

Chapter8 アプリケーション間の連携

WebAPIも小さくした方が利用しやすい。 他にもWebAPIのなぜPUTやDELETEではなく、GET, POSTを使った方が良いの説明などもあった。

Chapter9 オブジェクト指向の開発プロセス

ドメインモデルのソースコードには、業務の用語、業務の知識を反映しているので、分析と設計が一致していればドキュメントは不要という話が印象的だった。ドキュメント不要論に関しては自分は懐疑的だが、確かに無駄と思う部分も多い。

著者も全部不要と言っているわけではなく、「利用者向けのドキュメント」「画面や帳票」「データベースのテーブル名/カラム名とコメント」

また、全体を俯瞰するドキュメントとして、「システム企画書やプロジェクト計画書のシステム概要説明」「プレスリリース」「リリースノート」「利用者ガイドの導入部」は必要と言っている。

いかにコードに書いていない情報を共有するのかが重要になってくると感じた。

Chapter10 オブジェクト指向設計の学び方と教え方

おすすめの書籍がいくつか紹介されている。

紹介されているマーチンファウラーの「リファクタリング」は、自分も読んだことがあり、評価も高いのでおすすめです。

最後に

Javaで書かれていると言われてたので、ちょっと抵抗があったがコードもそんなに多くなく、オブジェクト指向入門しているレベルの人なら理解できると思う。 コードは補足であり、本文で十分理解できる内容だった。

chapter7のドキュメントは不要というのには懐疑的だが、全体的に参考になるし、DDD(ドメイン駆動設計)の入門書として良い本だった。 自分はドメイン駆動設計を先に読んでいたが、難しく理解できない部分も分かりやすく説明されていた。 しかし、自分の中に落とし込めていないところも多くあるので、そこは実践を通して身につけていく必要があると感じた。

自分がいかにドメイン駆動設計をしても、他の人が崩してしまっては全く意味がなくなるので、ドメインモデル設計の共有が一番難しいと感じた。 業務後に勉強する人は数少ないので、議論を重ねて知識を共有する必要がある。そのためにはドキュメントが必要な気がしている。

---

P.S.

新しく作る時はドメイン駆動設計を導入しやすいが、業務の多くはすでに出来上がっているシステムの機能開発がメインである。 すでに規模が大きくなっているので、途中からドメイン駆動設計の考えをチームメンバーに共有して、地道に改良していくのはなかなか大変だなと思っている。

どうすれば良いのか、参考になる事例があれば教えて欲しいです。

「サピエンス全史」を読んだ

本の基本情報

本の基本情報について紹介する。

• 著者名：ユヴァル・ノア・ハラリ
• 翻訳者： 柴田裕之
• 書籍名：サピエンス全史 文明の構造と人類の幸福
• 出版社：河出書房新社
• 発売日：2016/9/16
• 頁　数：585ページ

本の目次

以下は本書の目次です。

• 第1部 認知革命
  • 第1章　唯一生き延びた人類種
  • 第2章　虚構が協力を可能にした
  • 第3章　狩猟採取民の豊かな暮らし
  • 第4章　史上最も危険な種
• 第2部 農業革命
  • 第5章　農耕がもたらした繁栄と悲劇
  • 第6章　神話による社会の拡大
  • 第7章　書記体系の発明
  • 第8章　想像上のヒエラルキーと差別
• 第3部 人類の統一
  • 第9章　統一へと向かう世界
  • 第10章　最強の征服者、貨幣
  • 第11章　グローバル化を進める帝国のビジョン
  • 第12章　宗教という超人間的秩序
  • 第13章　歴史の必然と謎めいた選択
• 第4部 科学革命
  • 第14章　無知の発見と近代科学の成立
  • 第15章　科学と帝国の融合
  • 第16章　拡大するパイという資本主義のマジック
  • 第17章　産業の推進力
  • 第18章　国家と市場経済がもたらした世界平和
  • 第19章　文明は人間を幸福にしたのか
  • 第20章　超ホモ・サピエンスの時代へ
• あとがき -- 神になった動物

概要

第1部 認知革命

サピエンスは、虚構によって見知らぬ人同士が協力し、他の人類種を圧倒し滅ぼしたのではないかという話。

サピエンスのすごいところは、虚構は変えることで行動パターンも変化することができた。信じていたものをすぐに切り替えることができたことだ。

自分たちは虚構を意識せずに使っているが、他の動物は「敵が来た」などのコミュニケーションは取れるものの、虚構というものは存在しない。 この後の章でも出てくるが、現在でも虚構を信じることで人々が協力できているというのは、自分は考えてもいなかったので、ハッとさせられた。

第2部 農業革命

農業革命によって人類は爆発的に増えた。 しかし、狩猟採集社会の時と比べて、労働の長期化や栄養失調、感染症などの苦しみも与えた。

人類が爆発的に増えたことで、集団維持のため虚構による「想像上の秩序」と「書記体系」が発明された。

自分は、農業革命の食料が増えたという良い面しか知らなかったので、かなり悪い面も数多くあることは興味深かった。

社会で教わる良い物事も、別の視点から見れば悪いということを改めて感じさせられた。

第3部 人類の統一

貨幣も虚構であると言う話から、貨幣によって見知らぬ者、集団同士の協力すること、忌み嫌っている相手ですら貨幣を信じて取引ができることが書いてある。 敵対国で貨幣の種類が異なっていても、取引が成立することは改めて凄いと感じた。

信者からも怒られそうだが、宗教も虚構であると言い切っていた。宗教がここまで広がったのは、暴力や教育によって信者を増やしていき、それによって信者が増えて、さらに虚構が社会に根付くという循環が起きていることが知れた。

この章とは関係ないが、暴力の話は農業革命や他の章にも度々出てきており、今がいかに平和か感じさせられた。

第4部 科学革命

科学革命によって、人間が無知であることを知る話から始まり、かなり面白かった。以前までは、宗教の神が全てを知っており、それに従って生きれば良いという思想だったが、科学の進歩により人間には知らないことが沢山あることがわかった。

科学に投資した国は力を得て、知らないことを知りたいという探究欲求によって進歩の思想を得た。 科学に投資しなかった国との対比などもあって、投資の力を感じた。 投資は科学に投資すれば、必ず良くなるという信頼があって行われた。これにより金融機関制度も発達した。

科学者と征服者の相互関係により帝国主義が推進されていく。 この頃、秩序（虚構）＝ 社会構造 は絶え間なく変化していった。

最後には、世界は過去に比べて、戦争もなくなり、医療技術も発展して平和になったことが述べらている。 そして、この科学革命は人間を幸せにしたのか？という問いかけがある。

狩猟採取生活よりも幸せか、ということは容易には言えないと結論づけている。

今後、人類は「生命工学（遺伝子操作など）」「サイボーグ工学（人間の器官とモノをつなぐ）」「非有機的生命工学（遺伝子プログラミングによる生命法則の書き換えなど）」により、 ホモ・サピエンスを超える人類が誕生する未来において、政治的、倫理的問題に取り組む必要があると述べている。

最後に

人類がどういう歴史を辿ってきたかには興味もなかったし知らなかったが、今回読んでみて歴史への興味や他の教養本も読んでみたいと感じた。 歴史の遍歴を知ることで、失敗を繰り返さない。教養は定期的に学んでいきたい。 サピエンス全史は、ページ数が多く長いですが、本当にオススメできる本です。

自分はAudibleで聞いたのですが、本来ならかなり分厚いので挫折していたかも知れないですが、耳で聴くので空いた時間を使えて効率が良く読み切ることができた。 何回も聞くのも気軽にできるので、こちらもオススメです。

何かを残すんだ

satoru-takeuchi.hatenablog.com

上記の記事に感銘を受けたので、ここに自分の考えを記す。

理想の追求

自分は技術書だけ読んできた。 リーダブルコードをはじめ、デザインパターン、ソフトウェア開発の奥義、クリーンアーキテクチャ、リファクタリング、ドメイン駆動開発と設計に関する書籍を読んできた。 これだけ見れば、よくやっていると思う人もいるかもしれない。 しかし、俺は何も世に出していない。ただ読んでいるだけでアウトプットがほとんどない。

綺麗な誰でもわかりやすいコードを書いて、責務が分割したモデリング、テストは必ず書いて、リファクタリングを行っていく。 バージョンは最新のを使いたいし、今時の技術に携わりたいと思っている。

理想と現実

そんな理想を描いているものの、実際にコードを書いてきてはいるがその量は少ない。

この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してないから手が動かなくて全然書けないや」ということに気付きました。当たり前といえば当たり前のことなんですが、当時は衝撃を受けました。わたしは耳学問でいろいろ知っているのに何もできず、彼はお作法は知らないけど馬力で動くものをちゃんと作っていました。

会社で見ているコードに対して、汚いコードだな、レベル低いな、と思うことも多々ある。しかし、本当にレベル低いのは自分であった。

最近、友人と練習としてアプリを作ろうという話になった。コードを書き始めると、設計に悩みすぎたり書き方が分からなかったり、本当に全然書けない。 一年前までは競技プログラミングをしており、毎日コードを書いていて自信があったのに、完全に頭でっかちになってしまっている。

まだ何も残していない

俺はまだ何も残していない。GitHubに上がっているものは、ほとんどチュートリアルやUdemyで見ながら模写したものだけだ。 自分で考えて作ったものは何一つとしてない。

まずはクソでも良いから何かを書け。簡単でもいい。電卓でも、botでも何でも良いから残すんだ。