はじめに

はじめまして。地方の私立工業大学でもうすぐ4年生になる人間です。
今回は、自分がハッカソンや所属している組織でチーム開発を行う時に、意識していることを書いていこうと思います。

メンバー編成について

これについてはハッカソン視点で書くのではなく、自分が所属している組織で経験したことに基づいて書いていこうと思います。

これは学生目線で話してしまいますが、自分たちのチームでは大事にしていることが一つあります。

そのプロジェクトを本当にやりたい人・熱量を高く保ちながら行動していける人を採用する

僕たちは企業ではないので、良い結果(利益がたくさん)だけを求めるのではなく、過程を大事にしています。なので個人の現在のスキルセットは重視してません。それよりもモチベーションが高い人を採用したいと思っています。
もちろん結果が出るに越したことはないですが、それよりも個人がそのプロジェクトを経験し、自律的に開発していける時間を増やすことを自分は望んでいます。

アイデア出しについて

まず最初に手法云々より、アイデア出しそのもので意識していることを書きます。

思考する時間と意見を出す時間を明確に分ける

アイデアなど決めたいことはあるが、なかなか出てこない時は、メンバーが考えを整理して、話しやすくするため思考する時間を設けて、そのあとまとめた考えを意見として出す時間を設けています。
ポイントはしっかりと時間管理を行うこと。制限がないと、ずっと考えたりするだけで生産性の無い時間を作ってしまうだけなので。

手法

アイデア出しの手法は色々ありますが、自分はハッカソンと所属する組織でのチーム開発で手法を分けています。

ハッカソンではブレインストーミング手法
所属組織のチーム開発では、時流を考える手法

ブレスト

ブレストは、みなさんご存知の通りだと思うので説明は省きますが、ハッカソンでブレスト手法を行うメリットとしてはいくつかあります。

アイデアがたくさん出やすい
あまり頭を使わずに意見を言いやすい環境を作ることが出来る
一つのアイデアだけでなく、複数のアイデアから良い感じのアイデアにまとめることが出来る(新しいアイデアの着想)

こんな感じですかね〜

ハッカソンはアイデアとサービスのUI勝負だと思っているので、アイデアをバンバン出せるブレインストーミング手法を自分は採用しています。

時流を考える

時流を考える
これを意識してアイデア出しをしているチームは少ないのかな〜と個人的に思っています。
そもそもこの時流を考える手法どこで知ったかというと、所属組織のリーダーがインターンで学んできたアイデア手法なんですけど、

リーダー　「自分たちのチーム開発でも取り入れよう」

この一言から、チームでも実践していき、自分もその手法を知ることとなりました。
時流を考える手法のメリットとしては以下が挙げられます。

ブルーオーシャンを見つけやすい
生み出すアイデアが課題解決策として有効となる場合が大きい
- 開発するプロダクト自体が、一発屋になりにくい
まだ世の中で満たされていない課題を、いち早く解決することが出来る

メリットを見たら、このアイデア出しの手法は、かなり良い手法ではないかと思います。世の中の流行となってるものから課題を探し、いち早くそれに対して解決策を出すので競合も少ないです。

しかしチームとしてこの手法を行うことによって起きるデメリットもあるので以下に挙げます。

時間が圧倒的にかかる
開発が好きな人にとっては、辛い時間を過ごさせてしまう

時間が圧倒的にかかる

「世の中で満たされていない問題を解決するため」に、この手法を用いるので当然、時間はかかります。自分たちのチームではアイデア出しだけで１ヶ月弱の期間になりました。

開発が好きな人にとっては、辛い時間を過ごさせてしまう

開発をするのが好き・コードを書く時間が好きという人にとっては、この手法はかなり辛いのかな〜と思っています。実際に自分のチームでも「アイデア出しに飽きてしまった」の声が多発してしまい、この手法を行うことによって逆にメンバーのモチベーションを下げているのではないかと思う一面もありました。

技術選定について

技術選定については、作るプロダクトによって様々だと思いますが、自分には使用する技術を決める時、2つの条件と一つの共通項から判断して決めています。

共通項

自分たちが考えたアイデアを最大限に発揮できるような技術を選ぶ

共通項に関しては当たり前ですが、上記を設けています。プロダクトを作るからにはより良いものにしたいと考えますからね〜。

条件1「開発期間が長ければ長いほど、メンバーや個人のやりたいことを中心にして選ぶ」

開発期間が長いということは、自分たちの扱う技術に対して調査を行う時間が一定数ある。調査ができるということは、実装したい機能などに必要な技術を調べ、それを作っているサービスに適用させ、違和感があれば改善していく工程も可能になると考えれるから。

条件2「開発期間が短ければ短いほど、メンバーや個人のスキルセットの中で一番、スキルレベルが高いものを選ぶ」

開発期間が短いということは、技術に対する調査ができず、自分が今持っているスキルの中から何が一番プロダクトを良くするのかを取捨選択しなければいけない。よって自分のスキルが一番高く、かつ共通項を満たすものを選ぶべきだと考える。

ふり返りについて

自分たちのチームでは、ふり返りの手法としてKPTを使用しています。

そもそもKPTとは

K = Keep：継続していきたいこと
P = Problem：現状、問題となっていること・新たに発覚した問題のこと
T= Try：次回から改善・挑戦していきたいこと

KPTをすることのメリットとして自分が思うことはこんな感じです。

メンバーが、今抱えている問題・やりたいことを明確に分かることができ、それらをチームで共有することで解決策を生み出せ、抱えている課題を解消し、チームの生産性を向上させることができる。またメンバーのモチベーションをTによって把握することが出来る。

そして、最近リーダーから教えてもらったんですけど、KPTでなければいけない理由として挙げられるのが、

K:継続すべきこと
P:新たに認識した問題点
T:次に挑戦・改善すること
を習慣化することで、次はTの何を意識して進めるとチームがより良い方向に向かうのか導きやすいのでKPTでなければいけない。
また、KPTフォーマットがチーム内で正しく認知させているため、1人1人が意識しているKを知り、自分が取り入れることが出来るという側面も大きい。

では、このKPTをどのタイミングで使うかについて話していきます。

KPTによる振り返りのスパンは短い方が良い

結論から言ってしまうとコレです。チームが抱える課題を解消するには、

問題となっていることをチーム内で共有->問題を認識->解決に挑戦

この間隔を短くすることが、改善するために必要なことだと考えます。

アドバイスについて

「なぜ」を意識した説明をする

抽象的な意見・説明だけだと、受け手側は誤った認識で物事を進めてしまう恐れがあります。
「なぜ、それを行うのか」「それをすることによって何が嬉しいのか」などをしっかりと説明することによって、受け手側と提案者側での共有認識の誤差は少なくなるのではないかと思います。

リーダーがすべきこと

まず前提として自分はリーダーの仕事というのは、少ない方が理想的なのではないかと思っています。その理由として自分が思う理想のチームは、

一人一人が裁量を持ち、自律して行動しているチーム

上記を踏まえた上で、自分が思うリーダーがすべきことは以下です。

メンバーのモチベーションを把握し、モチベーションに適したタスクをヒアリングによって選定する
Working Agreementの土台(抽象的なもの)を考える

最後に

いろいろ書いてきましたが、本記事は学生である自分が意識していることを書いたので、企業目線から見ると「意識すべき点が全然違うよ〜」などの声もあると思います。なので他の方々がどういう方法・意識でチーム開発を行なっているのかはすごく気になるので教えて欲しいと思っています。