インフルエンザA型から奇跡の生還を果たしつつあるmixです。
こんにちは。
皆様予防接種は絶対しましょうね！毎年してたのに今年忘れてた。。。
本日の内容はちょっと微熱の中書いているので
文がいつも以上にあれていたらすみませぬ。
今日の内容
アプリ開発って困ること多いですよね。
作るサービスの大枠が決まっても、
実際何作ればいいかとか、実際何作ればいいかとか、あとは、実際何作れb(略)
そんな時に今日紹介する__「mixの5ステップ」__です！
具体的なステップはBtoBの業務アプリを想定して考えていますが、
BtoCでもある程度応用できると思います。
ただ、何の後ろ盾もないのでそこのところはご了承下さいませ。
意見とか頂いて改善していけたらいいな、と都合よく思っています。
※やってみた系ブログじゃなくてすません。最後に言い訳コラムをのっけてます。
mixが思うSaaS時代の難しさ
サービス使う人はいろんな人がいるのに、提供するサービスは(基本)１個というのが
最近のサービスの特徴です。
昔みたいに導入企業ごとにカスタマイズできない。
極論__「いろいろなニーズがあるのに、答え方は1つ」__です。
例えば空想ですが、空腹を満たすための店を出す、なんて考えてみましょう。
ニーズ「パン食べたい」
ニーズ「ジュース飲みたい」
ニーズ「ステーキとフォアグラ食べたい、あ、ワインも」
この問題に対して店を出すとします、どうしましょう？
ちょっと高級路線だけ毛色違いそうですね。
まず問題を簡単にするために分類してみますか。
・高級志向とお得志向
・飲みものと食べ物
・・・
ニーズを分類したから対策をいくつか考えてみましょうか。
・このサービスのターゲットとなるニーズ分類を決める
・分類ごとに、機能を作る
→うーん、じゃあターゲットをお得志向の食べ物に絞ってみよう！
それで解決でしょうか？
そこから先はどうでしょう？
パンといっても自分で焼いて食べたい、
お手軽に！サンドウィッチがすぐ食べたい、
・・・
絞った後もまだまだ多様性が見られます。
つまり、どこかのタイミングで、
「たくさんのニーズに１つの手段で解決策を提供しなければ」問題にはぶち当たるのです。
どうすればいいのか？
代表的なのあげてみましょう。
①カスタマイズ可能にする
メリットは、
・使う人がやりたいことを定義できれば自分専用の機能として使えること
・使う側に委ねるため、ニーズとか深く考えなくてよく、簡単なこと
逆にデメリットは、
・カスタマイズ側に能力がないと実現できないこと
・機能は煩雑になること
この方法は結構いろんなサービスに見られます。
失敗すると、設定が多くて大変、なんかできるらしいけどよく分からない状態、
成功例は、僕のイメージですけど、Excelとかでしょうか。汎用性の究極。
次に書く方法ができない場合この方法で逃げるのも「なし」ではないでしょう。
ただ、新人の時言われましたよね。
「なんでもできるというのは何にもできないと等価だ！」みたいな。
多様性への対応は難しい。
②もっとばっさり切り捨てる！?
やれること、カバーできることは限られています。
なので、「使ってメリットある人だけ使って」という戦略。
誰のニーズも満たせないより、
ターゲットを絞ってでも、ニーズを確実に満たす方がいい場合もあるので有効な手段です。
製品力とアイディア力に天性のものがあればこの戦略もありでしょう。
③本質を探って解決する問題を限定する
これが本題です。
最終的に絞るという意味では②と同じですが、工夫を加えます。
さっき把握したつもりのニーズも、
その表面だけ真に受けて終わっては、何も見えていないのと同じです。
「なんで自分で焼いて食べたいのか」
「なんで急いでいるのか」
その追求から始まります。
突き詰めていったら
「自分でやいた方が健康的だから」
「急いでても朝は食べないと脳に悪いと思うから」
ということかもしれません。
そうすると、
「食と健康の正しいあり方を伝え、その通り提供するサービス」として再定義して、
提供するアプリを作るべきでは、という別の解決策が見えます。
そうすれば、
たとえ自分でパンが焼けなくても
一瞬でサンドウィッチがでなくても
ユーザーのニーズは充たせるのです。
サービスが変わってるからそういうのはなし！！という意見が出るかもしれませんが、
サービスが変わることの問題ってそこまでないような気がします。
目的はサービスの内容じゃなく、ユーザーに価値を届けることです。
説明の都合上たとえを適当につけましたが
わかりにくいかもですね。すみません。コメントでの批判は随時募集します。。。
何がいいたいか、あとの内容にかかってきますが、
絞るとしても「ニーズの本質を知る」プロセスが大切、ということです。
そうやって考えられたサービスによってもたらされるのは
「ユーザーが最も喜ぶ解決策」です。
ただ、矛盾をはらみますが、
「ユーザーが当初思っていた解決策」とイコールではありません。
前置き終わり！本題！mixの5ステップ
いきなり業務アプリに戻りますね。
①[準備]業務の「目的」を理解しよう！
これが大事！！
なぜその業務が生まれたか？最終目的はなんなのか？
超重要ですが、上で書いた内容なので
③本質を探って解決する問題を限定する
の部分を参照下さい。
②[準備]登場人物をまとめよう！
企業にはチームや関係者がいます。
チームや関係者がいるということは役割が分かれていて、
そこにはレポートラインもあるはずです。
意識してまとめましょう。
③[準備]現状の業務をフロー図にしよう！
上の２つ、
「なぜ？何を達成するのか」
「どういうチームでどう実行するのか」
この２つを把握したら、現状の処理を把握するためフロー図にしましょう。
そして、実際にその仕事をしている人に
意見をもらってブラッシュアップしましょう。
「ここは違う！こう大体あってる。」
という具体的な意見がもらえるはずです。
そのためにも__具体的に把握しにいきましょう！__
作業時間や頻度も借でいいから記載することが大切です。
そして、問題(ミスとか、もろもろ)がどの程度あるのか聞いてみよう。
これがあなた作るサービスのキモになるかもしれません。
ヒアリングの時には個別情報を沢山聞くでしょう。
この時に大切なのは、__他の会社にもあった方が良い業務なのか、否か__を判断することです。
個別情報に引きづられると、本質から離れてしまいます。
④[設計]改善できる部分を徹底的に考えてみよう！
どこをどう改善するのか、コンサルタントみたいですが、考える必要があります。
改善方法がシステムなだけでアプリ開発も一つの問題解決です。
見えている問題であればアプローチの方法を書いた書籍は沢山ありますし、
極論、真面目に論理的に分析と対応を積み上げるだけです。
なので、ここでは別の話をします。
重要なポイントが1つあります。それは、
知識や思い込みを捨てて、理想を描くこと！
例えばスーパーのレジシステム開発を着手する時に、
「あれ？レジなしで買い物できれば全部解決じゃない？」という発想をできますか？
なんて突拍子もないことを、と思うかもしれません。
でもここがイノベーションの境界線です。
現実とか決まりとか普通とか常識とかから解き放たれた状態から、
問題を一気に解決する「すごいアイディア」が生まれます。
アマゾンがやってましたね。
これが難しい理由は、
僕たちがなまじ知識や経験や常識があるおかげで
局所解に陥っているからです。
この「すごいアイディア」は上に書いたように
「顧客が思ってもいない解決策」だったりするので、
__ニーズもまだない__んです。
だから見えているニーズばかりに投資する。
・・・イノベーションのジレンマですね。
経験や知識と引き換えに
頭の柔軟性は保ちにくくなります。怖いです。
そこから解き放たれるためには、「突拍子のなさ」と真面目に向き合うことが必要です。
常識から外れた思想を目にしたら、とてつもなくラッキーです！
まずは「自己否定」して全力で向き合いましょう！
⑤[設計]改善された理想の「業務」をフロー図にしよう！
さて楽しいシステムができそうですか？
ちょっと冷静になりましょう。
システムの外にも人間の活動は存在します。
何をどう便利にしてもシステム「外」の行動を考慮する必要があります。
例えば、
・人工知能が画期的な分析レポートをアプリで提供します！
→あの、レポートは上長に見せるのですが、出力可能ですか？
・超リアルタイムで分析して施策をリアルタイムに自動で実施します！
→え、予算必要な時もあるので便利なワークフローとか逆に欲しいな。。。
→戦略とも照らし合わせたいからそこの整合性も取れないと。。。
システムだけに目がいっても実際の作業にフィットしません。
システム外の業務も考えきれていますか？
システム外作業を合わせた理解によって業務アプリのUXは劇的に変わります。
前段の調査はここでいきます。
他の会社にもあった方が良い業務、であればコンサルして業務も改善できます。
何かしらの制約でメリットのない個別業務が発生するのであれば
コンサルティングして業務改善した方がメリットがでるかもしれません。
※現実的にはすぐ対応できないことがあるので個別機能が必要なこともあります。
上記のようなことを把握するためにも、細かいですがシステム内外通して、
フローを書いて整理する必要があります。
このフローを見ながら、
理想的な業務として業務アプリの利用を提案できるかどうかを冷静に見直しましょう。
##おまけ[設計]最後にもう一度新旧比較結果を書いてまとめよう！
システムが実現することによるメリット(時によってはデメリットも含む)を
一度整理しましょう。
それがこのシステムの「売り」です。
きっと営業やコンサルはシステムの「売り」を常に語り、
開発者はこの「売り」をさらに実現するためのアイディアと実装を施し、
システムは描いた理想に向かって成長していくでしょう。
最後に
すごい機能、みんながワクワクするような機能、ぜひどんどん開発していきたいですね！
ご意見とかあればぜひぜひ。
結論
メリクリまであと__2日!!__
余談：mixのこの記事までの苦悩
※前回から恒例、言い訳コラムです。
ボツ：機械学習 ✖️ なにか
機械学習の記事書くか。といってもやり方もコードもネットにたくさんあります。。
最近javaで機械学習の本が出ててびっくり、もちろん買いました。
そのため、java絡めても独自に書くことがありません。
活用系にしようかと思いましたがデータのストックがない。。
qiitaランキングとか3年くらいためとけばよかったです。
ボツ：自然言語処理 ✖️ なにか
じゃword2vec使うか！せっかくだしslackでword2vec使って、
誰が何を得意としてるかの分析をしよう！(30分前までこれにしようと思ってました)
けど、記事すでにあったーーーー。。。。
じゃあそれを全自動に！き、きつい。
python-mecabにユーザー辞書追加す→端末依存だから設定ファイルに
slackのデータ抽出→apiで全取得(or dump)→データ整形パターン洗い出し
うん、今日そこまで元気ない。
ボツ：awsのec2スケジューラをgo言語で作ってみる
趣味です。今絶賛echoで書いてます。
解説書いてもいいけどgoの書き方とか手探りすぎて
ちょっと恥ずかしい。。。ボツ。
結論：今までの知見を整理してみる
体調回復してきたら上のは別途qiitaであげるとして今日はこれで！
→今日の記事はevernoteに書き溜めてた新人時から考えてた系の内容です。