こつつみ

コツコツ積み上げる

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

本の基本情報

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

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

本の目次

以下は本書の目次です。

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

概要

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

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

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

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

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

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

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

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

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

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

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でも何でも良いから残すんだ。

オブジェクト指向について考える

daiyamamoto.hatenablog.com

これを読んで思うこともあり、「なぜオブジェクト指向でつくるのか?」や「デザインパターン」、「クリーンアーキテクチャ」、「ドメイン駆動設計」 を読んで、今の自分の意見を書く。

個人の意見であり、これが正しいことはないし、何なら今まで知識だけで実践経験が少ないので間違っている可能性は大いにある。 しかし、現段階での自分の考えをここに残す。


継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている

まず、ここから間違っている。2000年代ではそうだったのかもしれないが、継承は基本的には使うべきではない。もちろん、インターフェースなどでは普通に使われるが。 継承を積極的に使っていくと差分プログラミングが始まってしまう。

Webのサーバーサイドで隆盛を誇っていたJavaだが、実のところWebサーバーサイドの現場のコードにオブジェクト指向が必要な部分などそう多くはなかった。

現場でオブジェクト指向は多く使われる。現在、GoFデザインパターンは半分くらいは廃れたが今でもなお健在だ。

抽象化することは当たり前にやられており、何よりも大切だと思う。

インターフェイスの分離やデザインパターンを使わない現場に入った時、IDEがコードのジャンプを適切に実行してくれることの楽さを感じた。

これはあるかもしれないが、適切にファイルが分割されていれば読み取るのはそんなに苦ではないと思うのだが...これは新人だから、もしくは、大規模な複雑なコードに出くわしてないからなのかもしれない。


実際に2000年代の時代を知らないから、本当に著者の気持ちは知ることはできない。

しかし、自分はオブジェクト指向は何よりも大切であると思う。ライブラリやフレームワーク作る側には必須だ。

サーバーサイドでも、API作るならオブジェクト指向必須であると感じる。 なぜいらないと言っているのか分からない。

最近はよく読みやすさをどうするか考えている。オブジェクト指向使うと読みにくいという人が多い。 適切にファイル分割されていれば、読みやすいと思うのだが。。。

設計をする上で、どうすれば新しく入ってきた人に理解しやすいかの答えはまだない。

オブジェクト指向が分からないやつが悪いとか言っていると、プロジェクトは破滅してしまう。 ちゃんと保守しやすい、変更しやすい、可読性が良いの両立。これが課題。

まだ新卒3年目。これからもオレオレ実装ではなく、誰でもわかりやすい設計・コードを模索していく。

「デール・カーネギーの人を動かす方法」を読んだ

本の基本情報

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

本の目次

以下は本書の目次です。

  • Part1 
    • 第1章 「蜜が欲しければ、蜂の巣を蹴るなかれ」
    • 第2章 「人を動かす」たったひとつの秘訣
    • 第3章 「それができる者は世界を味方につけ、そうでないものはひとり寂しく道を歩むことになる」
  • Part2 
    • 第1章 いつでもどこでも誰からも好かれる方法
    • 第2章 第一印象をよくするシンプルなやり方
    • 第3章 これを忘れるとトラブルのもと
    • 第4章 話し上手になるための近道
    • 第5章 人に話を聞いてもらうには
    • 第6章 たちまち人に好かれる方法
  • Part3 
    • 第1章 議論に勝者なし
    • 第2章 敵を増やす確実な方法
    • 第3章 間違っていたら素直に認める
    • 第4章 相手の心に届く話し方
    • 第5章 ソクラテスの秘宝
    • 第6章 心の思いを解き放つ安全弁
    • 第7章 協力を引き出す上手なやり方
    • 第8章 奇跡を起こす魔法の公式
    • 第9章 誰もが望んでいること
    • 第10章 人の心に響く訴え方
    • 第11章 映画やラジオに学ぼう
    • 第12章 何をやってもだめなときはこの手を使え
  • Part4 
    • 第1章 どうしても欠点を指摘したい時には
    • 第2章 嫌がられない批判のしかた
    • 第3章 まずは自分の至らないところを話す
    • 第4章 指図されるのが好きな人はいない
    • 第5章 人の顔を立てる
    • 第6章 人を奮発させて成功へと導く方法
    • 第7章 向上心を刺激する
    • 第8章 ハードルを下げる
    • 第9章 喜んで協力させる
  • Part5 
    • 第1章 奇跡的な結果をもたらした手紙
    • 第2章 あるがままを愛する
    • 第3章 離婚へのカウントダウンを始める確かな方法
    • 第4章 誰もが幸せになれる近道
    • 第5章 女性にとってとても大切なこと
    • 第6章 幸せになりたければ忘れてはいけないこと
    • 第7章 正しい夫婦生活の知識を持つ

概要

デール・カーネギーの人を動かす方法」では、実際に原則の名前は出てこないが、人を動かすと比較してみると完全に一致する。

Part1

人を動かす3原則

  • 原則1:盗人にも五分の理を認める

相手には相手の正義がある。決めつけで批判してはダメ。

  • 原則2:重要感を持たせる

人は強い認められたいという欲望がある。心からの賞賛により相手に自己重要感を持たせる。

  • 原則3:人の立場に身を置く

自分の欲しいものではなく、相手が欲するものを理解し、それを手に入れる方法を教えてやる。

「釣り針に自分の好物をつけるな」

Part2

人に好かれる6原則

  • 原則1:誠実な関心を寄せる

犬は下心なく純粋な関心・好意のみを人に捧げる。

相手の関心を持つ。相手の話したいことを話してやる。

  • 原則2:笑顔を忘れない

笑顔は人を引き寄せる。

笑顔でいれば自然と幸せな気持ちになる。

  • 原則3:名前を覚える

当たり前だが少ししか関わっていないのに、名前を覚えてもらったら嬉しい。

自分は名前を覚えるのが得意な方なので、存分に活かしていきたい。 少しの手間で大きなメリットを得られる可能性がある。

  • 原則4:聞き手にまわる

相手の関心に合わせて話をする。話し手に満足させる。

  • 原則5:関心のありかを見抜く

相手の最も関心があることに合わせる。

  • 原則6:心から褒める

褒める習慣を身につける。 批判はするけど、褒めることをする人はごく僅か。

Part3

人を説得する12原則

  • 原則1:議論を避ける

議論をすれば、相手に重要感を与えることはできない。

  • 原則2:誤りを指摘しない

相手の意見に敬意を払う。謝りはよっぽどのことがない限り、指摘するのは好ましくない。

  • 原則3:誤りを認める

自分が間違っていると気づいたら、速やかに謝りを認める。相手に指摘されるより気が楽(?)

  • 原則4:穏やかに話す

優しい打ち解けた態度で話あえば、相手の心を変えることもできる。

  • 原則5:イエスと答えられる問題を選ぶ

初めにイエスと言わせると、相手の心理は肯定的な方向へ動き始める。

  • 原則6:しゃべらせる

聞き手に回ると同じ。自己重要感を満たすことが大事。

  • 原則7:思いつかせる

人は自分で思いついた意見を大切にする。命令されるより、自分から進んでやるようにする。

全てを伝えるのではなく、ヒントやキーワードだけを伝えて、自分の意図を気づいてもらうよう誘導する(難しそう)。

  • 原則8:人の身になる

関心のありかを見抜くに近い。相手の行動・思想の背景を想像し、理解するように努める。

  • 原則9:同情を寄せる

「あなたがそう思うのはごもっともです。もし私があなただったら、やはりそう思うでしょう。」こう言って話を始めて同情を寄せる。

相手の意見にまずは賛成する。

  • 原則10:美しい心情に呼びかける

人を騙すような人間でも相手に心から信頼され、正直で公正な人物として扱われると、なかなか不正はできない。

相手の良心に訴える。

  • 原則11:演出を考える

相手を楽しませる演出方法を考える。プロポーズは、跪いて愛の言葉が本心であることを演出している。

  • 原則12:対抗意識を刺激する

競争心を起こさせることで、仕事の質・スピードを上げる。

人には誰でも「他人より優れてた自分であると認めてもらいたい」という欲求があるので、人を動かすには対抗心を燃やすような仕組みがあると人を説得しやすい。

Part4

人を変える9原則

  • 原則1:まず褒める

褒める。心から褒めると同じ。習慣づけよう。

  • 原則2:遠回しに注意を与える

人は注意されることを嫌がる。 問題点を直接的にではなく間接的に伝える。

  • 原則3:自分の過ちを話す

頭ごなしに注意すると相手が反抗心を持ってしまい、こちらの注意を素直に受け入れられないので、まずは自分の誤りを話した後に相手を注意する。

  • 原則4:命令をしない

決して命令はせず、自主的にやらせる。

「〇〇はどうかな?」と質問し、意見を求めてみる。

  • 原則5:顔をつぶさない

たとえ自分が正しく、相手が絶対に間違っていても、相手の顔を立てる。

  • 原則6:わずかなことでも褒める

さらに、褒める。たとえわずかでも相手が進歩を示せば褒めてしおう。

  • 原則7:期待をかける

いい評価を立ててあげると、その人間はあなたの期待を裏切られないように努める。

  • 原則8:激励する

人は激励されると、能力に自信を持つことができ、自分の優秀さを示そうと懸命に頑張る。

アドラー心理学では、勇気づけ。

kotsutsumi.hatenablog.com

  • 原則9:喜んで協力させる

相手が喜びそうなことを与えてこちらに協力させる。

相手の関心をひくことが、まずは大事。自己重要感を満たしてあげる。

Part5

幸福な家庭をつくる七原則

毎日生活を共にしていると相手の悪い所にばかり目が行く。 悪い所ばかりに目を向けるのはやめなければならない。

  • 原則2:長所を認める

本気で良好な関係を維持させたいなら、長所を探す努力をし、褒めなければならない。

  • 原則3:あら探しをしない

自分の満たされない、受け入れられない部分を相手で埋め合わせないようにせず、あら探しをしないことが、幸福な家庭を築くために大切。

  • 原則4:ほめる

もう、ここでも褒める。とにかく褒める。心から。

  • 原則5:さやかな心づくしを怠らない

妻に対するささやかな心づくしの価値を軽く見すぎている男性が世の中には多すぎる。結婚の幸福は、些細な心づくしの集積によって得られる。

相手に花を贈ったり、記念日を祝ったりすること、つまり相手への心遣いを示そう。

  • 原則6:礼儀を守る

家の中では会社や学校にいる時より無作法で礼儀を忘れてしまいがち。

百万の富をつくるよりも、やさしい妻と平和で幸福な家庭を築くほうが、男にとっては、はるかに意義のあることですが、家庭円満のために真剣な努力を傾ける男は少ない。

高圧的な態度をとるより、優しい態度を示す。

  • 原則7:正しい性の知識を持つ

割り切った態度で遠慮なく議論を重ね、適当な書物を読み、「正しい性の知識を持つ」ことが大切。

最後に

「人を動かす」と勘違いして買ったが、ほとんど同じである。出版社が違い、原則名は書いてないくらいの差である。

今回あげた原則は、当たり前だができていない人が多い。 できないのは忘れてしまうからだ。何回も読み直し、自分を見つめ直すことが必要。

原則は多いが、相手の関心を持つや褒めるなど共通しているものが多い。 自分の中で、この原則とこの原則は同じこと言っているなと探してみると意外と面白い。

デール・カーネギーの人を動かす方法」は元々、CD(?)ということもあり音声読書と合っている。

今回の「デール・カーネギーの人を動かす方法」は、Audibleで聞いたのですが他の本と比べても図とかがなかったので、いちいちスマホを見る必要がなくとても聴きやすかった。 何回も聞くのも気軽にできるので、おすすめです。

組み込みエンジニアからクラウドエンジニアになります

あんた誰?

新卒3年目のメーカー企業で通信関係の組み込みソフトウェアエンジニアしている uesho です!

この一年は、設計・実装・テストと一貫して開発に携わってきた。

kotsutsumi.hatenablog.com

上の記事でも書いたが、会社以外でも全部中途半端だけど、Webやクラウド自宅サーバーなど色んな分野の技術に触れてきた。 その中でも、自分は将来性や自分の興味が湧いたクラウドにいきたいと考えていた。

クラウドエンジニアになる

2021年5月に面接を受けて社内転職を試みた。その結果、7月から正式に配属されることが決まった。

クラウドエンジニアになれるのだ。そして、その部署はコードも書く機会が多いとのこと。 一番希望していた部署に行くことができた。

AWS SAAの資格をとって、自分は意欲がある人物であるとアピールできたのが大きいと思う。

クラウドエンジニアになると言ったが、実際に実務では使ったことないし、個人でしか使ったことがない。

配属されることが目的ではなく、そこ、いや市場で結果を出すことが目的だ。

クラウドも設計も実装も一貫してできる人材になる。技術だけではなく、ドメイン知識もコミュニケーションも全部できるようになりたい。

何か捨てて極めるのではなく、全部極めたい。興味の赴くままに。

ここが始まりという意識を持って進んでいきたい。

なぜ人に相談できないのか

自分は人に全然相談しない。進路を決めるときも、好きな人ができたときも、就活も全部1人で決めた。

これだけ聞くと良いように感じる。しかし、予備校とかで分からない問題があっても答え見て自己解決する。チューターの人には一回も聞きに行ったことがない。 答え書いてあるのに聞きに行く意味がわからなかった。振り返ってみると相談している人の方が良い大学に行っている印象を持った。

議論すると言うことが自分の理解が進んだんだろう。自分は何となく分かった気になっていただけだった。

相談しないが最近は「なんで相談できないんだろう?」と考えることが増えてしまった。相談したいのだ。

と言うのも、客観的に見て相談している人の方がキラキラして見えたのだ。自分が嫉妬していることに気づいたのだ。

何で相談できないのか、自分なりに考えてみた。他にも意見が欲しいので、こんなブログを見てくれた人は是非コメントが欲しい。

  • 2人で話すことが少ない (複数でいると話す必要がないなと思ってしまう)
  • 自分に自信がない (相手にどう思われるか不安) (こんなしょうもない質問するなとか思われそう?)
  • コミュ障で話が上手くない (これは経験を積むしかない...)
  • 外部と深い関わりを自ら絶っている (壁を作っているのかもしれない)
  • 相談しないから、相談されないのループ
  • 自分で解決しようとする (これが小学校とかから染み付いている)

まずは、自分の話を全くしていないので少しずつ自分の話をしていきたい。(slackの自分のチャンネルを有効活用していきた)