本記事は新人エンジニアAdvent Calendar 2016 2日目の記事です。
テーマ「新人エンジニアの実体験からの業務効率化手法」ということで、新入社員配属後の研修の中で起きたことと、そこで得られた教訓について述べさせていただきます。
なお、1日目の記事の別視点、私の主観によるものとなります。
合わせてご覧いただくと、より一層お楽しみいただけます。
得た教訓
私たちの研修は、「ギャップとの戦い」でした。
端的に、この研修で得た教訓は以下の二つです。
- わからないことはわからないと言いましょう
- わからないことがあったら聞きましょう
- 第三者の意見・視点を取り入れましょう
何れも当然のことではありますが、より一層意識し、実践しようと思ったものです。
以下、この教訓を得るに至った経緯を紹介させていただきます。
突っ込みどころの多い行動・考えが見られても、「バカなことを」とでも笑ってていただけると幸いです。
なお、本記事では実際に開発したアプリケーションの内容には触れません。
アプリケーションにご興味がありましたらこちらの記事(外部リンク)もご覧ください。
「チーム開発演習」とは？
研修の、そして本記事の本題であるチーム開発演習(以下、演習)は、"チームでソリューションを作る"ことを目指します。
その過程で、QCDその他を意識するのは当然として、
- チームとしてシステムを開発(v1.0)し
- デプロイ/テストし、プルリクエストを受け入れ、
- 新規機能を実装し、バージョンアップ(v1.1)を行っていく
という流れを実践・経験することが目的です。
演習における開発は以下のスケジュールで進められました。
チーム開発演習で起きたこと
その０：登場人物
私たちのチームの物語に、主に登場するのはチームメンバーとなる以下の2名 + それぞれのOJTです。
- @aya_taka (以下、自分)
- @KIKUYA-Takumi (以下、相方)
二人とも、情報系の修士卒です。
演習に必要と思われる技術の基本部分の導入は、演習以前の研修で行っています。
その１：最初の合意、戦争の足音
演習の序盤、作りたいものの方向性が決まるまでの段階は、非常に早く進みました。
最初に行われたヒアリングの結果から、私たちのチームは「ギャップを解消する」というテーマへの合意に至りました。
これは、この段階から、演習の最後までぶれずに、自分と相方の二人の間にありました。
思えば、この合意が強固だったからこそ、最後まで没交渉に陥ることなく進むことができたのでしょう。
企画段階において、アプリデザインやその中身にまで踏み込んだ提案資料は、おおむね好評をもって先輩方に受け入れられ、すぐさま開発スケジュールの具体化、そして、実際の開発へと進んでいきました。
私はバックエンドを担当し、相方はフロントエンドを担当する。
効率を求め、作業分野を完全に分離した結果、開発作業も非常にスムーズに進みました。
予定通り、何の問題もなく進む。この時の私は何の根拠もなく、そう信じていました。
しかし、スムーズな進行に浮かれる当時の私は、知る由も、いえ、知ろうともしていませんでした。
この時すでに、我々の間に様々なギャップがあったことを…。
その２：そして戦争へ
中間発表の際に出た指摘、「本当にそれで解決できるのか」
指摘内容をまとめると、
- 「コンセプトが弱い」
- 「ソリューションとして不適切」
といった内容です。
ここを発端に、v1.1向けに追加する機能について話し合う両者に、意見の対立が生じます。
このときの両者の意見は以下の通りです。
- 自分 : デリバリー重視「まずは完成させる、理由付けは後回し」
- 相方 : クオリティー重視「まずは何を解決するのか、コンセプトを決めてから」
「なぜそう考えるのかわからない」
私にとって相方の意見は、わかることにはわかるものの、しかし開発終盤のこの段階で求めるものではないと思えるものでした。
しかし、相方にも当然譲れないものがあり、クオリティーのためにコンセプトから考えるべきと主張します。
QCDという意味では、(バランスが取れているか、取る気があるかは別として)どちらも外すことはできないでしょう。
結果として両者の意見の対立は、言葉によるボクシングとでもいうべき、真正面からの殴り合いへと発展します。
かみ合わない両者は、バックエンドとフロントエンドという開発における担当部分の分離による知識の偏り、及び追加機能がバックエンド中心の実装になるという想定から、現実的に可能な機能を求める自分と、理想的なコンセプトを求める相方という構図に向かいます。
お互いの主張は平行線、どころかかみ合わず、同じところを見てすらいません。
ギャップは埋まらず、前には進めず、ただ言葉をぶつけ合い、時間だけが過ぎていく状況に、二人は焦りを募らせていきます。
その３：調停への動き
そんな、周囲の方に「怖かった」と言わしめるほど険悪な雰囲気で、それでも論戦を続けていた両者でしたが、状況の停滞から第三者の意見を取り入れることを決めます。
相方の提案によってOJTを交えた数度の話し合いが行われました。
この時の両者が提案したコンセプトと実装機能をまとめると、
- 自分
- コンセプト：当初通りの「話し合いによるギャップ埋め」
- 実装規模：1週間以内に確実に実装が終わる規模の機能
- 相方
- コンセプト：新規に「インタビューによるギャップ埋め」
- 実装規模：1週間以内の実装が厳しい規模の機能
正直、この機能の実装を担当する予定であった自分から見て、相方の提案した機能の仕様は、「細かく大量に変更しながら新しい要素を追加する」というものであり、時間的に非常に厳しいものに思えてなりませんでした。
なお、この時点で私は機能についてしか目に入っておらず、相方の指摘もコンセプトに対するものだけでした。
故に、案の定というべきでしょうか、この調停すら停滞し始めていたとき、OJTの一人のつぶやきがすべてを変えました。
その呟きは、簡単に言えば両者の意見のいいとこどり(自画自賛)を意味するものでした。
自分の提案する「現実的に実装可能な機能」で持って、相方の「理想的なコンセプトであるインタビュー」の補助を行うという内容です。
相容れないと考えていたために思いもしなかった「中間」は、両者の和解、そして状況の打開という結果を生みました。
そして、無事、アプリケーションはv1.1のリリースにたどり着きました。
まとめ
今回のお話において、ギャップはクレバスに例えることができるでしょう。
私たちのチームは見た目上、「ギャップを話し合いで埋める」という言葉・目標で一致していました。
しかし、その言葉がわかりやすかったからこそ、その言葉の周囲に散らばる数多のキーワードや、メンバー間の認識の確認がおろそかになり、結果としてチーム内のギャップが最後の最後まで顕在化せず、気付いたら詰みかけていたという内容です。
この演習中にぶつかったギャップ・問題のうち、大きなものは以下の5つです。
- QCDの優先順位
- ソリューション、その他用語の目的・意味・認識
- 実装難易度に対する認識の違い
- それぞれの持つ情報・知識・技術の違い
- 理想と現実
いずれもどこにでもあり、同時に長く付き合うであろうギャップです。
この最初の段階で、これらにぶつかったという経験は確かに価値あるものではあるでしょう。
本演習は、「ギャップを話し合いで埋める」をテーマに、様々なギャップと戦い抜いた研修でした。
故に、ギャップの解決のため、最初に挙げた教訓をもう一度、
- ギャップを示すために、わからないことはわからないと言いましょう
- ギャップを知るために、わからないことがあったら聞きましょう
- ギャップを埋めるために、第三者の意見・視点を取り入れましょう
今私は、わからない知識ははわからないといいますし、同時に調べ、質問もします。
なぜそういう考えなのかわからないと聞きもします。
また、何かをする際には他者からレビューを受けることを心がけています。
この記事も、職場の先輩によるレビューを数回受けています。
人に聞こうと見てもらおうと、褒められこそすれ怒られないのが「新人」です。
言葉の殴り合いに至る前に、出来ることはあります。
思考とその過程を話し合い、第三者の視点を取り入れ、妥協・譲歩できないか検討しましょう。
ほら、ギャップはあなたの足元にも…。
リンク
- 開発アプリケーションの説明記事
- 開発アプリケーションのGitHubリポジトリ
- 「GLEAN」