初心者である私が共同開発にのぞむ中で想定外な出来事に３つ遭遇したので、それについて、どう検討していったかを記載していきます。
# 一つ目【スクールでの共同開発廃止】
私は、ITスクールに通っていました。
入った目的は大きく２つあり、勉強習慣を身につけることと共同開発を行うことでした。
しかし、スクールが始まるまでの期間で、共同開発が廃止になることが決定されました。
ここで当初考えていた共同開発体験という目的ができなくなりました。
そこで私は
スクールのチームメイトとオリジナルの共同開発をやろうと画策しました。
その為に、勉強会を開催してメンバーとの交流を深めて、
就職活動の話題のネタの一つになるということをエサに
共同開発を提案しました。
この時は、漠然と何をテーマにすれば良いか分からない状態でしたが
ある日の勉強会で、
メンバーの一人が中学生の野球監督をされていて、作りたいものがあると言われました。
それはスコアブックを記録。その記録を翻訳して、親御さんに子供の成績を知らせるアプリです。
すぐに使用して、フィードバックが得られる環境で
想定される工程数もそれなりに多そうだと判断して、
共同開発のテーマを野球スコアアプリ「BBSCORE」にしようと思いました。
提案したところ周りからの賛同を得られ実施することになりました。
# 2つ目【高い理想とメンバーの離脱】
共同開発を募集したところ合計６名集まりました。
そこでペルソナとスケジュールなどを決める
初回の打ち合わせを行うこととなりましたが
１つ問題が発生しました。
それは理想が高いメンバーが１人いたことです。
その方は前職でゲーム開発の経験者の方でチーム内でもプログラミングができる方で、
スケジュールや要件定義を初心者向けに調整して提案したところ、全部否定されました。
作りたいものを作るのが第一で、期間も短期間、実装方法も初心者にとって難しいものにすべきと言われたのです。
私はこの意見に対しても納得しましたが、初心者もいるので妥協する点が必要だと再度伝えました。
しかし話は平行線でした。
このままでは、私とその方で話が進まなくなるので他の方の意見も伺ったところ、反対意見がなく、
ハードルが高い方で進めていくこととなりました。
不安を残す中で、第一回目の打ち合わせは終了しました。
数日後、第2回目の打ち合わせを実施しました。
2回目ではDB設計と要件定義の詳細設定、担当を決めました。
内容についての確認で激しく言い合いを行うことはありましたが、
ホワイトボードに図や表を書きながら、イメージの擦り合わせを行うことができました。
このまま何とか進められそうだ。そう思った矢先
３回目以降の打ち合わせから雲行きが怪しくなりました。
いざ打ち合わせをやっていこうと望んだ３回目に
欠席で２名参加できないと連絡があり、
その数日後に共同開発から抜けることになりました。
1人は共同開発ではなく個人のアプリ作成に専念したいから抜けると言われ、
こちらは個人の理念があるので皆が納得しました。
もう1人は事前相談もなく欠席して、DMで繋がった方と
実際の案件を優先して取り掛かろうとしている状況でした。
私はこの件のヒアリングを担当して、情報をメンバーに伝えたところ
一緒にやっていくのは難しいとの判断で抜けてもらうことになりました。
この出来事を振り返って、認識の擦り合わせとルールが曖昧だったことが原因だと考えました。
チーム一人一人がどう思っているのかをヒアリングして、意見の調整をはかる。
その上で全員が納得する様な設計を作成していくことが大切。
また、報告連絡相談などのルールをしっかりと定め、一定の秩序維持が求められました。
# 3つ目【間違った役割分担、期間設定によるメンバーの対立】
残ったメンバー４名で開発をすすめることとなりました。
この時、野球監督されているメンバーがお仕事をしなければならない状況となり、ペースを落としての開発となりました。
役割として、下記の様に決まりました。
DB設計、要件定義、全体的なフォロー、ビュー ：私（Kさんメンター）
バックエンドおよびスクラムマスター :Nさん
DB設計、要件定義、バックエンドメンター :Yさん（元ゲーム開発者、Nさんメンター）
ビュー全般 :Kさん(野球監督、アプリ発案)
開発の流れは
ビュー→バック→テストと言う形です。
この状況で開発を進めていきましたが1つほど問題がありました。
まず、それは役割分担の配分が偏っていたことです。
と言うのも、Kさんは仕事をされている上、フロント側の理解が浅いのにも関わらず、全てのビューの担当にしてしまい、一人ではビューが完成しない事態となりました。
メンバーの２人はKさんにアプリ発案者と言うこともあり
情念を持って取り組んで欲しいと考えていたようで
時間を延長してもやり切るようにと伝えておりました。
しかし、私は量が多いビューは２人でバック１人の配分が良いと主張し、
何度か私もビューの作成を行おうと提案をしましたが
それだと私がほとんど完成させてしまうのではと却下されました。
結局
Kさん本人も次はしっかりやりますと宣言をし
期限を伸ばし取り組むこととなりましたが完成しませんでした。
再度打ち合わせとなりました。
するとメンバーの心情が変わっておりました。
Kさんは仕事があって、理解度もスクールでほとんど触れてこなかったビューなので
そこまでできなくて当たり前だと。
更に期間を延長して、
理解できるように学習した上で取り組むのが良いとの方針に変化してました。
この時の心境の変化の原因は個人アプリが完成して余裕がでてきたからでした。
ここで再度、作業分担の見直しとはいきませんでしたが、
以下の３点でリスタートということでまとまりました。
期間を今年中とゆっくり設ける。
質問に関してのルールを設け、slackで相談
都度進捗状況の報告連絡相談を徹底
# 最後に
素人の共同開発はそれぞれの使える時間に限りがあり、理解度も異なっているので大変難しいと実感しました。
主張の強い方に意見が偏りますし、
声を出せない方の意見を拾い上げていくことも大事で今後の課題だと感じました。
また、私の今後の課題としては、相手を説得できるように持っていくことだと考えてます。
否定的な感情に流されずに物事を判断して、
向こうだけでなくこちらにも非があったのではないかと考える力があったのにも関わらず
相手を納得できるように持っていけなかったのは、単純な力不足でした。
今後は、きちんと理由をつけた上で話すこと。相手に想像させて共感させるような話し方を意識して共同開発に取り組んでいきたいと考えております。
