はじめに
チームの中でどのように振舞うべきか、というのはコード書けるかどうかとはまた違うスキルですよね。
— 佐藤正志＠プログラマーの成長加速させたい！ (@ms2sato) August 29, 2018
実はコード書く事と別に学ぶこともできると思っています。 https://t.co/hDJ5MWQPIe
誰だって最初は未経験なわけで、プログラミング学習サイトやサービスはいっぱいあるけど「実際の現場のようなチーム開発を学ぶ場に出会えるかどうか」みたいな部分はもしかして運ゲーになってたりする…？？
— やまかな🌸⚽ (@mochikana514) August 29, 2018
あるあるだよなーと思うことで。コード書けることと、チーム内での立ち居振る舞いが両立している人はかなり少ないんですよね。片方ずつは努力でどうにかできたとしても二つは別々の切り口なんですよね。かたや「一人でも」を重んじていて、かたや「メンバーにとって」を重んじているので。下記の派生エントリの一つでもあります。
質問すること
私個人の話を書いておくと、個人の開発時代が長かったのと、立場的に自分が牽引する側に居ることの方が多かったのもあり、起業してから「既にかなりの開発が進んでいて、何かしらの文化が構成されている開発チーム」に関係することが増えました。私もそこで結構うまくできなかったりしたこともあって、辛かったなぁ...みたいなことを思い出しながら書いてみます。
当時関わった外部のチームの方々が暖かく対応してくれて良かったです。今でも新しくプロジェクトに関わりはじめる時はドキドキします。
上手に質問するのは難しいです！
特に「なにをいつ聞いてよいか（むしろ聞かなければいけないか）」の呼吸を掴むこと、ですかね。
技術もまだまだ発展途上でプロジェクトに参加した時、わからないことは多数ですし、むしろわからないことだらけだと思うんですよ。でもそれを片っ端からメンバーに聞いてまわったらそれは良い顔されないですよね。「そんなん自力でグーグルで調べてや」って言われてしまいます。
逆に、聞かずにどうにかしようとしてずっと調べ続けていると「なんで聞かないの？聞かないと無理でしょ？」と言われてしまったりします。なんでや！自力で調べろって言ったのはあんたやろ！
あるあるかと思うのですが、整理すると下記3点くらいでやるべき行動が変わるんですよ。
- 誰かに聞いて良いこと
- 聞かずに一人で調べるべきこと、考えるべきこと
- タイミング
誰かに聞いて良いこと
- 文書化されていないか、文書が示されていないこと。
- それがわからなければ最初に聞くのは「xxについてどこかに書いてありますか？読みたいです。」的なこと
- そのプロジェクトでしかわからないこと
- サービスの内容や仕様
- 文化っぽいこと（タグの付け方、WIPの出し方、レビュアーのアサインの仕方、ブランチの名前付け）
- ただし、観察すれば類推できることも多いので、ここで先に観察してから仮説を立ててから「確認として」聞けると良いかと。
- 不自然な実装の経緯*1
- 今やるべきことやゴール
- これがわからないと何もできないはず。明瞭になっていなければ確認しないと進められないはず。
- 「それを明瞭にさせるために少し進めるのがゴール」というケースもあるので、難しいですよね。
- ある程度進むまではあまり大きな裁量は無いはずなので、目指すべき直近のゴールについてわからなければ、誰かに聞かないといけない。
（できれば）聞かずに一人で調べるべきこと、考えるべきこと
- 検索すれば出てくるような一般的な技術のこと
- コードを読めばわかること（程度はありますが）
- エラーに対応する方法
- ツールの使い方
タイミング
これが一番難しいような気がするのですが、上記の条件は状況によって変わっていく場合があります。「今やっていることのゴールがいつまでか」ということに影響を受けるんですよ。時間に余裕があるなら調べる時間を取っても良いでしょうが、時間が無い時には聞いてわかることを聞いて、仕事を終えに行くのも大事だったりします。
初学者の方の場合には、ほとんどの仕事にバッファが見積もられているはずなので、上記のようなことになっても「聞かずに」と言われる可能性はあります。そのあたりの話はこの次の章で書きます。
質問の前にするべきこと（実は質問自体よりも大事！）
いきなり質問する前に、こんなことをしたりすると良いということを書いてみようかと。
「今、時間がかかっている、もしくは時間がかかりそう」と先に伝えること
これが結構大事な気がしています。時間がかかかる予測ができたタイミングで報告や相談をしてみて、先輩などに「その時間をかけるべきか」の判断を仰ぐというものです。「自力解決をすべきかどうか」という判断は自分自身には出来ないケースも多いので、まだよくわかっていないうちは「こいつは手強いぞ」と感じたなら軽く相談するのは良いと思います。
分報を導入しているチームなどであれば「いまxxxに対応してて、苦戦中」などと書いてみるのも良いですよね。
大切なのは「めーーーーーっちゃ時間かけちゃいました。まだできません。わかりません（＞＜）。」という状況になるのを避けることです。この時に既に報告や相談をしているなら、その時間は自分の独断で進めたものでは無いので一方的に責められることは無いでしょう。
## 質問したい内容の整理
何か質問するにつけてもその内容が相手にとって意味不明なことが多いと「こいつ、なんか言ってるけどわけわからん」と思われてしまいますよね。積み重なるとコミュニケーション自体が結構やりづらくなります。少なくとも以下のようなことを整理してみると良いと思います。
- やりたかったこと
- 目的とか、前提とか、今実現したかったことを改めて整理
- 起きている事実
- どんなエラーが起きているか
- 画面表示やログ
- やりたかったことと、事実のギャップがわかる情報
- 解消するためにした行動
- どんなワードで検索したか
- コードをどのように変えてみたか
- 考えていること
- うまくいかない理由について足りない知識からでも考えること
- 打破するためには何が必要か、推察すること
ちなみに、こういうことをしている時に「あ、あれまだ試してない」と気づいて解決できることも多いので、騙されたと思ってまずはやってみると良いと思います。
ツール
この辺は今はコードについてはgitとGitHubの扱いがわかっていれば良いと思うのでこのブログでは論じません。聞いてくれれば私の考えは答えられるけれど巷にいっぱいある情報ですよね。ドキュメントもSaaS型のWEBサービス使っているところが多いと思うのでそれぞれ調べれば良いかと。
どうやって経験するの？
以下は、チーム開発を練習するための場所や方法について考えてみます。
野良プロジェクト立ち上げ型
ただ誰かと集まってやってみる形ですね。以下のような利点欠点があるでしょうか。
- 低コストで実現可能。
- 気心の知れた人たちでやれば楽しい。
一方で以下はネガティブな内容ですね。
- 仲間を選ばないと頓挫してしまう。
- 全て独学で進むことで、勝手に大きな勘違いをしたり、一般的ではない文化を作ってしまう可能性がある。
就業型
「これができれば苦労しない」という方は多いのかも知れませんが、世の中には稀有な環境もありますのでそういう場所をうまく探せるのであれば良いかと思います。
[PR] チームトレやってます。
弊社ではチーム開発のトレーニングやっていますよ。弊社の社内で実際に利用しているサービスの開発を通して、チームでの作法を学習していただきます。詳しくは下記をご覧くださいませー。*2
就業目指している方も、チーム経験あると強いのでご検討いかがでしょうか。十分な実力が発揮できそうなら、こちらでの成果を弊社からも紹介の材料としています。
