ビジネス の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• ビジネス へ行く。
• ビジネス の差分を削除

*概要 [#t9fd471f]
-商談・見積もり・請求書の書き方・開業など、一人でお金儲けするための方法論
-ひとりで作業できる範囲の仕事やってたら給料は上がんないわけですよ。1人で10人月とか100人月とかやらないと。
-身銭切ってでもプロトタイプを作って持ってきていないようなアイデアだと審査するに値しない。切れる身銭を得ることも大事。
-イケメンは重要。ファッション、身だしなみ、頭皮、筋トレ。清潔で決まったスーツを着て、低い声で綺麗な姿勢で話をされたら話の内容以前に凄みを感じる
-事業成功の1. 充分なマーケットがある 2. 事業・プロダクトに独自性がある 3. 強いビジョン、チーム。全部コンプリートした上で10年、20年と継続が必要で、お金がなくなったらソッコー破綻。『新規事業』って響きはいいけど茨の道だよね。
-アメリカの場合はマーケットサイズが桁違いなので、Lean StartupはProblem Solution Fitの手法が集約されているケースが多いけど、日本でLeanを応用するなら、Product Market Fitにもっとフォーカスしないと、プロダクト作ったけどマーケットなくて死ぬってことが多いんじゃないかという仮説。加えていうならば、多くのスタートアップはProblem Solution Fitではコンシューマ向けのストーリーを描く一方で、マーケットフィットさせようとした瞬間にマーケットサイズで絶望して、結果としてBtoBの戦略をとるようにSaaS系BtoBにPivotする、というのが定石のように感じる。
 



*下位ページ [#z1ead702]
-[[外注]]

*目次 [#r5d1bdb4]
#contents


*参考 [#pd879882]
-[[misoca>https://app.misoca.jp/estimates]]
--ネット上で見積書、納品書、請求書を作れるサービス。
--電子捺印だが、サービスを通じて郵送もできる。
//-[[MFクラウド会計>https://biz.moneyforward.com/sign_in]]
//-[[MFクラウド請求書>https://invoice.moneyforward.com/billings]]
-freee

*ビジネスの構造 [#xf4562a7]
-財務の改善のために顧客ファーストであることが非常に大切
-例えば、財務 <- 顧客 <- 業務プロセス <- 人材 という整理が BSC のメンタルモデルを作っている https://s-naga.jp/k-page/14bsc.html (別にこれが最高だとは言わないけど)
--こういうグラフ構造って、結局デバッグをする時にどこで詰まっているのかを理解するために結局必要になってくるし、絵ポンチの作成も馬鹿にしたものではないように思えてきた

-飲食市場では 1 億人の食欲を奪い合うだけのゼロサムゲーム。これで挑戦していると性格が悪くなる。伸びでいる会社・業界でやる

-SWOT は内部の状況と外部の状況から導き出される戦略
--【積極化戦略】強み×機会
--【段階的戦略】弱み×機会
--【差別化戦略】強み×脅威
--【縮小・撤退】弱み×脅威
 
-KGI -> North Star Metric -> KPI
-KGIとは、この「売上」「収益」
--KGI: 売上・収益目標
--North Star Metricは、顧客視点での未来の成功に対する先行指標。 上述のように、月間売上やARPU（Average Revenue Per User）などの後行指標では、プロダクトが及ぼす影響について予め情報を知らされません。Twitter での登録後30人の他のユーザーをフォローしたユーザーの数。「①体験価値」「②戦略」「③収益」の全ての交差点がそれに当たる。
--KPI: 数値化される目標
 
-Value Proposition
--なぜ自分たちの商品を選ぶかについての一文
--これに応じて既存サービスを分類し、強みを知ることができる

*顧客ドリブン [#vd4ff869]
-「それはユーザーには関係ない」って何回も言わされる
--メルカリで出品しようとしたらめちゃくちゃめんどくさくなっている。ユーザーの裾野が増えると説明したい気持ちが高まり、即カメラ起動でサクッと出品、という体験が消えている
--ユーザーには社内の事情なんて1パーミルも関係ないんだけど、当事者になると混ざってしまって難しい。だから、何回も「それはユーザには関係ない」と言わなければならない

-ユーザにとっての価値は概ね見たことのない新規な価値を提供するか、コストを下げる新しい提案をするかのどちらか
--通常コストを下げるほうがわかりやすいしやりやすいが、前者のほうがブルーオーシャンなので圧倒的に儲かる夢がある

*ビジネスの役割 [#x716082c]
-営業目線
--営業戦略、件数、売上
-マネージャ目線
--組織、各種KPI
-経営者目線
--PL/BS、キャッシュフロー、事業戦略

*銀行口座 [#x7845542]
-口座番号は7桁
-普通口座，貯金口座があり，普通口座しか振込んだり振り込まれたりできない．
-手数料
--対応する銀行から下ろすと手数料が無料になる（みずほ：8:45-18:00，ゆうちょ：7:00-21:00）
--コンビニ銀行から取引する場合は全ての時間で手数料がかかる

*見積書から領収書まで [#vb2067a4]
-[[請求書払いの仕組み>https://www.makeleaps.jp/%E8%A6%8B%E7%A9%8D%E6%9B%B8%E2%86%92%E7%B4%8D%E5%93%81%E6%9B%B8%E2%86%92%E8%AB%8B%E6%B1%82%E6%9B%B8%E2%86%92%E9%A0%98%E5%8F%8E%E6%9B%B8%E3%81%AE%E5%BD%B9%E5%89%B2%E3%81%A8%E6%B5%81%E3%82%8C/]]

**見積書・[[請求書]] [#m8bdde4a]
-見積書・請求書には一切法的効力ない
--フォーマットはない
--電子捺印しても法的には問題ないが、慣習的に不可（トラブルがあったときに「電子捺印しかされていない」見積書・請求書は、不利になる恐れ）（[[参考>http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1033178865]]）


-消費税も請求する

-請求書のタイミング
--納品時に、担当者に請求書おくらせていただいてよろしいでしょうかとでも聞く。良いといったら送る。
--検収が、とかいわれることもあるのでその場合は指示に従う。
---検収：納入品が発注どおりか検査して受け取ること。（品物の種類や数量、破損の有無、機器の動作確認、システム検証）


*正しく外注する [#e856e8ea]
-日本の企業は法務とか経理とかコストセンターは外注しないのに、ソフトウェア開発(局所性が高いシステム)を外注してるのやべえ
--一方で汎用性が高いものまでSaaS使わずに特注してる。やってることが中途半端。
--自社固有の物は自社で作って、汎用的なものはアリモノで良い。非効率的な組織は規模を少しずつ小さくして効率的な組織がシェアを伸ばす組織の世代交代が起こるだろうし、これは日本や現代に限らず歴史的に世界中で起こってきたことだと思う。
 


*[[納税]] [#e33903a2]
-正しく納税して捕まらないように

*[[開業]] [#a50cb391]
-青色申告しよう→した

*プロジェクトの炎上 [#l77d89d3]
+営業が技術のことを何も知らない
--よく聞く炎上
+できない案件を取ってくる
--よく聞くがただのバカ
+全体の最適解を知っている人がいない．
--全技術・問題を知りつつ，マネジメントが出来る人が必要←重要

*[[営業]] [#tdf0ce5a]
-見積の時の注意

*稟議 [#qbcf424f]
-稟議書（「りんぎしょ」は慣用読みであるが変換は「りんぎ」だし「りんぎ」）
-稟議書の書式は、組織により異なる．以下のようになる

 （題名）業務用自動車の購入について
 （本文）標記の件、下記の通り自動車を購入したくお伺いいたします。
 記
 １．理由　　配送用自動車が老朽化しており、買い替えの必要が生じたため。
 ２．価格　　＊＊＊円
 以下、購入先の業者名、予算は＊＊円計上してあったが、実績（実際の額）は＊＊円で差額が＊＊円、といった内容を記載し、見積書を添付する。



*仕事 [#x6bbd725]
-仕事と作業を区別せよ
--仕事と作業を単語として使い分けるべき
-「仕事」とは自分で作り出すもの。与えられたものは「仕事」ではない、それは「作業」だ
--「私の仕事は何ですか？」なんて質問を恥ずかしげもなくできるのは子供だけだ。
--子供は大人から与えられないと生きていけない存在だ。食べ物も服も家も与えられ守られている。
--与える側になれ
--そして、仕事というのは社会に何かを与え、初めて大人になれる。




*全ては相場 [#q643f429]
-人の価値は「相場」が決める。自分が決めるんじゃない。
--でも相場を無視して転職する人はおおい。自分と同じような人なんて世の中にたくさんいる
--売るのは相場が決まってから、その前に売りだしても、相場もわからないバカとしか思えない

*ペーパーカンパニー [#v42ae5a8]
-ペーパーカンパニーで自分に給料を払ったことにして脱税？どういう原理だろう

















*イシューから始めよ [#i3d3697a]
悩むのと考えることは違う。常に考える必要がある。悩むのは答えが出ない問題を解こうとしているということ

生産性 = アウトプット / インプット
issue = ２つ以上の集団で決着がついていない、重要で白黒がはっきりしていない問題
value = 高い issue 度に対する高い質の解

問題を解くより問題を見極める
解の質を上げるよりも、問題の質を上げる
知るほど知恵より知るほど馬鹿になる
速くやるよりやることを削る
数字の桁数にこだわるより答えが出るかにこだわる

解の質を上げる努力だけで value を出す癖がついた人は、issue を見極められないので良い上司になれない
「今思いついた問題の中で、本当に答えを出すべき問題はどれでしょうか？」

-成果への道
--仮説ドリブン（設問ではなく仮説を立てる）
--仮説のインプットとアウトプットを規定する
--アウトプットドリブン
--メッセージドリブン

絵や図は大まかなイメージを掴むためには重要だが、イシュー・概念をきっちりと定義するには言葉が最も適切なツールである

仮説は Why を問わずに What, How, Where を問うほうが生産的（機序を問うて意味があることは少ない）
- Where: どこを目指すべきか？
- What: 何をするべきか？何を避けるべきか？
- How: どう行うべきか？どう進めるべきか？

仮説は比較を入れると明確になる。「ゲーム操作の快適さは速度より操作性なのではないか？」
仮説は非常識な洞察・新しい構造を埋め込むと深くなる
イシューの仮説にはイシューがイシューであるか？という構造が重要なイシューなのかを問うときに便利
売上低迷→ロゴを刷新して広告を打つことでブランドの再構築？→そのイシューはそもそもイシューなのか？（セグメントの縮小なのか、他社との比較なのか）

一次情報にあたるのが大事。また、外部の専門家に押しかけて電話しても、守秘義務に関わることは話さなくてもいいよと言われると意外と話をしてくれる。

MECE である必要はあるが、本質的な MECE とそうでない MECE がある。
売上＝市場シェア * 市場規模＝個数 * 単価 = ユーザー数 * ユーザーあたりの売上 = 首都圏売上＋その他売上

事業コンセプト＝WHERE (どのようなセグメントにどのような動きがあるか、時代的に留意することはあるか、具体的にどの市場ニーズを狙うか) * WHAT&HOW (バリューチェーン上のどの立ち位置か、どこで顧客を引き寄せるか、どこで設けるか)

思考の整理方法として、ビジネスシステム・3C, VDS, 7S, BSC, SWOT といったものがあるが、適切なフレームワークでなければつかわないほうがまし


*雑多 [#q150ba34]






入社前の「エンジニアに面接で判断して欲しい」と、入社後の「求職者の面接に時間取られたくない」はトレードオフなので、適切な足切りライン見つけてあげるの超大事。コーディングテストの足切り基準は適切に。

なるべくproactiveに提案・行動する。

プレセールス
講演会などで発表する、デモンストレーションをするなど

ダイレクトセールス

カスタマーサポート
ヘルプデスク＝テクニカルサポートは、その名の通り、困っているお客様を助けることが仕事。そのため、製品やサービスについての専門性がカスタマーサポートよりも必要。お客様の入り口となるカスタマーサポート。お客様からの相談内容をヒアリングした上で、より専門性の高い対応をすべきだと思われたお客様をヘルプデスクに回すといった対応がとられます。

テクニカルサポート
ヘルプのドキュメント作成修正

セールスエンジニア
販売を目的とする営業職と、実際に作業をする技術職の両方の要素を持つ仕事です。主にソフトウェアや電子機器商品などを扱う企業で、営業担当者と一緒にクライアントのもとへ向かいます。
現場では、営業としてクライアント側の担当者と交渉や調整を行ないながら、技術者として自社製品の導入あたってのアドバイスを行なう職種なのです。


カスタマーサクセス
カスタマーサポートはリアクティブなサポートだが、カスタマーサクセスはプロアクティブなサポートを行い、信頼性を獲得するための方法
ブスクリプション型（継続課金）ビジネスの企業で設置され、顧客を成功に導くことでLTVの最大化を目的とする組織や一連の活動を指します。具体的なKPI指標としては解約率（チャーンレート）やアップセル・クロスセル、ユーザーのアクティブ率向上などが挙げられます。
お客様の業務改善を支援していき、お客様に有用性を実感していただく必要がある
「これは、今まで体験した中で最も優れたサービスですか？」という質問に対して、必ず「はい」の回答を得る。
「サポートではなく、成功のプランを設計してあげる。」

カスタマーサポートのための定量的な指標がいくつかある
カスタマーチャーン
カスタマーチャーンはカスタマー（顧客数）にフォーカスをした指標で、全体の顧客数に対しての解約率を見る指標です。
カスタマーチャーン＝ 計測期間での解約数 ÷ 一定期間内での契約顧客数
レベニューチャーン
レベニューチャーンは収益にフォーカスをした指標で、売上に対して解約によるインパクトがどれだけあるのかを見る指標です。
サブスクリプション型の場合は、単純な解約数ではなく売上インパクトを図るレベニューチャーンをモニタリングする必要があります。
レベニューチャーン＝ （計測期間でのサービス単価 × 解約数） ÷ 計測期間内での合計売上


LTV
Life Time Value
一つの会社が（顧客ライフサイクル）内にどれだけの利益をもたらすのかを算出したもの。
新規顧客獲得のコストは既存顧客維持の5倍といわれており、既存顧客を維持・拡大することは常に重要なテーマと言える。

CRM 
Customer Relationship Management
商品やサービスを提供する会社が、顧客との間に親密な信頼関係を作り、購入してくれた顧客をリピーターに、リピーターからファンになるような活動を行い、顧客と会社の相互利益を向上させることを目指す総合的な経営手法である。
例えば、美容室でカットをしてもらった数日後、カットを担当した美容師さんから「先日の髪型はいかがですか？」と書かれたハガキが届く。これもCRMのひとつである。
一人ひとり、どんなアプローチをされたら嬉しく感じてもらえるのか、動かすことができるのかを丁寧に考え、それを一人ひとりに実行すること。
商売をするうえであたりまえに大切なことながら、規模が大きくなればできなくなると思い込んでいたコミュニケーションを実行していくことがCRM活動である。


KGI/KPI指標
OKRの組織版みたいなもの。KGIが目標で、KPIは手段が設定されガチ。
例えば、KGIで来月の売り上げ目標を1億円と設定した場合に、KPIではその目標実現のために新規問い合わせ件数1,000件、新規商談件数100件、新規顧客獲得件数20件、平均受注単価500万円をそれぞれ目標として設定するというふうに使われます。

 

KPIとKGIの関係性
KPIは目標への達成プロセスを管理するために使われ、KGIは企業や事業全体の目標を管理するために設定されます。経営戦略論的にはKGIが企業戦略の達成度を評価する指標で、KPIがそこに至るまでの各種戦略の達成度を評価する指標です。
例えば、自社サイトに対する新規お問い合わせ件数の目標を月間30件に設定したとします。
その場合、Webサイトへのアクセス自体が減ってしまうと目標達成が見込めなくなります。そのため、検索エンジンからのセッション数の増加をKPIとして設定し、Googleアナリティクスを利用して達成レベルを随時チェックする必要があります。 
ほかにも営業の現場では、訪問回数や成約率、解約件数などをチェックしたり、製造業では機械稼働率や不良品の発生率、企業の人事部門では離職率、管理部門ではクレーム件数などをKPIにしている場合もあります。
KPIのメリット
KPIのメリットは、共通の指標が用いられることでメンバーの意思統一が図りやすくなることです。また、評価基準が客観的なのでチームとメンバーに対する評価を公平に行うことができます。

HRT（謙虚・尊敬・信頼）

DevOps
迅速に変化をしつつかつ安定運用もするというアプリケーションの継続サイクルを、Dev（開発者）とOps（運用者）がいがみ合うことなる実現するための、ムダやボトルネックを取り除くことでカイゼン行動のこと。ツール・組織文化の両方の観点で必要
自動化は、テスト、ビルド、デプロイといった今まで人間が行なっていた作業を自動化することで ヒューマンエラーを防ぐことができます。 信頼性を高めることで運用者もシステムの変更を承認しやすくなります。という観点で重要
【 ツール 】
1自動化されたインフラストラクチャ（Automated infrastructure）： インフラの構築を自動化する。よく使われているツールにはAnsibleやChef、Dockerなどがある
2バージョン管理システムの共有（Shared version control）： GitやMercurialなどの同じバージョン管理システムをDevとOpsで共有する
3ワンステップによるビルドとデプロイ（One step build and deploy）： 手順書などを使い、手動でビルドやデプロイをするのではなく、ビルドやデプロイを自動化する。よく使われているツールやサービスにはJenkinsやCapistranoなどがある
4フィーチャーフラグ（Feature flags）： 詳細は後述のコラムで説明。コード中の機能の有効／無効を設定ファイルで管理する
5メトリクスの共有（Shared metrics） ： 取得したメトリクスの結果をダッシュボードでお互いに共有する。よく使われているサービスにはNew RelicやApplication Insightsなどがある
6IRCとインスタントメッセンジャーのBot（IRC and IM robots）： SlackやHipChatなどのチャットツールに自動的にビルドやデプロイのログ、アラート内容を投稿する仕組みを作ることで情報をお互いに共有する
【 組織文化 】
Aお互いを尊重する（Respect）： 一緒に働く相手のことを心から思いやる、相手を一人の人間として扱い、能力や功績を評価する
Bお互いを信頼する（Trust）： 自分以外の人は優秀で、正しいことをすると信じる。信じて仕事を任せる
C失敗に対して健全な態度を取る（Healthy attitude about failure）： 新しいことに挑戦すれば自ずと失敗は起こってしまうもの。失敗は起こるものであり、相手のミスだと責めるものではない
D相手を非難しない（Avoiding Blame）： 相手に非があると断じて言葉で責めるのではなく、次に同じ問題が起こらないように建設的な批判を行う



ソフトウェア開発の一連の流れは、ソフトウェアを開発する役割（Dev）とソフトウェアの価値をユーザーに届け続ける役割（Ops）が存在していると言えるでしょう。後者の役割を担うのが、システム運用です。

-SRE (site reliability enginieer)
--「。開発者と運用担当者の間に許容できるダウンタイムをベースにした"合意事項"を作り，互いの責任範囲を明確にしたSREを定めたことで，「⁠Googleには協力し合うという企業カルチャーが生まれ，高い信頼性と驚異的スピードのイノベーションにつながった」とあります。」
--ソフトウェアエンジニアの役割を兼ねるインフラ屋
--運用を自動化していくことがミッション
--一般的に、SREチームは、「サービスの可用性」「レイテンシ」「パフォーマンス」「効率性」「変更管理」「モニタリング」「緊急対応」「キャパシティプランニング」に責任を持ちます。
--ここがしっかりしていないと、モニタリングは貧弱で障害らしいものが発生しても状況がつかめず、混乱する。時間の無駄になる。
サービスレベル目標（SLO）を踏まえた指標管理、セキュリティ対策や緊急パッチの適用、各種モニタリングシステムの開発・運用、--ロードバランサや自社製 KVS の開発、データセンター間ネットワークの設計や各種ハードウェアの調達、更新など様々な業務
--「たとえサービスの拡大で作業量が増えたとしても、自動化でカバーしてくれ！」というのがSREへの期待なのです。
可用性を99.995％に設定したとすると、残りの0.005％を「エラーバジェット（Error Budget＝サービスを止めても良い時間の合計）」と呼び、商況を鑑みて、可用性が下がるリスクを理解した上で、メンテナンスや早期リリースに利用するなど、エラーバジェットを超過しない範囲で、できるだけサービスを改善するのです。
--SLO（Service Level Objectives＝サービスレベル目標）やSLA（Service Level Agreements＝サービスレベル合意）といった、明確な数値基準
--あらかじめエラーバジェットを決めておくことは、さまざまなメリットがあります。「ビジネス上の事情によっては、可用性を下げてでもリリースを優先する」といった判断がしやすくなりますし、バジェットを使い切ることが目標になれば、素早く新技術の検証に取り組むモチベーションにもなります。
---アラート（Alert）：サービスダウンの検知など、即時対応が必要なもの。電話で来る
---チケット（Ticket）：「リソース使用量の増加傾向」など、即時対応が必要ではない状況。この場合は、リソース増強などを検討して対処することになる。メールで来る。
---ロギング（Logging）：普段は確認する必要がなく、詳細の分析や追跡の際に利用する通知はサれない
--この分類は、「人間がメールを読み、対応の必要性を判断しなければならないシステムには根本的な欠陥がある」
--Googleは、組織で取り組む業務の方針として、「トイル（Toil＝労苦）」と呼ばれる、自動化できるにもかかわらず、手作業で行う運用作業にかける労働時間を「全体の50％まで」と制限しています。残りの時間で、自動化を目指すコーディングやサービスレベル向上に関連するプロジェクトに対応するというわけです。
--GoogleのSREチームはGoogleの検索、広告、Gmail、YouTube、App Engineなどのサービスの可用性やパフォーマンス、拡張性などに携わっています。もし、これらのサービスで問題が発生すれば、SREがソースコードを追って原因を特定し、パッチを充ててリリースをすることもあるようです。GoogleのSREの特徴として、ソフトウェアエンジニアとしての業務の比重が大きい事が挙げれます。業務時間の20-80%は開発の業務に関わっているようです。
--Critical User Journey に基づいた SLI/SLO


CRE
顧客の不安を徹底的に拭うという役割
クラウドを導入している組織を外から見ていると、非常に不安を感じているのがよくわかります。
その妥当な理由を把握するまで少し時間がかかりましたが、最終的に次のような考えに落ち着きました。
人は、自分の環境を管理したいと進化的に思ってしまうのです。これは、生き抜くための特性として本当に価値のあることです。そのため管理できないと感じると、あまりいい反応を示さなくなります。危険度が高ければ高いほど、管理できないことに対して、より大きく反応してしまいます。Dropbox はパブリック クラウド プロバイダーの利用を止め、オンプレミスに戻ると発表。
物理的なインフラと（ある程度の）データを管理することは断念しましょう。不安が生じますが、その代わりクラウドによってさらに大きなイノベーションを得ることができ、コストが低減し、セキュリティは高まり、安定性も増します」
完全に合理的な取引ですが、私たちの中にある最も進化的な衝動の 1 つに逆らうことになります。
過去 5 ～ 6 年の間に、安価な料金と引き換えに不安を飲み込むことをよしとしないお客様がたくさんいることを学びました。特にクラウドに関しては、ほとんどの企業で危険が伴うため、なおさらです。圧倒的多数の企業にアプローチするには、こうした不安に対応することが必須条件の中心
サポート チームの役割は、以前は非常にわかりやすいものでした。質問に答え、問題を素早く効率的に解決することです。しかし今では、すべての IT サポート チームの役割は、結局のところほぼ FAQ やヘルプ センター、確認リスト、手続きといったものになっています。
クラウド テクノロジーの時代において、これは完全に間違っています。
不安を抱えるお客様は、その気持ちを理解してもらいたいと考え、思いやりや人間性を求めているのです。「そう感じているのは自分たちだけではなく、プロバイダーも自分たちのことを真剣に考えている」といったことを感じ取りたいのです。
真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。アプリケーションのデザインやコード、運用などに内在する信頼性に対する不安を払拭する努力は今までなされてきていない。アプリケーションの誤った使い方などをGoogle社員に直接監査、チェックしてもらうことができる。
Googleの監査は極めて厳しく、これくらいの厳しい運用目標でクラウドサービスが動いているんだ、というアピールにもなる
また、Pokemon GoのようにGoogleの認めた運用で問題が起きそうになった時には全力のサポートがなされる（運命共同体なので）。
クラウド事業者と顧客が同様に互いの責任範囲をすみやかに実行するという契約です。ここで特徴的なのは，SREでの"ダウンタイム"にあたるものが，CREでは"エラー予算"と呼ばれている点です。Googleが顧客のシステムを精査した結果，Googleが考える信頼性と現実の顧客のシステムの間にあるギャップ ―この"エラー予算"をベースに共通のシステムモニタリング体制を構築するとあります。
CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施します。ここで見つけたものを客が解決すれば、客のアプリケーションの信頼性は向上する。これをやるのにたいして、Googleは無料で行っているが、これは客からの信頼を得ているために合理的である。このような投資を行っているというだけで、お客様の不安が軽減されているのです。こうした原理や実践が、お客様が Google を使い続ける大きな動機となります。技術的にロックインするのではなく、人間関係を通じて構築される一体感につながるのです。実際、努力が必要なので、お客様の大半は申し込まないのではないかと私たちは見ています。ただ、数十億ドルものビジネスをクラウド上で行っている大企業が、このような機会を見逃すのは愚かな行為だとも思います。