【2022年 新入社員研修：中編】本格的に困難続きの開発がスタート！！

こんにちは！KDLの吉田です。

立ち上げレビュー、第1回報告会 を経て模擬開発研修で実際に開発していくプロジェクトの概要がつかめてきました。既に最終発表まで9日と期限が迫っているので、急ピッチで開発を進めていきます！！ 

私たちが模擬開発研修で作成しているシステムは、KDLの新卒採用管理システム、「KDL ATS（Applicant Tracking System = 採用管理システム）」です！模擬開発研修ブログ二本目の本編では、開発の中盤に対応した以下4点についてご紹介します。

• 　クライアントの意見を形に
• 　技術選定について
• 　システムの大幅な仕様変更
• 　締め切りまでに完成できる？？

クライアントの意見を形に

システムの概要がつかめてきたところで、開発メンバーとクライアントがイメージを共有するためのツールとして「Adobe XD」を導入しました。と同時に、完成イメージを共有し開発をスムーズに進めるために、ワイヤーフレームの作成に取りかかりました。

ワイヤーフレームとは、Webページのレイアウトやデザインの大枠を定める設計図のようなものです。最終的にどのようなデザインになるのか、クライアントや開発メンバーがおおざっぱな認識を合わせるために使われます。
今回注意した点は、開発メンバーとの共通認識を深めながら、ワイヤーフレーム作成→改善のサイクルを繰り返したことです。
ワイヤーフレームはシステムの表面（見た目）の部分になるので、デザインだけを意識して作成してしまうと、開発メンバーが実際にプログラミングをする際に、「デザイン的には理解できるけど、裏（システムの動作）はどうなっているの？？」といった不明点が出てきてしまいます。それを防ぐため、ワイヤーフレームを作成しては開発メンバーに確認し、不明点を解決！する順序で進めました。

これまで個人でワイヤーフレームを作成したことはありましたが、複数人で共有する機会は初めてです。ワイヤーフレームを開発メンバーやクライアントとのミーティングで利用するタイミングの多さに驚きました。ワイヤーフレームはデザインの大枠とは言っても、少しでも不可解な部分やスケジュールの問題があると共通認識にズレを生むため、ミスがないよう入念に確認しながら作成・編集をしなければならない影響範囲の広いものだと感じました。

ユーザーが直接操作する画面部分（フロントエンド）に関しては、クライアントの要求事項を満たすために、5つの工夫を行いました。

1. 従来の管理方法であるExcelの見た目や使い勝手はそのままに、一覧で候補者を閲覧できる表ベースを採用！
2. ログイン中のユーザーを判別するため、「[email protected]さん、こんにちは」という形式で、ユーザーのメールアドレスを常時表示！
3. 代理でのデータの登録・編集ができるよう、入力画面の登録者・編集者の設定を任意項目に！
4. 卒業年度は現在を基準に候補を自動表示。よく選択される候補年度が上位表示されるように！
5. 必須項目や入力形式は自動入力チェック機能で、ユーザーの入力ミスを軽減！

この5つの要素を加えることで、クライアントにとってより使い勝手の良いシステムを実現できると考え開発を進めていきました！！

技術選定について

使用技術については、今回初めて使用する技術も多く、わたしたちにとって大きな挑戦になったと思います。

技術の大枠を二つに分けると、フロントエンドとバックエンドに分けられます。
フロントエンドは、ユーザーがシステムを利用する際に表示される画面を構築していく役割、バックエンドは、システムのデータベースやサーバーといったユーザーからは見えない部分（裏側）の設定を行う役割を担っています。

模擬開発研修で利用する技術の選定にあたって、私を含めたフロントエンドチームは実装経験のある人が多い技術を優先的に採用しました。それに対し、バックエンドチームは、ほぼ全ての技術が初めての実装という男気ある選択をしていました。

今回フロントエンドで採用した技術は、内定者期間のKDLでのアルバイトで実装経験がありました。模擬開発研修が始まる前は、何も知らない技術に触れることになったらどうしようと不安に思っていたので、気持ちが少し楽になりましたが、研修中に間接的に新しい技術に触れるうち、新しい技術に挑戦したかったなという思いも出てきました。
しかし、今回のフロントエンドの技術を初めて経験するメンバーに何か少しでも伝えられることがあればいいなと思い、研修に取り組みました。

システムの大幅な仕様変更

模擬開発研修も中盤に差し掛かり、緊張の第2回報告会がやってきました！！
発表内容は、クライアントから受けた依頼について、経緯やクライアントの要望、現段階の進捗状況、今後の課題です。全員が発言するというルールのもと、発表は無事に終了しました。
発表後、KDLの生産技術チーム・KDX(KDL社内のDXを推進するチーム)の方々から、発表の導入部分の説明が理解しやすい構成になっていてよかったと褒めていただき、自分が担当していた所だったこともあって、とても嬉しかったです。

一方でフィードバックの際に、「本当にそれが必要な機能かクライアントに聞いた方がいい」というご指摘をいただきました。
私たちが考えていた設計は、「やらなければならないこと」と「やりたいこと」の区別が出来ておらず、開発期間に対してオーバースペック気味になっていたのです。自分たちでは気づけていなかったのですが、そのフィードバックをいただけたことで今後の課題と進め方について考える機会になりました。

改めてどんな機能をどの段階まで作り込むのかを新入社員で話し合い、考えていた理想のシステムから、現実的に必要な機能を備えたシステムへと計画を修正しました。その中でも、後々データ分析で使用できるデータを取得する機能は残すなど、”模擬開発研修で作成したシステム”ではなく、実際に業務で利用する際に必要となる部分は絶対に残すという方針で、クライアントの必須要件を満たしつつ妥協点を探し、細かい所まで話し合いました。

仕様変更を行ったことに伴い、エンドポイント・データベース・フロントエンドのデザインなどが変更になりましたが、それぞれが関わっている箇所に応じて認識違いが起きないように個別で話し合いを行い、ドキュメントの書き換えや、コード修正を迅速に行いました。

この仕様変更のために、一旦皆が手を止めて話し合う時間を取ったのですが、それぞれで気になるポイントが違い、「それ前にも同じこと言った〜〜！」など色々な意見が出て、個人的にはとても楽しかったです。そして、意見のぶつけ合いをできるだけラフに行いたかったので、あえて関西弁でホワイトボードに意見を書き、笑いながら時間を過ごせたことで意見や質問が言いやすい雰囲気だったのではないかなと思います。

翌日に変更点に関する認識を合わせるためにクライアントとの会議を開催。仕様変更の説明や、今後のデータ分析のために、どのデータをどのような形で持っておくかについても話し合いました。クライアントから「その仕様で大丈夫です」という言葉をいただき安心することが出来ました！
今回の会議は機能を減らした提案を行ったので、クライアントにマイナスな印象を与える会議だと個人的には感じていたのですが、仕様変更後のシステム案を採用してもらえたことで、クライアントが望んでいるもの全てを開発するだけではなく、期間や必要機能を自分達でも考え、提案することがシステム開発において重要だと感じました。

締め切りまでに完成できる？？

仕様変更により、作業量は大幅に減少しましたが、今回初挑戦した技術も多く、開発期間中、安心できる時間がほとんどありませんでした。順調にシステムが動作すれば30分で終わる作業も、エラーが出て、解決するのに3時間を要することもありました。

模擬開発研修中は、初めてのことだらけで時間に追われながら対応していくという日々を過ごしていました。その中でも、先を見越したスケジュール管理の重要性と大切さを痛感することが多かったです。全体のスケジュールを想定できていなければシステム開発の規模感を導き出すことも難しく、クライアントへの提案も不安定なものになってしまいます。慎重に計画を立てて土台を固めた上で、全力疾走することは安心感もあり、効率も良いのではないかと感じました。

今回は、初日から全力疾走してしまったこともあり、後になって仕様変更が発生するという事態になってしまいました。最終発表も迫っており、新入社員全員が完成するのかどうかの確信が持てず、不安な気持ちを抱えていましたが、期間内に完成させたいという想いは新入社員全員が持ち続けて開発に挑んでいたのではないかなと思います！！

次回のブログは開発終盤から最終発表の内容を杉山さんが担当します。お楽しみに〜〜！