請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。 リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいるのか、そして移転の対価を払う価値があるの...
ソフトウェア開発
ソフトウェア開発に関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。
API のバージョン管理をめぐる議論は、たいてい間違った側から始まります。バージョン番号をどこに置くか、という話です。実のところ、それはこの主題のなかでもっとも結果を左右しない決定です。本当に重要なのは、そもそもどの変更が新しいバージョンを必要とするのかであり、ほとんどのチームはここを、油断する方向に読み違えます。純粋な追加にすぎないと信じたものを出荷し、どこかのクライアントが壊れるのです。 使える考え方はこうです。あなたの API は、呼び出す側が何を当てにしてよいかについての約束にほかなりません。まっとうな呼び出し側が当てにしていたものを無効にしてしまうなら、その変更は破壊的です。そして呼び出し側は、ドキュメントが明示的に許して...
ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。 よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている内容からは導きようのない数字を求めてしま...
ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。 理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利用者。そういったものが保守の中身を決めて...
技術デューデリジェンスはコード品質のコンテストではありません。それにもかかわらず、これから受ける側のチームは、たいてい見当違いのところに時間を注ぎ込みます。会社を買おうとしている人間で、あなたの設計した抽象化に点数をつけたい人はひとりもいません。買い手が知りたいのは、このシステムを保有し続けるのにいくらかかるのか、そして資金が動いたあとにどれほどひどいことが起こりうるのか、その二点だけです。 この捉え直しが大事なのは、最初に直すべきものが変わるからです。見た目は汚いけれども動いていて、チームが中身を理解していて、安全に手を入れられるコードは、軽微な指摘で終わります。逆に、洗練されてはいるがひとりの人間しか理解していないコードは重大な...
データベース性能の改善作業は、たいてい誰かが「もっと大きなインスタンスにしよう」と言い出すところから始まり、そしてたいていは、ページを開くたびにひとつのクエリが400万行を順次スキャンしていた、という発見で終わります。制約はもともとハードウェアではありませんでした。制約は実行計画のほうにあったのです。 この筋書きは十分に繰り返し起きるので、既定の仮説としてはっきり言葉にしておく価値があります。アプリケーションが遅く、そのうえデータベースが忙しいのなら、原因はほぼ必ず、ごく少数の特定のクエリであって、処理能力全体の不足ではありません。そしてサーバーを大きくする対処は、テーブルがふたたび育つのに必要な時間のぶんだけ、問題を覆い隠してくれ...
ソフトウェアテスト戦略は、たいていカバレッジという数字で語られます。しかしカバレッジは、この分野全体のなかで最も情報量の少ない数字です。カバレッジ九十パーセントのコードベースであっても、最もよく使われる経路でバグを本番に送り出すことがあります。カバレッジが測っているのは、テスト実行中にどの行が実行されたかであって、その行について意味のある検証が行われたかどうかではないからです。 自分たちのテストスイートを信頼しているチームは、パーセンテージが最も高いチームではありません。本当に壊れているときにテストが落ち、それ以外のときは静かにしているチームです。そしてこの性質は、お金で買うのがはるかに難しいことが分かっています。 どんなテストにつ...
フィンテックのソフトウェア開発は、誰が資金を保有する認可を持っているのかと誰かが問うその瞬間まで、ごく普通のソフトウェア開発とまったく同じように見積もられ、同じように日程が組まれます。その問いが出た時点で、案件は工学の課題であることをやめ、工学の要素を含んだ規制の課題に変わります。そして頭の中に描いていた日程は、そのままでは達成できないものになります。 技術が難所になることはめったにありません。資金を動かすこと自体はすでに解かれた問題で、成熟した事業者があり、仕様が文書化されたインターフェースがあり、初日から触れるテスト環境も用意されています。フィンテックの構築を長引かせるのは、認可上の立場と、監査に対して証跡を示す義務と、アーキテ...
MVPのソフトウェア開発が失敗するのは、実装のさなかではなく、スコープを決める会議の席です。誰かが「実用最小限の製品」と口にすると全員がうなずき、そのあとに届く機能一覧には、ユーザーアカウント、管理画面、課金、通知、ダッシュボード、そしてモバイルアプリまで並んでいます。それは実用最小限の製品ではありません。それはもう完成した製品であり、頭のなかに思い浮かべた数字の三倍の時間がかかります。 害をもたらしている言葉は「実用」、つまり viable の部分です。多くのチームはこれを「誰にでも売れるだけの出来ばえ」と読みますが、本来の意味は「これを欲しがる人がいるかどうかを知るのに、ぎりぎり足りる程度」です。 もっとも費用を節約できるスコー...
多くのチームは、APIのセキュリティを認証の問題として扱います。トークンを発行し、すべてのルートでそれを検査し、これで仕事は終わったと考えます。そしてある日、テスターがURLの数字をひとつ書き換えるだけで、別の顧客の請求書を読み出します。 「認証済み」と「認可済み」のあいだにあるこの隙間こそ、実際のAPI侵害の大半が住み着いている場所です。しかもこれは、スキャナーが安定して見つけてくれる種類の問題ではありません。自動化されたツールは、有効なトークンと200の応答を見て成功と報告します。その応答に他人のデータが含まれていたと気づけるのは、あなたの業務ルールを理解している人間だけです。 核心となる区別: 認証は誰が呼び出しているのかを証...