こんにちは。VP of Engineeringをしている里山です。
今回のCREATORS BLOGも、新卒社員に研修での体験などを紹介してもらいたいとおもいます。 前回に引き続き、今回もプロジェクトフォーカスラーニング研修の続編を新卒の仲間から紹介してもらいたいとおもいます。
プロジェクトフォーカスラーニング（チーム開発編）
こんにちは。19新卒入社の岡本です。
前回の「個人開発編」に続き、今回は「チーム開発編」と題して私が経験した事を話します。私は情報系の大学を卒業していますが、学生時代は個人開発しかやってきておらず、チーム開発は初めての挑戦でした。
本記事では、その経験から得た知識を元に、私が考える「理想のチーム開発とは何なのか」についてご紹介できたらと思います。
チーム開発とは
今回のチーム開発(以下、開発)では、「仮想クライアントからの要望を受け、チームでソリューションを作る」事を目指しました。
QCD (品質：Quality, 価格：Cost, 納期：Delivery) を意識するのは勿論の事、以下の3点を実践・経験する事が目的です。
- ウォーターフォールモデルでのシステム開発
- 個人開発で培った、ゴール設定や作業タスクの洗い出し、優先度付けなどの知識の活用
- クライアントの要望に応えながら、新規機能を追加し、バージョンアップを行う
また、演習における開発は以下のスケジュールに沿って進められました。
研修では全部で10チーム程あり、他チームが仮想クライアントとして私たちに依頼をしてきました。 今回、私たちのチームに依頼したクライアントの概要・要件は以下の表になります。
| 項目 | 内容 |
|---|---|
| クライアント名 | こがね大学 (仮称) |
| 学生数 | 3万人程度 |
| 依頼内容 | 大学図書の蔵書管理をデジタル化したい |
| 依頼の背景 | これまでは司書が複数人体制で管理をしてきたが、負担増加により管理する事が困難になった |
| 現在の蔵書数 | 10万冊以上 |
以上の要望を受け、私たちのチームでは
- 司書の負担軽減
- 蔵書の一元管理化
の2点を考慮したシステムの開発をしました。
では、次に開発をする上での重要な点について説明します。
開発プロセス
前述にある通り、今回の開発手法はウォーターフォールです。ウォーターフォールでの最大のメリットは、全体的な計画を立てやすい点が挙げられます。開始時に要件を定義し詳細に落とし込む為、最初にやるべき事が何なのかを明確にでき、スケジュールを立て易くします。
このモデルでは、以下のプロセスからなります。
- 基本計画：システムの目標や実現可能性の調査、分析
- メンバーの選定と役割の確定 (後述参照)
- 要件定義：利用者がシステムに求める事を定義
- 外部設計：利用者目線でのシステム設計
- 内部設計：開発者目線でのシステム開発
- コーディング：モジュールをプログラミング言語で記述し単体テスト
- テスト：動作検証
- リリース・保守・運用：システムを動作させ業務を遂行
また、「コーディング」プロセスの折り返しとして、左側に設計、右側にテストを配置した下記の"V字モデル"が特徴です。
メンバー選定と役割
研修ではメンバーは5 ~ 6人編成、役割は講師による指名でしたが、一般的にはプロジェクトを成功に導けるメンバーを選定します。その中でも重要な1人は、プロジェクトマネージャー(以下、PM)と呼ばれるプロジェクトの管理者です。自分がコーディングをするのでは無く、進捗管理や工数管理などプロジェクトが円滑に進むように管理をする役割です。
また、クライアントとのやり取りやプロダクト変更に対する見積もり作成など、チームの表に立って外部とのコミュニケーションを取ります。PMは、チームのメンバーが動きやすいような環境を作る事が役割と言っても過言ではありません。その他にも役割は様々あり、開発規模によって大きく異なります。
今回の開発では以下の役割を設置しました。
| 略称 | 正式名 | 役割 |
|---|---|---|
| PM | プロジェクトマネージャー | プロジェクトを取りまとめる |
| TL | テクニカルリーダー | 技術面でチームのスキルアップを図る |
| DL | ドキュメントリーダー | 日々、作成されるドキュメントや納品物を管理する |
その他のメンバーはPM・TL・DLの作業負担が上らないように設計や開発を進めサポートします。役割が無くても自分の持ち場に責任を持って行動することが大切です。
私は今回 TL の役割を担い、チームを技術面から支える事に注力しましたが、チーム全員がコミュニケーションを取る事で円滑に開発を進める事ができました。
技術選定
今回の開発では前提条件として、以下の4点があります。
- Spring Frameworkの使用
- Java 言語の使用
- データベース (PostgreSQL) の使用
- Git を使用したバージョン管理
Spring Framework (以下、Spring)は、Java のWebアプリケーション開発で最も使用されているフレームワークです。
Spring の特徴はコンテナです。コンテナの機能の1つに DI (Dependency Injection) があります。DIとは「依存性の注入」と言われ、DI の概念がある事で、ソフトウェアの階層を綺麗に分離した設計で作る事が簡単にできます。
弊社のサービス・リニューアルでは、サーバーサイドを Kotlin と Spring を使用しています。Spring は Java 言語で開発する事が一般的ですが、最近ではコード量の少ない Kotlin を使って開発する事が注目されています。研修では Java を使用しましたが、違った言語を使用してSpring開発をしている事に大変興味を持ち、モチベーションが向上しました。
私自身、開発中に Spring を使っていてシステム変更の容易さや拡張性、システムの安定性に優れているなと強く感じました。STS (Spring Tools Suite) を使用すれば、Spring で簡単に開発できるので、まだ使った事の無い方や、同じ新卒の方も興味があれば是非使ってみて下さい。
以上の点を踏まえて、私たちの開発では以下の図のようなシステム構成をしました。
開発ではサーバーを建てず、全てローカル内で実行しました。 また、データの永続化には Spring Data JPA を使用し、PostgreSQL を介してデータの取得しています。ビルドツールは、個人開発では Gradle を使用していましたが、研修では Maven で学習していましたのでそちらを採用しました。
さらに、Java 開発では setter / getter やコンストラクタなど冗長なコードが多数存在する為、何度も同じコードを書く面倒さがあり、コーディングの負担になると考えていました。
そこで、私たちのチームでは Lombok と呼ばれるオープンソースのライブラリを採用し、冗長なコードを簡潔にした事で劇的にコーディング量を減らす事ができました。その他、フロントエンドのデザインを比較的簡単に整えられる Bootstrap なども採用しました。
個人開発との違い
個人開発との最大の違いは、メンバーで作業を分担するので開発規模を個人開発よりも大きく出来る点です。様々なスキルや特色を持ったメンバーが集う事で、意見を集約し、新しい技術の導入も期待できます。
しかし、メンバーが増える一方で、コミュニケーションをスムーズに取る事が難しくなります。課題の共有、進捗、スケジュール管理など、コミュニケーションを円滑に進める事が無駄なコストの削減へ繋がります。
私は開発の中で、チームの目的を振り返る事を一番心掛けていました。チームの目的を統一させる事で、チームは益々良い方向に変わると思います。結論、コミュニケーションは必要不可欠なものなのです。メンバー間の関係性がどれだけ良くても、相互理解がなくては不安は確実に生まれます。それをメンバー全員に一度は発言する機会を設けるなど、意図的にコミュニケーションを増やす事でフラットな環境を作り上げていくことが大切だと感じました。
苦労した点
ウォーターフォール開発プロセスの難しさ
ウォーターフォールではこの図を意識しながら開発・テストを行います。
しかし、このプロセスの問題点は最初にしか要件定義ができない事です。
万が一、仕様の変更が発生すれば工期の延長は免れず、開発者の負担も増大します。故に、ユーザの意見を取り入れにくい手法とも言えます。その弱点を補い、仕様や設計の変更を行う事を前提に開発をするプロセスがアジャイル開発です。
アジャイル開発では、以下の図の様に開発全体を2週間程度に細区分し、イテレーション(Itreration)と呼ばれるサイクルを繰り返しながら開発を進めます。その様に進める事で、途中の変更にも臨機応変に対応する事が可能です。
では、「アジャイル開発で行えば良いのでは？」と思い、調べてみましたが、そんな単純な話ではなく、開発手法と言うのは一筋縄ではいかないものであると感じました。
ユーザの意見を頻繁に取り入れる事は、はじめに想定していた見積もりから乖離し、費用が膨らむ事で、赤字のプロジェクトになるリスクもあります。更には、この手法自体が開発者全員に適している訳では無いので、パフォーマンスが落ちるメンバーがチームに多数存在する可能性もあります。
つまり、開発プロセスとは"目標を達成するための手段"でしかないと言う事は常に認識しておくべきです。
PMとの兼任
本来、TLと兼任する事は非常にリスクの大きい事ですが、私がPMを引き継ぐと言う異例の事態が発生しました。正直、この時が私の研修中、最も精神・肉体的疲労がピークに達した瞬間でした。
この両方の役割の兼任を経験して、学んだ事は2点あります。
1. 自分を信じない
PMと兼任する事は想像以上にやるべき事が多かったです。私はつい自分が頑張って何とかしようと思ってしまいがちなのですが、PMはプロダクトを成功に導く事が全てです。その為、無理な場合はそれを認める事が大切であると実感しました。1人の遅れが全体に影響してくるので、頼れる所はどんどん頼る事で上手く回り始めました。
2. 自分の開発スピードを常に把握しておく
自分のエンジニアリングに対しては普段よりも余分に見積もるべきです。私も当初は、「定義さえしてしまえば後は専念できるな」と考えていましたが浅はかでした。PMを兼任する人はどの程度の開発スピードを自分がだせるのかを常に把握しておくべきだと感じました。兼任をしていると時間の確保も難しくなるのである程度の裁量をメンバーに与える、共有やミーティングの時間は決まった時間に行う、など無駄な時間を減らす事で効率良く回せるようになりました。
以上の事を踏まえ、PMとTLを兼任する事は大きなプレッシャーを感じながら進め様々な困難がありましたが、最後までやり遂げた瞬間の達成度や喜びは格別で、私にとってもこの経験は大きな自信になりました。
まとめ
今回は、「チーム開発」での経験について書かせて頂きましたが、個人開発同様にコミュニケーションを取り合う事は必須です。私も今回の開発では、幾度となくメンバーと衝突をし、情報共有の難しさを痛感しましたが、コミュニケーションを取る事で相手の状況や課題も明確にする事ができました。また、今回はTLも兼任していたのでサービスの細かい部分までコミットでき、メンバーと協力して細部まで拘る事でより良いプロダクトにする事が出来たと思っています。
また、私はエンジニアリングに注力しすぎると自分の視野が狭くなり、先の事まで意識が向かなくなりPMとしての役割が十分に果たせていない瞬間が度々ありました。その点は、臨機応変にエンジニアリングの役割や担当する範囲を柔軟に変えていく事が重要だと感じました。「視野が狭くなる」点は普段からもよく指摘されているので、今後も念頭に置いて行動していきます。
最後に、チーム開発ではよりユーザを意識して開発に取り組む事ができました。私は、チーム開発も個人開発も、誰に満足して貰いたいのかを常に意識し、開発をするメンバーも含め皆が満足感を得る事ができるように進めていく事が大切であると考えています。これは開発に限らず、誰かと何かを成し遂げる為には必ず必要な要素だと思いました。
この経験を糧に、私は皆をワクワクさせるものを創り上げられるようにしていきます。
