【新人研修】チーム開発研修を通して、働く上で必要なことが見えてきた話
はじめまして、新入社員の乘松です。
人財開発課の野﨑さんから、
「技術研修で行った、チーム開発研修のレポート記事を書いてくれ」
と無茶振りを言われました。
無茶振りには理解のある野﨑さんだと思っていたのですが、全然学んでなかったみたいです。
断るという選択肢は残されていない私は、引き受けることにしました。
こういうブログっぽい記事を書くのは実に中学生ぶりです。10年ちょっと前はブログ流行ってましたよね~
文章を書くのは苦手な自分ですが、頑張って書きます!
チーム開発研修とは…
〈概要〉
チーム開発研修は、技術研修(プログラミング研修)のカリキュラムの一つです。
6人でチームを組み、共同で一つのアプリケーションを作成していきます。
それまでの技術研修で培った、プログラミングの知識を生かしてアプリ開発を行います。
今回のチーム開発研修では、Java Servletを使ったWebアプリケーションを作成しました。
〈目的〉
研修配布資料によれば、チーム開発研修の目的は以下の通りです。
〈研修の流れ〉
ウォーターフォールモデルについて理解する
要件定義書、設計書の作成を体験する
講師が作成した設計書をもとに製造を行う
試験工程を体験する
成果物を発表する
本研修では、図の①~⑥までの工程を実施します。
チーム開発研修日記
研修を振り返りながら、日記のように研修での出来事やその時の自分の考えなどを綴っていきます。
少々長丁場ですが、最後までお付き合いください。
0日目 乘松、チームリーダーになる。
同期の中で技術研修の進捗が最も早かった私は、当然のようにチームリーダーになった。
チームリーダーとして、
メンバー全員が活躍できるように仕事を割り振ったり、
こまめに進捗を確認したりして、
有意義な研修にするぞ~、と思った。
明日からの研修が楽しみである。
1日目 はじめが肝心、要件定義。
まずは講義が行われ、
チーム開発のキホンのキが教えられた。
2時間ほどで講義が終わり、チーム開発に移った。
今回の研修では、カレンダーアプリを作成することになった。
チーム開発研修の初日は、オープンソースのカレンダーシステムを参考に、
「こんな機能を追加したら良いのでは?」
「この機能は使いにくい、こう変更して使いやすくしよう」
といった視点で、まずは実装できるかは度外視して自由な発想で機能提案書を作成した。
初日は個人作業だった。
実際の開発では、仕事を受注できるかを決める重要な工程である。
お客様の目線で使いやすいシステムを考えることが大切だと思った。
2日目 最も重要?設計工程。
1日目に考えた機能提案を実現するための設計を行った。
データベースに用意すべきテーブルやカラムは何か
画面にはどんな要素をどのように配置するか
画面遷移はどうするか
入力フォームから受け取るデータは何か、name属性はどうするか
etc…
この日も個人作業だった。
クラス名やメソッド名、その他変数名まで、この段階で決める。
設計が甘く、開発工程に入ってから後戻りしてメソッド等を追加する必要が出てくると、複数人で書くコード同士で齟齬が生じるのは必至だろう。
そのため、ウォーターフォールモデルのチーム開発において、設計工程は最も重要な工程だと言っても過言ではないと感じた。
3日目 製造開始。チーム開発のキモはコミットにあり!?(製造1日目)
いよいよチームでの作業が始まった。
講師から渡された設計書とWBSに従って、各々がコーディングを始めることになった。
まずはカレンダーアプリの基本機能として、予定の新規作成、参照、編集、コピー、削除の機能を作る。
人によっては、研修の進捗的にServletを学んでいなかったり、Webアプリケーション作成演習をやっていなかったりした。
そういった経験不足から、私のチームのメンバーをはじめ、多くの同期が
「設計書読んだけど、何をすればいいのかさっぱり分からん」
という状態になっていたのが印象に残っている。
しかし、その人たちも「何も分からないんだけど」というのを、私や講師に聞いて、とりあえず何から始めればいいのかを理解できているようだった。
やることが分かってからは各自順調に作業を進め、この日のうちに担当の作業を完了したメンバーもいた。
多くのメンバーがServletやWebアプリの構成などはほとんど理解できていなかったはずだが、自分のやるべきことを理解してよくやってくれているな~と思った。
製造工程1日目で、自分も担当機能をとりあえず実装することができた。
処理自体は書けたが、画面の見た目は全く作れていなかったので、翌日はCSSを書くところから始めることにした。
また、チームでバージョン管理を行う経験もほとんど初めてだった。
バージョン管理システムで適切にコードを共有することも、チーム開発研修で学ぶべきことだと思った。
きちんと動くコードが書けたら適宜コミットするよう、初日からメンバーに周知徹底した。
みんな競合の解決で苦戦していましたが、やり方を覚えて少しずつ慣れていってもらえればと思った。
初日からメンバー全員がコミットしていたのは、たぶん私たちのチームだけだったと思う。
チームでファイルの編集履歴を蓄積する認識を共有できていたことが、順調にチーム開発を進められた要因の一つだと感じた。
4日目 チームリーダーの難しさ。自作業と指示のバランス(製造2日目)
初日に引き続いて、基本機能の作成を進めた。
個人の作業としては、前日の計画通り、画面の見た目を整えることができた。
また、ユーザーが使いやすいように、JavaScriptでセレクトボックスを動的に変更するコードも追加した。
具体的には、日付を選択するセレクトボックスで、選んだ年月に応じて日の最大値を変化させるようにした。(2月31日などが選べないように)
これまでの研修で、フロントエンドの開発はほとんどやってこなかったが、ユーザーの使用感に直接影響するという点で楽しかった。
一方、チームメンバーは「よく分からん」と言いながら、それぞれの担当機能と格闘していた。
特に、予定の編集画面の表示と遷移の処理で進捗が滞っているようだった。
さて、初日で担当作業を完了したメンバーもいた、という話をした。
すなわち、苦戦している人と、自分の作業が終わって手持ち無沙汰な人がいたということである。
とはいえ、それ以上作業を分担するのも難しかったため、作業量に偏りがあるまま開発が進んでしまった。
リーダーとしてうまく仕事を割り振ることができればよかったのだが、自分自身の作業に集中したかったこともあり、それができなかった。
この日で自分の作業が一段落したので、翌日は作業が詰まっているメンバーのサポートをしようと思った。
5日目 結合とバグ、そして放任(製造3日目)
進捗が滞っていたメンバーの状況を確認し、コーディングの指針を伝えた。
その後、無事全員が担当箇所のコードを書き終え、結合テストを行える段階になった。
結合テストを実施すると、当然さまざまなエラーが出てきた。
今回は単体テストを実施できていなかったこともあり、単純なミスが多くあった。
設計書に従ってコードを書いたつもりでも、結合するまでバグに気付きにくいことがあり、Webアプリ開発の難しさを感じた。
バグの原因はエラーログから容易に特定できたので、コードの修正は難なく完了した。
そんなこんなで結合テストからのバグ修正を経て、基本機能の作成が完了した。
基本機能ができたので、次は追加機能の作成に着手した。
1日目の提案書作成でメンバーが考えた機能をもとに、講師が設計書を作成してくれており、
私以外のチームメンバーはその設計書に従って、以下2つの追加機能を作っていくことになった。
予定の検索機能
簡易的な掲示板機能
私はというと、
「ユーザー登録とログイン機能を作ってください。設計書はないので自由にやってもらえればOKです」
というざっくりした指示のもと、追加機能の作成に入った。
6日目 チーム開発、軌道に乗る(製造4日目)
前日に続いて、追加機能の実装に取り組んだ。
自分の担当機能については、とりあえずユーザー登録とログインするだけの機能は実装できた。
しかし、ゲストユーザーに対してアクセス制限をかけるような処理は実装できていない。
翌日はそのためのコードを書くことにした。
他のチームメンバーも、試行錯誤しながら追加機能の実装に取り組んでいた。
追加機能に入ってからは、たまに質問を受けるくらいで、細かい作業進捗は把握できていなかったが、少しずつ完成に向かえているようだった。
7日目 決死のデバッグ(製造最終日)
あっという間に製造工程最終日がやってきた。
前日の課題だった、ログイン状態に応じたアクセス制限処理を追加し、無事ログイン機能が形になった。
チームメンバーが開発していた検索機能と掲示板機能も完成した。
期限までに与えられた課題をクリアすることができ、一安心だ。
が、結合テストを実施してみると、やはりバグはあるもので……
製造工程最終日はデバッグに奔走することになった。
チームメンバーが熱心にバグを見つけてくれたおかげで、自分はデバッグ作業に集中できた。
見つかったバグを取り除き切った時の達成感はひとしおであった……
8日目 面倒だが重要、試験工程。
製造工程が終わったら、次は試験工程を実施した。
これまでの自分のプログラミング経験は、研究や効率化など自分のためのもので、成果物も自分で完結するものだった。
そのため、とりあえず動けば良いし、バグってたらそれはそのとき、と考えていた。
しかし、仕事の場合、成果物の出来や信頼性をお客様にきちんと示す必要がある。
試験工程は、テストの結果を細かく記録し、要望通りの機能が問題なく動作することを証明するのが目的だ。
研修では、自分たちが作った機能について試験を行った。
試験工程の進め方と試験証跡の書き方を理解することができた。
試験証跡を書いたのは初めてだったが、動作確認の細かい手順を記載したり、動作の様子のスクリーンショットを撮ったり、結構面倒で大変な作業だと思った。
9日目 乘松、盗む(成果発表1日目)
さて、製造に係るすべての工程が完了したので、この日の午前中は成果物の発表に向けた準備に取り掛かった。
また、午後からはいくつかの班が成果発表を行った。
他の班も、それぞれ特徴的な追加機能を実装していたので、発表を聞いていて面白かった。
いいなと思った機能がいくつかあったので、参考にして自分たちのアプリにも機能を追加した。
盗める技術は盗んでおこう。
10日目 放任、そして反省(成果発表2日目)
機能追加が楽しくなっていた私は、発表当日までコードの加筆を行った。
自由にやっていいよって言われたから……(震え声)
発表では、結果的に盛りだくさんになった機能を一通り紹介できた。
今回は、追加機能をスライドではあまり説明せず、デモ実演で説明するという形を取った。
しかし、機能が多かったこともあり、多少グダグダな説明となってしまった。
スライドで説明することを面倒がらず、きちんと準備すべきだったと反省である……
仕事をする上で重要なこと、それは…
チーム開発研修を通して、チームリーダーとしてメンバーの進捗を確認したりサポートしたりしながら、自分の作業も進めることの難しさを感じた。
また、チーム内でコミュニケーションを取ること、またそれをしやすい環境を作ることの重要性を学んだ。
自分はリーダーでありながら、ついつい自分の作業に集中してしまいがちだった。
そんなときでも、メンバーが構わず質問や相談に来てくれた。
そのおかげで、各自作業が行き詰ってしまうことなく、チームとして順調に研修を進めることができたと感じている。
このような経験から、仕事をする上で重要なことは、
①報連相をはじめとしてチーム内でコミュニケーションを取ること
そして、
②普段からコミュニケーションを取りやすい環境を作っておくこと
だと実感した。
乘松より、結びの言葉
最後まで読んでいただき、ありがとうございました。
当初の想定よりも真面目っぽくて、かなり長い記事になってしまいました…
改めて、文章を書くことの難しさを実感しました。
この、チーム開発の研修を通して、短期間で様々なことを学ぶことができました。
個人的には、同期と仲良く話しながら作業ができ、コードもいっぱい書けたので、非常に有意義で楽しい研修でした!
繰り返しになりますが、最後まで読んでいただき、ありがとうございました~
この記事が気に入ったらサポートをしてみませんか?