行ってみた:クラスメソッドのモバイル開発を知る!第5回〜プロジェクトマネジメント編
【9/7(金) 大阪】クラスメソッドのモバイル開発を知る!第5回〜プロジェクトマネジメント編 のイベントに行ったためまとめてみました。
概要
イベントページより
第5回のテーマは「クラスメソッドのアジャイルな開発」
我々が日々開発しているソフトウェアに全く価値がなければ、虚しい日々を過ごすことになるでしょう。しかし素晴らしい価値があれば、利用者を含めた多くの人々に充実した日々が訪れます。そもそもソフトウェアの価値とは何なのか、またそれを届け続けるためにクラスメソッドで行っている事は何か、をお話しします。
とのことです。
「ユーザーの価値」ってなんだろう?
今年入社したばかりのモバイルアプリサービス部グループマネージャーさんのお話です。
クラスメソッドさんでは事業会社向けの受託開発が主な業務とのことでした。そのため、「ユーザー」というのはその事業会社と事業会社が開発するモバイルアプリを利用するエンドユーザー両方の事になります。
ちょっと便利な未来を作る
顧客の叶えたい未来を実現するため。ちょっと便利の積み重ねがすごく便利な未来を生み出す。
最高のユーザー体験を提供するというビジョン。常に顧客の意図をくみとり、解決策を考え共有する。
事業会社への価値
- 既存事業のチャネルを増やし売上増を目指す
- ユーザーを囲い込む
- ロイヤルカスタマー育成
アプリで実現できるのか?
- アプリの利用者は?
- 集客方法は?
- 運用体制は?
- KGI, KPIは明確か?
- アプリでなければならないか?
事業会社は数百万~数千万の投資でアプリを作るため、価値があるアプリかをよくディスカッションすることが重要。
事業会社の課題を共に解決したい
- マネジメント
- UX/UI設計
- デザイン
- アプリ開発
エンドユーザーへの価値(難しい)
過去にこの方が事業会社で関わったプロジェクトは8/10CLOSEしたそうです。
CLOSEのパターン
すべてがトップダウン(社長の要望)。
エンジニアもデザイナーもマーケターも何のために業務を行っているか把握できないため、みんな仕事が苦しい。マーケティングも誰に売っていいか分からない(広告すら出せないで終わることも)。
継続できたパターン
社長不在でみんながサークルを作ってプロジェクトを進行する(3,4人)。企画の段階から。 社長が何か言ってきても話はつきかえす。ちゃんと納得できる理由をつける。 →メンバーのモチベーションがアップ
価値を高めるための実際の企画方法
- プロトペルソナ
- 6up sketches
- リーンキャンバス
企画内容の検証方法
- webアンケート
- 該当インタビュー
- 座談会
- 知人にききまくる
→反応の良くないものは不採用。不採用も多数でてくる。
アプリを作る前にテストマーケティングを行う。 開発せずに適当な既存サービスを利用して1ヶ月程検証を行う。 →売れるのが確認できたり、目標に達成したか等、有効かどうかを確認する。 インスタで検証したりも。
検証ができたら実際に進めていく
- 最低限のMVPの決定
- Bullseyesの作成
- 事業計画の作成
- 価格の費用試算→収支シミュレーション
まとめ
エンドユーザーへの価値を追求し続ける。クラスメソッドに依頼すれば単に成果物を完成させるだけでなく、プラスアルファの価値をもたせ事業に貢献することができる。
感想
単なる受託開発でなく、顧客と一緒にエンドユーザーにとって最適となるサービスを企画検証して作り上げていくという付加価値はすごいと思いました。
スタートアップの開発方法などでよくこういう手法は目にしますが、実際に受託開発でも取り入れて役立てられるのは面白いですね。
受託でアジャイル開発
こちらの方も今年入社されたばかりの方で、元々はフリーエンジニアをされていたりしたようです。
現在はスクラムマスター、組織改善を行っているとのことです。
クラスメソッドの働き方
- 常駐しない
- 自社開発1:受託開発8
- 主なターゲットは小売、外食事業者
- B2B2C
- もっと来店してもらう、買ってもらう目的のモバイルアプリ開発
受託でアジャイル可能? →顧客とそれをとりまく環境による
受託開発 x アジャイル特有の関心事
クラスメソッドはアジャイルの方が価値を出せる。 →マーケティング用のツールを作るから →市場の変化、いろんな関係者からのフィードバックに適応していく必要があるため
アジャイル開発にはどんな顧客が合うか?
・顧客がアジャイルが向いていると確信or経験している ・開発経験少ない顧客(提案しやすい) ・既存の開発会社のリードタイムが遅いなどの不満を持っている
アジャイル開発が合わない顧客
・既存ののやり方での開発経験が長い ・連携するシステムが多い場合 ・顧客の現場に決定権がない
契約は?
準委任契約=アジャイルやりやすい
請負=工夫次第で可能な場合もある
- 調整しにくい
- 最初の制度の低い計画を引きずりがち
- 3ヶ月毎契約で、各期間に自由に開発できる余裕を持った計画として進めたことはあった
契約 < 信頼関係 契約交渉より顧客との協調が重要
なので最初の契約は課題
プロダクトオーナーはだれがやるのがよい?
顧客の場合
- 開発チームと一緒にやるのにハードルがある
- 業界に詳しい
開発チームの場合
チームの一員となり、詳しい人。条件を満たせれば誰でもいい。 今は社内の方がいいかもしれないが場合による。
実際に色々やってみたこと
チームで顧客の会社に行く(スクラムイベント時など)
- 重要な情報得る
- 内情を感じる
- 普段会えない関係者からフィードバック
現場視察(レストランなど)
- 利用者などを観察(お客さんや、店員さんの忙しさなど)
合宿する
- プロジェクトスタート時等に気持ちが高まる
- たくさん仕事の話ができる
- 楽しい
その他大切な事
*顧客と期待やフィードバックを伝え合う →勝手な期待で裏切られる缶を防ぐ →お互いの改善
プロセスやツールより個人と対話を。
大阪オフィスで働いてみて
クラスメソッドと大阪オフィスについて色々な情報を聞くことができました。
クラスメソッドやっていること
Developers.IO
- やってみた系技術メディア
- 平日日中170万PV
- 社員はジョインしたその日に自己紹介ブログを書く
- なんでも誰でも書きたい人が書く
- AWS以外でもなんでも
- ノルマ無し
- インバウンド強い
AWS
- ロックインしてる
- 次々便利になるので不便はなく楽しい
リモートワーク
- 会社の文化
- 自己判断
- 体調悪いという理由はだめ
- 災害時はリモートか休暇
- ふるさと勤務(それでの入社もある)
- 家の環境を整えておくことが重要
- オフィスよりも厳しい気持ちでやる
- 運動不足に気をつける
- アウトプットし続ける(出社してないので成果がでないと何もできてない気分になってしまう)
海外カンファレンス
各地にオフィス
8拠点。バンクーバー、ベルリンに海外の拠点もある。
大阪
- 色々な福利厚生。運動器具、ゲームなども。
- ルールはつくらない
- 自分からアクションしていく →皆協力的なので言い出しっぺが損をしない。発言を恐れる必要がなく安心
リモートでうまくいく
- 対顧客…Backlog
- 社内…GitHubやSlack
- 朝雑談。日中Slackでも雑談
- チームビルディング重要
- 怒らない
災害
- 災害耐性があがってきている
- 最近の地震や台風の際、仕事ができない人がいても大阪か北海道どっちかでカバーしたりしてた
まとめ
とにかく仕事が楽しそうでした。内容だけでなく環境も。もちろん大変な時とかも色々あるようでしたが、それでも一般的な開発会社に比べて楽しさ多めでエンジニアのストレス少なめな印象でした。
拠点も多くあるため、モバイルアプリ&連携のためのサーバーサイド開発が得意な方は、気になったら調べてみると良さそうです。
Originally published at crieit.net.
