nktn2

【プロジェクト概要・人数・体制】 不動産管理マッチングプラットフォーム「COSOJI 」の開発 https://cosoji.jp/owner/ フロントエンド：Next.js（3名） バックエンド：Laravel（4名）　※管理画面含む 【自身の役割】 副業で開発メンバーとして参加 ビジネスサイドと直接やりとりし、要件定義から設計、実装、テストまで実施 バックエンドの開発がメインだったが、フロントエンドの軽微な修正、ファイルアップロード機能まわりで一部AWSにも触れた 【プロジェクトの背景・課題】 １．アーリーフェーズのスタートアップでリソース・開発体制共に整っていなかった ２．不動産管理という特性上、地方の屋外で使用されることも多く、通信速度が出にくい中で表示・アップロード速度の高速化が求められた 【課題に対して自身が発揮したバリュー及び成果】 １．プロダクトとしてもPMFを目指すようなフェーズだったので、ビジネスサイドから出てきたアイデアをそのまま作るのではなく、いかに ”小さく作って（または作らずに）検証する” ことができるか、という視点でと擦り合わせて要件に落とし込んだ。 また、バックエンドがメインだったが必要があればフロント・インフラの部分も含めて対応した。 ２．愚直に、①かかる時間の測定、②原因の究明、③対策の仮説、④実施、⑤検証というプロセスを回した。 既存APIから返していた無駄なデータを減らす、必要なリクエストを並列で投げる、アップロードするファイルを圧縮することなど対応した結果、一定の効果は得られた。 また、画像のアップロードが遅い課題に対し、アップロードした後のサーバー側の処理をLambdaなどに任せ、フロントに早くレスポンスを返すことでの高速化も検証したが、開発・その後の保守のコストと見合わないと判断し、見送った。

【プロジェクト概要・人数・体制】 横浜ベイスターズ公式アプリの開発、ユーザ移管 http://www.baystars.co.jp/app/mybaystars/ アプリ：React Native（3名） バックエンド：Express(Node.js) × GraphQL（3名） 管理ツール：Next.js（1名） 【自身の役割】 自分は主に要件定義と設計、バックエンド開発、全体の進捗管理を担当。 【プロジェクトの背景・課題】 １．GraphQLは新しい試みとして採択。 ２．既存の公式アプリ（別ベンダーが運用）からのユーザ移管があったが、クライアントがITに強い会社ではなく、データ構造など仕様に不明点が多かった。 【課題に対して自身が発揮したバリュー及び成果】 １．Typeの設計と初期学習コストはかかったが、SELECT系の処理はクライアント側がqueryを自由度高く使うことができ、シンプルな処理であれば、機能追加、改修の効率は上がった。 ただしmutation系の処理はRESTでやってた頃と対して変わらなかったこと、汎用的なページネーションや複数項目でのソートなど微妙に痒いところに手が届かない感もあり、今後の改善を継続したい。 （ORマッパーのSequelizeのクセに悩まされたこともある。） ２．別ベンダーも含めた調整の打ち合わせを設定し、役割分担と移管フローを事前に入念に詰めた。 特にクライアントの都合上、移管はプロ野球のオープン戦終了後〜開幕前日の3日間の間に完了する必要があったため、必要な工程を整理し、ヒューマンエラー防止のため可能な限りデータのインポート、画像同期などのコマンドを事前に用意した。

【プロジェクト概要・人数・体制】 ドローン関連Webサービスの開発（非公開） webフロントエンド：Nuxt.js（3名） webバックエンド：Ruby on Rails（API）（2名） アプリ：Objective-C（1名） 【自身の役割】 webのフロント、バックエンド両方を担当。 Railsに関しては開発経験もあったのでDBと必要なAPIのエンドポイントを定義した上で実タスクは別メンバーにアサインしてコードレビューと火消しがメインの関わり方。 メンバーの採用も行った。（バックエンド1名） 【プロジェクトの背景・課題】 １．当初はSPAでなく、フロントエンドもRailsで進めていたが、発注元からの要望でバックエンドはAPIとして開発し、フロントは vue.js での開発という注文がきたため方針転換した。 ２．アプリ自体が先行してリリースされており、そこで作ったミッションをクラウドで共有する、というのが主な提供価値。 【課題に対して自身が発揮したバリュー及び成果】 １．フロントエンドのVue.js（Nuxt.js）は自分も他メンバーとともに学習しながらコーディング、コードレビューを並行して進めていった。 SPAの開発は初めてだったが、Nuxt.jsは扱いやすく、画面数も減らせるので、良い試みだったが、いくつかハマりポイントもあった。 ・SSR 特にログイン情報など、ページをまたいで取り回したいデータはstoreに持たせたかったが、結局セッションでサーバサイドにも持つことが必要という結論になった。 ・リクエストの投げ方 特定の遷移、イベントの際に複数のAPIリクエストを投げるケースがあるが、で最適なロード時間を実現するためその順序と、必要な部分は並列で投げることをチーム内に徹底した。 ２．通信環境がない状態でもアプリは利用できることが前提であり、複数人で編集することによるコンフリクトの防止などの要件を整理し、飛行ミッションデータは自動同期ではなくGitを参考に、push / pullを任意で行う、コンフリクトが起きそうな場合、編集する前にアラートで警告するなどの仕様策定を進めた。

【プロジェクト概要・人数・体制】 慶應大学病院との共同事業として、医者と患者の間で利用するライフログアプリを開発。（非公開） エンジニア4名（アプリ開発2名、データのインポート周り1名、管理者用画面1名） 要求された機能が少なくシンプルなものだったので、工数削減を期待してReactNativeを採択。 結果、ネイティブの機能を利用する必要がある箇所も少なく、2人*1.5ヶ月程度に工数が抑えられた。 概要としては患者が日々食べたもの、体調、生活習慣や、薬の記録などをアプリに記録し、それを医者が事前情報として見ることにより、実際の診療の時間の効果を高める、薬を使用する習慣づけるなどの効果を期待するもの。 【自身の役割】 【プロジェクトの背景・課題】 １．当初はサーバにAPIと管理画面を用意し、都度患者のデータが更新されていく仕様で進めていたが、病院側からクラウドにデータを保持することに対し許可が下りず代替案を考える必要があった ２．端末の貸し出しになったので、患者が貸与端末に不正な操作を行わないような機能制限を考える必要があった。 【課題に対して自身が発揮したバリュー及び成果】 １．結果としてSDカードにデータを吐き出し、管理ツールが置かれているローカルPCで吸い出す、というフローに変更した。 （そのため、Android端末と管理ツール用PCも合わせて納品） ２．チャイルドロックの機能を利用するなど、実開発以外の部分でも先方の特殊な運用フローに合わせた解決策を検討・提案した。

【プロジェクト概要・人数・体制】 ドローンパイロットとドローンを利用したい事業者をつなぐマッチングサイト「drone market」の開発 https://www.dronemarket.jp/ 構成は一般的なRailsのモノリシックなWebアプリケーション。 フロントエンド（2名） バックエンド（3名） 管理者用画面（1名） 【自身の役割】 当初はフロントエンドの人的リソース不足を補うために応援要員としてJOINしたが、途中でバックエンドの方の進捗が遅れたため、結果的に両方対応した。 【プロジェクトの背景・課題】 １．企画サイドの強い要望で、開発しながら①事前登録開始、②他ユーザの情報が閲覧可能、③実際に発注をかけることができる本リリース、という3段階のリリースがあった。 ２．ユーザ設計において、マッチングサイトではあるが発注者、受注者と立場が違う関係性になるので、データの持ち方は課題となった。 【課題に対して自身が発揮したバリュー及び成果】 １．それぞれの段階で、どの機能、ページができている必要があるのか、どのアクセスは許可するのかといった仕様の共有を企画サイドと常にすり合わせながら進めた。 ２．時間をかけて議論を進めた結果、「誰もが発注者にも受注者にもなれる」という企画側の要望を受けユーザとしては一つのuserテーブル内の同一レコードとして扱いながら、userモデルには最低限の共通処理のみを持つようにし、実際に扱う際にはuserモデルを継承した vendor(発注者) / operator(受注者) モデルのインスタンスとして利用するような設計とした。

【プロジェクト概要・人数・体制】 ドローン関連のiOSアプリの開発。 アプリはiOSのみ、swiftリリース後だったが、SDKの都合でObjective-Cで開発。 （エンジニア3名） 【自身の役割】 協業していた会社のSDKを利用しながらの開発で、UIの開発とSDKのつなぎこみがメインの仕事だった。 【プロジェクトの背景・課題】 １．「ドローンの利用に関するデータ構造」をいかに設計すべきか、という前例もあまりない中で考える必要があった。 ２．ドローンというモノの特性上、飛行のログなどはどこまでアプリで取得できていれば良いか、不具合があった際の責任の所在を明確にする必要があった。 【課題に対して自身が発揮したバリュー及び成果】 １．協業先や社内のドローンパイロットにヒアリングを重ね、実際の利用現場にも帯同して、テストも実施した。 「どのパラメータはユーザが操作できる変数として提供すべきか？」や「万が一のアクシデントの際に何がログとして残っていることは必須なのか」などは現場の知見無くして完成には至らなかったと思う。 ２．責任の所在はSDKを提供している協業先にある、などの自社のリスクヘッジに関して、開発の観点から懸念されるような事項は、窓口となっている営業担当者とディスカッションを重ねた。

【プロジェクト概要・人数・体制】 北海道大学博物館デジタルサイネージの開発 https://www.orso.jp/infomation/2016/0822.html Unityでwindows10上で動くスタンドアローンのアプリ。 クイズを回答すると画面内の記者が北海道を進んで、背景や表示される写真が変わっていくという仕掛け。（エンジニア1名） 【自身の役割】 エンジニアは自分一人だったので、デザイン以外の要件定義と設計、開発を担当。 【プロジェクトの背景・課題】 １．クイズの問題は納品先の北海道大学が任意で追加・編集したいという要望があった。 ２．アプリケーション内で表示する写真は運用コストをかけず季節などによる更新感を出したいという要望があった。 【課題に対して自身が発揮したバリュー及び成果】 １．当初はWebで利用できる管理画面を合わせて開発し、ネットワーク経由で問題を取得することを検討した。 しかし大学側のネットワークの管理者が別部門であり別途調整が必要になること、そもそもそこまで更新頻度も高くなくリアルタイム性も求められないことなどから、工数削減のため最終的にwindows10のローカル上のcsvファイルをデータストレージとして、必要な際にはそのcsvファイルを更新してもらう形で先方と調整した。 ２．当初はInstagramAPIの利用を検討した。 しかし利用規約上審査が必要で、申請するもリジェクトされたため、FlickerAPIから取得した画像を座標情報でフィルタリングして北海道の写真を抽出した。 クライアントからは最終的なアウトプットのイメージだけ要望として伝えられる形だったため、上記のように提供する手法はこちらがやりやすく、工数を抑えられるような手法を柔軟に採択することができた