「納品」をなくせばうまくいく 倉貫 義人

「納品」をなくせばうまくいく 倉貫 義人 https://www.amazon.co.jp/dp/4534051948/

最近、度々読んでいる株式会社ソニックガーデンの倉貫さんの本。倉貫さんの本はどれも面白いしマインドセットを形成するのにとても良い本だった。自分び感想を混ぜ込んだメモ。書籍の内容については書籍を参照。

本当に必要な機能を、本当に必要な順番に、少しずつ開発していく。

意識を商談時に顧客と共有することで発注-受注の関係でなく、相互に協力し合えるパートナー関係が築ける。

「一括請負」の顧客側のリスクとしては、受託開発会社にとっては「納品」ゴールとなってしまう。受託側も納品後を見据えた顧客との継続的な関係性を築く意識が必要

ソフトウェアは完成しただけでは価値がなくむしろ負債。通常のソフトウェア開発では、開発後に製品リリース、売上が立ち始めて、開発と販促コストとの損益分岐点を超えてようやく利益がでる。

納品を目指す一括請負はディフェンシブな開発。要件定義と見積、作るものをガチガチに固めてから開発を始めるため、開発会社が利益を確保するためには、見積範囲に収まるようコストを抑える動きになる。契約通りに進むことが一番の利益。

開発中に出た新バージョンのデバイスやOS、SDKの更新にどこまで対応するか。ロードマップを参考に不確定要素を盛り込めればよいが、技術革新が日進月歩で起こる昨今において、数か月前に決めた要件定義で決めたことを守ることが顧客のためになっていない場合もある。

発注者が開発をアウトソーシングして、自社運用する場合など、開発と運用で業者が異なる場合がある。一次請け、二次請けがあるような下請けの仕組みも同様。開発のプロとしてはメンテナンスしやすい設計を心掛けるだろうが、納期や見積オーバーになりそうな時に、まずは納品を最優先する動きになる。

発注側は納品時の検収でプログラムの保守性を正しくチェックすることが求められるが、発注側にもスケジュールがあり「テストを通す」ことが重視される場合も出てくる。

結果として、保守性が悪くメンテナンスしにくいソフトウェアができる。開発と別会社である運用業者から見れば、自社開発でないため改修に影響範囲が見えず、開発会社への依頼による金額が発生する。

月額定額の「納品のない受託開発」では、担当のエンジニアが顧客の内製部隊として、ソフトウェアの最初の企画段階から、開発はもちろんのこと、運用までのライフサイクルのすべてを受け持つ

作り終えたら終わりということではなく、顧客のビジネスが続く限り責任を持って、その成長をバックアップすることを約束する

未来を予見した大掛かりな要件定義をしなくても定額制の範囲で少しずつ見直し、修正することで、本当に必要なソフトウェアを作ることができる。

発注先が大手企業になればソフトウェア開発を外注した場合、準委任にできればよいが契約形態として受託開発一択になるケースもある。

開発フェーズが PoC/Pilot/Deploy段階なのかにも依存する。受託案件＝枝葉末節まで詰めた要件定義を行うことが必ずも是ではない。ビジネス、担当者の中長期的を取り組みを考慮し顧客にとって有益な関係を築く。

ソフトウェア・エンジニアの仕事は時間単価では図れない。時間単価で働く＝時間内は仕事場にいることが価値になる。効率的に仕事を仕上げても直接的な評価につながらない。

成果は、新しい機能や改善を加えたりすることで評価してもらう。成果のためにどれだけ時間が掛かったかは顧客には関係ない。顧客ビジネスにとって価値ある成果を出しているかで判断してもらう。

顧客からの意見・要望を鵜呑みに対応するのではなく、本当に必要かどうか問い直せる関係性を築くことで「逆になんでも気軽にいえるようになる」

発注側担当者とエンジニアの中間フィルターは要らない。フィルターはプロジェクトに関する顧客との風通しの良い関係作りである。顧客とエンジニアが気兼ねなくやり取りできるのであれば、それが最も意思疎通・判断が早い。「気持ちいい風」が必要なもので、フィルター自体が必要なわけではない。

「いったん伝えてしまったら作られてしまうそうなので、社内でかなり揉んでからでないと相談できなかった」 開発会社側としては枷により顧客の本来求めていたものからズレたものを提供しては本末転倒。作らなくてすむものは作らない。

顧客を疑って契約で縛るのではなく、信頼関係を構築すべく努力を惜しまない。 Givers Gain の精神を感じる。

意思決定者を打合せに同席させる。打合せは事前に行った設計報告や確認ではなく、その場で方向や具体策を考えて決め切れる参加者を整えておく。

開発会社の技術に興味を持ってくれて自身の業界ドメイン知識を活かして熱意と予算を持った問い合わせに「要件定義書を出せ、無いなら作るのに１０００万かかる」と回答したら何にもならない。問合せ者は技術も評価できず費用感も判断付かないから問合せしてきてる。

上手くいくかわからない１度の開発ギャンブルを要求し高額請求されては尻込みする。顧客との関係作りを含めた baby step で小さく作って少しずつ改良していく。

ソフトウェアを「所有」するから「利用」する考えに変わると、「完成」から「持続」がゴールになる。エンジニアの考え方にも変化が必要。バグは「出さない」から「すぐに直す」、サーバーは「停止しないように」から「すぐに復旧できるように」

専任の担当エンジニアがいなくなったらどうするのか。１つはサポートエンジニアを用意しプロジェクトを把握することで属人性を下げる。もう一つはコードレビューで資料を残さない代わりに読みやすいプログラムに。牽いては高い保守性と品質に。