技術ドキュメントは、いつも決まった、そして予測のつくかたちで失敗します。誰かが二週間ほどの落ち着いた時期に大量に書き上げ、そのあいだにシステムのほうが変わり、誰も更新せず、一年も経てば、その文書は自信たっぷりに間違ったことを述べている状態になります。そこから先は、何もないよりも悪い状態です。書いてあることを信じた読み手が、すでに成り立たなくなった情報にもとづいて手を動かしてしまうからです。 これに対するよくある反応は、もっと書こうという号令です。ところがそれは同じ失敗を早めるだけで終わります。役に立つ反応は、書く量を減らし、そのうえで何を書くのかを選ぶことです。ここでの制約は書く手間ではありません。書いたあとに保守し続ける手間のほう...
記事
すべての記事を一か所で閲覧。AI、プログラミング、セキュリティ、インフラ、Web 開発に関するチュートリアルや解説、ガイド、更新情報を見つけましょう。
開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされるか、という点にあります。 追いかける価...
稼働率SLAは約束のように見えて、実際には返金規定のように振る舞います。提供側はそれを知っています。契約する側は知らないことが多く、可用性を買ったつもりでサービスレベル契約に署名しますが、実際に買っているのは、可用性が得られなかったときに受け取れるわずかな割引です。 それが必ずしも悪い取引だというわけではありません。ただ、多くの人が結んでいるつもりの取引とは別の取引であり、その違いはシステムが止まって、契約には何と書いてあるのかと誰かが尋ねた瞬間に効いてきます。 スリーナインは完璧に近く聞こえますが、月に43分の停止を許容します。 フォーナインが許容するのは4分です。平日の午後に43分の障害を吸収できる事業なら、99.9%で十分であ...
ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。 不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。 署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰かがそれを実際に動かせるでしょうか。ビル...
請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。 リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいるのか、そして移転の対価を払う価値があるの...
小規模なチームにおける災害復旧は、たいていの場合、誰も開いたことのないドキュメントの中の一行で終わっています。バックアップは有効になっています、という一文です。その記述自体は事実ですが、何かの答えになっているわけではありません。実際に障害が起きたときに戻ってくるデータがどれだけ古いものなのか、復元にどれくらいの時間がかかるのか、そしてこれまでに誰か一人でも最後まで復元をやり切ったことがあるのか、そのどれについても何ひとつ語っていないからです。 バックアップを持っているという状態と、実際に復旧できるという状態のあいだには、はっきりとした隔たりがあります。ほとんどの障害が本格的なインシデントへ変わるのは、まさにその隔たりの中でのことで...
コンテンツプルーニングは、検索最適化のなかで最も直感に反する作業です。ページが増えれば流入も増えるはずだ、という感覚が誰の頭にもあるからです。記事を公開する行為は資産が積み上がっていくように感じられます。ところが記事を消す行為は、誰かが費用を払って作らせた仕事をそのまま捨てているように感じられます。だからこそ、削除は最後まで先送りにされ、増え続けるページの山だけが残ります。 削除が効く仕組みは単純で、自分のサイトのページ同士が競合しているという一点に尽きます。自分のページのうち二本が同じ検索意図を狙っていると、本来なら一本に集まっていたはずの評価が二つに割れます。そして、どちらを見せるかを判断しなければならない検索側の仕組みが、結果...
API のバージョン管理をめぐる議論は、たいてい間違った側から始まります。バージョン番号をどこに置くか、という話です。実のところ、それはこの主題のなかでもっとも結果を左右しない決定です。本当に重要なのは、そもそもどの変更が新しいバージョンを必要とするのかであり、ほとんどのチームはここを、油断する方向に読み違えます。純粋な追加にすぎないと信じたものを出荷し、どこかのクライアントが壊れるのです。 使える考え方はこうです。あなたの API は、呼び出す側が何を当てにしてよいかについての約束にほかなりません。まっとうな呼び出し側が当てにしていたものを無効にしてしまうなら、その変更は破壊的です。そして呼び出し側は、ドキュメントが明示的に許して...
ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。 よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている内容からは導きようのない数字を求めてしま...
ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。 理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利用者。そういったものが保守の中身を決めて...