はらだっちのブログ

プロ意識を持ち続ける。その一環として学んだことをこのブログで日々アウトプットしていきます!

「スピーチや会話の「えーっと」がなくなる本」を読んだ感想

はじめに

同僚がこの本をslackの分報でつぶやいていて、興味を持ったので読んでみました。

モチベーション

自分は話すことにとてもネガティブな印象を持っています。すごく緊張して、伝えたいことをうまく話せないことが多いです。この手のスピーチ改善系の話は好きなのですが、そういえば1冊読み込んだことはないなと思い読んでみました。

期間

3時間くらい。難しい話は全くないので、時間があればさらさら読めると思います。

ページ数:197ページ

感想

気づきがいくつもあった

「心」、「思考」、「声」の3つの要素のバランスが崩れるとフィラーはでやすい

元々、心の状態が乱れてると不安になる、話すことが準備できてないと不安になる、だからフィラーが出る、ということは認識していました。しかし、「声」自体も要素に入っているのは意識していませんでした。逆に声が大きく滑舌良く話せるなら、他の二つの要素が欠けててもフィラーが出る状況をカバーできるようです。これは盲点でした。

「えーっと」、「あのー」だけでがフィラーではない

フィラーと聞くと、「えーっ」や「あのー」がフィラーだと思いがちですが、実は普段使っている口癖もフィラーにあたるものが多々あります。

例えば、話し出すときに「なんか」と言ったり。「まぁ」だったり。

みんな使っているので自然ではあるのですが、文章中には要らない言葉で、相手からすると聞きづらい話し方になります。この辺り意識していると、普段の緊張してないシーンでも自分がめちゃめちゃ使っていてびっくりします。

最も納得感があったは「不明瞭化」です。人に何かを説明するときに断定した言い回しをせず、不用意に「~とか」、を使ってしまいます。これは”間違えを指摘されないように余白を残す”ための話し方ですが、実はこれこそが相手に伝わりずらい話し方なのです。

不用意に「とか」だったり、「~な気がする」だったりを使うと相手への伝わり方はボヤっとするし、こいつ自信が無いんだなと思われてビジネスはやりづらくなります。今後意識して使用しないように改善します。

文章を短く区切る

頭がいい人って、長い文章を流ちょうに話すイメージがありました。しかし、実際は文章を短く話すことが相手に伝わる話し方であり、短くなるとフィラーが入り込む余地がなくなります。

至極当然ですが、普段気付かない点でとても学びになりました。

フィラー改善に向けての段階的なトレーニング方法が記載されていた

フィラーが出ないようにするために9つのトレーニングが紹介されている

本で紹介されているトレーニングは段階的に練習していくものです。この中で、気を引いたのが、

  • テレビの音量を気持ち大きめにして、アナウンサーに負けない声でスピーチする。
  • 話した文章をパートナーにおうむ返しで話してもらう

です。1つ目は、発声量を大きくするのはもちろん、なんか外乱が起こった時に、焦らずに話し続けられる応用力が身につきます。

2つ目は、自分のスピーチをパートナーにおうむ返ししてもらうことで、自分が話したスピーチが短い文章で話せているかを確認することが出来ます。もし、相手がおうむ返し出来なければ、それは短い文章で話せていないということ、相手が理解できてないということ。すごくわかりやすいトレーニングですよね。これも実践していきます。

おわりに

この本は、易しいけど実践すれば非常に効果のある手法が紹介された本だと感じました。興味のある方は是非読んでみてください。

テスト駆動開発 第一部を読んだ感想

はじめに

最近、t_wadaさんのテスト駆動開発のライブコーディングのyoutube動画を見る機会がありました。この前読んだちょうぜつ本にFizzbuzz問題テスト駆動開発が載っていたのでやり方のイメージはついていましたが、実際にライブコーディングを見るとコーダーの頭の中がとても良く分かり有益な動画でした。そちらに触発されて本家のテスト駆動開発本を読破したくなってしまったので読んでみました。

読んだ期間

  • 第一部 約250ページ 約6時間(2日間に分けて読んだ)
  • 技術書にしてはサクサク読めるなと思いました

感想

  • 「はじめに」の中で「有機的に設計を進められるようになる」という言葉がありました。有機的の辞書は「有機体のように、多くの部分から成り立ちながらも、各部分の間に密接な関連や統一があり、全体としてうまくまとまっているさま」。そうそう、やりたいことってこれなんだよと思い読む前にワクワクしました。

  • progateや良いコード悪いコード本やちょうぜつ本、設計原則本を読んでjavaに触れてたおかげで特に苦にならずに読めました。途中の重複削除でインターフェースを使ってポリモーフィズムを実現したりする部分はUMLを学んだからこそつまずくことがすくなかったです。けど、GoFデザインパターン以外でもImposterパターンとか知らない用語が出て来て、そこは学びになりました。

  • 通化して継承させてみたプログラムが、実は最終的には親クラスにすべて移行した方がすっきりすることが分かって予想外でした。最初からきれいなプログラムなんて書けない。やってみて、視座が上がって、もっと重複削除・改善していけるってことに気づかされました。

  • 12章が一番衝撃だったかもです。メタファーを考えるというのが自分の中で一番難しいと感じています。具体と抽象の行き来の話だと思うが、自分は具体例を出すのは出来てると思います。しかしそれを抽象化するのがとても苦手です。これについて、メタファーを考えることで、設計に意味を見出せることがとても学びでした。この本だと、お金を足したり引いたりするのには「式(Expression)」、両替には「銀行」といったメタファーが出て来ます。最初読んだときは一発で理解できませんでしたが、このように役割をメタファーで定義することにより、Expressionにreduce(変形=両替)を持たせるという直感的に分かりにくいオブジェクトを作ることを避けることが出来ました。データモデリングとはまた抽象化の切り口が異なりますが、ドメイン駆動設計とは同一の考え方な気がしました。

  • 最終的に、自分が予想していた(というかどう実装するか全く想像できてない)コードとは全く異なるコードに着地しました。もし自分が(いつものようにTDDを使わずに)コードを書いていたら、ドルとフランを計算するという具体的なロジックを作成した後、そのままどうすればいいか手が止まって終わってしまっただろうな。これを三角測量等を駆使してテスト駆動でやりたいことを少しづつ段階的に追加していくことで、最終的に複雑度の低いコードにたどり着くことが出来ることがとても理解できました。

おわりに

私はJavaのコーディングをしたことが無いのですが、サクサクと読めました。2023年に色々な本を読んみ、予備知識が着実に付いてきていることを実感できました。そしてこの後の章を読むのもとても楽しみです。また、読んだらブログ記事にしたいと思います。

WEB API :The Good Partsを2章まで読んだ

はじめに

仕事でWEB APIを設計する機会があったのですが、「良いAPI設計とは何だろう?」という疑問がそもそもありました。同僚から本書を紹介してもらったので読んでみました。

理解・感想

良いURI設計をするにあたるメモ

  • 設計するにあたる考え方の背景
    • SQLのようにテーブルアクセスするのをただ内包しただけでは、ユーザが内部のテーブル仕様を知ってないといけない。
    • 内部構造を公開するとセキュリティが怪うくなる
      • したがってもう少し高い次元で機能を設計する必要がある
  • 公開したAPIがどのように使用されるかユースケースをきちんと考えること
    • LSUDsなのか、SSKDsなのか
  • 覚えやすく、どんな機能を持つURIなのかが一目でわかるようにすること
    • 短く入力しやすい
      • やたらに”api”という文字を繰り返し含まない、とか。
    • 人間が読んで理解できる
      • 名称はわかりやすい単語で
        • どうしたらいいか分からない場合は、ProgrammableWebを参考にする
        • 余談:httpヘッダはreferrerが正しいのにrefererとなってしまってる。
    • 大文字小文字が混在していない
      • 小文字で統一する
      • キャメルケースも良くない
      • HTTPの世界ではURIはホストとスキーマ以外は大文字小文字が区別される仕様
    • 改造しやすい
      • HATEOASというRESTを拡張した概念においては、Hackableでない方が良い、という考え方もある
    • サーバ側のアーキテクチャが反映されていないこと
      • Table APIとかはテーブル指定でデータ取得できちゃうからセキュリティ的にも良くないし、ユーザはテーブル構造知らなきゃいけないので良くなさそう
    • URIの付与ルールが統一されていること

認可フローについて

元々grant Typeが複数あり、Authorization code flowとかは使ったこともあり知っていましたが、その他のフローの違いが良く分かってなかったです。本書を読むことで再度調べるきっかけとなり、解像度高く理解することが出来ました。以下のサイトが参考になりました。

https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f

オーケストレーション層という考え方

私はTypescript / Next.jsでの開発を行うことが多いです。そして、Next.jsはサーバサイドにてapi routeにてapiを構築することが出来るのですが、これについて「backendでAPIを作るのにわざわざapi routeでラップする必要があるのか?」といった場面に遭遇しました。backendサーバをクライアントから隠蔽する、というが目的の一つとしてはあるのですが、オーケストレーション層として使う、という考えがしっくりきました。 https://parkpark.dev/posts/nextjs-api-to-bff

また、「あれそういえばBFFとの違いって何だっけ?」というのも調べるきっかけとなり、BFFはフロントエンドのためのオーケストレーション層である、ということも理解しました。

https://scrapbox.io/terfno/BFFOrchestration_Layer_です

Martin FowlerのREST APIの設計レベル

REST API LEVEL 3のHATEOASの概念導入については知らなかった考え方なので勉強になりました。

SSKDsをターゲットとしたAPIを作ることが多いので、今後HATEOASな設計にもチャレンジできるように理解を深めていきたいと思います。

おわりに

仕事ではフロントエンドの開発を中心にやっているのですが、API設計も原則はフロントエンドの設計原則と同じように感じました。保守性が高くなる設計をするために、分かりやすい名称にする、無駄を排除する、抽象化して内部構造が上位レイヤーに漏れ出さない様に疎結合化する。

このような原則を常に意識しながら今後の開発に活かしていこう、というのを改めて認識させてくれました。

「ソフトウェア品質を高める開発者テスト」を読んだ感想

会社で自分たちがアプリケーションの品質を担保していく際に、どのようなことを考えてなければならないか改めて見直したいと思い読んでみました。

読書時間

3~4時間 

感想

内容的には概念的な部分を分かりやすく少し工学的に説明している感じの本なので初心者でもわかりやすく、ITエンジニアならさらっと読めてしまう本かなと思いました。

気づき

単体テストには2種類ある

筆者は「単体テスト」という言葉について、「コードベースの単体テスト」と「単機能ベースの単体テスト」の2種類の文脈で使われている、と紹介していました。私は以前はウォーターフォールの現場(手動テスト)にて現在はアジャイルにチャレンジする職場にいることもあり、言われてみると確かにそうだな、と思いました。というか、ウォーターフォールの現場居た時はSTEAD(NTTデータ社の開発標準)を採用しており「PD/M/UT」という工程がありました。このUTがUnit Testを指しているのですが、システムごとに指しているものが異なっており理解するまで本当に時間がかかったのを思い出しました。今後は相手のバックボーンに応じてどの文脈で話しているかきちんと理解した上で会話しようと思いました。

Shift Leftについての認識が誤っていた

自分は、Shift Leftは「早い段階からちゃんと確認をしようね」ぐらいの理解をしていました。しかし実際はそうではなく、Shift Leftをすることで後工程でのバグ発生確率が下がってくる、また、テスト自体の実施効果についても、前工程で実施することの方が効果があるということをこの本を読んでようやく理解できました。

 古き良き?日本のウォータフォールを長く経験していたので(特に私は金融システムに居たのもあって)、「単体テストも統合テストもシステムテストもすべて同じレベルで網羅的にやらなければならない」という強迫観念があり、アジャイル単体テストについては「自動化することでリグレッションテストも素早くできるようになるからデグレードを防げる」という役割でしかない、とすら思ってしまってました。その点はすごく助かりました。

複雑度を測定して効果的にテストをしていく

それでも限りある人的リソースの中でテストの全てを網羅的にやるのは大変、じゃあせめて重要なところから優先順位をつけてやれたら。というところで複雑度やバグが多く発生しているモジュールを定量的に計測しあたりをつける、というアイディアについてもやりたいと思いました。サイクロマティック複雑度等の概念は知ってはいたものの本気で測るには至ってませんでした。このあたりをしっかり計測していければ、高品質なアプリケーションになっていくのもうなずけます。

 また、ミューテーションテストについても実際のやり方やツールがあることを知らなかったので今動いているコードに適用してみてどんな挙動を示すか試してみたいと思いました。

終わりに

内容が簡単な割には現場で使えるエッセンスが入った本でした。また筆者の方はMicrosoft・SAP・ソニー等数々の有名企業で品質についてのコンサルをされてきた方なので内容も信頼できると思いますし、この考えを参考に日々のアプリケーション品質の確保に努めていきたいと思いました。

"「自己肯定感低めの人」の人づきあい読本”を読んだ感想

はじめに

Youtubeのリールで「メンタルノイズ」カウンセラーの山根洋士という方の動画流れてきました。

最近はあんまり自分の自己肯定感について悩むことはなくなったのですが、人が集まった場面で意見することに抵抗を感じることはまだまだあります。また、アジャイル開発に限らずですが、仕事をする上でメンタルタフネス/マインドフルネスはとても重要だと考えていて、多くのストレスの原因は人間関係からくると思っています。

これからまた仕事が忙しくなってきそうなので、なるべく人付き合いでストレスを溜めないマインドセットを確認しておこうと思い、また、技術書ばかり読み続けるのもしんどかったりするので息抜きも兼ねて読んでみました。

読んだ期間

2時間くらい。200ページくらいありますが、自己啓発の分かりやすい本なので、技術書と異なりスラスラ読めました。

感想・理解したこと

  • よくある心理療法の本でした。新入社員の頃、病みかけて産業医に勧められた本に書かれてた本と書かれてるロジックは一緒かなと思います。

  • 起こった事象に対しての認知のゆがみに気付き、是正していくことが重要。自己肯定感が低い(と思っている人)や病みやすい人は、この部分が歪んでる(=この本ではメンタルノイズと言ってる。)

  • 人は生まれながらにして価値がある。
    • 「他と違う能力があるから価値がある」と思っていると、その他との比較で負けた時に、自信を失ってしまう。大事なことは自己納得感。
    • 誰かが死んだら必ず誰かが悲しむ。必ず誰かが悲しむということは、「生きてるだけで価値があるということ」の裏返し。小さい頃の悪い記憶や経験でこれベースに考えられなくなっていると自己肯定感が低くなる。
  • 嫌いな人は必ずいる
    • 「誰でも仲よくしよう」、「友達100人できるかな」、という教育方針で育てられるけど、実際は無理。だって自分の嫌いな人はいるし、嫌われることもある。大事なことはそういう人と関わらないこと。
    • 本の最初に「好きな人とし付き合わず、嫌いな人とは付き合わないこと。」と約束してください、と書いてあった。この考え方には結構救われるなと思った。

終わりに

こういう本って、仕事でやられてる時に読むことは良くありましたが、冷静な時に読むとより素直に読めるなと思いました。大事なことは自分には価値があり、他人と比較することなく、自己犠牲に走ることなく、出来ることを出来る範囲でやっていくこと。そんなことを再認識させてくれた本でした。

「ちょうぜつソフトウェア設計入門」読んだらソフトウェア設計の道筋が見えた

はじめに

メーカーでシステム開発をしているはらだっちです。最近「良い設計とは?」ということについて悩み、モデリングとかDDDにとかに手を出し始めていたところ、同僚から「ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用」が良本だよと教えてもらったので読んでみました。

私のレベルと読書期間

レベル

大手SIerにて7年プロマネ・2年営業を経て転職し、フロントエンジニア3年目。SIer時代はパッケージの水平展開プロジェクトでベンダー管理を主業務としていたためため、手を動かしての開発経験が無く、設計力は皆無。転職してからはUMLを学び始めて、最近UMTP L3まで取得。今年でフロントエンジニア3年目なのでプロ意識をもって働きたい。

読書期間

届いてから18日間で読み終えました。途中でJSTQB FLの勉強やDBスペシャリストの勉強もしていたので実質15日程度で読んだのかなと思います。

感想

表紙からは想像できないほどしっかりした内容

表紙がとてもポップなイラストなので、「中身はマンガかな?」とさえ思っていましたが、中身はとてもしっかりしていました。保守性の高いソフトウェアを設計するための考え方が、クリーンアーキテクチャを皮切りに一貫して書かれている、といった印象でした。

章の順番が秀逸

一般的に良くある本では技術が登場した歴史順に順を追って説明されることが多いですが、この本は最近の整理された考え方について、理解がすすみやすい順番で章が構成されていました。具体的には「クリーンアーキテクチャ」、「パッケージ原則」、「オブジェクト指向」、「UML」、「オブジェクト指向原則 SOLID」、「テスト駆動開発」、「依存性注入」、「デザインパターン」、「アジャイル開発」といった具合です。ソフトウェアの中心に”安定”を詰め込み、安定に依存する方向になるようにソフトウェアを構成していく。そのために抑えておく原則と具体的な開発手法が理解しやすい順番に登場してくるため、難しい内容でしたが最後まで読み切ることが出来ました。

DDDについても解説されてた

まずは、DDDの用語についての解説。「エンティティ」、「値オブジェクト」、「サービス」、「ファクトリ」、「リポジトリ」。普段何気なく使っている用語ですが、章の冒頭でDDDの文脈ではどういう意味なのかちゃんと書いてあり、とても親切でした。また、DDDとは要件定義・分析・設計・実装・テストを同じフェーズで行っていくことだ、ということもしっかりと分かっていなかったのでアハ体験でした。ウォーターフォール経験が長く、どうしてもフェーズに当てはめたくなったり、区切りが無いとそわそわしてしまうのですが、大事なことは実際に動くプログラムで、そこから得られる知見を最大限活用して次につなげる活動なんだなと再認識させられました。 1つ分からなかったのは、実践的モデラーとはスクラムの文脈だとどのロールにいるのかな?と思いました。開発者なのか、POなのか。その辺りどなたか詳しい人がいたら教えてください。

理解できたこと・気づき

安定に向かって依存の方向を揃えるということ

UMLで依存の矢印が出てきますが、もともとは単に「どっちのオブジェクトがそれを使うかわかるようにしてる」くらいの理解しかありませんでした。オニオンアーキテクチャを知ったあたりで「リポジトリ層で依存を逆転させるんです!これが重要なんです!」って聞いて、分かるようで「なんでそれがそんなにいい事なんだろう」とも思っていました。

この本を読んで、「ドメインのコアに安定を詰め込む」その安定に他の層が依存していくことで高凝集・低結合となる、ということが理解できました。

テスト駆動開発は設計手法

TDDってワードは巷では何百回と聞いていました。「アジャイルにやりたいなら自動テストは当たり前。回帰テストデグレが確認できるからね。だからTDDは重要なんでしょ。」と思っていました。しかしながらTDDの意味合いは全然違って、より良い設計に導くために必要な手法だということに気づかされました。

依存性注入の考え方について

DI(Dependency Injection)という言葉も聞いたことはあったのですが深くは理解できてませんでした。そして依存関係逆転の原則(dependency inversion principle)についても。

いやー、なるほど。DIを実装ことによって依存関係を逆転することが出来、より疎結合になる。そのためには単体テストがしやすくなってることが重要、だからTDDも重要。色んな知識がこの本を読むことで結び付けられました。

クラスと高階関数について

普段の業務でReact / Nextjsを使っていて、どのようなソフトウェア設計をすべきなのか常に悩んでいます。オブジェクト指向をどの本で学んでもクラスが出てくるので、業務ロジックを書きたいなら同じようにクラスを使えばいいのかな?と感じます。幸いjavascript / typescriptでもクラスは書ける(厳密にはprototypeベースかもしれないが)のでそうすればいいのかな、と思います。  しかしながら、社外の有識者に「Reactにおいてクラスを使うのはあまりモダンではない、Reactの一般的なお作法で書いた方が良いのでは?」と言われたり、エンジニアからも「Reactは関数型プログラミングだよね(良くわかってないけど)」と言われたり。そして、stateやhooksと言った状態管理・副作用管理の機能もあるため、頭の中で「どうやって書くことが保守性の高いソフトウェアに繋がるのだ????」と大混乱が起こっていました。  まだ、その霧は完全に晴れてはいないのですが、1つこの本で気付いた大きなことは「高階関数で振る舞いが渡せる」ということです。これはクラスでなくても依存性注入と同等のことが出来るということだな、すなわち高凝集・疎結合を実現する手段の一つだなと理解しました。

終わりに

自分がどれだけ理解できているのか確かめるためにブログにアウトプットしているのですが、書けば書くほど、「ん?やっぱりよくわかってないな」という点がいっぱい出てきて改めて奥が深いなと思います。再度本を振り返りつつ、”安定に依存する”という大原則を胸にこれからも学び続けたいと思います。