ポストモーテムは、開くのは簡単で、役に立つものにするのは難しい会議です。会議が開かれ、ドキュメントが書かれ、アクションアイテムが四つ記録され、そして六か月後に同じ障害がふたたび起きます。そのころ誰かが、まったく別のものを探している最中に、あの古いドキュメントを見つけることになります。 この話題では「非難なし」という言葉にほとんどの注目が集まります。その原則は実際に重要なのですが、失敗が起きているのはそこではありません。非難なしを厳格に守りながら、それでも何ひとつ変わらないレビューを回している組織はいくらでもあります。理由は単純で、レビューそのものを成果物として扱ってしまい、成果物を生み出すための手段として扱わなかったからです。 あな...
コード品質
コード品質に関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。
技術ドキュメントは、いつも決まった、そして予測のつくかたちで失敗します。誰かが二週間ほどの落ち着いた時期に大量に書き上げ、そのあいだにシステムのほうが変わり、誰も更新せず、一年も経てば、その文書は自信たっぷりに間違ったことを述べている状態になります。そこから先は、何もないよりも悪い状態です。書いてあることを信じた読み手が、すでに成り立たなくなった情報にもとづいて手を動かしてしまうからです。 これに対するよくある反応は、もっと書こうという号令です。ところがそれは同じ失敗を早めるだけで終わります。役に立つ反応は、書く量を減らし、そのうえで何を書くのかを選ぶことです。ここでの制約は書く手間ではありません。書いたあとに保守し続ける手間のほう...
開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされるか、という点にあります。 追いかける価...
API のバージョン管理をめぐる議論は、たいてい間違った側から始まります。バージョン番号をどこに置くか、という話です。実のところ、それはこの主題のなかでもっとも結果を左右しない決定です。本当に重要なのは、そもそもどの変更が新しいバージョンを必要とするのかであり、ほとんどのチームはここを、油断する方向に読み違えます。純粋な追加にすぎないと信じたものを出荷し、どこかのクライアントが壊れるのです。 使える考え方はこうです。あなたの API は、呼び出す側が何を当てにしてよいかについての約束にほかなりません。まっとうな呼び出し側が当てにしていたものを無効にしてしまうなら、その変更は破壊的です。そして呼び出し側は、ドキュメントが明示的に許して...
技術デューデリジェンスはコード品質のコンテストではありません。それにもかかわらず、これから受ける側のチームは、たいてい見当違いのところに時間を注ぎ込みます。会社を買おうとしている人間で、あなたの設計した抽象化に点数をつけたい人はひとりもいません。買い手が知りたいのは、このシステムを保有し続けるのにいくらかかるのか、そして資金が動いたあとにどれほどひどいことが起こりうるのか、その二点だけです。 この捉え直しが大事なのは、最初に直すべきものが変わるからです。見た目は汚いけれども動いていて、チームが中身を理解していて、安全に手を入れられるコードは、軽微な指摘で終わります。逆に、洗練されてはいるがひとりの人間しか理解していないコードは重大な...
データベース性能の改善作業は、たいてい誰かが「もっと大きなインスタンスにしよう」と言い出すところから始まり、そしてたいていは、ページを開くたびにひとつのクエリが400万行を順次スキャンしていた、という発見で終わります。制約はもともとハードウェアではありませんでした。制約は実行計画のほうにあったのです。 この筋書きは十分に繰り返し起きるので、既定の仮説としてはっきり言葉にしておく価値があります。アプリケーションが遅く、そのうえデータベースが忙しいのなら、原因はほぼ必ず、ごく少数の特定のクエリであって、処理能力全体の不足ではありません。そしてサーバーを大きくする対処は、テーブルがふたたび育つのに必要な時間のぶんだけ、問題を覆い隠してくれ...
ソフトウェアテスト戦略は、たいていカバレッジという数字で語られます。しかしカバレッジは、この分野全体のなかで最も情報量の少ない数字です。カバレッジ九十パーセントのコードベースであっても、最もよく使われる経路でバグを本番に送り出すことがあります。カバレッジが測っているのは、テスト実行中にどの行が実行されたかであって、その行について意味のある検証が行われたかどうかではないからです。 自分たちのテストスイートを信頼しているチームは、パーセンテージが最も高いチームではありません。本当に壊れているときにテストが落ち、それ以外のときは静かにしているチームです。そしてこの性質は、お金で買うのがはるかに難しいことが分かっています。 どんなテストにつ...
ソフトウェア開発ライフサイクル（通常SDLC）とは、チームがソフトウェアをアイデアから機能する保守済みプロダクトへと導くために従う構造化されたプロセスです。ソフトウェアを開発する側でも発注する側でも理解が重要で、プロセスの質が結果の品質・コスト・適時性を大きく左右するからです。本ガイドではSDLCをわかりやすく解説します。各フェーズとその内容、AgileとWaterfallの違い、プロジェクトが失敗しやすい箇所、そして優れたプロセスがコストとリスクをどう管理するかをご説明します。 まとめ ソフトウェア開発ライフサイクルとは、ソフトウェアの計画・構築・テスト・展開・保守を行う構造化されたプロセスです 古典的なフェーズは計画、要件定義、...
ウェブ開発のベストプラクティスは、単に動くだけのウェブサイトと、パフォーマンスが高く、検索順位で上位に立ち、長く使われるウェブサイトの違いを生み出します。2026年、基準はかつてないほど高くなっています。ユーザーは即座な読み込み時間を期待し、検索エンジンはスピードとアクセシビリティを評価し、セキュリティの脅威は絶え間なく続いています。良いニュースは、優れたウェブサイトを生み出す実践方法がよく知られているということです。このガイドでは、パフォーマンス、アクセシビリティ、セキュリティ、SEO、コード品質、テストの分野において、今日本当に重要なウェブ開発のベストプラクティスを、抽象的な原則ではなく実際に適用できる実践的なガイダンスとともに...
「技術的負債」の検索数は過去2年間で35%以上増加しています。この増加は主に、締め切りプレッシャーのもとで構築されたレガシーシステムを引き継ぎ、その維持・拡張に苦労している英国のエンジニアリングチームによって牽引されています。この用語はJiraのバックログやスプリントレトロスペクティブで曖昧に使われていますが、ほとんどの開発者は正確な定義を見たことがなく、ましてや体系的な対処戦略を持っているわけでもありません。 このガイドでは、技術的負債とは実際に何なのか、どこから生まれるのか、どう測定するのか、そして現実の英国プロダクトチームで効果を発揮する実践的な戦略について解説します。Ward Cunninghamの原型となったメタファー...