Salesforce 連携がプロトコルで失敗することは、まずありません。認証は解決済みの問題ですし、レコードを 1 件登録するのも解決済みの問題です。プロジェクトを終わらせるのは、1 日あたりのリクエスト割り当てと、データモデルの形のほうです。しかもその両方は、たいてい本番稼働から三週間ほど経った頃、夜間ジョブがエラーを返しはじめ、なぜテストでは通っていたのか誰も説明できなくなった時点で発見されます。 パターンは予測できるほど一貫しています。開発者は Developer Edition 組織に対して実装し、すべて通り、顧客が検収します。そのコードがやがて出会うのは、マーケティング用コネクタと、データウェアハウスへの抽出処理...
カスタムソフトウェア開発
カスタムソフトウェア開発に関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。
ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。 不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。 署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰かがそれを実際に動かせるでしょうか。ビル...
請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。 リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいるのか、そして移転の対価を払う価値があるの...
ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。 よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている内容からは導きようのない数字を求めてしま...
ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。 理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利用者。そういったものが保守の中身を決めて...
技術デューデリジェンスはコード品質のコンテストではありません。それにもかかわらず、これから受ける側のチームは、たいてい見当違いのところに時間を注ぎ込みます。会社を買おうとしている人間で、あなたの設計した抽象化に点数をつけたい人はひとりもいません。買い手が知りたいのは、このシステムを保有し続けるのにいくらかかるのか、そして資金が動いたあとにどれほどひどいことが起こりうるのか、その二点だけです。 この捉え直しが大事なのは、最初に直すべきものが変わるからです。見た目は汚いけれども動いていて、チームが中身を理解していて、安全に手を入れられるコードは、軽微な指摘で終わります。逆に、洗練されてはいるがひとりの人間しか理解していないコードは重大な...
フィンテックのソフトウェア開発は、誰が資金を保有する認可を持っているのかと誰かが問うその瞬間まで、ごく普通のソフトウェア開発とまったく同じように見積もられ、同じように日程が組まれます。その問いが出た時点で、案件は工学の課題であることをやめ、工学の要素を含んだ規制の課題に変わります。そして頭の中に描いていた日程は、そのままでは達成できないものになります。 技術が難所になることはめったにありません。資金を動かすこと自体はすでに解かれた問題で、成熟した事業者があり、仕様が文書化されたインターフェースがあり、初日から触れるテスト環境も用意されています。フィンテックの構築を長引かせるのは、認可上の立場と、監査に対して証跡を示す義務と、アーキテ...
MVPのソフトウェア開発が失敗するのは、実装のさなかではなく、スコープを決める会議の席です。誰かが「実用最小限の製品」と口にすると全員がうなずき、そのあとに届く機能一覧には、ユーザーアカウント、管理画面、課金、通知、ダッシュボード、そしてモバイルアプリまで並んでいます。それは実用最小限の製品ではありません。それはもう完成した製品であり、頭のなかに思い浮かべた数字の三倍の時間がかかります。 害をもたらしている言葉は「実用」、つまり viable の部分です。多くのチームはこれを「誰にでも売れるだけの出来ばえ」と読みますが、本来の意味は「これを欲しがる人がいるかどうかを知るのに、ぎりぎり足りる程度」です。 もっとも費用を節約できるスコー...
英国での医療ソフトウェア開発は、他のどの業種の同等の仕事よりも費用がかかり、時間もかかります。理由はコードが難しいからではありません。予算のかなりの部分が機能ではなく証跡に費やされるからです。臨床リスク文書、情報ガバナンス、そして購入者が試用の前にすら求めてくる保証関連の書類です。 他分野でソフトウェアを作ってきたチームは、これを一貫して過小評価します。アプリケーションを見積もり、案件を獲得し、それから、コンプライアンスの層が最後の工程ではなく初日から始めなければならない並行作業だと気づきます。後から見直すと高くつくアーキテクチャ上の判断を、その層が縛るからです。 費用を本当に押し上げるもの: 英国の医療案件では、およそ四分の一から...
エンドポイントの本数からカスタムAPI開発の費用を見積もろうとすると、たいてい三倍ほど外します。エンドポイントそのものは、この仕事のなかでいちばん安い部分だからです。すでに自社が持っているデータを読み書きするだけの十数本であれば、力量のあるバックエンド開発者にとっては二週間ほどの作業にすぎません。 お金がかかるのは、その十数本を「よその会社が自社の事業を載せてもよい」と判断できるものへ変えていく、周辺のすべてです。セキュリティレビューに耐える認証、あとから方針を変える余地を残すバージョニング、誰も問い合わせを送ってこなくて済む水準のドキュメント、そしてどの顧客がいま困っているのかを教えてくれる運用の仕組み。「APIがあります」と「よ...