私のキャリアを通じて、ソフトウェア開発は「伝統的な」エンジニアリングと比較されてきました。それは通常、ソフトウェア開発者が適切な仕事をしていないことを叱責するような意味合いで使われます。電子工学の学位を取得した者として、私はキャリアの初期段階でこの考え方に共感していました。しかし、この考え方は誤っています。なぜなら、ほとんどの人はエンジニアリングが実際にどのように機能するかについて誤った印象を持っているからです。

テスト駆動開発（TDD）は、テストを書くことによってソフトウェア開発を導くソフトウェア構築手法です。これは、1990年代後半にケント・ベックによってエクストリームプログラミングの一部として開発されました。本質的には、以下の3つの簡単なステップを繰り返します。

リグレッションバグとは、以前から存在していたソフトウェアの機能に新たに現れたバグのことです。それらを調査する際、通常はソフトウェアのどの変更がそれらを発生させたのかを特定することが重要です。その変更を調べることで、バグがどこにあり、どのように修正するかについての貴重な手がかりが得られます。この形式の調査にはよく知られた用語はありませんが、私はそれをDiffデバッグと呼んでいます。

生成AI、特にLLM（大規模言語モデル）は、一般に広く知られるようになりました。多くのソフトウェア開発者と同様に、ビルギッタは可能性に興味をそそられていますが、長期的には私たちの職業にとって具体的にどのような意味を持つのか確信が持てていません。彼女は、このテクノロジーがソフトウェアデリバリーの実践にどのように影響するかについての私たちの取り組みを調整するために、Thoughtworksで役割を担っています。このページでは、彼女と同僚が学び、考えていることを説明するための一連のメモを掲載しています。

分散システムは、プログラムに特有の課題をもたらします。多くの場合、データを複数コピーする必要があり、それらを同期させ続ける必要があります。しかし、処理ノードが確実に動作することを期待することはできず、ネットワークの遅延によって簡単に矛盾が生じる可能性があります。それにもかかわらず、多くの組織はデータストレージ、メッセージング、システム管理、および計算機能を取り扱うさまざまなコア分散ソフトウェアに依存しています。これらのシステムは、同様のソリューションで解決する共通の問題に直面しています。2020年、ウンメッシュ・ジョシはこれらのソリューションをパターンとして収集し始め、開発に合わせてこのサイトに公開しました。2023年、これらは書籍『Patterns of Distributed Systems』として出版されました。このページには、各パターンの短い概要へのリンクと、oreilly.comでのオンライン電子書籍出版の関連章への深いリンクがあります。

伝統的なリベラルアーツの学位は、プロダクトマネージャーにとって非常に重要なスキルを提供します。

React UIコントロールがより洗練されるにつれて、複雑なロジックが視覚的な表現と絡み合う可能性があります。これにより、コンポーネントの動作について推論するのが難しくなり、テストするのが難しくなり、異なる外観が必要な同様のコンポーネントを構築する必要が生じます。ヘッドレスコンポーネントは、すべての非視覚的なロジックと状態管理を抽出し、コンポーネントの頭脳とその外観を分離します。

テクノロジーを有効に活用するには、テクノロジーに関する考え方を根本的なビジネス計画と一致させる必要があります。テクノロジー戦略は、ビジネスとテクノロジーを適切に統合することで、この整合性を促進できます。私たちは、戦略的イニシアチブの共通の側面を認識することに基づいて、この戦略的思考を支援するための概念フレームワークを開発しました。これにより、11の一般的な戦略的方向性を特定できます。各方向性について、提起する主要なビジネス上の質問と、テクノロジーの影響を調査するために行う必要がある調査を概説します。このフレームワークは、より効果的なテクノロジー戦略につながるだけでなく、テクノロジーがビジネス思考に情報を提供し、新しい収益源を開発することを可能にすることがわかりました。

開発者がAPIからのJSON出力を次々と誇らしげに表示している「デモ」に参加したことはありませんか？その間、ユーザーは混乱し、気が散って、それを理解することができませんでした。開発中にAPIを使用しようとして、機能テストをできるようにするための正しいJSONペイロードとヘッダーの呪文を見つけるのがどれほど難しいかに不満を感じたことはありませんか？デモフロントエンドは、そのようなAPIをデモンストレーションおよび探索するための基本的な機能を提供するシンプルなUIです。

大企業向けのソフトウェア資産のような、大規模なソフトウェアの取り組みには多くの人が必要です。そして、多くの人がいる場合は常に、それらを効果的なチームに分割する方法を考え出す必要があります。ビジネスケイパビリティ中心のチームを編成することは、ソフトウェアの取り組みが顧客のニーズに対応するのに役立ちますが、必要なスキルの範囲がそのようなチームを圧倒することがよくあります。チームトポロジーは、マシュー・スケルトンとマヌエル・パイスが開発した、ソフトウェア開発チームの組織を記述するためのモデルです。これは、4つのチーム形式と3つのチームインタラクションモードを定義します。このモデルは、ビジネスケイパビリティ中心のチームが、価値のあるソフトウェアの安定した流れを提供するというタスクにおいて成功するための健全なインタラクションを促進します。

Two Pizzaチームは、特定のビジネスケイパビリティ向けのソフトウェアを完全にサポートする小規模チームです。この用語は、Amazonがソフトウェアスタッフを組織化する方法を説明するために使用されたことから普及しました。

プラットフォームチームは、プラットフォームの採用を確実にするために他のチームに独自に依存しています。他のチームのコードベースにコード変更を取り入れることが、彼らの成功に不可欠です。チーム間のコラボレーションにはさまざまなパターンがあり、適切なパターンを選択するかどうかは、プラットフォームの採用段階と、外部の影響を受け入れるチームとコードベースの両方の能力の両方に依存します。

Xapoは、ビットコインサービスプロバイダーとして設立され、オンライン銀行に発展しました。この移行中に、ソフトウェア資産を再評価し、将来を導くためのアーキテクチャ機能を確立する必要がありました。ドメイン駆動設計、チームトポロジー、およびアーキテクチャアドバイスプロセスのアイデアを取り入れて、アーキテクチャアドバイスフォーラムを開発しました。これにより、ソフトウェアデリバリーチームの連携が強化され、一貫性のあるテクノロジー戦略が実現しました。

私たちは、「Boba」と呼ばれる、製品戦略と生成的アイデア創出のための実験的なAIコパイロットを構築しています。その過程で、これらの種類のアプリケーションを構築する方法について役立つ教訓を学び、それをパターンとしてまとめてきました。これらのパターンにより、アプリケーションはユーザーが大規模言語モデル（LLM）とより効果的に対話できるようになり、プロンプトを調整してより良い結果を得たり、複雑な会話フローのパスをナビゲートしたり、LLMが利用できない知識を統合したりできます。

モジュール型アーキテクチャはソフトウェアデリバリーを改善できますか？はい！ - ただし、いくつかの注意点があります。この記事では、成長痛を和らげるために、アーキテクチャをよりモジュール型のものに移行しようとした企業の道のりをまとめています。彼らは、モジュール性はアーキテクチャだけでなく、ビジネスコミュニケーション、チームトポロジー、および効果的な開発者エクスペリエンスにも拡張される多面的なソリューションであることを発見しました。これらの要素に注意を払うことで、企業はモバイルアプリケーションの配信パフォーマンスを大幅に向上させることができました。

プライバシー保護技術（PETs）は、ソフトウェアやシステムによって処理、保存、収集されるデータの対象となる人々のプライバシーや機密性を高める技術です。価値があり、すぐに使用できる3つのPETsは、差分プライバシー、分散・連合分析と学習、および暗号化計算です。これらはプライバシーに対する厳格な保証を提供するため、個人データの侵害を最小限に抑えながらデータを提供するためにますます普及しています。

従来のフレームワークベースの依存性注入に対する不満に基づき、モジュールにコンテキストを注入するために、部分適用を利用した構成戦略を採用しました。設計プロセスとしてのテスト駆動開発と、クラスよりも関数に焦点を当てることを組み合わせると、モジュールは明確でクリーンな状態を維持でき、意図しない結合をほとんど防ぐことができます。

経験豊富なテクニカルライターが、いくつかの執筆プロジェクトでChatGPTを補助として使用することを模索します。彼は、ChatGPTが下書きや追加コンテンツのプロンプトを通じて時間節約を提供できることを発見しましたが、正確さと深さに欠けており、楽観的な調子であることも認めました。全体的に、反復的に作業し、よく作成されたプロンプトで小さな塊を求める場合は便利です。

Stable Diffusionに「テクニカルライターの肖像」を依頼

徐豪との社内チャットでの私の記録。彼は、ChatGPTを駆使して自己テスト済みの有用なコードを生成する方法を示しています。彼の最初のプロンプトは、LLMに実装戦略（思考連鎖プロンプト）を仕込みます。彼のプロンプトは、コードではなく実装計画（一般知識プロンプト）も求めています。計画ができた後、彼はそれを使用して実装を改善し、有用なコードセクションを生成します。

タイムボックスイテレーションにおける一般的なアプローチは、関係するスタッフの利用率を最大化するために、各イテレーションに可能な限り多くのユーザーストーリーを割り当てることです。余裕時間とは、ストーリーに割り当てられていない時間を意図的に残し、その時間を計画外の作業に使用するという方針です。これは非効率に見えるかもしれませんが、通常、チームの生産性を大幅に向上させます。

タイムボックスイテレーションは、特にアジャイルソフトウェアプロジェクトに関連して、プロジェクトの作業を分割し、スケジュールする方法です。チームは、ソフトウェアの目に見える機能をユーザーストーリーに分解し、時間を固定期間（例：1週間）に分解します。これをイテレーションと呼びます。次に、ストーリーをイテレーションに割り当てることで、ストーリーをスケジュールします。チームがイテレーションにどれだけのストーリーが収まるかを把握できるように、ストーリーは大まかに見積もられます。

継続的なフローは、アジャイルソフトウェア開発によく関連付けられる、作業をスケジュールするためのアプローチです。チームは、ソフトウェアの機能をユーザーストーリーに分解します。次に、これらのストーリーを大まかなリストに優先順位付けします。その後、チームはこれらのユーザーストーリーの一部を取り出し、作業を行います。1つ完了したら、リストから次のストーリーを取り出します。

BGGで新たにトップ評価を獲得したゲームを評価する

確立されたUIパターンは、UI設計における複雑な問題を解決する上で実証済みの有効性があるにもかかわらず、フロントエンド開発の世界では十分に活用されていないことがよくあります。この記事では、確立されたUI構築パターンをReactの世界に適用する方法を、メリットを示すためのリファクタリングジャーニーコードの例とともに探ります。応答性と将来の変更を向上させるために、レイヤーアーキテクチャがReactアプリケーションを整理するのにどのように役立つかに重点を置いています。

レトロスペクティブ、または人々が議論し、議論から学ぶことになっているあらゆる種類の会議を使用している場合、時々、効率の悪いセッションを経験したことがあるでしょう。それは不思議ではなく、ほとんどの人に起こります。この記事では、これらの不幸な状況の3つ、つまり、洞察の生成をスキップする、変更できないことに迷ってしまう、そして大声で主張する人に支配されるという状況について説明し、解決策を提供します。

加速するとは、より速く動くこと、スピードを上げることです。現代社会で成功したいと願うすべての組織にとって、データを効果的に扱うことは重要であり、データメッシュは、組織がデータから大規模に価値を実現する方法を示しています。データメッシュ加速ワークショップは、チームと組織がデータメッシュの変革を加速するのを支援します。現在の状況を理解し、次のステップがどのようなものになるかを探求することによって支援します。

2022年に購入したお気に入りの新曲6曲