はじめに
この記事はお遊びです。
決して本気で受け取らないようにしてください。
回答も書いていますが、もちろん僕の主観です。
また、お題も僕の得意分野で書いています。
Twitter(@townsoft)でプロマネとエンジニアについて盛り上がっていたので、お遊び的にエンジニア（僕）が書いたものです。
※上記の理由で、エンジニアに偏っています。悪しからず。
Q.1 無茶振り
社長「今日から新しいプロジェクトを始める。そのプロジェクトは君に任せるよ。」
あなた「はい」
社長「うちのサービスもそろそろ伸び悩んでいるため、そろそろ新しいプロジェクトで新規開拓を行う。」
あなた「どのようなプロジェクトを進める予定ですか？」
社長「チャットサービスだ。スマホでチャットを使ってうちのサービスのコミュニケーションを円滑に行おうと思うんだ。」
あなた「うちのサービスってどのようなものでしたっけ？」
社長「君はそんなことも知らんでうちに来たのか？まぁ良い。」
社長「うちのサービスはQ&Aサービスで困っている人たちを助けて来ただろう？」
あなた「あぁ、そうでしたね。」
社長「しかし、うちのサービスはPC向けでシステムも古い。これを今の若者に合わせたスマホで困っている人の問題を解決させようと思うんだ。」
あなた「なるほど」
社長「これを作るのにどれくらいかかるかね？」
さて、あなたはどのように答えますか？
答えを考えてからQ2へ進んでください。
Q.2 調和
あなた「ところで、どのようなサービスにするのですか？」
社長「今、うちにあるサービスは掲示板の延長のようなものでレスポンスが悪くサービスの活性化が難しい。」
あなた「ほう」
社長「なので、レスポンスの早いチャットサービスを使ってユーザーごとのQ&Aをまとめたサービスを作りたい。」
あなた「（なんか同じような話になって来たな。）」
あなた「そのサービスの目的はなんですか？」
社長「ユーザーを集めて最終的には会社の利益を出したい。」
あなた「（マネタイズが目的か？）」
あなた「具体的にはどのようなサービスにすれば良いのですか？」
社長「それは君が考えるんだよ。俺は言いたいことは全て言った。利益を求めるチャットツールを作ってくれ。」
実は、このような丸投げプロジェクトは実在する。
あなたはどのように回答すればこの会社でのポジションを守れるだろうか？
Q.3 提案
社長の思いつき案をどのように形にするべきかを考えた結果、あなたは以下のようなものを作ることにした。
- 一旦iPhoneアプリで対応する。
- チャットは匿名性を高めるため、ユーザー名は不要だが他のユーザーになりすましができないようにする。
- チャットは各カテゴリーにまとめて新しいチャットを上部に表示するようにする。
- カテゴリーの作成は弊社で行い、ユーザーが追加削除することはできない。
- ユーザーは好きなカテゴリーにチャットスレッドを作成することができる
- 一人が作れるチャットスレッドは一つしか作れず、そのスレッドを閉じると次のスレッドを作れる。
- ユーザーはカテゴリーに関心があるかどうかを設定できる。
- 関心のあるカテゴリーにスレッドが立ったり、自分が作成or回答したスレッドに回答がある場合はプッシュ通知が送られるようにする。
などなどの仕様を考えた。
以下のことはPhase2以降で考える。
- Android端末などの対応
- マネタイズ（投稿を本体システムに流したり、ユーザーを本体システムに流したり、広告を貼ったりなどは今回の考慮には不要）
Phase1ではユーザーが集まるかのランニングをしたいと社長に話したところ、社長から了解を得た。
さて、仕様は決まったとしてあなたの次のアクションはなんだろうか？
Q.4 リソース
さて、今回のシステムをどのように作ろうか？
この時点で必要となるハードウェアリソースはどのようなものになるでしょうか？
もちろんだが、ググって回答を探してもOK。
ここで重要なのは、自分の知識+α（googleなど）で回答が出せれば良い。
Q.5 調査能力
一旦関係者集めて聞いてみたところ以下の意見が出た。
- サーバーは「りなっくす」で構築しますか？
- アプリケーションは「れいるず」で構築するのが良いのでは？
- アプリケーションは「ぷれい」で構築するのが良いのでは？
- アプリケーションは「えりくさー」か「ごー」で構築したい。
- 「データベースは何を使いますか？」
- チャットサーバーを自前で構築するのは難しいので「ふぁいあーべーす」を使ったらどうか？
- 「ふぁいあーべーす」で行うなら「りあるたいむでーたべーす」と「ふぁいあーすすとあ」のどちらが良いですか？
- チャットの自前実装するなら「こねくしょんすう」を考慮しないといけない。「なぜ？」
- チャットを自前実装するなら「のーえすきゅーえる」が良いと思います。
- プッシュ通知は「ふぁいあーべーす」などのサービスを使った方が良いのでは？「どのサービスが良いですか？」
- 「Appleの手続きはどのようなものがありますか？」
- アプリ配信するために「どのような手順が必要ですか？」
- 障害ログは「サーバーとクライアントでどのように管理しますか？」
- 「デザインはどうしますか？」 etc...
さて、「」内のキーワードを調べて回答ができるだろうか？
また、？のついた「」内の回答を出せるだろうか？
Q.6 選定
これらの選定をどのようにしますか？
また、選定した理由を説明できますか？
Q.7 環境構築
なんとかエンジニアも集まり仕事を始めます。
どのように進めますか？
リモート作業を許しますか？
全員同じスペースで進めますか？
Q.8 作業担当者
誰を割り当てるかを具体的に思いついたでしょうか？
実際に仕事をしないとしても、あの人にはこの役割などのイメージが湧いたでしょうか？
Q.9 今までの現場
この問いについて、どの現場で作業することをイメージしたでしょうか？
A.1
ここで５人月などと具体的な回答をしてしまった人はプロマネには少し早いです。
この時点では情報が少なく回答ができないはずです。
A.2
ここでは具体的に提案できれば良いのだが、このQuestionの回答は社長や会社の気質による。
なので、どの回答でも社長の期限をとれて現実的に作れるものが出せれば良い。
A.3
やることは数多くあります。
ここには２つの例をあげておきます。
どのように人を集めるか？
「今のサービスからユーザーを流せるか？」
「流せるとしたら今のサービスからどれくらいのユーザーを流せるかの確認をとる。」
現在サービスとの調整は必須です。
人員を借りたり、ユーザーを流動させたりする可能性もあるため良好な状態を保っている必要があります。
また、広告を出すつもりなら予算の確認やどの広告会社を使うかを考える必要があります。
現在の会社のリソース状況の確認
現在の会社の人員状況
（空いている人はどれくらいいて、その人たちのスキルはどのようなものか？外部の力がひつようであるか？）
サーバーの空き台数、相乗りしても良いのか？
プロジェクトの作業スペースはどれくらい確保できるか？
スマホの確保などなど
A.4
この時点でどれくらいのサービス規模になるかを計算しておく必要があります。
が、この適正テストはお遊びなのでとりあえず最低限必須なものをあげられればOKです。
Macbook
iPhoneの開発は基本的にMacがないとできません。
（厳密には申請はMacが必須になります。）
アプリケーションサーバー（ApacheやNginx）
カテゴリーやチャットのデータの処理を行うサーバーです。
また、画面のレンダリングに必要な情報もここで作成します。
データベースサーバー
カテゴリーやユーザー情報をまとめます。
規模によってはアプリケーションサーバーと同じでも良いのですが、スケーラビリティの観点やシステム障害などを考えると物理的に別にしておくのが理想的です。
チャットサーバー
チャットでは素早いレスポンスを求められるため、通常はアプリケーションサーバーとは別にする場合が多いです。
本適正テストではこのチャットサーバーを別のもので代替えしています。
プッシュ通知サーバー
これは自前ではなくなんらかのサービスを使う方が好ましいです。
自社運用を行うとメンテナンスコストがそれ相応にかかります。
配信サーバー
スマホのテストアプリケーションを配信するためのサーバーです。
これをAppStoreのTestFlightで行うという回答でもOKですが、規模依存します。
その他
テストサーバーとかルーターとか、Awsを使う、コード管理をどうするか？など。
どこで何を行うかを考えてハードウェア調達ができれば上記である必要はありません。
なお、これらの回答は間違っていても良いです。
たたき台となるものを出しておけば議論することができます。
何も出さないと議論がブレたり、回答を出すのに時間がかかってしまいます。
※漏れている部分は説明時に他の人が指摘してくれる場合が多いです。
A.5
全てを理解している必要はありませんが、次の問いに答えられるようにある程度の技術力が問われます。
重要なのは調べれば回答が出せる状態の知識を有していることです。
A.6
以下、回答の一例です。
サーバーはAWSで行います。
OSはLinuxを使い、DBはMySQLを使います。
理由はメンバーが一番馴染んでいて、スケーラビリティが容易だから。
チャットサーバーはFireBaseで行います。
チャットデータはFireStoreを使います。
FireBaseを使えばイベントの取得、クライアントの障害ログをCrashlitycsで拾えるためです。
また、開発コストが大幅に削減できます。
ElixirやGoは知見のあるエンジニアを集めるのが難しいので、Railsで行います。
Railsなら自分のツテで知見のあるエンジニアを集めやすいからです。
Appleの申請周りは面倒なことが多いので、私が行います。
プロジェクト名だけを先に決めておけば、プロジェクトが始まってしばらくしてからでも間に合うのでその時に行います。
申請を進めた時にTestFlightの用意もします。
AppleIdは会社から提示します。
デザインに関しては、一旦デザイナーと話して方針を決めます。
エンジニアとデザイナーでのやり取りに関しては、別で打ち合わせを設けます。
デザイナーとエンジニアでデザイン共有ができればどの方法で進めても構いません。「Sketch」などのツールなどを使う場合は教えてください。
などの指針が示せて、関係者を納得させられればOKです。
A.7
ここはイメージがあり、そのイメージで社長などを納得させられればOKです。
僕の場合はリモート作業のコントロールに自信がないので、みんなを集めて「朝会」や「タスク看板」などを用意して情報共有がしやすい場を作るでしょう。
ただ、会社の制約が大きい場所でもあるので現場に大きく依存します。
A.8
イメージした人は信頼している人でしょう。
そういう人が何人かいるとプロジェクトを進めやすくなります。
A.9
このイメージは今の現場が浮かぶ人が多いのでは？
過去のイメージが湧いた人は、その現場が良い現場だったのかと思います。
最後に
初めは勢いよく書いていたのですが、書けば書くほど色々な調整が頭に浮かんできたので途中から浮かんだものは記載していません。
なので、冒頭にも書いた通りお遊びです。（汗
プロマネ適正と書きながらプロジェクトの開始までしかQuestionが書かれていないのは理由があります。
多くのプロジェクトは開始までにマネージャーが行った施策で成否が決まると思っております。
（忘れましが、これはトムデマルコが書いている本のどこかにも書かれていました。僕もそう思います。）
なので、初めにどこまで調整をしたかが重要だと思ったので開始後のQuesionは書いていません。
さて、仕事しよっと・・・