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