僕ぷろじぇくとりーだー。またチームを破壊する

 

 

 

3年前、人生初の「チーム開発」なるものを経験した。

 

当時の自分は他者を尊重するってことを理解できていなかったし、自分に対して自信も余裕もなかったと思う。

 

だから平気で自分の発言を押し通そうとするし、他者を蔑むようなことをしていました。

 

 

 

かと思えば次の日には長文でクソ真面目に謝罪してる。情緒不安定なDV男かよ。

 

 

今思えば、チーム開発とか、他者との関わり方とかそういうのを勉強し始めたきっかけって、この経験が本当に大きい。

 

 

それが理由なのかはわからんけど、当時に比べて反省点がぼろぼろ出てくる。

ぷよぷよが上達するほど、自分が下手に感じてくる感覚に似てる(多分伝わらない)

 

 

 

 

 

そんな自分が、1年間プロジェクトリーダーとして活動した諸々を書いていきます。

 

 

クソ長いので、興味のある部分だけ読んでもらえるとありがたいです。(前提条件だけは最初に読んだ方がいいかも)

 

 

 

 

前提条件

 タイトルで偉そうに「僕ぷろじぇくとりーだー」なんて書いてるけど、そのプロジェクトの実態は、単なる大学内のPBLです。

 

PBLってのは、企業がやってるプロジェクトを真似してお勉強しまちょうね〜って感じの活動のことです。

 

自分が経験したPBLの条件(活動)を挙げていくと、こんな感じ

  • 週1回3時間の活動
  • 活動に対する給与なし
  • 活動に対する単位取得なし
  • 参加は基本的に自由(学部1年〜修士2年が入り乱れる)
  • 年2回の企業発表あり
  • 学内サービスを開発
  • 基本オンラインで活動(新型コロナの影響)
  • 基本的に学業、研究、就活、アルバイトが優先される

 

正社員として働いたことがないので、企業さんのことは全然知らんけど

このPBLにはこのPBLなりの歪な難しさがあると思う。

 

まず、単位も出なければ、給料も出ない。

これって想像以上にでかい。モチベーションの最低限の基盤が存在しないってことだから。

 

だから、各々このPBLに対する「核」をもって取り組む必要がある。

 

仮にそれがあったとしても、チームがそれを大事にする文化がなかったり、

途中でその核を達成してまったり、そもそも途中でその核が変わってしまった場合は、もうそのチームに所属する意味がなくなっちゃう。

 

しかも、このPBLは基本的に学業・研究・就活・アルバイトよりも優先度が低いから、「核」はそれなりに大きいものでなきゃいけない。

 

とはいえ、リーダーがチーム全体のモチベーションをコントロールして、「俺についてこい!!」くらいことが言えれば話は変わってくるかもしれない。

自分はそんなこと全くできなかったんですけどねぇ。

 

 

そんでもって、PBLっていう特性上、メンバー各々の「核」が非常にぶれやすい。

  • とにかくサービス開発を体験してみたい
  • 知り合いがいるから入った
  • 意識高そうな組織にとりあえず入りたい(学部1年の時の自分💩)
  • 技術力を向上させたい
  • 人の役に立つようなサービスを考えたい
  • チーム開発を通じて大規模向けアーキテクチャを試したい
  • チームをマネジメントしたい

 

初めましての人や、ほとんど開発言語を触ったことがない人がいる中で、

これらの「核」が競合しないように、競合した場合は落とし所を見つけながら、1年間週1回3時間しかない中で活動していく必要がある。

 

その上で、「成果」と「学び」のバランスも考えないといけないのがえっちすぎる。

 

成果ってのは、基本的には開発するサービスのことです。

ある程度の成果が出せないと、日頃この活動をサポートしてくれている企業さんに面目が立たなくなる。

 

学びってのは、この活動を通じて得たものの総量の大きさって感じかな...?

せっかく入ってきてくれたメンバーをほったらかしにして、上級生だけでサービスを開発していくなんてことはあってはならないと思うし、そんな活動に自分はPBL的な価値はないと思う。

 

 

 

 

...なんか前提条件というか、難しさみたいなのをあげると、ただ単に文句言ってるだけに感じちゃうわね。

あくまで、こういう前提を理解してもらった方が、以降の項目が読みやすくなると思って書いています。

 

チームをリードしていく上で、こういう前提を理解した上で望むのは絶対に必要だと思うし、

与えられた条件下でどう活動していくかを考えていくことも、チーム開発の面白さだと思います。

 

 

 

 

 

 

 

まぁ、チームを破壊した人間がそれ言っても説得力ないんだけどね。

 

 

 

 

 

 

チーム崩壊を招いた最大の要因

 当初このチームは23人で活動していました。

それが、終わる頃には11人(ただいるだけの人を除くともっと少ない)になっていました。

 

無断欠席は当たり前だし、開発もコミュニケーションもうまくいかず最悪な状態にあったと思います。

 

 

自分も、最後の方はチーム状況を改善させようというより、「どうやってそれっぽく最終発表会を終わらせるか」ということしか考えていなかった。

 

正直、ここまで精神的に追い込まれたのは初めてだった。今振り返ると貧弱すぎんだろ。

 

チーム崩壊の原因は色々あるとして、大きく以下の2点に集約されるのかなって思う。

 

  1. リーダーの実質的な不在
  2. 他者を尊重することに対する履き違い

 

 

 

プロジェクトリーダーの実質的な不在

 前提条件で「核」の話をしたけど、自分にとっての「核」は、チームで開発することそのものでした。

 

PBLという歪な条件下で、自分たちなりの進め方を模索・追求していく。

顔も知らなかった新しいメンバーと、新たな視点を共有し成長していく。

 

はっきりいって、開発するサービスなんてどうでもよかった

 

 

 

プロジェクトリーダーってより、プロジェクトマネージャーって感じ。

そんな奴がプロジェクトリーダーをやると、実質的にチームのプロジェクトリーダーが不在になる。

 

 

そんな状態でメンバーがついてくるわけないんよね。

そもそもついていくものすらないわけだし。

 

 

 

 

 

 

 

このことに気づくのに半年かかりましたとさ。

 

 

 

 

 

他者を尊重することに対する履き違い

 3年前の初プロジェクトで、自分は他者を尊重することができず、結果としてチームを崩壊させました。

 

反省どころか猛省したし、2度とこんな過ちは繰り返すまいと、五臓六腑に刻み込んできました。

 

 

それがいつしか、「尊重すること」が「傷つけないこと」に挿げ変わっていました。

 

メンバーを傷つけないようにすると、いつまでたってもメンバー同士で意見がぶつかった際に意思決定ができない。

 

Aの意見を聞いて「あーそうだねいいねいいねー」って、

Bの意見を聞いて「確かにそれもそうだねーうーんどうしようねー」って、

 

そうじゃねぇだろ。意思決定はアイデア出しの発散フェーズとは真逆のことやりてぇんだろうが。

 

 

確かにメンバー全員の意見とか、意思はちゃんと聞くし汲み取っていく。

だけど、現状のチームのことを考えて最良の選択をする。それ以外は切り捨てる。

 

 

それでも、仮に意見を切り捨てられたとしても、

 

この人が決めたことについていきたい

 

そう思ってもらえるような行動や姿勢を見せていくことが、「他者を尊重する」ってことじゃねぇのかよ。

 

 

そのための努力をせずに、チーム開発でみんな1番だよーみたいな小学校の運動会みたいなことやってなんか意味あんのかよ馬鹿がよぉ

 

 

 

 

 

 

 

自分が目指したかったもの

 とりあえず情報系の大学に入ったから、意識高いっぽいことしてみたい!

 

2016年、当時学部1年生の自分は、そんなしょーもねぇ理由でこのPBLに参加しました。

 

実際のところ、こういった感じでこのPBLに参加する人は少なくないと思う。

PBLの参加を検討する下級生の話を聞いても、

 

「何から始めればいいですか」

 

みたいなことをすごく聞かれる。

 

「〇〇をやりたくて、○○の技術を扱いたいんですけど、詳しい人知りませんか」

 

みたいな聞かれ方をすることがほとんどない。

 

でも、だからこそ

 

「何をすればいいのかわからないけど、自発的に何かに挑戦していきたい」

 

みたいな子たちと一緒に成長していけるような場所を作りたかった。

1年間を通して、自分に自身が持てるくらい技術力が身につくような場所を作りたかった。

 

自分だったら、そういう場所を作れると思ってた。自分の能力をあまりにも過信しすぎてた。

このPBLの条件を考えると、「何かやってみたい」じゃあまりにも「核」が小さすぎる。

 

 

だからこそ、リーダーとして開発するサービスの価値を見出して引っ張っていく必要があった。

 

複雑な概念を抽象化して説明できるだけの技術力が必要だった。

 

メンバーの想いを引き出してあげられるようなコミュニケーション能力が必要だった。

 

 

 

 

いろいろ足りてなさスギィって感じだけど、まぁまだ23年間しか生きてないわけだし、こっからよな。

 

 

 

 

 

 

 

つらかったこと

 まともに(PBLがまともなプロジェクトと言えるかどうかは置いといて)プロジェクトリーダーなるものをやったのは今回が初めてだったんだけど、

無断欠席(or遅刻)されるがつらいったらありゃしない。

 

そもそも無断欠席されることがつらいってことすら想像してなかった。

鬱になりかけた一番の原因は何って聞かれたら、多分これを答えると思う。

 

なんであんなにしんどいんだろうね。

なんか知らんけど、自分のやってることを全否定された気分になるんよなぁ。

 

実際に何人かと1対1で話し合ったこともあったんだけど、結局対して改善されんかった。

気持ち的には幾分か楽にはなったんだけど、チームの成功を考えるとそれだけじゃダメなんよね。

 

 

あとは、孤独感をめっちゃ感じた。

誰も自分の味方をしてくれてないというしょうもない錯覚すら覚えた。

 

でも、それって単に自分のリーダーとしての能力が不足してるだけなんよね。

このチームで目指すことに対して、メンバー全員が同じ認識を持って、各メンバーに対して期待することをちゃんと伝えていれば、孤独感なんて感じないんやろなぁ。

 

それができたら苦労しないって話なのかもしれないけど、

じゃあ今以上にやりようはなかった?って聞かれると、全くそんなことはないし、

「難しい」ってのは、それに取り組まない理由にはならんよね。

 

 

あーあと、孤独感っていうと、メンバーにどれだけ弱みを見せていいのかって部分がすごく難しかった。

 

技術的な話であれば、

「ごめん、わからん。一緒に勉強しよう!」

で済むと思うんだけど、チームの方向性の話となるとそういうわけにも行かない。

 

「これからこのチームどうしていこうか...」

ってリーダーが言い続けるチームやばすぎやろ...

 

ちょうどこの頃、この辺について企業の社員さんとお話しすることが多かったんだけど、

一番納得できたのは

 

チームが目指す最終地点には絶対の自信をもつ、でもそこに至るまでの道には自信を持たなくていい

 

って話だった。

 

例えば、Twitterを例に挙げると、

ユーザの何気ない呟きを共有できるようにしたら絶対面白い!!って部分は自信を持つけど、

じゃあそのためにどうサービスを実装するかって部分は、わかんねぇ教えてくれーでも最悪問題ないって感じかな。

 

世間では当たり前の話なのかもしれないけど、全然知らんかった。

(というよりは、意識できていなかったって表現の方が正しいかな...)

 

そういう意味で、自分が目指す最終地点はサービスじゃなくて開発する環境そのものでした。

 

この辺から、

あれ、自分のやりたいことってプロジェクトリーダーじゃない...?

って思い始めた。

 

 

 

 

 

学んだこと

 学んだことについては細かいことまで書くと絶対ダレるので、特に印象に残った3つだけ書きます。 

 

良い悪いより、価値があるかないか

 この考え方めぇちゃくちゃ大事。多分誰かと一緒に何かをやる上で、一生使うことになると思う。

 

例を挙げるなら、

 

「オマエ、遅刻した。遅刻は悪いことダ。ユルサナイ」→ ドカーン

 

ってのが、良い悪いで考えるってことで、

 

「オマエ、遅刻した。どうすれば遅刻しないようにナル?それとも、そもそも遅刻って概念がないような体制を考エル?」 

 

ってのが「チームにとって」価値があるかないかで考えること(だと思う)

 

 

はっきりいって、良いか悪いかなんてどうでもいいんよな。

別に「悪い」ことしたチームメンバーを訴訟して、懲役を科したいわけじゃないんだし。(訴訟したいメンバーがいるチームは、そもそもチームじゃない)

 

リーダーがやるべきことは、メンバーを訴訟することじゃなく、最高の形でチームが目指す最終地点に導くことなんよな...

 

 

大体、人の行動の理由なんて、過去の体験と周りの環境と偶然がほとんどを占めてるんだし、多少やらかしちゃうのはしょうがなくね?

 

ものすごく極端な話をすると、過去の体験と周りの環境と偶然が噛み合っちゃったら、誰だって平気で殺人を厭わない人間になると思う。

 

だから、やらかした「人」が悪いって考え方をしてると、いつまで経ってもチームの状況は改善されない。

 

 

分野や領域に問わず、トップレベルの強ぇ人が優しいのって、「悪い」ことに目くじらを立てる無意味さを知ってるからなのかなって、何となく思った。

 

 

 

畏怖の言辞「そもそも」

  意思決定の場で交わされる言葉において、「そもそも」ほど恐ろしいものはない。

 

意思決定の場で大事なのは、メンバー全員の総合的合意を得ることだと思う。

だから、仮に自分が求めていたものは違った意思決定がなされた場合でも、どういった経緯で決まったのかを全員が理解しておく必要がある。

 

じゃないと、決まったことに対して疑問が残った状態で作業することになったり、途中で決まったことが簡単にひっくり返ったりする可能性がものすごく上がっちゃう。

 

 

だから、意思決定の場で「そもそも」って言葉が飛び出した瞬間、もうその段階から総合的合意が得られてないことがまるわかリング。

 

「そもそも」って言葉が出てくる原因は、以下のようなことが考えられると思う。

  • その人が今までの話を聞いていない or 聞くような環境が整っていない
  • 誰でもすぐに疑問を開示できるような環境が整っていない
  • 総合的合意が得られるような進め方になっていない 

 

 勿論、「そもそも」って発言した人は悪くない。(さっきも言ったけど、良いか悪いかはどうでもいい)

 

 

大事なのは、「そもそも」って発言が出てきた際に、チームで総合的合意が得られていないことを自覚して、その原因を精査し改善していくことだと思う。

 

 

 

オンラインによる孤立化 

 オンラインが中心の活動ってのは今年度が初めてだったんだけど、

正直なところ、オンラインの難しさを舐めてた。

 

コミュニケーションが難しくなるって言うのは勿論そうなんだけど、

新しく入ってきた子がめちゃめちゃ孤立しやすい。 

 

チームメンバーが顔見知りだったりすると、音声だけでもある程度相手の顔が浮かぶし、むしろオンラインの方が色々と楽だったりする。

 

なんだけど、周りに知ってる人がいないとそういうわけにも行かない。

ただでさえ緊張している中で、周りの様子が全然わからないって相当なストレスだと思う。

 

特にオンラインで話してると、同じところで複数の話題を話すことができない。

だから、必然的に重要度が高かったり、チーム内で知り合いが多い人の発言が中心になっちゃう。

細かく話すところを分けたとしても、そこに移動することそのものにハードルがある。(移動前にそこがどんな雰囲気かとか、どんなこと話してたかってのもわからんしね)

 

 

自分としても、調子どうよみたいな話しかけがすごくやりづらかった。

如何せん困ってそうとか悩んでそうとかがオンラインだと全然読み取れん...

 

 

改善策としては、オンライン通話のやり方を工夫するってのも大事だけど、

それ以上に何気ない雑談の機会を意識的に増やすってのが大事だと思う。

雑談を挟んだかどうかでチームの雰囲気って全然違ってくる。

チームにもよるんだろうけど、少なくとも自分はもっと雑談の重要性を伝えていくべきだった。

 

 

 

 

 

良かったこと

 自分は、このPBLをチーム全員が成長していける場にしたかった。(詳細は自分が目指したかったものにて)

 

結局、自分の力が及ばなくて叶わなかったけど、たった一人、

たった一人だけど、このPBLを通じてものすごく成長してくれた子がいました。

 

彼はTypeScriptの型エラーを、TSLintの設定を無理やり外すことでエラーが消えましたって言うような子でした。(静的型付け言語の意図をちゃんと説明しなかった僕が圧倒的に悪い)

 

それが今では、React、Reduxの概念を理解した上で、Atomic Designを使いこなし、さらにはAtomic Designの利点を理解した上でその問題点を指摘するまでに成長していました。

 

勿論、成長したのは彼自身の能力でしかないけど、

その成長に少しでも貢献できたこと、その成長過程を側で見られたことが嬉しかった。

 

 

自分が培ってきたものが、誰かの人生に少しでも貢献できるのって、本当に素敵なことだと思いましたとさ。

 

 

 

 

 

プロジェクトで使用(検討)したツール

 前提条件でも話したけど、今年度は基本的にオンラインでの活動だったから、ツールに関しては例年より考えることが多かった気がする...

 

Zoom

 オンラインの活動ってことで、最初に使ったツール

良い感じではあったんだけど、当時(2020年4月)はブレイクアウトルームや画面共有の機能が整備されていなかった(1画面しか共有できない等)ので、結局通話のツールとしてはDiscordを採用することに。

 

Discord

 本プロジェクトで採用した通話ツール

各メンバーがどのボイスチャンネルにいるのかがすぐに把握できるデザインが良き。 

チャットもできるけど、文章の共有はSlack、通話はDiscordで分けていました。

Slackを使わずに、通話とチャットとDiscordで完結させる方が良かったかも。

チャンネルとしては、サービスの役割ごとにボイスチャンネルを作って分けていました。

 

SpatialChat

 検討はしたけど、結局使わなかった通話ツール

通話に参加している人が円として表示されて、円同士が近いほど、その人の声が聞こえるようになるってやつ。

よりオフラインに近い感じにできるかなーって思ったんだけど、やっぱり遠くの声が聞こえるって言うのに限界があったし、どうしてもチーム開発で使えるまでは行かないかなーって感じだった。(普段はオンライン懇親会とかでよく使われているらしい)

 

Slack

 本プロジェクトで採用したチャット(?)ツール

例年このPBLで採用されているので、特に検討もしなかった。

チャンネルとしては、各メンバーの分報チャンネルを作るのが結構良さげだった。

やっぱ新しく入ってくれた子とかは、どのチャンネルで発言して良いかわからないみたいな問題が出てきちゃう。

そんな時に、呟き感覚で書ける自分用のチャンネルがあると、とりあえずそう言った問題がなくなるし、メンバー間で交流もしやすくなる。

他の候補としては、Microsoft Teamsとかがあると思う。

 

Google Drive

 本プロジェクトで採用した資料置き場

作成したスライドやポスターとかを置いて、メンバー間で共有できるようにしてた。

Drive上で共同作業するっていう用途ではあまり使ってなかった。

共有だけならDropboxでもよかったかも。

 

HackMD

 本プロジェクトで採用したオンライン版のホワイトボード(?)

マークダウン形式でメモとって共有できるツール。

とにかく軽いってのが最高。複数人で同時に書き込んでもほとんどラグがない。

何かしらの話し合いの最中に使ってることが多かった。

 

Trello (+ Elegantt)

 本プロジェクトで採用したスケジュール管理ツール

スケジュールはガントチャートで管理したかったんだけど、意外と20人規模のチーム用のツールって無料じゃ使えなかった...

だから、TrelloにChrome拡張機能であるEleganttを使ってガントチャートに変換してました。

使えることには使えるんだけど、いかんせんEleganttがめちゃくちゃ重かった...

これ以外で無料で使えるツールがあれば教えて欲しいです。

 

Miro

 本プロジェクトで採用したオンラインアイデア出しツール

オンラインでアイデア出しとかやったことなかったけど、かなり使いやすかった。

Miroに関しては、2つのボードまでは無料で使える。

1つのボード内に画像とかを配置しすぎると、どうしても重くはなっちゃう。

似たようなツールとしてMURALがあるけど、どっちも違いがよくわからんかった。

 

XD

 本プロジェクトで採用したモックアップ作成ツール

他にモックアップを作るツールとしてはFigmaがあるけど、どっちもそこまで使いこなしてないから、違いがよくわかってない。

本プロジェクトのフロントエンドはAtomic Designを採用してるんだけど、Figmaの方がAtomic Designと近い用語を使ってる気はする。

 

 

 

フロントエンドの開発環境

 フロントエンドの開発環境作りは結構頑張ったつもりなので、紹介させて欲しい。

使った諸々は以下の感じです。

  • 言語:TypeScript
  • ライブラリ:React、Redux、redux-saga
  • UIデザイン手法:Atomic Design
  • UI開発環境:Storybook

 

こういう技術選定になった理由としては、正直、自分が一番まともに教えられそうだからっていうのが最大の理由です。

 

そういった中で、如何にプログラミング初学者の子にも「チーム開発」を体験してもらえるかっていうのが大きなテーマでした。

 

Reduxとredux-sagaの考え方は一見複雑に感じちゃうけど、

強力な一方向のデータフローを実現しているから、1ファイルあたりの記述量が抑えられて、結果的に各ファイルの記述内容や意図が理解しやすくなると思った。

 

あとは、状態管理や通信処理をUIの記述部分から完全に分離できるってのがでかい。

これによって、プログラミング初学者の子はUI部分(or 通信処理)だけに集中して取り組める。

 

UI Componentの切り方(?)としては、Atomic Designを採用しました。

理由としては、メジャーなUIデザイン手法の中で最もUI Componentの分割が細かかったからです。

ビジネスが絡むサービスの場合は、もっとまともな理由がないと話にならないんだろうけど、自分がこのPBLに対する認識的にはこの程度の理由で問題ないと思った。

 

あとは、Reactの良さを活かしやすいってのも大きかった。

何かしらの技術を学ぶ上で、その技術の良さを実感できるかどうかってものすごく大事だと思う。

 

Atomで基本的なReact Componentを理解

 → OrganismsでReactの再利用性やデザイン手法の利点を理解 

 

みたいな流れをイメージしていました。

 

 上記の勉強用サンプルコードを書いていたので、是非ご意見いただけると嬉しいです。

(諸々の説明はREADME.mdにあります) 

 

 

 

それと、勉強用サンプルコードには導入してないんだけど、Storybookってのがめちゃめちゃ良かった。

 

作ったComponentを一覧で見られるサービスなんだけど、これがあるおかげでデザインのレビューが凄くやりやすかった。

デザイナーさんとのコミュニケーションが取りやすくなるのも大きなメリットだと思う。(うちのプロジェクトではそれは実現しなかったけど...)

 

 

 

 

 

おわりに

  今年度は、本当に精神的にしんどかったー。

多分周りからしたら何も変わってないと思われるんだろうけど、かなり心に傷を負った1年間でした。

 

それだけに、得られた学びは大きかった。

心に傷を負ったのも、それはそれで良かったのかなと。

 

「傷ついたことがないから、他人に何を言ったら傷つくかがわかんないんじゃない?」

 

って言われたこともあったくらいだし。

 

内容はかなり吟味してまとめたつもりだけど、グダグダな文章になっていないかとか、逆にまとめられすぎて軽い感じになっちゃってないかとかが心配。

 

 

 

内容の質はどうであれ、少しでも役に立つようなことが書かれていれば幸いです。

 

 

あと、感想とか読者の実体験とかツールの話とかコメントでもらえると嬉しいかも。