チーム開発を終えて。

正直すごいストレスとプレッシャーだったチーム開発もようやく昨日で終わったので、

学んだこと・気づいたこと・感じたこと(技術的側面は省く)などを、自分への備忘メモとしてまとめておきます。

すべて個人的な見解と感想なので、「こうしたら上手くいく」というわけではありませんが、ご参考までに。

 

報連相がすべて】

よく言われるように「コミュニケーションが大事」というレベルではなく、「コミュニケーションがすべて」です。

報告・連絡・相談をそれぞれが確実に行えば、開発は比較的スムーズに進みます。

とはいえ、それを完璧に実行するのは至難の技であるのは百も承知。

私自身も、できていない場面も多々ありました(反省)。

完全遂行が難しくても、各メンバーがこの意識を常時もっているだけで、状況は前向きに転がると思います。

また、Slackなどのテキストコミュニケーションでは、みんな全部は読んでいないという前提で動いた方が良いです。なんだかんだでチーム開発時は結構な量のやりとりになりますし、僕は毎日数百通のメールなどをこなす職場で働いてきたので慣れていますが、ほとんどの人は大量のテキストコミュニケーションに慣れていません。初めは自分の感覚でたくさんどんどん送っていたのですが、途中から減らしました。(読まれなくても「言ったよね」という言質にはなるので、必要最小限は送った方がよい)

大切なことは、テキストコミュケーションだけで終わらせず、それに上乗せして声がけすることだと思います。

 

【人は十人十色で当たり前。初期条件は変わらないし、変えようとしない】

スクールに来ている目的も、理解度も、稼働時間も、やる気も、人生の背景も、キャラも、性格も、能力も、特性も、嗜好も、ポリシーも当然全員それぞれことごとく違います。人にはそれぞれだけの真実があり、それを他人はどうしようもありません。

そこを無理やり、何かに合わせよう・統一しようとしないのが本当に大切!!(合わせようとしたくなる時もあったけど笑)

というか、それぞれの初期条件に合わせて、開発を進めました。

 

【最初の目標と方針設定が、マジ大切】

仕事であれば、「納期」と「お金」という前提目標があるのでわかりやすいのですが、「プログラミングスクールにおけるチーム開発」となると目標の定義が曖昧です。

というわけで、チームのキックオフでは、まず全員の初期条件の確認(自己紹介やチーム開発に期待しているもの、稼働時間など)を話しあいました。

みんなそれぞれチーム開発に対して前向きで、期待も大きく、

当時のメンバーの技術理解度や稼働時間なども考慮した上で、

「必須機能(必要最低限)だけを納期までにきちんと実装する」

「誰かが途中で脱落することなく、みんなで卒業する」

「各自、学びを深める」

というのがチームの目標に決まりました。

結果として、全部達成できたかなと思っています。

振り返ってみれば、開発が比較的順調に進んだのは、初日のこの話し合いがすべてだったかもしれません。

 

【Trelloでのタスク管理の徹底】

今思えば、Trelloというシステムは上手くできているなと思うのですが、最初1週間は上手く使いこなせていませんでした。

第1回目のスプリントレビューの後、Trelloを毎日見ることをみんなで徹底したら、流れがよくなりました。(Trelloのタスクカード内容を把握した上で開発を進め、右へ右へ動かしていくんだというフローがわかってきた)

また、まだよく作るアプリの各機能を把握もしていない2〜3日目でしたが、それぞれのタスクカードの作業内容・難易度・作業量・完了定義などをみんなで話しあったことで、「どんな機能が必要なのか・それを実装するにはどうするのか」について、たたき台が出来ました。

ここが、開発が比較的に順調に進んだ第2の要因。

 

アジャイル開発だったけど、大まかな見通しはたてる】

1週間目終わるくらいまでは、みんな「本当にこんな感じで進めていて完成できるのだろうか?」という不安が大きかったように思います。

なので、アジャイル開発ではありますが、大まかな見通しをまとめました。

その時作ったガントチャートを貼っておきます。

f:id:AngelWingJasmineT:20200118094745j:plain

今、振り返って見ると、結果としてほぼこのガントチャート通りに開発は進みました。

最初の説明会でも言われたことですが、「スプリントレビューを目標に1週間ずつ区切ったものを4回繰り返す」と考えるとわかりやすいです。

その1週間ごとに、目標を達成していけば、着実に完成に近づいていきます。

チームメンバーそれぞれが確実に毎週のタスクをこなしていったので、当初の大まかな見通し通りに開発が進み、無事完成しました。

 

・第1スプリントレビュー目標

 DB設計、デプロイ、TOPページ、ユーザー新規登録・ログインは終わらせる

・第2スプリントレビュー目標

 商品出品、商品詳細、商品購入(いけるところまで)、ビューほぼすべてを終わらせる

・第3スプリントレビュー目標

 すべての必須機能を終わらせる。

・最終スプリント

 調整メイン。可能な範囲で機能追加。

※レビュー担当のメンターさんにも言われたのですが、

できるだけ早く「ユーザー登録」「商品出品」「商品購入」の3本柱のサーバーサイドを終わらせるのが肝です。

 

また、チーム開発期間内にクリスマスや年末年始があり、さらにスクールの休校日が飛び飛びに入った関係で、各自のモチベーション維持や作業管理が通常時より大変でした。(その分、納期までの日数的には通常時のチーム開発より、ちょっと多かったので助かりましたが、、、)

 

【動きを担保した状態で開発を進める】

仕事の現場だと、いくら細部を作り込んでいても「納品時にきちんと動く状態になっていなかったらアウト」です。

逆に「作り込みが若干甘くとも、必要な機能がついていて、きちんと動いて、アプリとして成立していれば、まぁセーフ(もちろん作り込みがきちんと出来ているべきではありますが)」です。

つまり、クオリティ云々でなく納品オンリーの観点でいってしまえば、「0点か100点か」の世界です。

なので、出来るだけ「きちんと動いている状態を担保しながら開発を進めること」を意識し、「各機能の実装の際も、本当に必要な項目だけをまず動くように作る(まず大枠を作ってしまう)。最初は余計な項目はつけない。その後、項目を増やす」という方針を徹底しました。

その結果、割と余裕をもった状態で「必須項目はきちんと動くアプリ」が完成しました。

逆に「各機能内の項目などは結構端折って状態」のまま、終わりを迎えました💦

なにはともあれ、納期内にきちんと動く状態で納品できてよかったです。

 

スクラムマスターと技術的なリーダーは別々に】

チーム内では、僕は技術的なリーダーをやらせてもらいました。

スクラムマスターは人をまとめるのに慣れている方が立候補してやってくださいました!!

こうしておくと、

・負担が分散する

・必然的に、スクラムマスターと技術的なリーダーの間でコミュニケーションが発生するので、コミュニケーションの発火点になる

・技術的リーダーがスクラムマスターを兼ねると、独善的・独走的になってしまう場合もあるので、それを防ぐ

といったメリットがあります。

(まぁ、最後1週間ほど、僕も暴走してしまっていましたが。。。汗)

ただ、チームの中で飛び抜けて理解している人がいないなら、無理に技術リーダーを立てる必要もないとは思います。

 

【最初に各機能の詳細や実装方法を時間がかかってでも調べる】

ここからは反省点。

焦りもあって、最初に各機能の詳細や実装方法を、そこまでじっくりはやりませんでした。

今振り返ってみると、その調べをやっておけば、もっと効率良く開発を進められたかも。

ざっくりやったがために、

・DB設計にてこずった→DBは特に最初にきっちりまとめておいた方がよい。あとで変更が出ると他の作業への影響大なので。

・同じ担当者がやった方がよいタスクを、別々に割り振ってしまっていた

・同じことを、それぞれの担当者がやっていた

などの非効率が発生しました。

 

【タスクの割り振り、マークアップとサーバーサイドは均等に】

マークアップとサーバーサイドは均等に割り振るようにしていて、それは上手くいったかと思います。

・同じページで、マークアップとサーバーサイドが発生する時は、同じ人にそれぞれを担当してもらってそれも上手く機能したと思います。

・どのページも、サーバーサイドに入る前にマークアップを先にしてたのですが、実際動的な部分を組み込む時に、ビューが崩れてしまうことが多かったので、サーバーサイドの枠組みを作ってから、それにビューを嵌め込んで整えていくというやり方の方が効率がよかったかもしれません。

 

【コンフリクト時は声をかけあう】

・gitの共同開発は一人では学べないので、今回体験できて本当に良かったことの一つです。最初コンフリクトがでた時は、チームみんなで大騒ぎしながら解決して、ビビりながらも楽しかったです。コンフリクトが出過ぎて、後半はコンフリクト自体に慣れてきましが(笑)

これもコミュニケーションというか、確認しあって進めればなんとかなります。

でも、コードの一部に書き足した場合など、消えてしまっている場合があったので、やっぱり自分で「消してもいいだろ」と判断するのでなく、該当するであろうメンバーに逐一声をかけるのが大事かと。自戒も込めて。

・同じくmergeする際も、声をかけた方が無難。

 

【コードの読みやすさを意識】

・人の作ったビューをちょっと直したい時など、SCSSが解読しづらい場合や複雑な構造になってしまっていて直せない場合がありました。逆もしかりだと思います。

特にチーム開発では、コードはわかりやすい構造で書き、必要な部分にはコメントアウトで説明を入れて、人が読みやすいように書かなければいけないことを学びました。

 

【いらないファイルは消す】

作業用に作っていたファイルを消さずに置いたままにしておいたため、他の人がそのファイルを元に作業してしまうということがありました。

いらなくなったファイルはすぐに消さないと、他の人に迷惑がかかることを学びました。

 

【全体のファイル構成や人の書いたコードも把握しておく】

効率・スピード重視で、チーム内でレビューし合うことを端折ってしまっていたので、ここは疎かになりました。

勉強という意味合いだけではなく、特にデプロイ担当者はデプロイ時にエラーが出た場合、エラーポイントを特定し解決するために、ある程度把握しておいた方がよいです。

 

【足並みを揃える】

チーム開発なので、独走せずに足並みを揃えることも大事です。

前半はすごく意識していたのですが、年明けくらいから、納期を意識するあまり「横並びで相談」というスタンスから「一方的に指示出しする」ことが増えてしまったので反省してます。

また、完成が見えてからはスピード感を元に戻してちょっと暴走してしまったので、これも反省。

 

【任せたら、信じて待つ】

僕は昔からこれが苦手です。仕事上であれば、進捗管理の観点から、ある程度待った上でタスクを取りあげたりもしてきました。

今回は仕事でないし、待つことができました。

が、各担当者に結構「どうなってる?早くしてよね!圧」をかけ過ぎたなと、これまた反省してます。

(その圧に関係あるかどうかは分かりませんが笑、メンバーみんな裏でかなり復習・勉強していたと思うので、すごいなぁと尊敬してます。みんな、そんなことはわざわざ言わないけど、見ていて分かりました、感じました。)

 

【みんなの相談・質問に応えられるように】

基本任せるのですが、質問に応えられたり、時に一緒に作業を進めたりすることも必要です。

私自身、当初各メンバーからの質問に応えられないことも多かった(自分の担当タスク以外のところをあまり把握していなかった)ので、途中からタスクを割り振る前に、その機能の内容や実装方法を予習するようにしました。おかげで、全タスクの概要を把握しているので、一人でこのアプリを作れるようになりました。(ビューは整えてないけど、一人で作った同じアプリも出来ています笑)

これを行ったことで、各自の作業量やつまりそうなところがわかるようになり、当初よりはマシなアドバイスや質問への返答ができるようになったかなと思います。

また、進捗上早めに仕上げなければいけないが苦戦しているタスクにおいては、自分のタスクを後回しに、休日カフェで担当メンバーと一緒に作業したりしました。これは自分の勉強にもなりましたし、良い思い出でもあります。

あと、これはディレクターとして働いていた時からのクセなのですが最悪の事態もいつも想定していました。「最悪その人がいなくなってしまったとしても、自分が代わりに入って納期に間に合わせれるか?」と常に問い準備していたので、終わりが見え始めてくるまでは特にシンドかったですね笑。

 

【アプリとして成立させるための最終調整】

各機能LGTMをもらってmergeしても、それだけできれいにアプリとして成立するわけではありません。

ビューの統一性や導線などを整えたり、ログイン時非ログイン時の区別や自分の出品した商品は買えなくするなどガード節を書いたり、全体的な調整が必要です。

これは、通しでアプリを見ての動作確認が必要なので、誰か一人きっちり責任を持って対応する必要があります。

Trelloにタスク化はされていませんが、個人的にはこれも必須1タスクとしてもよいくらい大切だと思います。

 

【takerからgiverへ】

仕事でディレクションをやってきた身としては、正直「お金ももらえない、むしろ払っているのに、なんで人に教えたりまとめたりして、こんなに時間も労力も使って苦しまなきゃいけないんだ」と精神的に苦しい時期もありました。

でも、教えたりまとめたりすることで自分の力がアップしたのは間違いないですし、それに喜びを感じる瞬間もありました。また、それが自然とできている優秀な若い子たちがスクールにはたくさんいました。

これまで、自分のことだけしか考えずに生きてきたので、そろそろ社会に恩返しをしていく時期かなとも思います。口だけの人は結局淘汰されていきますのでね。

今回のスクール通いをきっかけにtakerからgiverへ生まれ変わりたいです。

 

【自分のお金になる部分に気づく】

僕は「ディレクション」や「調整」という作業が好きではありませんし、得意と思ったこともありません。全体的にはむしろ嫌いです。(たまには嬉しかったり、楽しかったりはしますけども)

なんなら「ずっと人と関わらず一人でいたい」方なので、本音いえば「一人で淡々と黙々と作業」してたい。

ディレクションや調整は、ストレスやプレッシャーをすごく感じてしまいます。

でも、なぜかいつもそういった仕事・立場・役回りに行き着いてしまいます。

それは、自分が好きとか得意とかいう問題と関係なく、周りから「求められるかどうか」なのかと。そして、「周りから求められる」→「やる」→「喜ばれる・感謝される」→「お金になる」ということなのかなと思いました。

一人で好きな時間に好きな場所で、できるだけ人と関わらず(笑)にいたくて、リモートワークを目指していましたが、今回学んだ「自分のお金になる部分は?」という視点も踏まえて、次のステージ・生き方を選んでいきたいです。

とにかく、チーム開発は仕事復帰へ向けての良いリハビリになりました!!

 

チームのみなさん、ありがとうございました!!

 

【まとめ(チーム開発を順調に進めるには)】

・コミュニケーション(報連相)の徹底が大前提

・最初によく話しあう(それぞれの初期前提の洗い出し、それに合わせた目標設定、方向性の決定)

・最初に作るものを深く研究する(機能の把握、実装方法の検討、完了定義を明確に)

・4つのスプリントごとの大まかな見通しを立て、スケジュール感をチーム内で統一

・あとはスプリントごとに「各自が責任持って目標通りに担当タスク作業を進める→スプリントレビュー→実際の進捗に合わせて、タスク割り振りやスケジュールを微調整」を繰り返す。

・特にスプリントレビュー前後のコミュニケーションをあつくし、進捗状況の把握と次の1週間の目標をみんなで共有の上、作業を進めるのが大事。

・それを4回繰り返したら、完成します。

 

以上

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です