個人開発のススメ。中学生になった息子のためにアプリ開発をしたら、「ビジネス理解」への小さな一歩が進んだ話
ナイル株式会社にてメディアテクノロジー事業本部でエンジニアをしている福本さんによる「個人開発のススメ」をお届け。本来エンジニアは、ものづくりを通じて本質的な課題を解決し、誰かに喜んでもらう仕事なはず。エンジニアリングの「作業化」という問題をどう解決していく? 中学生になった息子のためのアプリ開発、個人開発にそのヒントがあった!?
- 個人開発のススメ
- 個人開発のきっかけは怠惰
- 調査調査!
- 要件をまとめよう
- スピードが命
- 技術選定&コーディング
- 結果どうなったか
- でおわっちゃだめ!
- 無理くりビジネスモデル・キャンパスを作る">無理くりビジネスモデル・キャンバスを作る
- 顧客を主語にして考えよう">顧客を主語にして考えよう(1)-(4)
- ここからはサービス提供者を主語に変えます">ここからはサービス提供者を主語に変えます(5)-(9)
- これからのエンジニアに必要なもの
個人開発のススメ
こんにちは、ナイル株式会社メディアテクノロジー事業本部でエンジニアをしています福本(@doctor0siki)です。
普段はエンジニアとして広告管理システムの開発に携わっているのですが、本日は中学生になった息子のための「個人開発」で学ぶ、ビジネス理解への小さな一歩をテーマにお届けできればと思います。
さて、突然ですが、
「エンジニア」
とは、どういった存在でしょうか。たとえば、依頼者の要望にただ答えるだけではなく、それ以上のものを作り出す「ものづくり」のスペシャリスト。技術に対する専門性が非常に高く、刻々と変化するテクノロジーを常に追い続け、必要となった時に蓄えてきたノウハウを新たなチャレンジの場に喜んで投入する。
仕事でプログラミングや開発を続けていると
- 仕様書通り設計実装
- 納期を守る
- メンテナンス性を考え品質を担保する
- コストを極力かけない
で業務がうまく回っていく仕組みを構築していく。依頼者もそこに絶大なる価値を感じ、評価、企業によってはその人の成長性も見越して対価を支払う。
エンジニアの仕事をざっと説明するとそんな感じじゃないですか?
でもね。こういう「仕事だけ」をやっていると実は陥っちゃうまずいことがあるんです。
それは、エンジニアリングの「作業化」という問題。
本来エンジニアは、ものづくりを通じて本質的な課題を解決し、誰かに喜んでもらう仕事なはずなんです。そこで質問です。
最近
- ユーザーの喜ぶ顔が見られてない
- 生の声(要望等)が聞けてない
- ユーザーが普段何をしているか知らない
- エンジニアとして製品に愛を込めることができていない
一つでも当てはまったら是非これから紹介する「個人開発」を試してみてください。
個人開発のきっかけは怠惰
私には、2021年4月から中学生になった息子がいます。
中学は、基本的には徒歩圏内で通学できる場所が指定校となりますが、本人たっての希望で、行き帰り片道7分のバスに乗り越境通学をしています。
でも皆さん、知っていました??
バスって道路事情や乗車時間のロス等、予期せぬ事態で時刻表通りに運行されないんです。
これには生まれて初めてバス通学をする息子も学校への到着時間が読めず本気で困っていたため、親のスマホに(理由があり、まだスマホ与えてないんです)バスあと何分?というアプリがあるのでそれを参考に「そろそろ家でないとだめだよ」って親が寝ぼけ眼で、自分のスマホを確認し家を出る時間を伝えるサポートをしていました。
入学式から数週間後・・・
最近の学校はすごい!なんとICT教育の一環で区からiPadが一人一台無料で貸し出されたんです。
いよいよこれで、あのアプリをiPadにいれて、親はゆっくり寝られる!!と喜んだのも束の間
だめなんですよ・・・。
提供されたiPadにはアプリは一切入れられないよう設定されているんですよね。結局私は毎朝6時台に起きて、「あと何分でバスくるよー」って言い続ける必要があるんだと落胆。WEBサイトなら、ある程度見られるんだけどな。
でも、ふとそこで気が付きます。
「あれ?私、WEBエンジニアじゃなかったっけ?そういうサービス作っちゃお!そしたら朝ゆっくり寝られるじゃん!」
ってね!怠惰はエンジニアの重要な原動力です。
今こそ仕事で得た、スキルを存分に活かすタイミングだと!
調査調査!
開発は調査フェーズが一番大事。
まずは車輪の再発明(すでにそういうサービスがないか)にならないか、をチェックしましょう。
今回でいうと
- WEBサービスでiPad最適化されており
- バスの接近情報を配信している
の様なサイトが無いかを軽く調査しました。この「軽く」ってのがポイントです。
調査し過ぎちゃだめなんですよ、バイアスがかかり凝り固まったアイディアしか出てこなくなってしまいます。
ちなみに新規サービスを立ち上げるときに、大きなイノベーションは99%起こりません。なぜなら私が「これって不便だな」と思ったなら、当然他の誰かも不便だなと同様に思っているはずで、その場合は大体既に近いサービスが存在するからです。
今回もそうでした。東急バスさんの「バスなび」という公式WEBサイトがそれに当たります。
バスの現在位置をビーコン的なモノで収集し、指定したバス停にあと何分でバスが到着するかがバッチリ表示されます。当然そのサイトがあるということは裏にAPIか何かが存在する可能性があります。今回東急バスさんにAPIがないか問い合わせしてみましたが、非公開とのことです。
残念ながらサービスとしては存在していました。ね、イノベーションは起こせません。
でも実は公式WEBサイトを上回るモノを作る考え方が一つだけあります。
それは敢えて
「n=1」
化することなんです。
公式WEBサイトでは、利用者が多く居ることから、どうしてもシステムが全体最適されてしまいます。我々は敢えてその逆張り【個人最適】をしていきましょう。
その人にあった形でオーダーメイドのシステムを作れれば、既存の公式WEBサイトでは絶対できない、その顧客にとってかゆいところに手が届く唯一無二の素晴らしいサービスが出来上がるはず。
これこそが個人開発の真の面白さです。
要件をまとめよう
要求仕様をまとめましょう。要求には必ず理由があります。そこがコアです。自分本位で自己満足でものを作っちゃだめです。使う相手が必ずいますから。それにそこを度外視しては、「n=1」にした意味が全く無い!
今回の要求は
要求:バス通学を行う自分の息子に、遅刻をしないで中学校に登校させたい
理由:バス通学が初めてなので、「学校への」到着時刻が読めず、遅刻しないよう親が事細かに時間を管理する必要がある為
このコアな要求に対して、関連する要求をマインドマップで広げていきました。
出来る、出来ないとか、そんなんは最初はどうでもいいんです!
まずは「n=1」にした相手が、何に困っているのか、じっくり観察しましょう。あの子ならこう思うはず。日頃の行動を見ていると、こうしがちだな。とか。そういうところからこれがあったらこういうミスを侵さないよな、と要求を広げていくことが大事です。ある程度広がったら今度はそれを要求仕様としてまとめていきます。
要求 | BUS-1 | 自宅から出て中学校のクラスに到着する予想時間を表示する。バス通学を行う自分の息子に、遅刻をしないで中学校に登校させたい。 | ||
理由 | バス通学が初めてなので、「学校への」到着時刻が読めない息子が遅刻しないよう、親が事細かに時間やタスクを管理する必要がある為 | |||
説明 | こういうのを一般的には過保護というらしいw | |||
要求 | 1 | 時刻判定や、表示する内容、計算の元となる設定を容易に変更できるようにすること | ||
理由 | 今後の本家サイトの変更や、ユーザーの成長で計算内容が変わる為 | |||
仕様 | 1 | 最寄りバス停のバス停情報URL | ||
理由 | 将来のバス停変更に備え、本家のURLを変更できるように | |||
仕様 | 2 | 家から最寄りのバス停までの徒歩時間 | ||
理由 | 年齢とともに歩くスピードも変わるから | |||
仕様 | 3 | バス乗車時間 | ||
理由 | 時期によって工事迂回等があった時に変更可能なように | |||
仕様 | 4 | 学校最寄りバス停到着後からクラス着席までの時間を設定する | ||
理由 | 学校の都合で入り口が変わる可能性があり、時間が変化するかもしれないので | |||
仕様 | 5 | 必須で学校に持っていくモノを設定できる | ||
理由 | 今はPASMO/マスク/ハンカチ/ティッシュ/水筒/健康観察表、そのうち追加削除されることを見越しておく | |||
仕様 | 6 | 登校時刻(以降遅刻)の設定 | ||
理由 | 場合によっては登校時刻が早くなる可能性もあるので | |||
仕様 | 7 | 始発時刻の分数への置き換えを行う | ||
理由 | 始発バス停では、17分待ち→発車待ち→16分待ちと表示が変わる為 | |||
要求 | 2 | 本家サービスから到着時刻を取得し、到着予想時刻を計算する | ||
理由 | 本家サービスの情報を元に息子専用カスタマイズをして表示をする為 | |||
仕様 | 1 | BUS-1-1-1で設定したURLから待ち時間を取得する | ||
理由 | 元データとなるため | |||
仕様 | 2 | HTMLパーサを使って構文解析をし、「x分待ち」のclassを探す | ||
理由 | ほしいのは分数の数値だけのため | |||
仕様 | 3 | 複数候補がある場合複数取得しておく | ||
理由 | 直近の2台の時間を表示したいため | |||
仕様 | 4 | 始発の場合の処理を別途作っておく必要あり | ||
理由 | 学始発バス停で発車待ちとなるケースがあるのでその場合でも○分数待ちと値が置き換えられるようにする必要があるため | |||
仕様 | 5 | 最寄りのバス停からバスの発車予想時刻(現在時刻+あと何分=発車予定時刻とする)を計算する | ||
理由 | あと何分では無く、何時に発車するのかを明確に出しておきたい | |||
仕様 | 6 | 発車予想時刻から、到着予想時刻(発車予定時刻+乗車時間+下車後クラスまでの時間の合算)を計算する | ||
理由 | 既存サービスでは到着予定時刻がないので必要 | |||
仕様 | 7 | 行動を促す為の文章を生成する | ||
理由 | たまにバス停まで行ってPASMOを忘れて帰ってきて遅刻するケースがあるので | |||
説明 | バス停までの時間+5分になったら持ち物チェックを促す | |||
バス停までの時間+3分になったら家を出るよう促す | ||||
バス停までの徒歩時間以下になったら諦めを促す | ||||
仕様 | 8 | 本家同様15秒に一度情報を取得し更新するように | ||
説明 | 道路状況によってあと何分の表示が変更されるので,等間隔で再取得し表示をリフレッシュする必要がある為 | |||
要求 | 3 | BUS-02で取得、計算した情報を表示する | ||
理由 | あと何分だけでは息子には情報が足らないため | |||
仕様 | 1 | 遠くからみてもパッと分かるように大きく要素を表示する | ||
説明 | 息子は電車好きなのでそういうフォントや色にできたら最高 | |||
背景は集中できるよう黒にする | ||||
仕様 | 2 | 表示する情報は次のバスとその次のバスの情報に絞る | ||
説明 | 多すぎても混乱するだけ | |||
仕様 | 3 | 次のバスの文字フォントは大きく目立たせておく | ||
説明 | 表示はあとバス発車まであと○○分を目立つようにしないと、そこに意識が集中しない | |||
仕様 | 4 | 発車予定時刻だけではなく、学校到着時刻を旅程表のように表示させる | ||
説明 | 見通しが立たないと不安になる性格のため | |||
仕様 | 5 | 所定の時刻に以降に到着するバスには【遅刻】と赤字で表示 | ||
説明 | 2つ先のバスの表示時に主に表示させ、次のバスを逃したら遅刻であることを認識させたい為 | |||
仕様 | 6 | URLやお気に入り等出ないよう、PWA的アプローチにする | ||
理由 | タブや、お気に入り等が出ると注意力がそちらに持っていかれてしまう為 |
さあ要求はできた。さて次は納期だ!
スピードが命
作ろうと思い立ったら、納期は極力短めに設定します。
「極力」改め「も・の・す・ご・く」短めに
個人開発は上司からの評価にも、収入UPにも直接つながらないので、どうしても自分の中で優先順位が後回しになり、ダラダラやりたくなっちゃうんですよね。で、そのうち面倒くさくなってやめちゃう。私は、こういう時、必ず守らなくてはならない厳しいタイマーを自分に対して設定します。
今回の題材は「バス」。バスってことはその日の「終バス」が必ずあるわけです。
開発着手は日曜日の18時30分、その日の終バスは22時30分発
終バスが最寄りのバス停に来るまでにサービスを完成させる!と心に決めます。
4時間の短期決戦です!勝負開始!
技術選定&コーディング
では残り4時間で何ができるか。新しい技術や、調べないと使えない経験の浅い技術は絶対に投入しません。新しい技術は、いつも仕事で投入しているでしょ?wだからいままで使いまくった開発手法、普段の業務で使い慣れたフレームワーク等を前提として徹底的な時短手法を考えます。
ちなみに弊社ではPHP+Laravel+MYSQLの構成が多いのですが、今回コストの問題からXServerさんの無料レンタルサーバの【XFree】を使わせていただいたので、SSHでログインできず、FTPでファイルをアップロードするしか方法がなかったことも有り、膨大なライブラリが必要なLaravelのようなフルスタックフレームワークは使っておりません。
そこで、時短のため必要最低限の構成だけパッケージ管理ソフトで用意し1CLASS、1ファイルで行くことにしました。
最低限のパッケージとして、
- TWIG
- dotenv
- Guzzle
だけは、PHPデフォルトで用意されているローカルサーバ機能を使って立ち上げたローカル環境にComposerで用意しましたが、出来上がったautoload.phpとvendorフォルダをFTPでサーバにアップロードしながらindex.phpをローカルで同時コーディングするという並列処理を実行します。でも幾ら急いでいても、気が向くままにコーディングしちゃだめですよ。拡張性がなくなるので。
で、ここで役に立つのが、先程作った要求仕様書です。
基本、欲しい機能単位に要求仕様書を作るので、それらをそのままメソッド化するだけでOK!あとはinvoke()で要求2を実行してもらいます。ここまで来たら、あとはただのブロック遊びです。サクッと組み上げていきましょう。で出来上がったのがこちらとなります。
https://github.com/doctor0siki/bus_navi
サービス名は、バスなび/間/学び、に因んで、「バス間ナビ」と命名しました!
結果どうなったか
支給されたiPadで毎朝バス間ナビを表示し、遅刻せず学校に到着することができています。
そして私はゆっくり朝寝ることができています。
めでたし。めでたし。
でおわっちゃだめ!
多数ある個人開発の記事を見ると大抵がここで終わってしまっています。
でもここまでで終わっちゃあ駄目なんですよ。
以下の3つを対応する癖をつけてください。
- 無理くりビジネスモデル・キャンバスを作る
→ビジネス化できる準備をしておこう - 楽しいプレゼン資料を作ること
→ないと思っていても、投資家からお声がかかったらプレゼンできるピッチ資料を作っておこう!ちょっとしたLT会にも使えるし - 必ずソースや、プレゼン資料を公開して要望や感想を聞こう!
→指摘をもらわない限り圧倒的な成長はのぞめないのです
今回はその中でもビジネスモデルキャンバスに特化し説明しようかと思います。
無理くりビジネスモデル・キャンバスを作る
「n=1」で作ったサービスなのに、ビジネス化?何を言っているんだ?とお思いかもしれません。
でも、先程も申し上げた通り、今回作り上げたもの「こそ」が、既存サービスと差別化できるたった1%のコアなのです。だから、無理くりにでもいいので、ビジネス化できないかを検討してみましょう。
ビジネス化する際に役に立つ思考ツールがビジネスモデルキャンバスです(リーンキャンバスともいいます)
ビジネスモデル・キャンバスとは、ビジネスの構造を整理するためのツールです。
ビジネス化する際に必要な観点が9つのカテゴリに分けられており一枚で事業の全体構成を理解することができる大変便利なツールです。
顧客を主語にして考えよう(1)-(4)
(1) まずは、価値を提供する顧客(息子)の特性を考えてみます。
学校に遅刻するのは、最寄りのバス停まで徒歩何分で到着し、バスに乗り、到着したバス停から何分歩き、昇降口まで到着し、上履きに履き替えてクラスに入り着席、学習の準備をすることができるのかがつかめていないからです。言い換えると、ゴール地点からの逆算がうちの息子苦手なんです。(特性と言いましたが、皆さんも初めてのことは大抵そうですよね?)
こういうのを苦手とする人たちは結構存在するので、顧客セグメントとしてまとめてしまいます。
(2) 次にこういうことを苦手とする人たちが多いところってどこだろうと考えて調べてみます。
学校、バス停等は当然ですが、療育施設や、デイケア等、そういう苦手な分野をサポートする施設も数多く存在することがわかります。そこを販売チャネルとして捉えます。
当然、この記事のように、SNSや媒体を利用し、利用者の拡散を図ることもわすれてはいけません。そういう時代ですし。
(3)特に重要なのが中心のVP(提供価値)です。サービスを作る上で顧客に対して、どのような価値を提供できるのかがそのサービスの肝なわけです。これは、すでに要求仕様の段階でまとめられているわけなので、大要求を記載するだけでいいのです。楽でしょ?
(4)は顧客とどんな関係を構築したいかを記載するのですが、この場合、顧客の自律を促しサービス提供者が怠惰を満喫できること、となりますが、それだとあまりにも夢が無いのでwサービスを提供することで、「顧客の遅刻をなくし余裕を持って通学してもらい、おまけに成績アップをしてもらえるWin-Winな親子関係を構築する」というのが、求められる最適解ですかね(笑)
ここからはサービス提供者を主語に変えます(5)-(9)
(5)サービス提供者として何をしていかなければならないのかを考えます。これ実際の後日談なのですが参考元の情報レイアウトにTOKYO2020のお知らせが挿入されしまったことでタグ要素の位置が変わり、バス間ナビに何も表示されなくなったことがありました。サービス提供側としては、どんな状況になったとしても安定してサービスを顧客に提供できる必要性があるので、メンテナンス性に優れた構成を検討し、サービス監視を怠らないことが必要です。
(6)サービス提供者として(3)の価値を提供するため、どんなリソースが必要かを明記します。
経営資源とも言い換えることが出きますね。例えば、4時間でコーディングできる能力を有した私のような優秀なwエンジニアが必要ですし、サービスを提供するサーバーも必要です。コーディングするためにはPCが必要ですし、ソースをアップロードするには、インターネット回線も必要ですね。当然サービスサイトのデザインとチラシも作りたいからデザイナーさんもほしいし、それらをばらまく営業さんも必要。と結構考えてくると出てきますね。
(7)個人開発なのでサービス提供を自分だけできるのが本当は望ましいのですが、実際はそうは行きません。今回は、東急バスさんの情報も使っており、実際走っているバスにも乗りますし、Xserverさんのレンタルサーバも使っていますし、GitHubでソース管理していますので、サービスを継続するためにはその様な沢山の役者が存在しています。また、支給されたiPadが回収されてしまえばサービスは提供できず、そもそも中学校での授業がすべてオンライン化し通学の必要すらなくなってしまったら・・とSWOT分析でいう外的要因等の結果も踏まえて多面的に考えてみます。それらがすべて想定どおり機能することで(3)のVPを提供できている訳です。(7)にはそういった役者を漏れなく記載しておく必要があります。
(8)コストを検討します。今回幸いなことにサーバも無料なのでコストは0円のように見えますが、実はそうでもないんです。私の人件費、PC,iPad等の電気代、インターネット接続料金の按分等、目に見えないコストが沢山です!それらが開発時かかることを想定すると、初期費用として、人件費(時給4,000円換算として)×4時間+諸経費=20,000円程度かかっています。また定期的なメンテナンス、機能改修を行うことを想定すると、初期費用の20%は保守費用としていただきたいですよね。こういうコストは必ず積み上げておいてください。
(9)最後に収益モデルを考えてみます。このサービスで収益を得る気は全く無いのですが、仮に最寄りのバス停等の情報と徒歩の時間をユーザーごとにカスタマイズできる様に拡張できれば、収益化も可能かと思います。機能面から考えると月10円頂ければ位の内容ですけどね。ですがこの収益単価は前述した(8)と(1)(2)に大きく関連しますので、実際には適当というわけにはいきません。本来ならば「n=1」の顧客に対して初期費用20,000円と、保守費用として月々4,000円を請求する必要性があります。もし仮に10円で運用する場合、最低限毎月約500名の会員に10円のサブスクに登録し続けて貰う必要があり、初期費用を20ヶ月かけて回収する必要があります。利用想定人数が500名となると流石にWEBサーバも増強し複数台用意する必要が出てきますので、(8)の経費がかさみ、どんどん会員数を増やしていかないとならず、(1)の顧客セグメントを見直し、(2)のチャネルも別途開拓する必要が出てくるなど、ここが適当だと、即赤字に陥ってしまいます。
また、ここまで書いておいて忘れてはいけないので念の為書いておきますが、今回は利用者である「中学生の息子」から毎月お金を巻き上げるつもりはないですのでw、先程の(1)顧客セグメントには「中学生の親」と、お財布の紐を握っている方の属性を追記します。
蓋を開けると私の作ったサービスに「私」がお金を払ってサービス提供していることになるのできちんと遅刻せず通学し成績UPして、成果として還元してもらいたいところですw
でもね、たまに仕事に集中していると(弊社は在宅勤務なので)「コーヒー飲む?」と言って、インスタントではなくドリップで本格コーヒーを淹れてくれたりする「ビジネスモデルがきちんと理解できている子で良かった!」と感謝していたりしますw
これからのエンジニアに必要なもの
さて、近年エンジニアを目指す学生さんや、社会人の方がどんどん増え始めていますね。
2020年からは小学校でScratchを使ったプログラミング教育も開始され、10年後には109万人がなんらかのプログラミング経験がある状態で社会人として仕事に参画します。
今は売り手市場のエンジニアでも、10年後には「要件定義→設計→実装→テスト→リリース→保守」だけを行ういわゆるエンジニアは、ノンコード開発のトレンドも手伝って今より需要がなくなり、買い手市場へ急転換、求められるスキルレベルもAIメンテナー&トレーナーに傾向し、更に技術も複雑化していくのではないか?と私は予測しています。
だからこそエンジニアは立ち止まることは許されない。少しでも気を抜いてサボってしまうと、あっという間に時代に取り残されてしまう。
でも、皆さん新しい事を学ぶことは苦ではないはずですよね?なぜなら、エンジニアって自らの知的好奇心を満たし、サービスを新しい技術で作り、喜んでもらい、楽しんでもらうことが本当は大好きなはずだから。だからこそエンジニアリングを「作業」にしちゃだめなんです。
冒頭にも記載しましたが、本来エンジニアは、何かを作ることで課題を解決し、喜んでもらい、利益を生んでもらえることが仕事です。その点、「個人開発」では、クライアントが自分の身近な人だったり、愛する息子だったり、自分自身すらターゲットにできる。
だからこそ
- ユーザーの喜ぶ顔が直接見られる
- 生の声(要望等)が聞ける
- ユーザーが普段何をしているか熟知できる
- エンジニアとして製品に愛を込めることができる
んですね。
これからのエンジニアは、技術的な専門性は今まで通り高めつつ、ビジネスの構造についてもきちんと理解し、システムだけではなくビジネスも「創れる」様になっていると、市場価値がグッと向上するのではないかと信じております。
今回「個人開発」というテーマで書かせていただきましたが、実はこういう「個人開発」こそ、ビジネス理解につながる小さな一歩であり、いつでもビジネス化できる様に準備をしておくことこそが10年後、きちんと生き残れるエンジニアになる為の必要条件なのではないかと。
(了)