![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
概要 †
下位ページ †目次 †参考 †
ビジネスの構造 †
顧客ドリブン †
ビジネスの役割 †
銀行口座 †
見積書から領収書まで †見積書・請求書 †
正しく外注する †
納税? †
開業 †
プロジェクトの炎上 †
営業 †
稟議 †
（題名）業務用自動車の購入について （本文）標記の件、下記の通り自動車を購入したくお伺いいたします。 記 １．理由 配送用自動車が老朽化しており、買い替えの必要が生じたため。 ２．価格 ＊＊＊円 以下、購入先の業者名、予算は＊＊円計上してあったが、実績（実際の額）は＊＊円で差額が＊＊円、といった内容を記載し、見積書を添付する。 仕事 †
全ては相場 †
ペーパーカンパニー †
イシューから始めよ †悩むのと考えることは違う。常に考える必要がある。悩むのは答えが出ない問題を解こうとしているということ 生産性 = アウトプット / インプット issue = ２つ以上の集団で決着がついていない、重要で白黒がはっきりしていない問題 value = 高い issue 度に対する高い質の解 問題を解くより問題を見極める 解の質を上げるよりも、問題の質を上げる 知るほど知恵より知るほど馬鹿になる 速くやるよりやることを削る 数字の桁数にこだわるより答えが出るかにこだわる 解の質を上げる努力だけで value を出す癖がついた人は、issue を見極められないので良い上司になれない 「今思いついた問題の中で、本当に答えを出すべき問題はどれでしょうか？」
絵や図は大まかなイメージを掴むためには重要だが、イシュー・概念をきっちりと定義するには言葉が最も適切なツールである 仮説は Why を問わずに What, How, Where を問うほうが生産的（機序を問うて意味があることは少ない）
仮説は比較を入れると明確になる。「ゲーム操作の快適さは速度より操作性なのではないか？」 仮説は非常識な洞察・新しい構造を埋め込むと深くなる イシューの仮説にはイシューがイシューであるか？という構造が重要なイシューなのかを問うときに便利 売上低迷→ロゴを刷新して広告を打つことでブランドの再構築？→そのイシューはそもそもイシューなのか？（セグメントの縮小なのか、他社との比較なのか） 一次情報にあたるのが大事。また、外部の専門家に押しかけて電話しても、守秘義務に関わることは話さなくてもいいよと言われると意外と話をしてくれる。 MECE である必要はあるが、本質的な MECE とそうでない MECE がある。 売上＝市場シェア * 市場規模＝個数 * 単価 = ユーザー数 * ユーザーあたりの売上 = 首都圏売上＋その他売上 事業コンセプト＝WHERE (どのようなセグメントにどのような動きがあるか、時代的に留意することはあるか、具体的にどの市場ニーズを狙うか) * WHAT&HOW (バリューチェーン上のどの立ち位置か、どこで顧客を引き寄せるか、どこで設けるか) 思考の整理方法として、ビジネスシステム・3C, VDS, 7S, BSC, SWOT といったものがあるが、適切なフレームワークでなければつかわないほうがまし 雑多 †入社前の「エンジニアに面接で判断して欲しい」と、入社後の「求職者の面接に時間取られたくない」はトレードオフなので、適切な足切りライン見つけてあげるの超大事。コーディングテストの足切り基準は適切に。 なるべく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）が存在していると言えるでしょう。後者の役割を担うのが、システム運用です。
CRE 顧客の不安を徹底的に拭うという役割 クラウドを導入している組織を外から見ていると、非常に不安を感じているのがよくわかります。 その妥当な理由を把握するまで少し時間がかかりましたが、最終的に次のような考えに落ち着きました。 人は、自分の環境を管理したいと進化的に思ってしまうのです。これは、生き抜くための特性として本当に価値のあることです。そのため管理できないと感じると、あまりいい反応を示さなくなります。危険度が高ければ高いほど、管理できないことに対して、より大きく反応してしまいます。Dropbox はパブリック クラウド プロバイダーの利用を止め、オンプレミスに戻ると発表。 物理的なインフラと（ある程度の）データを管理することは断念しましょう。不安が生じますが、その代わりクラウドによってさらに大きなイノベーションを得ることができ、コストが低減し、セキュリティは高まり、安定性も増します」 完全に合理的な取引ですが、私たちの中にある最も進化的な衝動の 1 つに逆らうことになります。 過去 5 ～ 6 年の間に、安価な料金と引き換えに不安を飲み込むことをよしとしないお客様がたくさんいることを学びました。特にクラウドに関しては、ほとんどの企業で危険が伴うため、なおさらです。圧倒的多数の企業にアプローチするには、こうした不安に対応することが必須条件の中心 サポート チームの役割は、以前は非常にわかりやすいものでした。質問に答え、問題を素早く効率的に解決することです。しかし今では、すべての IT サポート チームの役割は、結局のところほぼ FAQ やヘルプ センター、確認リスト、手続きといったものになっています。 クラウド テクノロジーの時代において、これは完全に間違っています。 不安を抱えるお客様は、その気持ちを理解してもらいたいと考え、思いやりや人間性を求めているのです。「そう感じているのは自分たちだけではなく、プロバイダーも自分たちのことを真剣に考えている」といったことを感じ取りたいのです。 真に適切なサポート チームのミッションはたった 1 つです。それは、お客様の不安をゼロにすることなのです。アプリケーションのデザインやコード、運用などに内在する信頼性に対する不安を払拭する努力は今までなされてきていない。アプリケーションの誤った使い方などをGoogle社員に直接監査、チェックしてもらうことができる。 Googleの監査は極めて厳しく、これくらいの厳しい運用目標でクラウドサービスが動いているんだ、というアピールにもなる また、Pokemon GoのようにGoogleの認めた運用で問題が起きそうになった時には全力のサポートがなされる（運命共同体なので）。 クラウド事業者と顧客が同様に互いの責任範囲をすみやかに実行するという契約です。ここで特徴的なのは，SREでの"ダウンタイム"にあたるものが，CREでは"エラー予算"と呼ばれている点です。Googleが顧客のシステムを精査した結果，Googleが考える信頼性と現実の顧客のシステムの間にあるギャップ ―この"エラー予算"をベースに共通のシステムモニタリング体制を構築するとあります。 CRE チームは、お客様の基幹アプリケーションにおける主要な要素を、コードからデザイン、実装、運用手順に至るまで綿密に調査します。そこで見つけたものを取り出し、アプリケーション（および関連チーム）に対して厳しく PRR を実施します。ここで見つけたものを客が解決すれば、客のアプリケーションの信頼性は向上する。これをやるのにたいして、Googleは無料で行っているが、これは客からの信頼を得ているために合理的である。このような投資を行っているというだけで、お客様の不安が軽減されているのです。こうした原理や実践が、お客様が Google を使い続ける大きな動機となります。技術的にロックインするのではなく、人間関係を通じて構築される一体感につながるのです。実際、努力が必要なので、お客様の大半は申し込まないのではないかと私たちは見ています。ただ、数十億ドルものビジネスをクラウド上で行っている大企業が、このような機会を見逃すのは愚かな行為だとも思います。 |
