GoogleでGoogle CloudやGeminiに携わるソフトウェアエンジニアのアディ・オスマニ氏が、Googleで約14年間働く中で得た「21の教訓」を自身のブログで公開しました。オスマニ氏は当初「良いコードを書くことが仕事」だと思っていたものの、長く働くほど「活躍するエンジニアは必ずしも最高のプログラマーではない」「コードの周りにある人間関係・社内政治・認識合わせ・曖昧さを乗りこなせる人が伸びる」と実感したとのことです。
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？ - GIGAZINE
⇧ 長期的に考えた場合に、フェーズにも依りけりな気がしますが、
- 複数人での「開発」である
- 「保守・運用」を考慮している
といった場合は、
◆9：遅さの原因は認識ズレ
遅延の原因を実行力や技術のせいにしがちですが、実際は「他の人との方向性・役割分担のつなぎ目・優先度の不一致が原因であることが多い」とオスマニ氏は指摘。経験のあるエンジニアほど「速くコードを書く」より「認識合わせ」に時間を使うのはそこがボトルネックだからだとしています。
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？ - GIGAZINE
◆12：書いて理解を固める
ドキュメントを書いたり発表したりレビューで説明したりAIに向かって整理して話したりする中で「うまく説明できない部分がまだ理解できていない部分」だとオスマニ氏は述べています。
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？ - GIGAZINE
◆13：誰かを支える仕事は可視化する
ドキュメントの整備・新人の立ち上げ支援・チーム間の調整などは重要ですが、無自覚に抱えると燃え尽きやすいとのこと。時間を区切る・持ち回りにする・成果物に変えるなどして可視化すべきだとしています。
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？ - GIGAZINE
◆16：「分からない」が安心を作る
経験のある人が不確実性を認めると周囲が質問しやすくなり前提も検証されます。逆に「分かったふり」の文化では問題が隠れ、爆発しやすいとのことです。
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？ - GIGAZINE
⇧ あたりが特に意識されていないと、カオスな状態になりますな。
後は、
◆19：工程は不確実性を減らすために存在する
オスマニ氏は「良い工程やルールは調整を楽にし失敗したときのコストを小さくする一方で、悪い工程やルールは責任追及のための形だけの作業になりがち」であり、リスク低減や明確化と結びつけて説明できない工程は負担でしかないと述べています。また、作業そのものよりも記録することに時間を費やしているのであれば「何かが根本的に間違っている」と指摘しています。
Googleで14年間働いたエンジニアが語る「活躍する人がコード以外で意識している21の教訓」とは？ - GIGAZINE
⇧ このあたりの「可視化」がされていないと、誤った「方針」で作業することになったりして、作業の「抜け漏れ」や「余計」な作業を実施してしまいがちなので、「開発業務」の「透明性」を担保するためにも、「開発」に関わる「ステークホルダー」間で、
- やること
- やらないこと
を「視える化」して共有して「不確実性」を減らすようにした方が良い気はするのよね...
結局のところ、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される。
⇧ 上記の考えに行き着く気はする。
- 「認識齟齬」が積み重なっていくこと
- 「車輪の再発明」が繰り返されること
- etc...
を回避するには、「ドキュメント」化による「ナレッジマネジメント」が重要になって来るような気はしますな...
ナレッジマネジメント（英語: knowledge management(en)）とは、企業が保持している情報・知識と、個人が持っているノウハウや経験などの知的資産を共有して、創造的な仕事につなげることを目指す経営管理手法。
⇧ 上記の考え方は「開発プロジェクト」にも活用した方が良い気はしますが...
まぁ、リリースされた「システム」乃至は「サービス」が廃止されるまで責任を持って面倒を見てくれることが確約されているのであれば、「属人化」するのも構わないとは思われるのだが、往々にして人事異動などで「引継ぎ」が発生することになることが多いですからな...
また、「開発ベンダー」によっては、意図的に「保守・運用」を困難にさせる「設計」をしたりするという話も聞きますしな...
そりゃあ、「開発」した「システム」にかかった「コスト」を、「保守・運用」で「回収」したくて自分たち以外が「保守・運用」をし辛いように「設計」、「実装」したくなる気持ちも分からないでもないが、「技術」には誠実であって欲しいところですな...
SQLアンチパターンでフラグによる論理削除を活用しているんだが...
図書館で、「SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策（著：Bill Karwin）」が借りれるようになったので、漸く読むことができました。
初版は、2013年1月26日に出版されたらしいのだが、第2版は、2025年7月11日に出版されたらしいので、12年の歳月を経ていることになる。
12年という期間は、日本だと、
- 1人の人間が誕生して小学校を卒業する年数でもあり
- 干支が1周する年数でもあり
- オリンピックが3回は実施される年数でもあり
といった感じで、時の流れを感じるには十分な年数である。
で、先輩の知見を学ばせていただく所存でございますと、読み進めたらば、「アンチパターン」回避のために「フラグ」による「論理削除」が活用されていた...
SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策
該当箇所は、「11章 サーティワンフレーバー（31 のフレーバー）」になるのだが、「11.5.3 廃止された値のサポート」で「フラグ」の役割を持つ「列（カラム）」によって「論理削除」を実現していた。
で、
- フラグ
- 論理削除
のどちらが悪いのかが分からないのだが、
⇧ 上記サイト様にありますように、「SQL」の「アンチパターン」の話になると、しばしばと言うか、結構な頻度で、
- フラグ
- 論理削除
についてが議論に上がっているように思われる。
基本的には、「フラグ」による「論理削除」を導入しない方が望ましいと思われるのだが、他に代替手段が無い場合は、消去法として導入せざるを得ないということなんですかね？
「SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策（著：Bill Karwin）」の「11章 サーティワンフレーバー（31 のフレーバー）」で紹介されているように、他の「トランザクション」系の「テーブル」から参照されてしまっている「マスター」系の「テーブル」だと「論理削除」するしか無さそうってことなんかね？
「トランザクション」系の「テーブル」であれば、「履歴」用の「テーブル」を別に用意して積み上げていく形で過去の「状態」を管理することができるんだろうけど、「マスター」系の「テーブル」の場合も同様に管理していけば良いのかしら？
このあたりの話については、スルーされているような気がしてならないが、「SQLアンチパターン」で「アンチパターン」の回避策として紹介されているっぽいので、有識者の方に解説してもらいたいところですな。
まぁ、他の「テーブル」に依存しないのであれば、「物理削除」で解決できると思うのだが...
ネットの情報を漁っていたところ、
⇧ 上記サイト様で、考察をまとめてくださっておりました。
とりあえず、「開発」対象の「システム」と「データベース」の「テーブル」の「設計」に依りけりという感じになってくるということですかね。
「論理削除」を実現している「フラグ」を「削除フラグ」と捉えた場合、必ずしも「削除フラグ」の導入が「NG」とも限らないということですかね...
ちなみに、
⇧ 上記にあるように、2025年12月頃に、
『削除フラグはその誤解の結果として生まれた実装上の逃げ道にすぎない。』
という「パワーワード」が出ているのだが、具体的な「設計」の代替案は提案されていないのよな...
まぁ、「言うは易く行うは難し」なのだろうけれど、
- AS IS（現在の姿）
- TO BE（理想の姿）
の「設計」を具体的に提示して欲しいよね...
とりあえず、『それを考えるのがエンジニアの仕事』っていう「逃げ道」は無しでお願いしたいものです。
毎度モヤモヤ感が半端ない…
今回はこのへんで。
