チーム開発をしていて思った、これだけはやってほしいこと

2019-05-08T19:10:10+09:00

2019-03-03

僕は、馬鹿にならないくらいの時間をチーム開発に注いでいる。

そんな中で普段思う事について正直に書いてみようと思う。

本音が欲しい

これはゲームに限らず、色んな人と一緒に開発をしていて思う。

僕は結構「こう思う」っていう意見を言うんだけど、それに対して賛同されても困る。

僕が求めているのは、それは「こういう時にダメじゃないかな？」とかの意見。

贅沢を言えば、その上で「こうした方が良いんじゃない？」という提案が欲しい。

その掛け合いで良いものが生まれるんだ。

常に「いいんじゃないかな」というだけなら、あまり意味がないというかそれ以上のものが出来ない。

特に、提案をしてくれる人と一緒にいると本当に良いものが出来る。

出来る限り早めのアウトプットが欲しい

僕の質問に対して、めちゃくちゃ考えてくれることがあるけど出来るだけ共有してほしい。

考えてる時間無言になられては、僕は何も得られないしどう考えたかも全然わからない。

ぶつかった問題があったら、僕なら答えが出せるかもしれないし出来れば共有してほしい。

あと、すぐに決断して行動してくれる人はとっても頼もしい。

社長さんとか、僕の尊敬する人たちは信じられないくらいの速度で「Yes」か「No」かを教えてくれる。

なかなか難しい事だけど、即断即決はすごく大事だと思う。

やるといった事はやって欲しい

「それ僕がやる」と言ってくれるのは助かる。

でも、言った上でやってくれないのは一番困る。

「やる」と言ったらやって欲しい。

出来なければ、全然人に頼って良いし、出来ないなら「やれない」と言ってほしい。

やると言ってくれた事には皆が手を出すわけにもいかないし、その完成に合わせて皆も作っているから全体に迷惑がかかる。

もう一度言うけど、出来ないなら「出来ない」と言ってくれ！！

自分の決断にちゃんと責任を負ってくれ。

うわぁ、愚痴っぽいなこれ。

別に愚痴が言いたい訳ではないのだけど。

ただ、これを守ってくれる人との開発はとても成功しやすいと思う。

僕もがんばろー。

書籍による学習ロードマップサイト【ミチアカリ】を作った際の体験談

2019-04-21T17:19:22+09:00

こんにちは！ 「三度の飯よりサービス開発」 しがしぃです。

以前、単行本のコメントメーカーを作成した記事を書きました。
単行本についているアレのWebアプリを作った話

今回は、問題解決を重視したサービスを開発しました。

書籍による学習ロードマップ共有サイト
その名も ミチアカリ です。
- 技術書を選ぶ時にどれを選べばよいかわからない
- 難しすぎる本を選んでしまった

などの問題を解決するためにサービスを開発しました。

あの新大陸を発見したコロンブスですらビックリするくらいの困難を経て、このサービスを開発しました。
その時の体験や学びをさーっと1記事にまとめました！

アイデアを考え始めたのは2018年10月から

サービスを公開したのは2019年4月12日です。（なんとか令和になる前にリリース出来ました...!!）

🎉Webアプリ完成しました🎉このアプリは本の学習ロードマップ共有サイトです📗- どのプログラミング書籍を選べば良いか分からない- 難しすぎる本を選んでしまったという問題を解決したいと思い作りました技術書を選ぶ時に、必ず参考にするようなサイトにしたいですhttps://t.co/5kIX4KFRBB
— しがしぃ@MyPoZi (@MyPoZi555) April 12, 2019

実質このプロジェクトは6ヶ月くらいと言えます。
なぜそんなにかかったのか。理由は、チーム開発で検証と実装を繰り返し、時には停滞していたからです。

10月 ~ 12月はアイデア出し

ある日、何作ろうかチームで考えていた所、ある先輩がやってきました。（私が尊敬している先輩の1人です）
話を聞くと、どうやらアイデア出しのフレームワークがあるらしく、司会進行をしてくださるみたいでした。
勿論チームの返事はOK。こんなありがたい話はありません。

そのアイデア出しのフレームワークとはGoogleなどで導入されているデザインスプリントでした
デザインスプリントを導入して分かった 3 つのメリットと注意点【前編】

簡単に言うと、

わずか 5 日間で、価値のあるプロダクトを開発するフレームワーク

です。
メリットは

失敗を素早く気づく
消費される人や予算と時間の節減
プロダクトのコンセプトに関するチーム内での意思統一
顧客の視点からアイデアを検証

などが挙げられます。
ほとんどの組織ではアイデア過多の状態。アイデアの検証や実行が伴わないことが問題であり、それを解決するのがデザインスプリントです。

デザインスプリントをやってみた

まず、身近に問題点や、解決したいことがないか話し合い、一番身近であるエンジニア関連についてアイデアを出すことになりました。
時間を測り、ポストイットにひたすら問題点を書いて貼っていきました。その後、1つ1つ書いたことについて意味をチーム内で共有し、話が広がった場合、違う色のポストイットにメモを書いていきました。そして、それぞれを分類分けし、分類ごとにタイトルを付けました。

分類された中からやりたいもの、解決できそうなもの、アイデアが思い浮かびそうなものなどの指標で3つ選びcrazy8を行ないました。
crazy8とは5分間で8個のアイデアを出す100m走より体力を使うアイデア出しの手法です。名前通り、狂ってますね。
以下は入門書が多すぎ問題を解決するための私が出したアイデア例です。

中級本を作るというアイデアね、、、
誰か中級本頼みました🙏

「5分で8個アイデア出すんでしょ？余裕でしょ！」
そう私は思いましたが、不可能でした、、、

アイデアは必ず8個じゃなくていいんです。大切なのは短い時間の中で一瞬のひらめきを出しまくることです。これ要らないでしょとかいう考えをする時間すらありません。

様々なアイデアが出ましたが、1人3票でアイデアに無言投票した結果、書籍を難易度で評価できるサービスに決定しました。
これだけで終わりません。さらに根本的な問題を突き詰めるために、少しアイデアを広く見て、技術書を買う時の不満という問題で再度1からやり直しました。

以上を繰り返し、

他の人の読書履歴と本と本の間の難易度が分かるサービス

を検証することとなりました。

この頃からプロダクトリーダーになったが、精神的に消耗した

まだプロダクトリーダーで消耗してるの？？
と言われそうなタイトルですね😅

実際、チーム開発するまで個人で
「プログラミング楽しい〜^q^」
だったのですが、チーム開発はプログラミングだけでなく

スケジュール管理
ファシリテーション
タスク管理
備品管理
メンバーとのコミュニケーション
他のチームでの運営、開発（合計3つくらい平行していました）

沢山やることがあり、毎日四六時中ずっとチーム開発のことを考えていました。
やったこともないし、何をしたらいいかすら分からなく、トラブルの耐性は一切ありませんでした。
精神衛生が非常に悪かったです。1ヶ月お風呂入ってないくらい。。。

「チーム開発、辞めようかな。」
と悩んで、デザインスプリント案を持ってきてくださった先輩に相談した結果、自分の中での優先順位やチーム開発というのも段々分かり、心も軽くなり、まだ頑張れました。
普通にメンバーに仕事を振ったら良いと思いますが、振ってみても結局全て自分でやってしまいます。私がメンバーを信用出来ていないと考えます。
そこで、しっかりメンバーに仕事を振り、メンバーが裁量を得れば、もっと上手く行ったと後から反省しています。

その後、

リーンキャンバス（事業プランを整理するフレームワーク）
ペルソナ（サービスを利用する顧客の中で最も重要な人物モデル）
市場規模
競合相手（9サービスくらい規模や強みなどを分析）
テスト項目、仮説

などを決め、様々な人に記事を書いてもらい、プロトタイプを制作しました。
そして、プロトタイプを使ってもらってインタビューをしました。

協力してくれた方たちには感謝です。一度きりの人生のうちの大切な時間を人のために使えるという心優しい方達ばかりでした。
その気持ちから私は自分1人で生きていないということを学ばさせていただきました。

12月から設計・開発をスタート

「やっと開発ができる..!!」

とワクワクしましたね〜。
しかし、私がするべき一番の仕事はメンバーが不自由なく動けるようにタスクを振ることでした。
個人で開発する時は、仕様書をしっかり書くということはしませんが、人に伝えるために全てを言語化しなければいけない辛さを味わいました。
先輩からチーム開発の手順、書き方などを教えてもらい、
私は
- ユーザーストーリー
- API設計
- 技術選定
- シーケンス図

など、ドキュメントを書きまくりました。

こんなシーケンス図を分からないなりに書いてみましたが、正直メンバーは殆ど見なかったと思います。

仕様書やユーザーストーリーはGithubのissueに書きました。
バッジだらけで見辛い。。。絵文字なんか使えばもう少し見やすかったのかな。他のチーム開発も見てみたいな...!!

タスク管理はGithubのProjectsを使いました。

ER図などデータベースに関しては、チームメンバーにデータベーススペシャリスト持ちの人がいたので、任せて勉強させてもらいました🙏

ブランチの切り方はGithub Flowで、プルリクエスト出したりレビューしたりなどしましたが、正解が分からないのでとりあえずやってみよう精神でした😂

2月から私は海外へ、しかし我慢できずサービス開発を

はい、ニュージーランドに1ヶ月間短期留学に行きました。
折角お金掛けて海外に行くので、海外でしか体験できないことをやりたかったので開発はお休みすることにしました。
その間、マネジメントは先輩に取ってもらいました🙏

しかし、結局我慢できなくて、海外生活後半は開発していました😇（結果出来たのが、単行本のコメントメーカーです）
私は本当に開発が好きなんだな〜と実感しました。

3月後半に帰国、１人でサービス開発

日本に帰国して、チーム開発しよう！と思い、slackで尋ねても誰からも返事がありません。

「あ〜、ダメだ。でも開発したい。」
「仕方ない、１人で開発するか。」
「もう自分だけで作るし、自分の好きな技術で作ればええんちゃう？？」

元のアイデアとは少し違う感じに改変してですが、結果１人で作りました。。。
この結果が良いか悪いか分かりません。チーム開発にこだわっていたら、完成すらしなかったかもしれません。
もしくは、チームという力で大成功していたかもしれません。

ただ、私は皆で楽しく開発したかったです。

いくらでも今回のチーム開発に関して反省しました。

ミチアカリを公開した日、カレー屋で１人で泣きました😂
色んな思いが込み上げてきて、抑えようとしましたが、止まりませんでした😂
今思い返すと笑えますよほんと😂

今回の体験は私にとって非常に良いものでした。普通に生活していたら100%味わえない体験だったんじゃないかなと。
反省あり、学びあり、感謝あり、
以前の私より圧倒的成長をすることが出来ました。
今後必ず活かします。

公開後の反応は良かった

公開後、皆さんが拡散していただいたおかげで、沢山の人に触っていただけました。（本当にありがとうございます🙇‍♂️）

「良さそう！」
「助かる！」
「すごい！」
「面白い！」

などの声もいただけました。皆様の反応は全て保存してあります😊

皆さんが作ってくださったコンテンツ（記事）は非常に良いもの何だな〜と分かりましたが、作ってくれる人が中々いません。
本をある程度読んで尚且書いてくれる人ですから、そりゃ少数派になるかなと。
この辺のアイデアはまだ詰める必要がありそうです。ユーザーはメリットを感じなければ使いませんよね。

少しずつ機能を付けていったり試行錯誤しています！

ミチアカリ(https://t.co/5kIX4KFRBB)にリクエスト機能追加しました。- 特定の学習ロードマップが知りたいけど、記事がない- ここまで本読んだけど、次何の本がオススメなんだろうそういうものが知りたい時に、リクエストとして出せる機能です。また、リクエスト記事にコメントを付けられます✌️ pic.twitter.com/cnbm5r0j2D
— しがしぃ@MyPoZi (@MyPoZi555) April 20, 2019

思い入れのあるサービスなので、これからグロースというものをやっていきます💪

まとめ

人生色々ある。失敗はない。省みれば全て学び。

チーム開発は思い通りに行かないことも多々あったが、非常に良い学びとなりました。
またチーム開発に挑戦したいです💪

良ければこちらも見ていって下さい〜！
デザインスプリントの本もあります。
ミチアカリのアイデア出しのために読んだ本

私は私が予想していた以上に皆様にお世話になっています。必ず忘れません。
この気持ちを大切に、私自身も他の人に優しく接することができるようになります。

今回は以上です！
また、Crieitで記事書くので次回もよろしくです👍

よければTwitterも😊

「チーム開発」の記事 - Crieit

チーム開発をしていて思った、これだけはやってほしいこと

書籍による学習ロードマップサイト【ミチアカリ】を作った際の体験談