概念がある事で、ソフトウェアの階層を綺麗に分離した設計で作る事が簡単にできます。使って開発する事が注目されています。使用しましたが、違った言語を使用してSpring開発をしている事に大変興味を持ち、モチベーションが向上しました。使っていてシステム変更の容易さや拡張性、システムの安定性に優れているなと強く感じました。簡単に開発できるので、まだ使った事の無い方や、同じ新卒の方も興味があれば是非使ってみて下さい。spring.io以上の点を踏まえて、私たちの開発では以下の図のようなシステム構成をしました。開発ではサーバーを建てず、全てローカル内で実行しました。介してデータの取得しています。学習していましたのでそちらを採用しました。コンストラクタなど冗長なコードが多数存在する為、何度も同じコードを書く面倒さがあり、コーディングの負担になると考えていました。呼ばれるオープンソースのライブラリを採用し、冗長なコードを簡潔にした事で劇的にコーディング量を減らす事ができました。個人開発との違い個人開発との最大の違いは、メンバーで作業を分担するので開発規模を個人開発よりも大きく出来る点です。様々なスキルや特色を持ったメンバーが集う事で、意見を集約し、新しい技術の導入も期待できます。メンバーが増える一方で、コミュニケーションをスムーズに取る事が難しくなります。課題の共有、進捗、スケジュール管理など、コミュニケーションを円滑に進める事が無駄なコストの削減へ繋がります。私は開発の中で、チームの目的を振り返る事を一番心掛けていました。チームの目的を統一させる事で、チームは益々良い方向に変わると思います。結論、コミュニケーションは必要不可欠なものなのです。メンバー間の関係性がどれだけ良くても、相互理解がなくては不安は確実に生まれます。それをメンバー全員に一度は発言する機会を設けるなど、意図的にコミュニケーションを増やす事でフラットな環境を作り上げていくことが大切だと感じました。苦労した点ウォーターフォール開発プロセスの難しさウォーターフォールではこの図を意識しながら開発・テストを行います。このプロセスの問題点は最初にしか要件定義ができない事です。万が一、仕様の変更が発生すれば工期の延長は免れず、開発者の負担も増大します。故に、ユーザの意見を取り入れにくい手法とも言えます。その弱点を補い、仕様や設計の変更を行う事を前提に開発をするプロセスがアジャイル開発です。アジャイル開発では、以下の図の様に開発全体を2週間程度に細区分し、イテレーション(Itreration)と呼ばれるサイクルを繰り返しながら開発を進めます。その様に進める事で、途中の変更にも臨機応変に対応する事が可能です。「アジャイル開発で行えば良いのでは?」と思い、調べてみましたが、そんな単純な話ではなく、開発手法と言うのは一筋縄ではいかないものであると感じました。ユーザの意見を頻繁に取り入れる事は、はじめに想定していた見積もりから乖離し、費用が膨らむ事で、赤字のプロジェクトになるリスクもあります。この手法自体が開発者全員に適している訳では無いので、パフォーマンスが落ちるメンバーがチームに多数存在する可能性もあります。開発プロセスとは"目標を達成するための手段"でしかないと言う事は常に認識しておくべきです。本来、TLと兼任する事は非常にリスクの大きい事ですが、私がPMを引き継ぐと言う異例の事態が発生しました。この時が私の研修中、最も精神・肉体的疲労がピークに達した瞬間でした。この両方の役割の兼任を経験して、学んだ事は2点あります。自分を信じないPMと兼任する事は想像以上にやるべき事が多かったです。私はつい自分が頑張って何とかしようと思ってしまいがちなのですが、PMはプロダクトを成功に導く事が全てです。その為、無理な場合はそれを認める事が大切であると実感しました。1人の遅れが全体に影響してくるので、頼れる所はどんどん頼る事で上手く回り始めました。自分の開発スピードを常に把握しておく自分のエンジニアリングに対しては普段よりも余分に見積もるべきです。私も当初は、「定義さえしてしまえば後は専念できるな」と考えていましたが浅はかでした。PMを兼任する人はどの程度の開発スピードを自分がだせるのかを常に把握しておくべきだと感じました。兼任をしていると時間の確保も難しくなるのである程度の裁量をメンバーに与える、共有やミーティングの時間は決まった時間に行う、など無駄な時間を減らす事で効率良く回せるようになりました。以上の事を踏まえ、PMとTLを兼任する事は大きなプレッシャーを感じながら進め様々な困難がありましたが、最後までやり遂げた瞬間の達成度や喜びは格別で、私にとってもこの経験は大きな自信になりました。まとめ今回は、「チーム開発」での経験について書かせて頂きましたが、個人開発同様にコミュニケーションを取り合う事は必須です。私も今回の開発では、幾度となくメンバーと衝突をし、情報共有の難しさを痛感しましたが、コミュニケーションを取る事で相手の状況や課題も明確にする事ができました。今回はTLも兼任していたのでサービスの細かい部分までコミットでき、メンバーと協力して細部まで拘る事でより良いプロダクトにする事が出来たと思っています。私はエンジニアリングに注力しすぎると自分の視野が狭くなり、先の事まで意識が向かなくなりPMとしての役割が十分に果たせていない瞬間が度々ありました。その点は、臨機応変にエンジニアリングの役割や担当する範囲を柔軟に変えていく事が重要だと感じました。「視野が狭くなる」点は普段からもよく指摘されているので、今後も念頭に置いて行動していきます。最後に、チーム開発ではよりユーザを意識して開発に取り組む事ができました。私は、チーム開発も個人開発も、誰に満足して貰いたいのかを常に意識し、開発をするメンバーも含め皆が満足感を得る事ができるように進めていく事が大切であると考えています。これは開発に限らず、誰かと何かを成し遂げる為には必ず必要な要素だと思いました。この経験を糧に、私は皆をワクワクさせるものを創り上げられるようにしていきます。こんにちは、アプリ開発を担当しております青沼です。仙台オフィス瀬上です。#iosdc初めまして、はんだと申します。#DroidKaigiこんにちは。7はてなブログをはじめよう!vm_creatorsさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。