アジャイル開発
アジャイル開発の概要
アジャイル開発、エッセンスとしては要件定義->設計->開発->テストと過程が続いていくが、本当にある工程が満足いく品質で確認事項や抜け漏れもなく終わったといえるためには、成果物を後工程で実際に使ってみる他ない。そのため、ウォーターフォール開発のように各工程を一回ずつしかやらないのではなく、アジャイルのようにちょっと成果物ができたらすぐ後工程に回すというのを１週間おきくらいに繰り返すのが良いという理論。
アジャイル開発がうまくできない時
アジャイル開発の数々のセレモニー（ミーティング）をただ形式的にこなせばいいというわけではないと思っている。本質を理解していない凡人がただ形式だけ真似しても、本質が抜け落ちてしまい何の意味もない、ということは世の中のあらゆる分野でよくあることだと思う。
ガチガチのウォーターフォール開発でどうしてもそれを変えられないという状況もあると思っている。ただ、アジャイル開発の本質の一つは上記概要に記載したことだと思っている。そのため、アジャイル開発のエッセンスを取り入れることはできる。成果物がちょっとキリのいいところまでできたら、すぐ後工程の人など他の人に見せてフィードバックをもらい、抜け漏れを洗い出して直すことが必要である。これを短いスパンで繰り返しやると良い。そうすればアジャイル開発のエッセンスは満たせていると思う。
実際エンジニアの立場でそのようにやってみた。バグの数が半分~1/3くらいになり、かなり品質が良くできた。フィードバックをもらう時間を後回しにせず、キリのいいところまでできたらすぐCIで自動でビルド・デプロイし、PMなどに見てもらったりした。あるいは自分でユーザーの立場に立って、成果物を触って違和感がないかチェックしたり、設計書・テスト項目書と照らし合わせて抜け漏れがないかいちいちチェックしてみたりした。その場その場でチェックをすぐにやっていくということである。
参考文献
- アジャイルサムライ−達人開発者への道−, Jonathan Rasmusson, オーム社, 2011
PMBOK
プロジェクト管理に必要な知識や分野などをもれなく洗い出したもの。
最新は第７版である。が、第７版は第６版と比べてかなり大規模な変更が入っている。また第６版と比べて具体的な運用部分などが省略されている部分も大きいとされる。そのため、第６版と第７版を合わせて理解しておくのが重要と考えられる。そこで、ここではまず最初に必要な第６版を取り上げる。
ここで詳しく扱うもの: 「10個の知識エリア」
あまり扱わないもの: 「ライフサイクル」「5プロセス群」
「ライフサイクル」「5プロセス群」について簡単に触れる:
ライフサイクル
要件定義、設計、開発、テスト、公開、譲渡 など。これらはプロジェクトによって柔軟に変えられる。例えばプロジェクトによっては「実現性調査」という過程があるかもしれない。またプロジェクトによっては「開発・公開」だけで終わるかもしれない。
５プロセス群
以下の５つ。これらはプロジェクトによって変わらないとされる。
- 立上げプロセス群 (Initiating)
- 計画プロセス群 (Planning)
- 実行プロセス群 (Executing)
- 監視・コントロール・プロセス群 (Monitoring and Controlling)
- 終結プロセス群 (Closing)
監視・コントロール・プロセス群以外の4プロセスはプロジェクトの開始から終了までの順番の期間として区切られている。一方、監視・コントロール・プロセス群 だけは、プロジェクトの全期間において継続的に行う必要があるとされる。
以上の５プロセスについて、それぞれ以下に取り上げる10個の知識エリアのマネジメントが濃淡の差はあれど必要になってくるとされる。単純に考えれば5✖️10=50で50項目気を付けることがあるということになるが、実際は不要とされる部分もあるため、気をつけるべきなのは50の半分ほどとなる。ここでは詳しくは解説しないが、5✖️10の雰囲気を掴むため、図のみ掲載する。
Project Management Process group and Knowledge Area Mapping (PMI, 2013) より引用
10個の知識エリア (Knowledge Areas)
プロジェクトマネジメントについては以下の気をつけるべき１０要素があるとされる。
以下は、一見当たり前のことを言っているようには聞こえるかもしれない。が、何が当たり前かは人によって違う。そのため、このように共通言語として明確化しておくことがPMBOKの価値だと筆者は考える。
統合マネジメント (Integration Management)
他の知識エリアやプロセスグループなどの特定、調査、調整などを総合的に行う。
例えば、（以下に取り上げている）スコープマネジメントができているか？ スケジュールマネジメントの作業はいつやるか？ ということの調整などがここに該当する。
スコープマネジメント (Scope Management)
プロジェクトで何をやり、何をやらないかを、なるべく後戻りや認識違いが発生しない粒度まで洗い出し、関係者と合意しておく作業とされている。これが一番重要なこととされており、PMBOKでも統合マネジメントの次に真っ先に取り上げられている。
これがうまくできていないと他の全てのマネジメントが崩壊する・できないこととなってしまう。なぜなら、やるべきことが決まっていないとなると、スケジュールを立てたり、物資を調達するなど他の作業をしても後からひっくり返ってしまい、無駄になってしまうことになるからである。
このマネジメントの成果物として、いわゆるWBS、WBSディクショナリの作成がプロジェクトの計画段階で必要だとされる。これらは、プロジェクトで必要な作業を全て列挙したものである。下図の左側のように、各作業を列挙している部分がWBSに該当する。
WBSでは、全ての作業が、容易に見積・コントロール可能なくらいまで細かく分解・洗い出しできているかが重要となる。そのため、実際の作業者など、知識豊富な人にレビューしてもらう必要があると思われる。
ただ注意事項として、ビジネスはその時々に応じて変化していくものであって、いくら完璧にスコープを決めたとしても後から変えなければいけないことも必ずあることには注意。
スコープ外の要求をお客様などからされた場合、スコープで合意していないからといって杓子定規に断るとあまり良くない。一旦検討して、ダメならダメだったなどと理由を伝えたり、後ろにずらしたり、代替案を提案するなどが考えられる。
スケジュールマネジメント (Schedule Management)
ガントチャートまたはバーンダウンチャートなどを用いる。
ガントチャートは、以下の右図のように、各作業項目に対して棒グラフのように開始時期と終了時期を列挙したものとなる。この表はある項目を後ろにずらすと、他の項目全ても後ろにずらさなければなら、ずめんどうくさい場合もあるため注意。また、作業者の作業スピード（ベロシティ）といった要素は見える化されないという欠点もある。
バーンダウンチャートでは上記の欠点はなく、作業者の作業スピード（ベロシティ）が線の傾き具合により明確化される。想定通りのスピードが出ているかすぐわかるので、指標としてスケジュールの管理がしやすい。
下図は、バーンダウンチャートの一例。実績（赤い線）が計画（青い線）に達しておらず、作業スピードが出ていないことが一目でわかる。
ただ、「作業スピードをスケジュール管理の指標にしています」というのを大々的に言ってしまうと、作業者がその指標が悪化しないように立ち回り、やるべきことをやらなかったり言うべきことを言わないようにするなどの現象が起きることもある。そのため、何を指標にしているかは大々的に言わず、マネージャーの心の中だけとしておくのが良いかと思われる。
コストマネジメント (Cost Management)
プロジェクトが承認された予算内で完了するために必要な管理を行います。アーンド・バリュー・マネジメントなどが有名な手法ですが、ここでは記事の長さの都合上割愛します。
品質マネジメント (Quality Management)
ステークホルダーの目的を果たすことができるよう、プロダクトが品質を満たしているかどうか管理することを言います。「QC7つ道具」といった日本初の枠組みが有名ですが、ここでは記事の長さの都合上割愛します。
リソースマネジメント (Resource Management)
人員などのリソース管理のことを言う。
一つのポイントとして、人のアサインについて、ある期間アサインし、その後アサインから外し、しばらくしてまたアサインするというように間を開けてしまうのはあまりよろしくない。なぜなら、その中途半端な間の期間にその人は別の仕事を見つけないと手が空いてしまうことになるが、その中途半端な期間をちょうど埋めるだけの他のプロジェクトがあるとは限らないからである。
コミュニケーションマネジメント (Communications Management)
プロジェクトとステークホルダー間で欲しい情報の交換が行われるよう管理することを言う。
コミュニケーションのやり方について、会話・メール・電話・SNSなど複数のチャンネルがあるとどこで何を話しているのかよくわからなくなることが多い（特に、お客様との会話）。そのため、Backlogなど容易に管理できるツールでのみコミュニケーションを図ることとすると良い。そして、そのことをプロジェクト開始時に所与のものとして合意しておくとよい。
リスクマネジメント (Risk Management)
プロジェクトにとってプラスになることの発生率を増大させつつ、マイナスになることの発生率や影響度を減少させるための管理のことを言う。ここではプラスの影響を及ぼすこともリスクに含まれるということに注意。
心構えとしては悪いことは必ず起こり、良いことは起こらないぐらいの想定でいるのが良いかもしれない。
また、起きるかもしれない悪いことについて、自分に知識がないと全く思いつくことができないかもしれない。そのため、その分野の有識者に話を聞き、人を巻き込むことが特に重要となる。
調達マネジメント (Procurement Management)
必要な物資や人の取得、購入を行うためのプロセスを言う。
ポイントとしては、物や人の調達には時間がかかることが多いため、「ちょっと進みが悪いかな？」と感じたくらいのところで、もう調達の準備を始めるくらいでちょうど良いという点が挙げられる。
ステークホルダーマネジメント (Stakeholder Management)
プロジェクトに影響を与えたり、または影響を与えられる可能性のある人をステークホルダーと言う。このステークホルダーを管理するためのプロセス。
対人のコミュニケーションの一つのコツとして、人にはいろいろ性格や価値観があり、その人に合わせた言動をして気に入られると良い。
| 人の性格など | 対応方法 |
|---|---|
| 雑談などを好む人情味のある人 | 適当などうでもいい雑談などを挟むと良い。 |
| 経営層など数字にこだわる人 | 数字や、ビジネス状のインパクトなどを話してあげると良い。 |
| エリートなど成果にこだわる人 | 余計な話はせず、ひたすら成果を上げて認められると良い。 |
| 人種・性別・国籍・政治・宗教・身体障害マイノリティ | それらについての話題には触れない。が、配慮が必要な場合、配慮を求められたときは可能な限り柔軟に配慮してあげると良い |
制約理論（Theory of Constraints）
ユダヤ人実業家 エリヤフ・ゴールドラット氏が「ザ・ゴール」の中で提唱したマネジメント理論。組織の中の弱点（ボトルネック）を見つけ出し、組織全体の出力を改善することを目指す。
制約理論とは
仕事が他の人や組織・部署と繋がって行われている
それぞれの人や組織の能力は一緒ではなく、早い遅いのばらつきがある
この場合、全体の成果（スループット）を決めるのは、一番弱い人や組織ということになる。他がいくら早くても、一番弱い部分が遅ければ一番弱い部分に合わせた成果しか出ないため。
例えば、設計やテストが１ヶ月で終わるとしても、開発が２ヶ月かかってしまう場合、設計やテストをいくら頑張っても絶対に２ヶ月は全体でかかってしまうということになる。そのため、一番弱い部分（ボトルネック）に資源を集中しすることが全体として最適な結果となる。
各部署が自分自身の作業だけを手を休めずやり続けているとすると、非常に非効率ということになる。理由は、そうするとボトルネックである人や部署（仕事が遅い人や部署）にどんどんやるべき作業が積み上がっていき、全体として非効率になってしまうからである。
そのためボトルネックでない人や部署はある程度自分の作業は余裕を持って終わらしておき、ボトルネックの人や部署を手伝ったり支援したりすると良い。
あるいは、ボトルネックの人や部署がこなせる量に合わせて、全体の作業の量や進行スケジュールなどを調整するような仕組みにすると良い。
あるいは、各部署の作業の順番を入れ替えたり、あるいは同時並行的にできるような場合は、ボトルネックの部分で作業を止めないで、他の作業を進めたり、同時並行的に進めたりすることで緩和できる。
開発が遅いため全部開発が終わっていないが、開発が終わっている部分だけでも先にテストを始める、というようなことがこれに該当する。
この点、ガチガチのウォーターフォール開発は要件定義 -> 設計 -> 開発 -> テスト の工程を順番に一回ずつやるだけで、柔軟に順番を変えたり、同時に並行したり、一部分だけやって何度もサイクルを回すというようなことを許容しないので、この点非常に非効率ということになる。
アジャイル開発のように、開発が終わった部分からすぐテストを始める、というようなやり方だと、テスト工程の人が手が空いて暇になるということがなくなるため、全体的に効率が良くなる。
仕事の需要や、各人の成果にはどうしてもバラツキがあるため、需要に合わせた最小限の体制しか積んでいないと、わずかな需要やパフォーマンスの変化によって容易に崩壊する体制となってしまう。
世の中には何事もばらつきや変動があるということを踏まえれば、ある程度ゆとりを持った体制にしておく必要がある。
ちょっと誰かが育休などを取っただけで他の人が限界を超えてしまうなどという体勢はゆとりがないと言える。普段は何をしてるかよくわからず半分遊んでいるようにも見える、というような人が昭和の時代はいたかと思う。理想論ではあるかもしれないが、そのような暇な人を抱えておくぐらい余裕を持っておくと、いざという時にも対応ができる。
NLPコミュニケーション
相手との信頼感ある関係性を築くためのコミュニケーションの手法。NLPとは神経言語プログラミングを指し、人間の心理を解析し受け入れやすいコミュニケーション等を確立することを目指す。
安心安全なコミュニケーション
人は、本能的には、正確なコミュニケーションを求めているわけではない。 安心安全なコミニケーションを求めている。そのためただ用件や事実などを正確に伝えれば、コミニケーションがうまくいくわけではない。 相手に安心感を抱かせるようなコミニケーションをすることで、自分の用事などが相手に受け入れてもらえやすくなる。あるいは自分の主張などを受け入れてもらいやすい状態を作れる。そのような手法がNLPコミュニケーションである。
相手が同意する=「はい」と言ってもらえるようなことを会話の中に盛り込んでおく。すなわち、相手を肯定するようなメッセージである。すると相手は安心できる。すると、その後の要求などを気持ちよく受け入れてもらいやすくなる。
例 ✖️「（いきなり声をかけて）これ間違ってるから治しといて。（相手「...はい」）」
↑事実を伝えているだけなので、正確性という意味では問題のないコミュニケーションである。しかし相手の都合を聞くなどの配慮もなくいきなりお願いしている + 相手に「間違っている」というメッセージを投げかけている。 すると相手は本能的には受け入れ難くなる。
◯ 「お疲れ様です。（相手「はい」）いつも作業ありがとうございます。（相手「はい」）助かってます。（相手「はい」）今ちょっといいですか。（相手「はい」）これをこのように修正することは可能でしょうか。（相手「はい、わかりました。」）」
ネガティブに考えられていることの思い込みの打破
ネガティブに考えられていることの思い込みの打破
人は、本能的には、安全を重視する。そのため何らかの既存のネガティブな経験から思い込みを作りあげ、そこから出ることを嫌う傾向がある。それがあまりにネガティブだと困り物である。自分、他人のそのような思い込みを崩す方法はいくつかある。
（ネガティブな思い込みに対して）なぜそうなるのか？ なぜそのように思ったのか？ を問う。 <- 思い込みの成立過程を追うことで、その思い込みがいつでも当てはまるわけではないことがわかるかもしれない。
（ネガティブな思い込みに対して）もしその思い込みから外れるようなことをしたら何が起こるのか？ を問う。 <- その思い込みから外れたところで大したことがない、または対処法があるとわかり、大した思い込みではないと気付けるかもしれない。
(ネガティブな思い込みに対して）その思い込みは本当にいつも、誰にでも、どこでも、どんな状況でも当てはまるのか？ を問う。<- その思い込みがいつでも当てはまるわけではないことがわかるかもしれない。
問題状況の言語化は「名詞」ではなく「動詞」で
問題状況の言語化は「名詞」ではなく「動詞」で
問題を「名詞」で捉えるとそれがあたかも重大で動かし難い問題かのように誤解してしまう傾向がある。「動詞」で言い直すと、それの解決策があることに気づきやすくなる。
例: 名詞で捉えた場合: 「部下との意思疎通の問題」がある
動詞で捉えた場合: 「主にA君が私と話すときに気を使いすぎてあまり意見を言ってくれていない」<- A君にリラックスしてもらうにはどうするか、など解決策が容易に思いつきやすい。
チームビルディング
- 日本人については海外と異なり本音で喋ったり褒めたりするのが苦手だったりする。本音や感情を出して喋ることは恥ずかしいと言う感覚があるのだろう。それを吸い上げるのが一種飲み会であったりはしたわけだが、近年は飲み会も難しい（最強のチームをつくる20のセオリー, 原田典子ほか, 幻冬舎, 2016）。
- 相手を否定せず安心感のある環境を作り上げたり、よくできている部分をしっかり褒めたりといったことを意識的に進める必要があるだろう。
ビジネスフレームワーク
-
ビジネスフレームワーク図鑑 The Ultimate Collection of Business Frameworks, 株式会社アンド, 2018, 翔泳社 より。
- 本の購入者は、以下の表のテンプレートファイルをダウンロードでき、非常に便利なので是非使ってみよう。
問題の発見
- As is/To be
- 6W2H
- なぜなぜ分析
- コントロール可能なものと不可能なものに分ける
- MECE（Mutually Exclusive and Collectively Exhaustive）
- Logic Tree
- 緊急度・重要度マトリクス
- 意思決定マトリックス
- 他責＆自責で分類
市場分析
- PEST分析
- ファイブフォース分析
- VRIO分析
- SWOT分析
顧客分析
- パレート分析
- RFM分析
- ペルソナ
- 共感マップ
- カスタマージャーニーマップ
競合分析
- 4P分析
- バリューチェーン分析
- コアコンピタンス分析
アイディア
- ブレインライティング
- マンダラート
- 形態分析法
- シナリオグラフ
- オズボーンのチェックリスト
- アイディアシート
- ストーリーボード
- プロコン表
- SUCCESs
- ペイオフマトリクス
戦略
- プロダクトポートフォリオマネジメント
- アンゾフの成長マトリクス
- クロスSWOT
- STP
- ポジショニングマップ
- ビジネスモデルキャンバス
- スキーム図
- ロードマップ
改善
- KTP
- PDCA
- 業務フロー図
- PERT図
- RACI
- ECRS
組織
- ミッション・ビジョン・バリュー
- Will・Can・Must
- ジョハリの窓
- 認知・行動ループ
- ウォンと・コミットメント
- PM理論
- ステークホルダー分析
- 動機づけ・衛生理論
伝達
- 商品企画書
- イベント企画書
設計書
参考: はじめての設計をやり抜くための本 第二版、吉原庄三郎、SYOEISYA, 2022
上記書籍を参考にしていただきたい。その上で、ここでは、ネット上で利用できる設計書テンプレートがあれば随時記載していく。
要件定義
全般
-
要件定義書
-
全基本設計書テンプレート
-
Note - 基本設計書のテンプレート
- 2024 年現在、無料でテンプレートを公開いただいているようである。
-
Note - 基本設計書のテンプレート
ユースケース分析
- ユースケース一覧
- ユースケース記述
- ビジネスルール一覧
- ビジネスルール
概念モデリング
- 概念モデル
- 用語集
非機能用件定義
- 非機能用件定義書
外部設計
画面設計
- UI設計ポリシー
- 画面遷移図
- 画面一覧
- 画面モックアップ
- 画面入力チェック仕様書
外部システムI/F設計
- 外部システムI/F設計書
バッチ設計
- バッチ設計書
帳票設計
- 帳票設計書
データベース論理設計
- 論理ER図
内部設計
画面プログラム設計
- Controller一覧
- Controller設計書
- 画面共通部品設計書
ビジネスロジックプログラム設計
- ビジネスロジック設計書
データベースプログラム設計
- エンティティクラス図
- CRUD設計書
データベース物理設計
- 物理ER図
- テーブル定義書
コンサル系ナレッジ
コミュニケーション
- 回答に詰まった時に口から出まかせでよくわからんことを喋るのは良くないので、１・2分考える時間をいただいていいか聞くと良い。
- 単なる意見だけだとはっきりいって潰されることも多いため、事実を集めて事実ベースで喋れば意見を通せる可能性が高まる。証拠の伴った事実を握りつぶすのは難しい。
- 相手のジェスチャーや様子を見ながら、理解してもらっているかどうか見ながら話す。無言の場合は大抵理解していないことが多い。
- 技術面などの情報をただただ列挙していくというような言葉はもはや会話とは言えない。相手が本当に何が欲しがっているかを汲み取り、それに合わせた提案などをする必要がある。相手が言っていることと、相手が本当に欲しがっていることが食い違う可能性すらある（相手が嘘をついていたり、相手自身も自分の欲しいものを言語化できていない）。
- 特にASDなど発達障害者は相手のいうことをただそのままに受け取ったり、自分が話す場合は単に自分の知っていることをひたすら列挙することがあるため、意図的に直す必要がある。
姿勢
- 顧客や上司がどんな期待を持っているかをよく聞き取り、それを外さず、かつできれば期待値をちょっと上回ると良い。
- 逆に、異常に期待値が高い場合はよく理由を説明して期待値を下げてもらうことも必要。
- 最終成果物が必要な背景事情、最終成果物の形式、クオリティの優劣、締め切り、他の仕事との優先順位、締め切りを確認しておく。
- どのように取り組んでいくか、という過程についてもざっくりと話し、合意をとると良い。
論理
- 論理を鍛えるトレーニングを毎日やる必要がある。
- 日々見かけるものがなぜ需要があるか、なぜそうなったかなどを一度自分で仮説を立てる。
- 調べる、人に聞くなどして答え合わせ
- 答えを丸暗記する必要はないが、基礎的な数字（感覚）は覚えておくと良い。
資料
- 議事録について、日時、場所、参加者、アジェンダ、決まったこと、決まらなかったこと、確認点、次回に向けてのTODOなどがあると良い。
- パワポ資料について、１ページにつき１つの数字や事実と、１つの解釈や意見を入れる。それ以上はごちゃつく。官公庁のパワポ資料であれば１ページに詰め込みまくることはあるがビジネスではやめた方がいい。
- パワポ、エクセルのショートカットを覚えて作業を高速化させることは必須と言える。
- エクセルでは多すぎて無理なほどのデータ量がある場合、データベース（SQL）を使うことも必要かもしれない。
- 資料を作る際、最終成果物のアウトラインをまず作るというのが有効。あとから抜け漏れがなくなるし、目的がわかっているので効率的な調査となる。
- あるテーマについて調査する際、2, 30冊の本を2~3日でざっくり目を通し、目的意識を持って拾い読みするといい。その中で見つけた大事なポイントを、さらに専門的な本を読んで深めていく。
- ただ、聞き齧った情報だけだと独自性がない上っ面だけになってしまう可能性も残る（特に、ネット記事でしか調べてない場合）。本でも良いが、実際に調査対象の物事を自分で少しでも試してみる、使ってみるという行動力も重要。
ビジネス系ナレッジ
ウィニング 勝利の経営, ジャック・ウェルチ
ミッション・バリュー
- 従業員によく動いてもらうためにミッションをしっかり定め広めることは大事ではある。ただ、それも金銭的にしっかりした報酬に裏打ちされたものではなければ長続きしない。
人材採用
- 職務を遂行する能力はもちろんのこと、管理職ならば周囲に良い影響を与えるようなポジティブさ、難しい判断ができる決断力、自分自身を偽らない誠実さといった点が必要になるだろう。
キャリア
- 昇進したい場合は上司に求められた成果を圧倒的に超えるような成果を出す必要がある。また、斜め上のどうでもいい方向で越えるのではなく、あくまでも求めらている方向性で超えていく必要があることに注意（独りよがりで何かプラスアルファを付け加えても意味がないので、上司や顧客の意向に沿っているかどうかを確かめる。）
ビジョナリーカンパニー 時代を超える生存の原則
トップクラスの企業では
- 一種カルト的な同質性（マッチする人には天国だが、マッチしない人はあっという間に追い出される）ような部分があるとする。
- 基本となる理念（内容は問わない）にどこまでも忠実だが、他方で理念以外のありとあらゆるものを変えていく。
- 当初からしっかりとした目論見や技術や計画性を持って参入した企業ではない企業が多い。そうした企業ももちろん素晴らしい成果をあげている企業は多いが、トップクラスとなるとむしろ行き当たりばったりに企業し、あらゆるものを試しまくったような企業が多い。
アプリマーケティング
Webマーケティングなどと同様にアプリも公開、運用においてマーケティングが必要となる。基礎となる理論や概念、ツールはさまざまな書籍で一通り紹介されているが、実際にやってみないと身につけるのは難しいと思われる。
アプリはWebサイト、SNSと違ってダウンロードの手間がかかる分、熱心なユーザーが多いとされ、ロイヤリティや売り上げも大きい傾向がある。従前のマーケターの方はアプリの重要性をそれほど理解していないこともあるが、実は重要となる。
アプリはどのワードで検索し、ダウンロードしたか、アプリを開いた後どんな行動を取ったかなどの行動を種々の分析ツールで極めて詳細に把握でき、ユーザー一人一人や、一定のユーザーグループのユーザーストーリーを理解できる。継続的な改善に取り組むことでより有効なアプリとすることができる。
プッシュ通知は、興味を失ったユーザーを取り戻せる非常に有力なツールなため必須級となる。それでもダメならクーポン配布、キャンペーン実施などユーザーへの利益を提示して、再びアプリを開く習慣をつけていただくという戦略が基本となる。
- 参考: 事例に学ぶスマホアプリマーケティングの鉄則87, 池村修, ASCII, 2016
- マーケターのためのアプリの教科書, 株式会社ヤプリ, インプレス, 2021
市場分析
- data.ai(旧 AppAnnie)というサイトを使うと、アプリのシェアが分析できる。
プロトタイピング
- アプリ企画段階でアプリの想像図を作るためのツールがある。Mockkitなどが有名。
ASO(App Store Optimization)
アプリ名、アプリアイコン、紹介文、スクリーンショットなどを作り込んでいくことになる。アプリ名は、Google Play Storeではいつでも変えられるので、Google Play Storeで色々変えてみて、いいものをiOSのApp Storeにも使うと良い。
アプリ内施策
-
Push通知、アプリ内のお知らせ、Deep Link、クーポン配布、スタンプラリー、その他キャンペーン実施など。
-
アプリアップデートの通知をpush通知やお知らせで促すこともできる。強制するというのはユーザー体験を損なうのであまり薦めない。
-
GTM(Google Tag Manager)を利用するとGoogle Analyticsを含めた複数サービスのタグを一括管理できて、格別にタグを埋め込む手間を節約できるので、ぜひ使うと良い。
参考: 【実践】Googleタグマネージャーとは？設定・導入・ログイン方法などの入門編
広報
プレスリリース、ニュースサイト、アプリレビューサイト、他アプリとの相互広告などの手法で広報を行うことができる。SNSへの口コミ投稿を促したり、自社サイトのブログや、アプリのランディングページの作成でも、タダで広報ができるのでマストと言える。
広告
アドネットワーク広告（Google Adsなど）、Facebookモバイル広告、記事広告（レビューサイトやニュースサイト）、店舗リアルアフィリエイトなどといった手法がある。
分析
Googleアナリティクスはアプリ内外のさまざまなユーザーの行動を詳細に分析できるためマストだろう。
他にも、マーケット分析を行うためのMetaps, クラッシュ分析を行うためのFirebase Crashlytics, ストアを行うためのdata.ai(旧 AppAnnie)やiOS・Androidの各ストアの公式ページ、どのようにGoogle検索からアプリに遷移したかを探るためのGoogle Search Consoleなどがある。
資料
マーケターのためのアプリの教科書 (株式会社ヤプリ, インプレス, 2021)は、購入者向けに、アプリのダウンロード数と売り上げの分析用エクセルファイルを公開しているので、購入の上ダウンロードしていただきたい: https://book.impress.co.jp/books/1120101149
参考文献
- よくわかるPMBOK第6版の活用, 鈴木安而, 秀和システム, 2018
- よくわかるPMBOK第7版の活用, 鈴木安而, 秀和システム, 2023
- Youtube, Deniz Sasal, Project Management Simplified: Learn The Fundamentals of PMI's Framework, https://www.youtube.com/watch?v=ZKOL-rZ79gs
- Youtube, プロジェクトマネジメントの教室, https://www.youtube.com/@user-it2mv8qb5l
- ザ・ゴール コミック版, エリヤフ・ゴールドラット, ダイヤモンド社, 2014
- マンガでやさしくわかるNLPコミュニケーション, 山崎啓支, 日本能率協会マネジメントセンター, 2013
- エンジニアがビジネスリーダーをめざすための１０の法則、ベイカレントコンサルティング、翔泳社、2016
- ビジネスフレームワーク図鑑 The Ultimate Collection of Business Frameworks, 株式会社アンド, 2018, 翔泳社
- はじめての設計をやり抜くための本 第二版、吉原庄三郎, 翔泳社, 2022
- 図解コンサル一年目が学ぶこと, 大石哲之, ディスカバー21, 2021
- ウィニング 勝利の経営, ジャック・ウェルチ, 日本経済新聞出版社, 2012
- 戦略思考コンプリートブック, 川瀬誠, 日本実業出版社, 2003
- 事例に学ぶスマホアプリマーケティングの鉄則87, 池村修, ASCII, 2016
- ビジョナリーカンパニー 時代を超える生存の原則, ジェームズ・C・コリンズ＆ジェリー・I・ポラス, 日経BP, 1995
- 最強のチームをつくる20のセオリー, 原田典子ほか, 幻冬舎, 2016
- マーケターのためのアプリの教科書, 株式会社ヤプリ, インプレス, 2021