AIとの付き合い方

久しく執筆。以前から感じている内容を時流にのってAIと絡め、ChatGPTで推敲しながらまとめてみる。

AIによる進化

個人の生産性は大幅に上がってると感じる。従来なら眼前の設計とコードを脳内メモリに入れ込んで、具体的な値によるイメージなり挙動を考えながら実装箇所にフォーカスして脳と手を稼働させてきた。これが時には実質ゼロになり、概要と入出力、方針を伝えれば90点以上のコードが生成される。時間と疲労コストをかけて実装というリターンを得る流れをほぼ代替できてしまうのだから、結果として生産性は大きく向上している。

また、脳内でまだ完成形まで到達できていない実装に対しても、具体的なゴール足り得る実装を提示してくる。自分の例として、バックエンド実装においてはレイヤード、クリーンアーキテクチャ、DDDなど一定の設計技法観点からするとどのような実装であるべきか、これに対して、学習元である人類の叡智(?)を元に例や思考過程を示してくれる。ゲーム実装においては一見複雑なロジックを何の抵抗もなく実現し、これがまた問題なく動作する訳で正直魔法に見える。

一方で各所で散見されるような、AIが生成したコードのレビューコストの問題も存在していると感じる。従来であれば開発者がコストを払って実装したPRに対してコストを払ってレビューが行われ、現物のソフトウェアとして世に出ていた。それが昨今では、初手の実装者自身ですら把握できていないコードがPRとして作成され、場合によっては自ら実装すらしていない。反面、作成した製品に責任を持つという側面から、開発チームとしてのレビューコストを減らす判断はしづらい。

開発者の手元というミクロな点において多大な生産性を発揮している一方、開発チーム内部において、不具合や障害発生時にその主たる窓口にいるのは結局人間である現実は変わらない。そうなるとコードの質を担保するうえでレビューをしない、という選択肢までは取りにくい。CopilotやCodeRabbitやらによるレビューは可能だが、それはあくまでコードとしてのレビューであって、プロダクト仕様としての評価、レビューは厳しい。こういった現実を考えるとレビューコスト自体はまだ人の頭から切り離せないものと思う。

ここまでを挙げた上で主張したい点に移っていくと、体感として個人を超えた段階、組織としての生産性は向上しているのかという部分にある。

進化の側面と組織

仕事とは関係しない別業種の方に会うシーンがあった。曰く、普段の業務やメール連絡、資料作成、データ分析において、大いにAIを活用していた。しかし、その会社は所謂JTC組織で、AIまでいかずともデジタルツールについての距離感がまだまだ遠いらしい故、そういった業務最適化を行えているのは現場の一部のみに留まるとのことだった。IT関連企業にいればこそだが、やはり世間においてはまだまだ導入が始まりながらも進まないような過渡期の1ステップ目くらいなのだなという実例に思えた。

これまでの流れを振り返ると、この構造自体は決して新しいものではないように思う。

例えば、業務効率化の文脈で言えば、かつてはエクセルを導入、というのが身近に感じられるところか。それまで手作業で処していた計算を、自動化によって高速化し、個人や周辺単位での生産性は大きく向上したと思われる。個人レベルでの生産性は向上したはずで、その流れが間違いなく組織にも影響を与えているとは思うのだが、未だに新人が一人で現場業務を最適化するといった話が出てくる。森を見て木を見ずにはなるが、組織全体としての最適化に至れていないケースもある良い例ではないだろうか。

より構造的な話で言えば、オフショア開発のような取り組みも同様に捉えられないかと思うに至った。

人件費を抑えつつ開発リソースは拡張するという点では合理性がある訳だが、コミュニケーションコストや仕様理解のズレといった現場ドリブンの新たな課題が生まれ、結果として期待したほどの生産性向上に繋がらないことも観測されているように感じる。身近な例で言えば、ベトナムといった東南アジアの国への開発委託だろうか。経営者やビジネス担当からすると、現地開発者とチームへのコストと日本での開発者雇用コストを、金銭とリターンで比較していると思われるのだが、少なくとも自分の観測範囲では、これらの方式で大いに成功した例を聞くことは少ない。事業として成立せずに終了してしまうことはあるとして、結果として、そこで生み出された製品がビジネスを支えているシーンは見かけるのだが、品質や体制的に運用が苦しくなり後から抜本的な改修に着手するケースもまたよくあるシーンとして実感するところ。

近年ではDXという言葉のもとで様々なツールやクラウドサービスが導入されてきたが、これもまた「導入すれば自動的に改善される」というものではなく、ゼロ距離で向き合っている現場のみならず、組織としての理解や運用が伴わなければ形骸化するという課題が繰り返されているようにも思える。新しい技術が導入されるたびに、個人レベルの生産性は上がっているのだが、組織に広く影響を与えそれ前提の最適化が行われるかというと、そういうわけではないという構造を繰り返しているような印象がある。そして、現在起きているAIの波も、構造としてはこれまでの業務効率化やDXと見方は変わらないのではないかと思っている。

なぜなら、組織の生産性はひとりの作業速度だけで決まるものではないからだ。意思決定、レビュー、責任範囲、境界、共通理解、運用、外部折衝。そういった人間同士の接続部分が残っている限り、個人の生産性だけが上がっても、組織全体が同じ速度で前に進むとは限らない。

ボトルネックの正体

これまでの例を見ると、AIによる生産性向上を実現できる個人が集まれば問題ないようにも思えるが、問題はAIに明るくない人がいること自体ではないと考えている。当然ながら、全員がAIの専門家になる必要はないし、全員がプロンプトやモデルの仕組みに詳しくなる必要もない。

ボトルネックは、わからないから任せる、自分の領域ではない、と距離をとることで、組織の中にAIを前提とした共通言語が存在できないことにあるように思う。この 「わからない」ことへの距離感が主題ではないだろうか。

これはソフトウェア開発現場でもよく見られてきた構造だと感じている。

常々体感してきたことなのだが、開発者だけがシステムの都合を理解していて、ビジネス側やマネジメント層が「技術のことはわからないので任せます」という距離感でいると、物事はうまく進みにくい。一定量の業務経験がある方なら、こういった事象に直面したことがあるのではないだろうか。もちろん、全員がコードを書ける必要はないし、設計を理解できる必要はない。だが、ソフトウェアが事業の核にいる以上、どのような制約があり、何が難しく、どこにリスクがあるのかを共通認識として持つことが要点であり、そこに対しての課題感が残ったままでは意思決定の質は上がらない。

これが、AIにも同質なことを言えるように感じる。

一部の人だけがAIを使いこなし、積極的利用に至っていない人からするとよくわからないが便利な万能ツール、として眺めているだけでは組織全体の前提は変わらない。AIを使いこなす人が増えるだけではなく、AIを前提にした判断や会話ができる状態になって初めて、組織としての生産性が変わり始めるものだと考える。

必要なのは全体の底上げ

AIによって個人ができることは飛躍的に増え、質も向上している。コード、調査、文章、仕様整理。これまで時間や集中力を消費していた作業の一部は、既にAIによって代替されていて、ソフトウェア開発に限って言えば、1、2年前とは明らかに景色が変わった。

ただ、その変化がそのまま組織全体の変化になるかというと、まだ大きな隔たりがあるように感じる。過去にも、局所的に生産性を変えたり、事業のあり方を大きく変えうる技術や仕組みは何度も現れてきていた。しかし、それだけで組織全体が滑らかに変わったかというと、必ずしもそうではなかったように思える。

AIもまた、おそらく似た立ち位置なのだと思う。（とはいえ今回ばかりは本当にゲームチェンジャーというフシはある）

従来と同じ、一部の人だけが使いこなす便利ツールの延長となるのか。
はたまた、組織全体の前提や意思決定まで変えるものになるのか。

モデル性能やツールの数ではなく、わからないものとどう向き合うかという、人間側のスタンスが問われる状況だと考えている。

進む組織と停滞する組織の差は、AIを導入したかどうかではなく、AIを前提に自分たちの働き方や意思決定を変えようとできるかどうかに表れるのではないだろうか。

2025までの振り返り

2018以来ブログに触ることなく過ごしてきたが、何かを記録して残しておくことの価値を再認識し始めた。年始に連ねて有給を取っているというタイミングもあり、これまでの数年を書き出す
どうしても動きとして大きい所属や印象に残っているプロジェクトの話で、技術的な事はないに等しい

2018〜、転職、フリーランス、創業に参画

2018は思えば最も変化のあった年で、お世話になった前職の体制変更を機に転職、程なくしてフリーランスとして仕事をしていた知り合い（以後O）と関わり、その創業に参加するなど身の上が大きく動いていた。

ブログが放置になったのは当時の仕事忙しさや思うところもあったはずだが、個人事業主として動くに際して、それまでのような適当な主張の発信はかえってリスクになり得るというような考えを持った記憶がある。契約や関係値を築き始めるに際して、自分という個人を知る手段としてこの場は良くも悪くも働いてしまう可能性があると判断していた。今考えると別にそんなことはなく、むしろ世の中や関係値というのはもっと人間臭く利害で成り立っており、どんな形であれ自分を主張して自身の在り方を知ってもらうほうが結果としてポジティブに転がる事が多いのではないか、というのが所感になっている。

ちなみに2018までの数年は多様な技術（Scala, Unity C#, PHP, Rails, TypeScript, Go, ウェブ, ゲーム, VR）に触れた事もあり一定充実した時間を過ごせた思う。懐かしい。

転職

2018年での前職から一度転職しているため前職という表現は正しくないが、一度転職した某社は入社前後でかみ合っていない要素が明確だった。大した話でもないし時効（と勝手に思っている）なのでまとめてみる。

当時の自分は、より設計や実装に対して実践的な環境を得たかったのだと思う。自分を取り巻く環境とはチーム構成やプロジェクトのフェーズ他さまざま変数があるわけだが、開発するソフトウェアがより価値を生むためにはどのように考え、何を重視するべきなのかを開発者の実体験として得たかった。言い換えると、直近でプロトタイプや何を目指して重視するポイントがどこにあるのかが宙に浮いているプロジェクト、極少数の独力がすべてで構成されるチームを横断してきたことの裏返しでもあった。その点、この時分の転職では実装設計基板や、ある種横断的なチームとして動くことも期待されるようなポジションと認識していて、面接においても概ねそのような話をできていたように思う（このあたりはより踏み込んで会話をするべきだったのかもしれない）。

この期待値を持った入社後、新たに立ち上げ始めるプロジェクトの1構成員としてアプリケーション実装を任されることとなった。人員状況や背景説明としては理解できたように思ったが、如何せん実装がひどかった。2000年後半2010年代ソシャゲブームで各社の中にいた方にはある程度伝わると信じたいが、到底中長期を見据えた実装、一定程度実装手法としてヨシとされる実装などではなかった。当時の言語化が難しい部分もあるが、利用しているフレームワークのうっすらとしたMVCが見え隠れし、謎概念によって区切られたクラスで気合いという名の連想配列操作が行われる。漢はだまってstatic、クラスやインターフェースの利用は実行速度どうこう言い始める、PHPの使い方教えてあげますよと言わんばかりのこれらの状況を前に途方に暮れた覚えがある。

2週間もしない段階であったか、自分はメンタルを維持できなくなっていた。
その昔、経験の浅かった時に放り込まれた雑然としたあるべき姿の見えないソフトウェア開発現場そのものだった。そのような中においても、極一部の現場仲間には、もっとあるべきソフトウェア開発を目指す、こんなはずはない、そう考える一縷の光のような同僚の方々がおられた。彼らの背中から学び、情報科学を体系的に学んでいない自分が勉強の火種を絶やさず、あるべきキャリアを見定める先人となってくれた方々をイメージしたからこその現在、転職のはずだった。目の前に広がる状況に、数年分のキャリア後退を感じた自分には落差が大きすぎたのだと思う。

フリーランス

時を同じくして当時フリーランスとして既に開業しているOから連絡があり話をする機会があった。実質すでに細かな実作業を手伝っており、状況が状況なら直ぐにでも手伝って欲しい案件があるという流れだった。好機とはこういった事を指すのかもしれない、と、そう時間を掛けることもなく退職、開業、クライアント企業との契約までを進めた。当時まだ若く漠然と何かに挑戦する機会を見出したい、そして現状を意図せぬ後退と捉えていた自分にとって、それはありがたい話でもあった。そうして颯爽と開業した所からが、2026年現在の自分の源流となっている。

最初の案件はVR関連のスタートアップ企業様でバックエンド開発の仕事になった。こちらでは企画とプロト開発段階からリリース直後の段階まで関わらせてもらった。フロントエンドはUnity、バックエンドにRailsのAPIサーバー、GCP、Firebaseを利用した構成となった。途中からサービスのコンセプトが変わったと聞いたが、当初はエンドユーザーがVRアバターを利用して配信を行い、他ユーザーは配信に参加できるという形態だった。 バックエンドAPIの実装についてそこまで特殊な内容は存在せず、リアルタイムに配信を行う仕組みはUnity製アプリとFirebaseが大きく担っていた。サードパーティのリアルタイム音声通信サービスを利用し、事業としても開発リソースのコアとしてもその部分に重点があるシステムだった。元よりコンテンツ開発にUnityを利用してきたこともあり、双方のコンポーネントに知見を持っている自身の能力を発揮しつつ、設計やRails習得に時間をあてることができ、貴重な経験となった。
今考えると久しく実サービス運用から遠ざかっていたため、スタートアップ企業でのサービス開発と久しぶりに新鮮なシステム運用までを体験できた点も良かったのだと感じる。

今日に至るまで状況等をちょくちょく聞いてはいたが、最近になって結果としてこのサービス自体は継続しているものの、事業（会社だったか?）自体を売却する運びとなり、現在は当時の関係者も残っていない状態となっていることを知った。サービスを軌道に乗せる事の難しさや運営上のさまざまな苦難を見聞きした経験となった。

創業

2018年9月、Oが自分で会社をやりたいという意向を表明し話を持ちかけてきたので、なんだか面白そうで乗ることにした。 軽い気持ちでは決してなかったのだが、元々何か仕事を一緒にやろうという関係値でもあったし、仕事の話と共に現状を変えるきっかけになった人物であるので、自分の中では何かのピースがはまったのだと思う。また、折角何もない状態から参画するのだから「株持ってバリバリやろうや〜」というテンションにどこまでできるかは不明だった。だが、何かに前のめりにトライしてみる事が上手くなかった自分にはこれまた好機だったのだと思う。少ない割合ではあるが創業者を除き、会社の生株を持つ大株主会社員1号が誕生と相成った。

如何せん開発案件はあるが他は何もないので、何かと社長について動き回った記憶がある。フルリモートではあるが便宜上そして一応集まれるオフィスを借りたり、バックオフィス業務を任せれる伝手を探したり結局アウトソースしたり、ほとんどリファラルしかない採用の中でも稀にある採用面接等をしたり、紹介されたVCに会いに行って空中戦したり、名古屋だの北海道だの、案件未満のプロト開発は幾星霜…
振り返ると充実していたのかもしれない。本当に何かを求めてアクションを起こすとドーパミンというのは出るもんだ

そんな中、ほぼ創業タイミングから参画させて頂いた某英語学習サービスの企業様、また社内開発陣の皆様には本当にお世話になりました。 以後約4年半に渡って従事させてもらい、個々の能力・知識の高さから来る開発体験の質はとても学びがあり良かったと同時に、将来また一定規模の開発に従事できることがあれば、これを試金石とさせてもらうくらいの体験となった。良くも悪くも開発陣の能力や発言（実際その通りになるかは別として）、実行力がこういった形で発揮できていると、事業側としても将来像を描きやすいのではないかと感じた。 技術的には完全にバックエンドの運用開発だったが、実装言語の知識だけでなく設計や実装技法の実践、しっかりしたテストコードの実装、マイクロサービス、コードレビュー、検討議論など、至る所で限定的だったあるべき（と考える）ソフトウェア開発の実践、という感じで個人的にとても刺さった。今も関わる開発チームにこのレベルがあって欲しいと考える基準になっている。

2022年ごろから、会社事情もあり前述のVR関連の似て非なるサービスの開発に立ち上げから従事した。正確には学習サービス従事中から稼働していたが、諸々の検討がありこちらのスタートアップ企業様の支援に振ることとなった。
なし崩し的といえば聞こえはいいが、結果として開発ディレクター的な立ち位置をとることとなり、これが難儀した。直近でみてきた開発マネジメントを参考フレームワークとしてある程度実践する訳だが、チームの手数の少なさもありどうしてもプレイングマネージャーとなり消耗していった。アバター挙動の試行錯誤と実装、バックエンド実装、限られた記述から会話を始め要件定義をおこしドキュメンテーションとする。見積もりを行った上で各位のタスクとして分解、事業としての線として問題がないか、そこに差し込みタスクという割り込みが入るので、こうなってくると健全に進める事は無理だと感じた。もちろんこれは何よりも圧倒的な人手（予算）不足、特定業務遂行者への依存がなせる状況であったと感じている。所謂PM業をこなす人材がいれば…と何度考えただろう
状況そのものにそこまで異常性はなく、よく聞くスタートアップ企業のプロジェクトだと思うが、集った人間の性質的にも難しく感じた。

このあたりから、プロジェクト関係者に対してもソフトウェア開発の難しさを理解してもらって寄り添ってもらえることの重要性を体感理解したように感じる。
「開発はわからない」という建て付けで思考を止める/丸投げをすると、話そのものが停滞する。この、わからない、をわからないなりにかみ砕き、意思決定者が言及するべき要点がどこにあるのか、をわかるまで思考することがソフトウェア知識がない人間にも求められる事ではないだろうか。
世のビッグテックにソフトウェアの本質がわからないトップはいるだろうか？ハウルの動く城のように、いとも簡単に転ぶ言ってしまえば商材が事業のコアにある、という事実をわかっているからこそ開発リソース（人、モノ）競争に投資しているのではないだろうか。 アーロンじゃないが、おまえが始めた物語なのだから、最善をいくならば自分の視座を変えるしかない、と考えるに至っている。（大佐も似たような事を言ってた気がする

2022〜、所属変更

立ち上げに参画したOの会社はいくつかの買収話を経て現在の企業に着地となった。幾らか見てきた視点からすると、信用の開発会社というのは、金はあるが実行部隊はいない企業にとって価値があるのだと思う。
少し前だとDXがどうのだの直近ではAIがどうのだとよく耳にする訳だが、昔から分かりやすいワードというのは流行る。オフショア、クラウド、ビッグデータ、Web3、もっといくらでもあるだろう。既に存在している経営課題を分かりやすく言い換えてるだけだったりする訳だけど、金のある企業は、とにかく気持ちよく丸投げれるソフトを扱う組織、というのを求めていそうだと感じた。青い銀行や諸々の失敗事案が存在するからこそ、少しでも評判のある会社や集まりに課題改善や案件を投げて安心したい、という流れが根底にあるのではないかと勝手に思っている。
ただ流石にAIの波は、これまでよりビッグウェーブであり、上手い付き合い方の模索は必須と感じる。今はまだソフトウェア開発の全てを丸投げはできない（だからこそ使い勝手悪いんだが）が、10年後には行間を読む能力を得て、文字通り全てをこなすようになるかもしれない。人間1人との出力差は比べるまでもないわけで、じゃあどうするか考えていく必要はあるんだろう。

さておき、会社買収により3年強ほど前から新しい所属となり、久々のブラウザゲーム開発、関連企業との協業コミュニティサイト開発などをこなしてきた。
前者はなぜか2D格ゲーを再実装してゲーム実装楽しいよなーとか自己満足していた。後者は、ある程度自由に開発していい、との事だったので、ようやくGoで全面的に設計実装に取り組み、フロントたるアプリはReact Native (Expo) でしこしこインプットと実践を行ってきている。人手がないため自分でAWSにECSクラスタ環境構築などを実践して満足しているところだ。ただし、壁打ち相手がチャッピーになってしまっているので、もう少し技術的な満足感を得たいところではある。

そんなこんなで2026年を迎えるに至った。既に苦楽(?)を共にしたOや数名は退社しており、今後の会社の行く末を見守りながら、自らのキャリアに思いを馳せている状況となっている。

その他最近のこと

投資

2023年からNISAを始めて資産運用に興味を持った。個別株や米国株に手を出したのは少し後だが、ETFなどよく言われる運用をしている。ちょうどここ2,3年というのは、黙ってても右肩上がりに資産が増えたり、トランプの発言に振り回されて暴落したり、いろんな波があったのだが、同時に経済は成長するものということを実感していた。知り合いつての元証券マンに本を頂いたり、ソフトウェアだけでなく別の世界が見えることそのものが楽しく、世の中の情報にも興味を持つことが増えた。
よく言われる事かもしれないが、金や経済の話はもっと義務教育に含めるべきだと思う。就職して働いてxxx、金がxxx、すべて経済活動、金なんじゃないか？金で得られないもの、金が支配しているもの、両輪でもって世の実態に即した本質を等しく教えられるべきだとは感じる。（言語化が上手くない）

ゲーム開発

一時期から自分でゲーム開発を行っている。
作りきる事が大事、とよく言われる訳だがご多分に漏れず自分もそのハードルを理解はしていたため、ひとまず作りきってリリースまでこぎ着けた。特段注目するところもないシンプルゲームなので宣伝もしないが、確かにやりきる事は大事であると同時に、自分なりのゲーム開発の流れのようなものを一巡することができた。
開発プラットフォームにUnityを利用しており、ゲーム設計とC#実装の実践を自由にやれる場となっている点も個人的にはすごく丁度いい。こと仕事でのゲーム開発となるとDが謎の仕様を定義したり、XX感など定義不能なアウトプットに振り回されるシーンが多い認識なのだが、個人で開発する分には自分が監督であり仕様となる。ソフトウェアを開発する気持ちよさ、自分の感性で形をつくれる良い場になっていると言える。アセットをどうやって用意して組み合わせていくかなど毎度悩ましい所はあるが…

個々数年はPCでゲームすることがほとんどのため、次回作はSteam向けゲームを出していこうと画策し絶賛企画開発中だ。Steamは最近特にインディーゲーが多く出ており、ともすれば無名作品は簡単に埋もれてしまう状況にあるが、稀に大ヒットする作品が生まれる土壌でもあり、一定の狙いとクオリティでバズる夢を目指して開発してみるのも悪くないと信じて実践している。100万本売れてぇ

世の中や社会について

ひょんなことから浜崎洋介先生を知り、2025年末からその言論(Youtube)をよく見ている。何が面白いかというと、日ごろ意識していない事柄に対しての言語化という部分で興味深かった。
例えば、日本人はなぜ空気に弱いのか等。歴史や人文の観点から納得感のある説明をされている点が、自分がこれまで見てこなかった分野であり、先述の投資のように新たな世界を見ている気になっている。もう少し深堀して自分の血肉にしていきたい所

まとめ

当然ながら数年ぶりだとあまりに書ける内容が多く、また忘れている事も多い、そして詳細が書けない。定期的に細々出力していこうと考えている。2026年に特別目標などないが、所属企業の如何によっては自分のキャリアを再度見つめるシーンが訪れるかもしれない。

無難に健康で実りある1年にしよう。

今更プログラミング言語Goを読んだ

諸般の事情につきGoをしっかり復習するべく読んでました。
2016年に出版された翻訳版ということもありGo1.5だったり若干時間を感じてしまいますが、もとよりミニマムな言語仕様で、後方互換も多分問題ない言語ということで現行1.11を触りながらでも何ら考慮することなく読了できました。2018年現在たくさんの使用例が記事として公開されていてその中でも表面的に新しい技術的な取り組みが見えるwebサービス系の事業でよくGoを目にします。が、本書最後にもあるように特定分野に限らずシンプルな言語機能で統一した記述ができるとても良い言語だと思います。

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES)

以下目についた章の雑多な所感

1章チュートリアル

かなり基本的なことが書いてあってこれから学習する人なら写経しながら読解すると良いと思う。Tour of Goとさして変わらないというか、構造体の埋込等にはこの段階では言及されていないので本当にさらう程度に読み進めていけば良さそう。

2章プログラム構造

恐らくどのプログラミング言語でも出てくる基本的な項目、代入や宣言、定義方法、パッケージとファイル作成、参照方法等諸々が懇切丁寧に書いてある。浅く仕事でもGo書いたのである程度理解が及んでる範囲だった。それでもパッケージングにおいてグローバルスコープに定義している変数に対して 変数, err := で代入したときに実は代入されてないなどの記述があり学びがあった。

4章コンポジット型

特にスライスが参照であるみたいな概念がよく理解できるので配列との違いや基本をもう一度理解したいみたいなときに写経していくと良さそうだった。構造体自体は複雑なものでないし問題なく読めたが、埋め込みは他の言語に見たことはなかったので復習になった。実際コードを読む際、埋め込まれている構造体が意味合い的に理解しうるものであれば良いのだが、構造体間の関連が汲み取れない実装を目の当たりにすると苦労しそうな気もする。この辺はクラスベースな言語におけるクラス設計そのものなので言語の表現力というよりも設計/実装力を問われる範囲だと思う。

5章 関数

エラーハンドリングしっかりやりなさいの旨が書いてある。実際Goで実装していくと err != nil 何回書くんだろうと気が滅入ってくるけど、起きうるエラーはインターフェースでありそのapiの振る舞いであるという方針が割と理解できた気がする。このerrorの扱いに関してはなんとなく受け入れて読み書きするよりも思想を理解していることが大事そう。

6章 メソッド

構造体の使用例とメソッド式が地味に学びがあった。構造体の埋め込みは良さそうな使用例をいまいち見たことがなくて単にstruct単位でまとめるというクラス定義の延長という程度のものという理解のもと見ていたけど、以下のような Cache は簡潔に埋め込みの適用例だなーと若干良さを感じた。

type Cache struct {
    sync.Mutex
    mapping map[string]string
}

メソッド式はこれまであまり使用例を見なかったのもあるが、愚直な実装を続ける限り使用することはほぼないが実装表現の幅として知っておけて良かった。

7章 インターフェース

局所的には interface{} でがんばるみたいな印象がある。

• 比較不能な型が入っていた場合 interface{} 型の比較はパニック起こす
• 動的な値が nil であってもレシーバはnilでなく if value != nil が意図しない動作となる場合もある

あたりは学びがある気がしていて、割とはまる箇所になりえそう。
実装を一つしか持っていないインターフェースは不要な抽象化ですというのはすごく同意で、実際の業務におけるコードでも如何様な設計思想に則ったのか細かなインターフェースを定義している割に実装は一つで、ユニットテストの実装時に利用してるかと思いきやノーテストでフィニッシュしてるケースを見たこともある。インターフェースの定義に限らずカジュアルに抽象を増やす実装がいけてないという認識は実現場にはないのが実情？

9章 並行性

race conditionとそのたgoroutineについて。競合に立ち向かうためにどうするかという手段として、単一のgoroutineに閉じ込める/相互排他する、という解説。CPUや各コンピュータリソース要因によってgoroutineの並行性を説明する箇所は学びがあった。
メモ化あたりは手を動かさないと理解に至らない感じあるので実践してきたい。goroutineとOSスレッドの差異はスタックサイズ、スケジューリング、GOMAXPROCSの影響とかがさらっと書いてあってあとでググって深掘りしたい。

11章 テスト

ランダムテストって必要なのか…？という感じもあるけど一応紹介されてるのでそういう手法もあるという理解で良さそう。実際仕事のコードでランダムテスト実装してPR送っても必要なのか議論になりそうな所感もある。ホワイト/ブラックボックステスト、あたりの話はテスト実装の技法としてprivateメソッドの実装をどこまでかっちりやるかとかモック実装方法（ライブラリ導入含め）、テスタビリティを考慮した設計等を問われる話しにもなるのでなかなか問の多い箇所だと思う

リフレクションその他

これまで低レイヤーに潜るような実装は避けてきているつもりなのでreflectパッケージとか無縁なわけで、というかアプリケーションを書くというコンテキストに置いてはそれで最善であるという信念すらあるわけですが、特段使い所を見極めて必要に応じて効果的にリフレクションを使えるようにはなりたいなーというモチベーションもワンチャンあることもあります。そんな稀有な機会のために必要事項を解説してある。周知の通りなんでもできるので下手に手を出すより先既存ライブラリやオフィシャルの実装コードを見て利用例を学ぶのが得策かなーという印象。
リフレクションを用いることでコンパイラを頼りにできなくなるし、静的型付き言語たるGoを選択したモチベーションから離れてしまう認識は必要そう。章末尾に記述されている通り。