チームが機能するってどういうこと？プロジェクトの状況に合わせてエンジニアが自ら考え役割分担した話
マンハッタンコードでエンジニアをしてるJ.J.🤟こと図師です。
当記事では、マンハッタンコードがSESの現場でどういったことをしてきたのかをほんの一部ご紹介します。併せてこの記事で弊社の独自サービスである、通称「ADS」の実態を感じ取ってもらえると更に嬉しく思います。
当記事で取り扱う案件
前回記事にプロジェクト概要が記載されています。まずは以下の記事を読んでいただくと、より全体像がイメージできるかと思います😆
時間がない人向けに案件概要を記載しておきます。
・Flutter案件
・アプリ基盤と主要機能はできている
・不具合改修はこれから
・追加したい機能要件がまだある
・ストアリリースまでやってほしい
取り扱う内容
案件概要の「追加したい機能要件」の開発にフォーカスをあててお話ししていきます。
どういった機能を追加したのか
いくつかあるのですが、今回の追加機能開発のメインは「投げ銭機能」でした。投げ銭というとアプリ内課金を想像する方もいると思いますが、仕組みとしてはサービスで管理しているユーザーの所持ポイントを消化して飲食店を応援できるといった仕組みです。
当案件での投げ銭機能を実現するには以下の実装が必要でした。
・画面数は新規が５、改修が１の合計６画面
・APIは新規で３本
デザイン指示書は後追いで来るためワイヤーフレームをベースに見積り・実装・テストをしていき、あとからデザイン反映をするような流れです。
弊社の委託元となるクライアントにバックエンドエンジニアとデザイナーがいるのでその方とコミュニケーションを取りながら進めました。
どのように対応したか
この案件には私とSallyの２名チームでアサインしていました。進め方について話をして、リリース日が近かったこともあり「スピード重視作戦」で進めることにしました。
月の契約稼働時間としてマスターエンジニアが40%・メンバーエンジニアが100%といったご契約プランでした。
稼働できる時間に制限もあるので、それぞれの得意を生かすような形で以下のように役割分担をしました。
マスター
APIのつなぎ込みとロジック実装を担当
主にバックエンドとコミュニケーションを取る
メンバー
ワイヤーに沿って画面実装と画面遷移を担当
主にデザイナーとコミュニケーションを取る
１機能完成までのざっくりフロー
正確に伝えるのが難しいのですが、API1本に対してこのフローを3回まわすような形で進めました。1画面1APIで機能が完成する場合には1人でやってしまっても良かったかもしれませんが、仕様が複雑だったり画面数も多かったことからうまく役割を区切って効率良く進められました。
もっと詳細なフローや出来事をお伝えしたいのですが、ここでは長くなってしまうので、話を聞きたい方は直接会いに来てください(笑)
まとめ
弊社では２名以上のチーム提案をしているのですが、プロジェクトの状況に合わせてベストな形で役割分担をして開発を進めていきます。個人のマンパワーではなくチームとして動きます。
また、社員同士で同じプロジェクトを何度か一緒に乗り越えてきていることもあり、どの案件にアサインしても新規案件にありがちな「初期コスト」がかからずにすぐに開発に着手することもメリットかなと思います。
予算の関係なども勿論あるのですが、チーム提案が受け入れられない会社さんもたまにいらっしゃいます。実際に一緒にお仕事をしてみないとその人・そのチーム・その会社の働き方というのはわかりません。当記事ではその一部をご紹介しました。最後まで読んでいただきありがとうございました😆
チーム提案のメリットは他にもあるので、他案件の事例などを題材にまた記事を書いてみようと思います。
スキください❤️
宣伝
お仕事のご相談・ご依頼
マンハッタンコードは、スマートフォンアプリの開発に特化しております。エンジニアリングから、デザイン、プロジェクト推進などアプリ開発を総合的に請け負うことが可能です。
弊社のホームページからお問い合わせください。
弊社の事業についてもう少し詳しく知りたい方はこちらをご覧ください。
採用情報
マンハッタンコードが求める人物像の記載がありますので、就職活動中の方は是非読んでみてください。
お問い合わせの際には「noteの記事を読みました！」と一言入れていただけると嬉しいです！