Salesforce 連携がプロトコルで失敗することは、まずありません。認証は解決済みの問題ですし、レコードを 1 件登録するのも解決済みの問題です。プロジェクトを終わらせるのは、1 日あたりのリクエスト割り当てと、データモデルの形のほうです。しかもその両方は、たいてい本番稼働から三週間ほど経った頃、夜間ジョブがエラーを返しはじめ、なぜテストでは通っていたのか誰も説明できなくなった時点で発見されます。 パターンは予測できるほど一貫しています。開発者は Developer Edition 組織に対して実装し、すべて通り、顧客が検収します。そのコードがやがて出会うのは、マーケティング用コネクタと、データウェアハウスへの抽出処理...
プログラミングチュートリアル
実践的なプログラミングチュートリアル。Python、C++、JavaScript などで明快な例とベストプラクティスを解説。設計、テスト、性能も学べます。
WordPressのプラグイン開発は、たいてい同じ道をたどります。予約フォーム、フィードの取り込み、決済画面の追加項目が必要になり、開発者がそれを書き、動き、みんな次の仕事へ移ります。二年後、そのサイトは古いバージョンのWordPressに取り残されています。更新してもそのプラグインが無事でいられると誰も確信できず、書いた本人はもういないからです。 原因がコアの変化の速さにあることはまれです。WordPressは互換性を壊すことに保守的で、五年前に書かれた出来のよいプラグインの多くは、今もWordPress 7.1の上で手を入れずに動いています。プラグインが壊れるのは、最初の一週間で下された判断のせいです。機能をテーマに置いたこと、...
ポストモーテムは、開くのは簡単で、役に立つものにするのは難しい会議です。会議が開かれ、ドキュメントが書かれ、アクションアイテムが四つ記録され、そして六か月後に同じ障害がふたたび起きます。そのころ誰かが、まったく別のものを探している最中に、あの古いドキュメントを見つけることになります。 この話題では「非難なし」という言葉にほとんどの注目が集まります。その原則は実際に重要なのですが、失敗が起きているのはそこではありません。非難なしを厳格に守りながら、それでも何ひとつ変わらないレビューを回している組織はいくらでもあります。理由は単純で、レビューそのものを成果物として扱ってしまい、成果物を生み出すための手段として扱わなかったからです。 あな...
技術ドキュメントは、いつも決まった、そして予測のつくかたちで失敗します。誰かが二週間ほどの落ち着いた時期に大量に書き上げ、そのあいだにシステムのほうが変わり、誰も更新せず、一年も経てば、その文書は自信たっぷりに間違ったことを述べている状態になります。そこから先は、何もないよりも悪い状態です。書いてあることを信じた読み手が、すでに成り立たなくなった情報にもとづいて手を動かしてしまうからです。 これに対するよくある反応は、もっと書こうという号令です。ところがそれは同じ失敗を早めるだけで終わります。役に立つ反応は、書く量を減らし、そのうえで何を書くのかを選ぶことです。ここでの制約は書く手間ではありません。書いたあとに保守し続ける手間のほう...
開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされるか、という点にあります。 追いかける価...
ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。 不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。 署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰かがそれを実際に動かせるでしょうか。ビル...
請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。 リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいるのか、そして移転の対価を払う価値があるの...
API のバージョン管理をめぐる議論は、たいてい間違った側から始まります。バージョン番号をどこに置くか、という話です。実のところ、それはこの主題のなかでもっとも結果を左右しない決定です。本当に重要なのは、そもそもどの変更が新しいバージョンを必要とするのかであり、ほとんどのチームはここを、油断する方向に読み違えます。純粋な追加にすぎないと信じたものを出荷し、どこかのクライアントが壊れるのです。 使える考え方はこうです。あなたの API は、呼び出す側が何を当てにしてよいかについての約束にほかなりません。まっとうな呼び出し側が当てにしていたものを無効にしてしまうなら、その変更は破壊的です。そして呼び出し側は、ドキュメントが明示的に許して...
ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。 よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている内容からは導きようのない数字を求めてしま...
ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。 理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利用者。そういったものが保守の中身を決めて...