2025/1 SoftwareDesign 2025年2月号 読了

 

Software Design (ソフトウェアデザイン) 2025年2月号 [雑誌]

 

主に読んだもの

• Pythonコードの書き方2025
  • Python3.13の新機能など
• PostgreSQL17の4大機能を徹底解説

• アンチパターンに立ち向かう実践データベースリファクタリング第13回：複雑な時間枠の検索
• ソフトウェア探検隊第5回：テストケースの選び方
  • 仕様のサンプリング方法にはいくつかのアプローチがある
    • 境界値分析法（On-Offポイント法）
    • Property-based testing
• ぼくらの「開発者体験」改善クエスト最終回 by NewsPicksプロダクトチーム：開発者体験のその先へ（今後100年サービスを継続するための障害対応とEOL対応）
  • 「全員インシデントコマンダー」の文化醸成
  • スピーディーな仮説検証
  • 生成AIã‚’Slackの障害対応スレッドの要約に使用し、状況把握・共有の容易化とポストモーテムの省力化
  • EOL対応は開発者体験向上やコスト削減にも効果的
• インターネットの姿をとらえる　第6回：インターネットからみたCDNのインパクト
  • インターネットトラフィック全体のうち約90%はCDN
• 一歩踏み出すための技術広報戦略の立て方　第2回
  • 技術発信をすることによる会社のブランディング
  • どのように段階的に技術発信の文化を作るのか

 

2024/10 SoftwareDesign 2024年11月号　読了

 

Software Design (ソフトウェアデザイン) 2024年11月号 [雑誌]

 

AI駆動開発目的に購入したが、さほど目新しい情報は無かった

2023/11 SoftwareDesign2023年12月号 読了

 

Software Design (ソフトウェアデザイン) 2023年12月号 [雑誌]

 

2025/1/13 GoogleCloudではじめる実践データエンジニアリング入門　読了（一部）

 

改訂新版 Google Cloudではじめる実践データエンジニアリング入門

 

本屋でたまたま手にとってなんか中身すごい良さそうだったので急に買ってしまった本。

Google Cloudの人たちが書いている本だし信頼度高い。

BigQueryを主として、データエンジニアリング向けのサービス全般の活用法や設計のベストプラクティスが解説されている。

広くそこそこ深くという感じで、まぁまぁ分厚い。

興味のある章だけとりあえず読んだ。（BigQueryアーキテクチャの解説やBigQueryまわりの設計についての部分）

最近BigQueryを使った設計を仕事で（初めて）行ったときにかなり調べたりしたのでBigQueryまわりは知っていることも多かったが、復習になったのとより深く知ることが出来た部分も色々あった。

復習したいとき、BigQueryまわりの設計でヒントが欲しい時はもちろん、体系的にわかりやすくまとまっているのでこれから経験が無いサービスの活用が考えられる場合などにもまたお世話になりそうな本だと感じた。

おすすめします。

購読しているメルマガについてまとめてみる

メルマガをいくつか長いこと購読しているけど気が向いたのでまとめてみる

 

• 中島聡 | 週刊 Life is beautiful - メルマガ

• 英語学習メルマガ『1æ—¥1フレーズ！生英語』 | 英語学習サイト：Hapa 英会話

• phrase | ニック式英会話

 

いつから購読しているか忘れたけど、どれもたぶん5年以上とか読んでる気がする

 

中島聡さんのLife is beautifulは有料(月880円)だけど英語のはどちらも無料。

ただLife is beautifulは週刊で月額880円で余裕でその価値があると思います。

中島聡さんはエンジニアの方だけど、過去には会社を立ち上げて経営をしていたこともあったり、NTTの研究所やMicrosoftのような大企業で勤めていたこともあれば、スタートアップで仕事をしていたこともあったり、VCもしていたりと、幅広い経験を持つめちゃくちゃスゴイ人。エンジニアで一番尊敬しています。（生まれ変わっても敵わないと思う）

まぁとにかくモノづくりが大好きでエネルギッシュなとにかくスゴイ方です（語彙力）

以下の本でも有名ですかね。

なぜ、あなたの仕事は終わらないのか スピードは最強の武器である

 

内容としては今の世界のニュース（テクノロジー関連や世界情勢などが多い）についてや、目に付いた記事についての話、読者からの質問コーナーなど。

時々あるソフトウェアエンジニアリング関連の話は、ソフトウェアエンジニアの人だと特に面白いかなと思います。

が、色々な話題が含まれるので、ソフトウェアエンジニアリングに関わる人だけでなく幅広い層の方が読んでいるらしいです。

とても面白いし勉強になるので、超おすすめです。

火曜日配信なので、平日の昼休みとかによく読んでます。

 

英語のメルマガ2つは、どちらもフレーズを紹介してくれるメルマガです。

HAPA英会話は月〜木にフレーズの配信、金に1週間の復習の配信。

ニックのひとこと英会話は月水金にフレーズの配信。

どちらも文法的解説とかニュアンスの解説とかも含まれてます。

ニック先生はよくYouTubeも見ますがそちらもわかりやすくて面白いです。

自分はこの2つのメルマガで紹介されているフレーズを単語カードのアプリに登録して忘却曲線に沿って復習してます。

 

気になったのあったら購読してみてください〜（まぁこのブログを読んでる人自体がいないと思うけど）

2025英語学習計画

teihenn5.hatenablog.com

 

今年は去年読んだこれを元に英語の勉強により力を入れる。

本を買って読んだのだが、全く同じ内容が著者のWebサイトに丸々書いてあった。（本買わんくて良かったやん…）

六ツ野英語教室｜英語上達完全マップ

なので以下では普通に本から得たネタバレも書く。

 

本に載っているトレーニングの種類

• 音読パッケージ
• 短文暗唱＝瞬間英作文
• 文法
• 精読
• 多読
• ボキャビル
• リスニングトレーニング
• 会話

 

色々あるが、自分は幸いなことに英語の基礎はある程度は持っている（TOEIC800くらい）ので、とりあえず音読パッケージを全力でやってみてどうなるかを見たい。（文法とか精読は大学受験時代腐るほどやったっちゃやったし。。まぁ大学受験めっちゃ前だけど…英語の勉強以外にもやりたいことはたくさんあるので）

ということで音読パッケージを全力でやる。

ちなみにメルマガ（HAPA英会話、ニックのひとこと英会話）は今年も引き続き読んでフレーズのインプットは続ける。

 

音読パッケージについて

使用教材

英語のハノン　初級

英語のハノン　初級　――スピーキングのためのやりなおし英文法スーパードリル

 

著者いわく英語のハノンシリーズの中核を成す初級編。

これも積読してしまっていたので、今こそ活用するとき。

 

練習のやり方

英語上達完全マップに載っていたサイクル法で音読練習を行う。

 

サイクル：教材の周回数を表す

 

以下にサイクル法による音読パッケージのやり方をまとめる（本やWebページにも載っているけど、ポイントなど含めて見やすくまとめてみた）

 

第1サイクルの1セッション

1〜2度音声を聴いてからテキストをしっかり読み解く。

（文構造を完全に把握して、意味、使い方が曖昧な単語は辞書を引いて確認し、英文について100%理解している状態で音読を行う）

1. テキストを見ながらリピーティング：5回

• 単なる音にならないよう、頭の中で意味とイメージを結びつけながら。

音読：15回

• 音声データを使わずに、自分で音読を行う。

• 5回のリピーティングで耳に残っているモデルの英語の発音、イントネーションを忠実に再生するつもりで音読する。

• この15回の間にしっかりと英文を自分の中に落とし込む。

• 英文を暗記しようとする必要はない。

• 必要であれば回数を増やしても問題ない。

テキストを見ないリピーティング：5回

• 十分なじんだ英文を、発話実感を伴って、音声データのポーズ中に滑らかにリピーティングし、仕上げる

• テキストなしのリピーティングが困難なときは無理にやろうとせず、テキストを見ながらのリピーティングを行う

• こういった場合はテキストなしのリピーティングは第2サイクル以降で実現すれば良い

シャドーイング：5回

• 難しければテキストを見ながらのシャドーイングか音読で代用する

通し聴き：数回

 

上記計30回。

これをひとまとまりの英文ごとに行い、テキストの最後の英文で終えれば、第1サイクル完了。

反復回数は守ること。5,6回程度の音読では少なすぎる。第2サイクル以降は必要な反復回数は減り楽になっていく。

 

第2サイクル手順モデル

ピラミッド方式でサイクルを回していく。

1. テキストを見ながらリピーティング：3回程度
2. 音読：10回程度
3. テキストを見ないリピーティング：3〜5回程度

• 第2サイクル以降のメインパート。英文をしっかり把握しつつ、正確かつスムーズなリピーティングが連続して3回程度できたら仕上がり。

シャドーイング：3回程度

• フォローアップとしてシャドーイングを行う。

 

上記のように反復回数は20回前後に減る。

ただ第2サイクルでもテキストなしのリピーティングが難しい等あれば、気にせずテキストを見ながらのリピーティングを行う。

無理をしなくても、完成は次回以降のサイクルに譲ればいい。

 

第3サイクル手順モデル

第3サイクル以降は、反復回数がさらに少なくなる。

スムーズなリピーティングが3回くらい含まれるなら、15回程度で良い。

1. テキストを見ながらリピーティング：2〜3回
2. 音読：6〜8回
3. テキストを見ないリピーティング：3〜5回
4. シャドーイング：2〜3回

 

第4サイクル手順モデル

1. テキストを見ながらリピーティング：2〜3回
2. 音読：4〜5回
3. テキストを見ないリピーティング：3〜4回
4. シャドーイング：1〜2回

 

ピラミッド方式によるサイクル法全体

合計回数が100回程度になるまでサイクルを回す。

サイクル回し全体の一例↓

第1サイクル30回　＋　第2サイクル20回　＋　第3サイクル15回　＋　第4サイクル10回　＋　... ＝ 100回

 

 

1セッションあたりの反復回数は自分なりのアレンジで多少変動しても問題ない。

大事な点は以下

• 第1サイクル30回のミニマム回数を守る。
• サイクルを回して合計の100回前後反復する。
• テキストの音読パッケージが仕上がったとき、ポーズ付きの音声を流して、テキストのどの部分だろうと、ほぼ完璧にリピーティングができる状態になっている。

 

自分の英語レベルが上がってくると同じテキストを100回も繰り返す必要性が薄れてくる。

自分が仕上がったとおもったときに、サイクル回しを切り上げれば良い。

さらに力がついてくると、同じテキストを何度も回す必要がなくなってくるとともに、

トレーニングそのものが様々なバリエーションに分岐していく。

この段階に至れば、サイクル法による音読パッケージを卒業してもよい。

自分の気に入った分を好きな回数1セッションだけ音読することを末永く続けていくと良い。（一期一会の音読）

 

まとめ

正直なかなかハードなトレーニングだと思う。

でも外国語を習得するというのはきっとそういうことだ。

頑張る。。

生成AIを開発でどう使うかなどについてのつぶやき

結構前だが、Cursorが出てから、個人開発ではVSCodeではなくCursorを行うようになった。
アウトプット効率の上がり方は凄い。
かなりの割合cursorが出したコードを採用していて、
少し前はAIでコーディング機会が減るのは寂しさを感じるかもと思っていたが、
ちゃんと設計指示などは自分が考えて与えるし、意外にもプログラミングの楽しさはさほど失われないなと思った。
というかかなり爆速で開発できるので、早くものを作り上げられる楽しさが大きく、この生産性の上がり方はやはり革命的だと思った（特にCursorは提案が良ければそのままapplyできる機能とか選択部分をチャットに追加とか、IDEとの統合度が高くそれ故他のツール(VSCode + Copilotなど)よりも明らかに体感の生産性が高い。）
ちなみにモデルはClaude 3.5 Sonnetを使用していた。

 

ただし、思ったこともあった。
爆速で開発できるのはそうだが、開発が進んでくるとあまりコントロールできている感がなくなってきて少し気になってくる（爆速で開発できすぎて）。
細かい部分など（例えば同じような役割の関数のインタフェースが揃っていないとか）。
最近よく話題に上がるAIエージェントについても、同様かと思う。
あまりに速くアウトプットができるようになってくると、利用する人間側が追いつけなくなる。

 

確かにプロトタイピングなどの用途にはこの上ないほど相性が良い。
しかし実際の製品コードでは、AIを使ってアウトプット速度が上がっても、落ち着いて丁寧に作ることが重要だと感じた。
つまり、しっかり設計を人間のエンジニアがきちんと考え頭の中で方針を持ったうえで、あとは書くだけ状態でAIに生成させられるのがベストかなと。
＝きれいな設計は担保しつつ、AIのコーディング速度の恩恵を受ける。もちろん設計自体もAIに考えてもらうのも良い。ただその場合も、人間がちゃんとレビューできる必要がある。

 

この、人間がちゃんと生成AIの出力をきちんとレビューして活用するというのは当然重要なことだと思っているのだけど、最近以下のような主張をXで見かけた。
テストさえしっかり作れば、プロダクションコードの生成ではきちんとAIの出力を必ずしも理解しきらなくても良い、なぜなら仕様の正しさはテストで担保していて、修正の際はAIですぐに生成しなおせるから、というような趣旨のもの。
自分は、言いたいことはわからんでもないがそれは流石に違うだろうと思う。
そんなブラックボックスで良いわけがないし、ソフトウェア開発はそんな単純な話ではないはず。
生成AIのアウトプットをどう利用するかを決めるのは利用者だし、その利用結果の責任を取るのももちろん利用者。
エンジニアがきちんとプロダクションコードを理解できていなければ、
例えば問題が起きた時は一体どう関係者に説明し解決していくのか。
性能改善を行いたいときはどうやってボトルネックを分析して解決していくのかなど。
それすらAIに聞きっぱなしできちんと理解しないままなんとかするのか。
AIの進化のスピードは確かに凄まじく、エンジニア不要論にまで繋げる言論も見られるけども、少なくとも今の段階で賛成はできない。（ただし、生成AIを活用するスキルが無いエンジニアは少しずつ淘汰されてしまうかもしれない）

 

ソフトウェア開発の文脈において、（現時点では）AIはエンジニアを滅ぼすものではなくエンジニアが上手く活用していくもの。
上手くAIを扱えることはもはや必須スキル。
AIを道具としてきちんとコントロールしたうえで上手く活用していけるように、これからも頑張ろうと思う。