システム開発（アジャイル・スクラム）とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

エンジニアがザ・モデル（THE MODEL）を読んだのでマーケティングや営業の基礎とか用語とかまとめる

マーケティング

はじめに

こんにちは！
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

最近プロダクトをリリースしたのですが、バックオフィスの業務について深く考えられてなかったりで、 新たに出てきたステークホルダーから「作る人って売ること考えられないことが多いよね」とマサカリ投げられ大怪我を負いました。

SWEだろうがビジネスサイドの視点も持たなきゃいけないよねってことで、 ザ・モデル（THE MODEL）/福田康隆を読んでみました。

内容としては成功体験に基づく営業手法みたいな色が強いのですが、 調べながら読み進めていくとマーケティングから営業まで幅広に知識がつくのでおすすめです。 インサイドセールスとか最近のモノの売り方よくわからんって人も最初の1冊に良いかもしれません。

本ブログでは、事前にインプットしておいた方がいい用語とざっくり内容をまとめていますので、 これを読んだうえで是非書籍を読んでいいただけると良いかと思います。 （すいません前置きが長くなりましたが本題に入ります）

ザ・モデルの内容

営業の多様化

従来のいわゆる営業マンがやっていた領域を考えてみると、 ファーストコンタクトのための電話や外回り、顧客と発注書のやりとりまで実に幅広でした。

それだと効率的にできなくなってきたり、 最近は特にネットで調べてからコンタクトを取ってくる関係上、 フィルターかけた後に営業と会話することになるため、そもそも選定初期の土台に立てなかったりと環境が変化してきました。

段階毎に役割を変える

自分個人が1消費者として購買行動を取る場合でも同じですが、 商品購入までに、商品を認知して、興味を惹かれていって、実際に購入するといったいくつかフェーズがあります。

その各フェーズを担当するロールに分けて、効率的にマーケティングや営業活動を行おうというのが最近の潮流というわけですね。

認知段階では色々なツールを用いて顧客分析してリードを獲得するマーケティング、 興味や関心を持ったリードをナーチャリングして営業に繋げるインサイドセールス、 実際に購入に繋げる営業、そして購入後に継続的な利用をサポートするカスタマーサクセスといった役割です。
※ 既に何言ってるかわからんって人は用語集あるのでもうちょっと我慢してください

上記の役割の人がどのように顧客管理をしていけばいいのか、 体系的にまとまっていますのでとても理解がし易かったです。

図で理解したいって人は、下記サイトに載っていますので参考に。

salesbase.salesrobotics.co.jp

用語集

カタカナが多い

純日本人の自分だと厳しいものがあったので用語をまとめました。

  • リード：見込み顧客のことであるがいくつか分類あり
  • MQL（Marketing Qualified Lead）：マーケティング活動によって生み出されたリード
  • SQL（Sales Qualified Lead）：確度の高い営業がフォローするリード
    ※ 参考（もうちょっと詳細に分割できるらしい）：リードとは？MQL/SQL/TQLの違いは？意外と知らない「リード」の意味と分類方法
  • オブジェクションハンドリング：応酬話法や想定問答のこと（いい感じな反論）
  • アップセル：上位なモデル等に乗り換え
  • クロスセル：現在利用しているものとは別のセットや商品を買ってもらう
  • ナーチャリング：育成のこと。インサイドセールスの文脈ではリードをより確度の高いリードにすること
  • BDR（Business Development Representative）：インサイドセールスのこと、ADR（Account Development Representative）とも
  • コンバージョン：商品購入や資料請求などの最終的な成果
  • ファネル：直訳で漏斗。興味持った顧客が最終的な購買活動に至るまでに数が減ってきますのでその形から。パーチェスファネルとか言いますね
  • ファストパス：認知レベルの顧客がいきなり買うと言い出すなど、プロセスの階段を飛び越えること
  • デッドエンド：リサイクルの対象外
    ※ 書籍に詳細に書いてありますが、例えば商談に至らずとなった場合でも、 継続的にアプローチする等で再度リードに戻ってくる可能性があり、リサイクルせよってことを言っていました
  • MCP（Mutual Close Plan）：営業が受注（注文書受領）までのスケジュールを細かく区切ってアクションを顧客と合意する
  • （購買検討フェーズにおける）4つの不：不信･不要･不適･不急のこと。購買までの心の壁
  • BANT条件：Budget、Authority、Needs、Timeframeの頭文字。営業のヒアリング項目でよくあるやつ
  • ロイヤルカスタマー： 簡単に言うと優良顧客。ある企業やサービスに対して忠誠心の高い顧客のこと
  • CAC（Customer Acquisition Cost）：顧客獲得コスト。マーケティング費用とか

その他勉強になったことメモ

マーケティングの役割

新しい施策を打ってリード獲得数主義ではなく、見込み客を次のステージに進めることが大事。

インサイドセールスについて

平日日中という限られた時間で業務効率を上げられるかが成果に直結する。 （こう考えると営業って本当に効率が重要ですな、、）

100人の壁

有名なやつ。

hosokawaeiji.com

最後に

ぜひ書籍をどうぞ。

雑多なお勉強メモ（AzureFrontDoor、IPベースとSNI、SANs証明書）

お勉強メモ

今日のお勉強メモ

主にAzure FrontDoorのドキュメントを見てたのですが、 色々知らないところあったのでメモ。（主にSSL周りかもです）

Azure FrondDoor

Azureで可用性向上のため、東西の日本リージョン分散させたいとかなると出てくる選択肢として、 FrontDoorというサービスがあります。

個人的にへえと思った機能は以下の通り。

  • 「ルールエンジンの構成」で合致した条件に応じて任意のリクエストやレスポンスヘッダを付与できる。 例えば、デバイスの種類がモバイルだったらとかメソッドがPOSTだったらなどの条件に合致したらX-xxxヘッダ付けたりとか。
  • FD裏のバックエンド達は別にオンプレでも他のクラウドプロバイダーでもOK

docs.microsoft.com

IPベースとSNI（ネームベース）のSSL

一昔前の話っぽいですが、基本的に1つのサーバ（パブリックIP）に対して証明書は1つの制限がありました。

これの影響で、1つのサーバに色々なユーザ（ドメイン）が乗っかると、いきなりURLが変わったりとか不都合が生じていたそうな。 それがIPベースの方です。

それを解決するための技術がSNIであり、 単一のIPアドレスと複数のドメインのそれぞれで別のSSLサーバー証明書を使うことができる。

www.idcf.jp

マルチドメイン（SANs）証明書

ワイルドカード証明書は利用している方も多いのではないでしょうか。 サブドメインをカバーする*.がついているものですね。

対してSANs証明書の方は、「異なるドメイン」のWebサイトを1つのSSL証明書でカバーができる。

www.geotrust.co.jp

次勉強すること

まだFrontDoorのDoc読み切ってないので概念あたりから読む。 AzureのWebApplicationFirewallについてまとめたい。（多機能！）

アジャイルスケーリングの手法（SAFe®︎編）

アジャイル

はじめに

こんにちは！
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

アジャイルスケーリングの手法、色々ありますよね。 各手法について意見を聞くことがあるのですが、不勉強なせいで自分の言葉で良し悪しが説明できなかったり、 ざっくりかつ良い感じにまとめた記事があまり見つからなかったので調べたメモです。

今回はSAFeについてです。


SAFeをざっくりと理解する

SAFeとはなにか

SAFeとはScaled Agile Frameworkの略で、いわゆるアジャイルスケーリングの手法の1つになります。 こちらのサイトによれば

世界で最も活用されているビジネスアジリティ実現の基盤となるフレームワークがSAFe®です。SAFe®は、リーン、アジャイル、DevOps の原則、プラクティス、コンピテンシーを組み合わせた実証済みのフレームワークです。役割毎の教育カリキュラムが用意され、グローバルのパートナーネットワークとコミュニティでビジネスアジリティ実現を支援します。

とあります。うーんよくわかりませんね。TDCさんのサイトの方がわかりやすい。

SAFe® (Scaled Agile Framework：スケールド・アジャイル・フレームワーク)とは、Dean Leffingwell 氏が中心になって開発したエンタープライズ向けアジャイル開発・ビジネスフレームワークであり、企業規模でのリーン・アジャイル開発を実現するために必要な、役割や責任、行動に関する考え方が体系化されたナレッジベースです。

SAFeは、複数のアジャイル・チームの意見調整、共同作業、デリバリーを同期させることが可能です。拡張性と柔軟性に優れたSAFeは、企業独自のビジネスニーズに合わせることができ、少人数によるソリューションから、構築と導入に数百人、数千人を必要とするエンタープライズシステム構築まで対応できます。

ざっくり言えば、SAFeは色々な書籍やXP、スクラムといったアジャイル開発手法等からナレッジをまとめて体系化したもののようです。

どんな組織が導入しているのか

少し調べたところ、国内だとNTTデータとか上記のTDCなんかが出てきますね。 国外だとCapital OneとかAmerican Expressなんかが導入事例として紹介されています。

www.scaledagile.com

普及率は高いらしい

どこまで信頼のおける指標なのかは存じ上げないですが、State of Agile Reportによると、アジャイルのスケーリング手法としては35%と一番割合が高いようです。

stateofagile.com


もうちょっと具体的に知りたい

Big Picture

こちらのサイトにビッグピクチャという一枚絵があり、全体像が俯瞰できます。（タブをFull SAFeにしてください）この画像からざっくり理解を進めていきます。

原理原則

濃いグレーの下部にさまざまな原理原則が記載されており、例えばリーンアジャイルの10の原則などについて書かれたりしています。

組織チームの役割

左側のグレーの人型オブジェクトの部分が組織チームの役割が記載されています。後ほど紹介する動画では各人の役割が明確に定義されているとのことでした。

それ以外の部分

組織チームのプロセスについて記載されています。スクラムとかカンバンとか見慣れた用語もありますね。

SAFeの進め方

AgileReleaseTrainとは

SAFeではAgileReleaseTrain（以下、ART（アート））という、既存の縦割り組織とは別の仮想組織を構成します。人数は50~125人で、複数のアジャイルチーム、及びそれを支援するチームで構成されます。Trainとあるように電車を模しており、それ以上の人数の場合は電車の数が増えていくようです。

ARTでどうプロセスを進めていくのか

以下の5つのイベントを繰り返します。

  • PI Planning
  • 状況把握と決断
  • システムデモ
  • 次に向けての準備
  • 振り返り

これがART全体の動き、個々のアジャイルチームはスクラムで仕事を進めるようです。

PI Planning

これがSAFeの特徴っぽいのですが、PI Planningという、ART全ての利害関係が集まるイベントがあります。行うこととしては、マネージャ等が最低限の制限とともにミッションを作成、チームが責任を持って直近3ヶ月のプランを作成するなど。関係者が近い位置にいるので色々決めやすい。


SAFeを組織内で拡大させるために

Implementation Roadmap

インプリメンテーションロードマップと呼ばれる、組織でSAFeを拡大するためのロードマップ、そしてフェーズ毎に必要なトレーニングがまとめられています。

www.scaledagileframework.com

トレーニングについてざっと紹介。

スタートポイントフェーズ

要は導入フェーズですね。Leading SAFeというトレーニングを受講する。 社内の推進リーダー、つまりイノベータ向けの全体像理解トレーニング。

ART開始前フェーズ

全体像を理解している人を増やすためにより多くの人を巻き込みLeading SAFeを受講する。 他にはSAFeプロダクトオーナーやSAFeスクラムマスターといったもの、SAFe for TeamsというART発車前に全員が受講するトレーニングもあるようです。

複数のARTを作るフェーズ

要は拡大期。いくつかの専門的なトレーニングが用意されており、SAFe Advancedスクラムマスターなどがあるようです。

動画で観たい方

こちらのサイトをどうぞ。

www.tdc.co.jp

最後に

何かコメントや誤りがございましたらコメントください。 次はLeSSかなー。

エラスティックリーダーシップを読んだ

マネジメント

はじめに

こんにちは！
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

今回は『エラスティックリーダーシップ: 自己組織化チームの育て方/ロイ・オシェロフ』を読みました。 部下を育てたい気持ちはありつつも押し付けになってしまってはとか、なかなか言ったことを実践してくれないとか、 リーダーやマネージャーでなくとも少し年次が上がってくると多少なりとも悩んだりする瞬間があると思います。

この書籍ではエラスティック、つまりチームに応じて変化する弾力性のあるリーダーシップの在り方について書いています。 抽象化と具体化の例がわかりやすく、こういった本をあまり読んだことない方でも取っ付きやすい内容になっています。


最初にフェーズとモードのはなし

本書ではフェーズとモードという用語が使われています。 フェーズとは簡単に言うとチームの状態のことで、モードとはそれに対する反応のこと。 モードの説明が当初わかりづらかったのですが、闘争本能のようなものだと。例えば敵が迫っているような状態（フェーズ）だと、 闘争本能によって行動したりしますよね。このようにあるフェーズだと認識すると呼び起こされるものという解釈でいます。


チームの3つのフェーズ

チームには、サバイバル、学習、自己組織化の3つのフェーズが存在します。 サバイバルから学習、自己組織化へ、そしてフェーズによってリーダーシップのスタイルを変えて導くのがリーダーの役割。

この書籍では一番スキルが長けているスーパーマン的人をリーダーの前提として置いているので、 「スキルを身に付けるには新しいことに挑まなければならない。自分で解決してしまえば学ぶのは一人だけになってしまう」と警告したりしています。

サバイバルフェーズとは

響きだけ聞くと炎上プロジェクトのように感じますが、 このフェーズではチームの学習時間がない状態のこと。 ゆとり（Slack）を作り、サバイバルから脱することを目指す。

学習フェーズ

ゆとりの時間があり、その時間で学習や検証を行っている。 問題を自力で解決できるように教え、挑戦させることで自己組織化チームへと育てる。

自己組織化フェーズ

リーダーが数日仕事を放棄できる状態であれば、チームは自己組織化しているといえる。

それぞれに合わせたリーダーシップ

サバイバルでは、指揮統制型のリーダーシップを取る。学習フェーズでは、コーチ型だが場合に応じて指揮統制型を使い分ける。 自己組織化では、ファシリテーター型を。


バス係数とバス因子

これは有名な話ですが、バスに轢かれてメンバーが来なくなったときに、 何人いなければチームが破綻するのかという数をバス係数と言います。（つまり高ければ高いほど良い） バス因子とは、バス係数となるメンバー名や役割のこと。


コミットメント言語

やりますという宣言をコミットメント言語と表現。 バグを修正しますとか制御できないものに関しては、1日に何時間バグ修正に取組むとか、 不可能なコミットメントを可能なものに変えること。 デイリースタンドアップやその他約束がなされる場所でこの言語が使われる。


メンバーの成長

学習フェーズ

成長には波がある。グラフで言えば、高原があり、谷（成長前の適応期間的なものだと理解）、峰というのを繰り返し右肩上がりに成長していく。 まっすぐな線で成長するわけではない。

メンバーに対する問い

コーチング的な内容だが、『あなたはそれに関して何をするつもりですか？』と問う。 これは「（私ではなく）何々すべきです」とか自分でやらない回答とかではなく、抜け道のないものを引き出すことができるので良いとのこと。

全く話変わりますが、コーチング学んだ人ってあんななんで？って聞き続けるんだろ、、 コーチングおじさんではなく上手く話を引き出すスキルが必要ですね。

どういったものがチームや個人を成長させるのか

真の成長機会は、恐怖・初期の不快感や不満があることであると言っています。 一瞬ウッと感じるような取り組むのに勇気のいるものが人を成長させるということですね。


リーダーがやるべきこと

バス因子とペアワークや教師になってもらうなど、因子を見つけ、防ぎ、減らすことが担う役割の大部分。 あとはサバイバルから学習フェーズでは50%はチームと話たり作業したり多くの時間を過ごすこと。


クリアリングミーティング

クリアリングミーティングというワークというか手法について紹介がありました。 ① 今週もっと上手くいったらよかったこと（上手くいかなかったこと）、 ② あなたはそれに関して何をするつもりか、 ③ 今週起こったよかったこと・メンバーがしたよかったことについてそれぞれメンバーに聞いていく。 具体的な場面での例がありましたが、①を各メンバーに聞いて、その後②〜③の順に聞いていく。長くなるからと割愛したりせずに傾聴。


キーワードや心理学っぽい用語


さいごに

気になった方は是非書籍をどうぞ。

今さらジェフサザーランドのスクラムを読んだ

アジャイル

はじめに

こんにちは！
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

よく本屋さんで見かけるグレーの表紙の『スクラム:仕事が４倍速くなる“世界標準”のチーム戦術/ジェフ・サザーランド』を読みました。 スクラム始めて2年くらいになりますが、背景理解的な意味で復習した方がいいかなってことで再読メモ。


へえって話

  • ヘンリーガントがガントチャート考案したのは1910年代らしい（100年以上経っとるものを未だに使っている現代社会）
  • スクラムの透明性については、コロラド州議会で導入を進めていたサンシャイン法（会議公開法）から影響
  • プロダクトオーナーの発想は、トヨタのチーフエンジニア（例えばカローラとかの生産ライン全体の責任者）から。 人事とかの権限はないが、ビジョンやどう造るのか責任を持つ。


ハイパープロダクティブ

ハイパープロダクティブ、直訳すると『超生産性』。 サブタイにもなっているが、この書籍ではスクラムを導入することによるスピードについての記述が多い。 主体性を持ったチームが障害を取除きつつ開発をすることによって仕事が4倍早くなる。

個人的にはスクラムは現状を見える化するのに特化したフレームワーク、アジャイルになる目的は変化への適応が 一番しっくりきており、スピードは副次的なものかなあってところだったので、強調ポイントにギャップはあったり。


トヨタ生産方式とか日本の製造業とスクラム

お馴染みかと思いますが、スクラムは日本の製造業から大きな影響を受けています。

ただ、その影響を与えた日本企業はW・エドワーズ・デミングというアメリカの統計学者から 学んだという話は皮肉ですね。問題の解決には後からではなく、問題を発見したその場で当たるのが ベストという考え方が根底にあるなどと紹介されていますが、トヨタ生産方式について断片的な知識しかないので、 そろそろ大野耐一氏の書籍を読みたいところ。


幸福

仕事では幸福こそ大切、幸せであればいい選択ができる。 想像力を発揮、仕事を辞めず大きな成果にも手が届く。 人は成功したから幸せになるのではなく、幸せだからこそ成功すると。

鶏と卵みたいな話は置いておいても、 このあたりの正のループが循環させたい！って思いで仕事したい。

チームのメンバーを幸せにする要素は主体性、スキルアップ、目的意識。 スクラムちゃんとやっていると勝手にこの要素ついてくるの本当すごいなって改めて思った。

ちなみに幸福のバブルという、成功したチームが改善しなくていいのでは？となり、 現状に満足する赤信号なので注意。 スクラムマスターを『賢い道化』と表現してましたが、誰もそこに触れなければ、 気付きを与えて導く役が重要であると言っています。


レトロスペクティブ

シンプルに進め方で変えられるところはないか、仕事を進めるうえでどこが一番の難関か、 という2点を聞くのが良い。なんか最近色々なふりかえりのフレームワークをやっていましたが、 ベースはここなんだなあと。


キーワードだったり出てきた心理学っぽい用語


さいごに

気になった方は是非書籍をどうぞ。

今さらエクストリームプログラミング（第2版）を読んだ

アジャイル

はじめに

こんにちは！
某企業で内製開発の推進やスクラムマスターとか色々やっております@daimyo404です。

弊社では、スクラムにXPのプラクティスを導入して開発を行っています。XPについては、断片的に知識はあったものの、体系的に理解できてなかったということもあり、改めて勉強してみました。

読んだ書籍は、『エクストリームプログラミング（第2版）/ケント・ベック（Kent Beck）、シンシア・アンドレス（Cynthia Andres）』です。日本語訳は角征典さんですね。今回第2版を読んだのですが、第1版とかなり違うようですので、改めて読んだりするもの良いかもしれません。なお、本記事はただの読書メモです。


XPとはなんなのか

建築家のC・アレグザンダーによる、パタンランゲージという知識記述の方法があります。それに触発されて、ソフトウェア開発における「パターン」をまとめ、著者のケントベックらはエクストリームプログラミングとして提唱しました。本書でもフォースなど、パタンランゲージの表現が出てきたりします。

XPには価値と原則、プラクティスという３つのキーワードが出てきます。


XPの5つの価値

XPでは5つの価値について述べています。

  • コミュニケーション
  • シンプリティ
  • フィードバック
  • 勇気
  • リスペクト

上記価値はそれぞれ独立したものというよりは相互的に作用します。比較的言葉の通りな感じですので、詳細知りたい方は、書籍をどうぞ。


XPの原則

  • 人間性
  • 経済性
  • 相互利益
  • 自己類似性
  • 改善
  • 多様性
  • ふりかえり
  • 流れ
  • 機械
  • 冗長性
  • 失敗
  • 品質
  • ベイビーステップ
  • 責任の引き受け

価値とプラクティスのギャップを埋めるものが原則です。

価値は抽象的すぎるため、プラクティスを実施する指針にするためのものと理解しています。 「否定的な感情に耳を傾ければ、新たな知見の源泉になる」というのは最近イライラしがちだったので自戒。


プラクティス

プラクティスには主要プラクティスと導出プラクティスの2種類があります。

主要プラクティスは無関係に役立ち、安全に始められる。導出プラクティスは主要を習得してから導入すること。つまり、基本的な主要を守ってから導出を始めようねと言っています。

主要プラクティスは以下の通り。

  • 全員同席
  • チーム全体
  • ストーリー
  • 週次サイクル
  • 四半期サイクル
  • テストファーストプログラミング

少し触れると、テストファーストプログラミングはロジック本体を修正する前に失敗するテストを書きましょうとか、週次サイクルは週次で仕事を計画しようとかそんな感じです。 スクラムでは具体的な開発方法については言及していないので、前者は導入できたりするかもですが、後者は少し被ってくる部分だったりしますかね。

導出プラクティスは以下の通り。

  • 本物の顧客参加
  • インクリメンタルなデプロイ
  • チームの継続
  • チームの縮小
  • 根本原因分析
  • コードの共有
  • コードとテスト
  • 単一のコードベース
  • デイリーデプロイ
  • 交渉によるスコープ契約
  • 利用都度課金

こちらも少し触れると、デプロイまでの期間をなるべく早く、デイリーでデプロイしようとかの考え方を言っています。主要を先に導入せよと言っているのは、テストファーストプログラミングなど、品質を高める活動をしないうちにデイリーデプロイすると失敗するから、そう言った理由になります。

また、プラクティスは組み合わせることで効果を増幅させます。


3つのキーワード

価値は抽象的なので原則という指針を持ってプラクティスに向かう。（実施する）

さいごに

気になった方は是非書籍をどうぞ。