こつつみ

コツコツ積み上げる

逆ポーランド記法電卓 を作ってみた

はじめに

Twitterで #uesho開発 というタグで、簡単なものから開発したものを公開していくことにしました。 これによって、将来見返した際に成長具合が可視化できると考えています。

その第一弾として、逆ポーランド記法電卓 を作ってみました。

逆ポーランド記法 とは?

以下、引用Wikipedia

逆ポーランド記法(ぎゃくポーランドきほう、英語: Reverse Polish Notation, RPN)は、数式やプログラムの記法の一種。演算子を被演算子の後にすることから、後置記法 (Postfix Notation) とも言う。

その他の記法として、演算子を被演算子の中間に記述する中置記法、前に記述する前置記法(ポーランド記法)がある。 名称の由来は、演算子と被演算子の順序がポーランド記法の逆になっていることによる。

目的

Pythonを使い始めてまだ二ヶ月経っていなかったので、まずはPythonに慣れること。 そして、Pythonでのオブジェクト指向を学ぶこと。

やったこと

実は会社の研修でPythonではなかったですが、似たようなものを作ったため、思い出しながら作っていきました。

振り返り

学びとしては、Pythonでのabcモジュールを使った抽象クラスの作り方を知った。この抽象クラスを作ったことで演算子を追加した際に、簡単に実装することができた。 Pythonでも抽象クラスを作ることが有用に感じた。しかし、逆にPythonは動的型付け言語なので一般的にどうするべきなのかがいまいち分からなかった。 もしかしたら、抽象クラスを作らなくても綺麗にできたのかもしれない。(気づいた人は教えていただきたい)

設計の観点では、電卓への入力値が正しいか判定するクラスを作成し、正しいデータだった場合にrequestデータとしてCaluculateクラスに渡す設計にした。 現在(2021/09/26)は、CLIだけでの実装だけである。しかし、今後GUIでもできるように設計したつもりなので、時間と余力があればGUIも作っていきたい。

【反省】今まで記事はネタバレブログだった

最近、Twitterでは書籍図解などが流行っているように思う。

漫画のネタバレなどは忌み嫌われるものである。しかし、書籍図解はみんなに感謝される。 全てが同じではないにせよ、本を読む時間がない人向けに書かれた図解はどう考えてもNGだ。

書籍の購買意欲を高める図解は好意的に受け取られるが、読んだ気にさせて「買わなくていいや」と思わせる図解は問題だと思うようになった。

いざ自分を振り返ってみると、書籍の紹介をしていく中で引用がたくさんあるので大まかな内容がわかってしまっている。 自分の中では文章書いた気になっているけど、自分の全然考察されていないので、全く独自性がない。自分の考えが全然ないのだ。

これからはブログを読んだ人が書籍を購入したくするべき。(アフィリエイト感が増してしまうけど...) 自分の考えを載せて解釈して自分に落とし込めて、初めて自分の中で腹落ちすると思う。そういう意味でも今のままの記事内容じゃ全然身につかない。 実際にも、ブログに書いた内容は忘れていることが多い。

アウトプットを意識して発信を続けていきたい。

「モデリングの学び方:座談会」に参加しました

2021/9/7 モデリングの学び方:座談会がオンライン上で開催されたので参加しました。

modeling-how-to-learn.connpass.com

まず今回申し込みが1000人超え、参加者700人だった。これだけモデリングに興味がある人がいるのかと驚いた。 そして、自分も含めてモデリングの仕方に困っている人が多そうだなと感じた。

自分のレベル感としては、以下の本は読んだが全く実践できていないという状況だ。

speakerdeck.com

まず、座談会として7人の話しての方に2つの質問が投げかけられた。

1. 普段はどんなモデリングをしているか?

皆さんのやり方は少し違えど、「ドメイン(ビジネス)モデルをしっかり知る」という点は共通していた。 あとは、しっかりクラス図を書く人もいれば、ホワイトボードで議論したり、ソースコードを作ったり消したりなど試行錯誤していたりなどあった。

自分の場合、モデリングの正解があれば聞きたいなと思っていたが、気づいてはいたが人それぞれ違うことを改めて知った。 しかし、先ほども書いたが、SIerならお客さんのサービス・自社開発なら自社サービスがどういうビジネスについて、 コンテキストマップに起こしたり、「概念モデル」をベースにユースケースロバストネス図を作成したり、オブジェクト図にしたりと、 それぞれのやり方でモデリングしているようだ。

話聞いていて思ったのは、エヴァンス本でも強く言われているがドメインのことをよく知っている人から聞いて、しっかりとドメインのことを理解することがモデリングには必要なんだと感じた。

2. どうやってモデリングを学んできた感じですか? 学び方のお勧めはありますか?

実践の中での問題を解決するためにモデリングについて学び始めた人が多いなと感じた。

自分は前の職場はC言語で書かれており、コードがとても汚くどうにかしたいという思いで色んな技術書を漁って読んでいた。 リファクタリングを実際にしたが、3ヶ月前にリファクタリングしたブランチのマージリクエストを出しているが、本番コードを修正してエラーが出るかもしれないからと未だにマージされていない。 単体テストも書いてやっていたが、どうすれば良かったのか分からずに部署が移動してしまった。(多分、マージされなそう)

現在の部署は、基本的にマイクロサービスになっておりモデリングする必要もないくらいのコードの大きさなのでモデリングしない。(全体を見ればモデリングできるとは思うが、現状する必要がない) 実務の中でモデリングについて学ぶのがかなり難しいなと思っている。現在は個人で試行錯誤しているが難しい。

ミノ駆動さんが言っていたペアプロリファクタリングをしていくのはとても良いなと思った。有識者の意見を聞きながらモデリング・設計をする機会があれば、自分の中のやり方というのが固まっていくのかなと思った。

あと良かったと思ったことは、「Tell, Don't Ask」だけは一番意識していると聞けたこと。有識者の気をつけているポイントを知れるのは良い。

TellDontAsk

他にもモデリングオブジェクト指向の学び方として以下が紹介されていた。

  • オブジェクト指向エクササイズ :これは賛否両論あるが、とっかかりとしては良さそうに感じた。

www.slideshare.net

www.ogis-ri.co.jp

最後に

なぜか一番印象に残ったのは、hiroさんがサーバーサイドには必ずクラス図を書いているということだ。

UMLについて研修を通して学んできて自分でも有用性を感じていたが、実際に実務で使うことがなく使っている人は現代ではいないのか?という気持ちになっていたので、 hiroさんがガッツリ使っていることを聞き、自分も書いていこうという気になった。ありがとうございます笑

個人だと小規模になりドメインモデルを考えるほどでもないので、手段が目的になってしまいがちになるのかな?と思っているが、 やっぱり手を動かして実践していくしか身につかないと思うので、個人開発でも積極的にモデリングの練習をしていきたい。

まだまだ自分の中に落とし込めていないので、「モデリングの学び方:座談会」の第二回があれば、また参加したい。

「思考・論理・分析」を読んだ

本の基本情報

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

  • 著者名:波頭亮
  • 書籍名:思考・論理・分析―「正しく考え、正しく分かること」の理論と実践
  • 出版社:産能大出版部
  • 発売日:2004/7/15
  • 頁 数:241ページ

本の目次

以下は本書の目次です。

  • 第1章 思考
  • 第2章 論理
  • 第3章 分析

考えたこと

この本は割と言われてみると当たり前のことが書かれているが、その当たり前を言語化し図を用いながら体系的に「正しく考え、正しく分かること」について説明している。 間違いなく良書である。

自分は全然自分で考えられていないと思うことが多々あるが、なんで考えがまとまらないか分かっていなかった。この本を読んでみて当たり前ができていなかったんだと気付かされた。

思考の段階では、あらゆる情報を分けて構造化させ、それぞれの情報について”それが何であるのか” そして、”それがどのようなものであるか”ということを理解する。

論理の段階では、命題から正しく推論し、新しい意味内容を得る。

分析段階では、分析プロセスの設計をして、情報を集め、分析し、意味合いを抽出する。 分析作業を進めていくと「分析すること」自体が目的となってしまいがちになるのは分析作業のあるあるだが「正しい思考過程」「正しい論理」「正しい分析手順」を踏むことで、意思決定やアクションに結びつく「優れた分析」を行えるようにする。

この本は、上のような実践的な話から、そもそも「思考」とは何か?「論理」とは?「分析」とは?というところから説明されている。 「ロジカルシンキング」の本として何個か読んできたが、方法が書かれているものは多くあったが、「思考・論理・分析」がそもそも何なのか説明されているものは、他にはなかった。 そのため、一度ロジックツリーやMECEなど知っているが、使いこなせていない人(自分はこれ)は、考え方を知ることができるので本書を一度読んで見ることを見ると良い。

なぜ「論理的」に考えることが必要なのかということにも言及されている。 思考という行為は属人的であり、思考者によって左右されるからである。 その思考を「客観的」に行なうために「論理的思考」が必要であると筆者はいう。 属人性の扱いに対してどれだけ丁寧に考えられていたのか?知識に偏りがないか?心理的バイアスが発生して、先入観や思い込みに捉われていないか?など の観点はまだまだ自分にはできていない。そもそも自分のアウトプットの質が低い。 今からでも、毎日「正しく考え、正しく分かること」を実践していかないと身についていきたい。

「Clean Architectures in Python」を読んだ

クリーンアーキテクチャの書籍は読んでいたものの、実際にコードに落とし込めなかった。 なので、Pythonでのクリーンアーキテクチャ的な設計ってあるのかな?と検索していると、以下リンクの「Clean Architectures in Python」を見つけ無料で読めることを知った。

github.com

「Clean Architectures in Python」は2020年のEuroPythonで発表していたみたいです。

ep2020.europython.eu

目次

「Clean Architectures in Python」の目次を書いておく。

  • Introduction
  • About the book
  • Chapter1 : A day in the life of a clean system
  • Chapter2 : Components of a clean architecture
  • Chapter3 : A basic example
  • Chapter4 : Add a web application
  • Chapter5 : Error management
  • Chapter6 : Integration with a real external system postgres
  • Chapter7 : Integration with a real external system mongodb
  • Chapter8 : Run a production ready system

学んだこと

まず英語で書かれているので、Google翻訳を使いつつ読んでいった。

この本では、前半はCLIで物件情報を一覧表示するアプリを作り、 後半は前半で作ったものをもとにFlaskというフレームワークを用いて、WebAPIにしていきながらクリーンアーキテクチャが解説されている。 ビジネスロジックさえ作っていればCLIでもWebAPIでも簡単に変更できることや、 DBをpostgresからmongoDBに変更するなど変更容易性の観点や、エラーマネジメントの話はとても参考になる。

最初から最後までテスト駆動開発(TDD)で進められており、その点も非常に参考になる。

他にも、Pythondataclassやレスポンスの設計やユースケースについても知ることが出来た。

まとめ

クリーンアーキテクチャもそうだが、Pythonを始めたばかりの自分にとってはpythonでのテストの書き方、テスト駆動開発やDBへの接続などがとても参考になった。 全体を通して、今の自分にとっては知りたいことが具体例として書いてあり、すべてのページで学びがあった。

PythonでWeb開発に携わる人は、そんなに長くなく2, 3日くらいで読めたので、一度読んでみることをオススメする。

「人月の神話」を読んだ

本の基本情報

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

  • 著者名: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章 タール沼

個人で作られたものが、企業で作られた奴より何倍も早く完成したという話があるが、実際に企業のプログラミングシステム製品にするには約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を買います!!