dorivenの日記

気がついたら社会人。気になる技術的なことについて少しずつ書いていけたらと思っております。

裏開発備忘録

どうも、最近プライベートもやるべき事も中々ホットになってまいりました。
そういえば、ネットワークスペシャリスト試験受けるつもりだったのですが、試験日とプライベートの日程が重なってしまったので、今回は受けられないですね。
ネットワークに関する理解が曖昧だったので、この機に知識を深めたかったのですが。
さて、少し投稿が遅れてしまいましたが、今日は内定者同士でチームに分かれて開発を行っていたことで得られた事とか、裏話的な話をします。

開発プロジェクトの概要



メンバー

エンジニアの内定者が9名いるのですが、その中で 3 x 3 のチームに分かれて開発を行っていました。
こちらのチームメンバーは
・自分
・@1000ch
・@inappe
以上の3名で開発を行いました。

開発したサービスの概要

開発しようとした物はFacebookアプリです。
出てきたお題に対して、その人(Facebook上での友人)になりきったつもりで回答を行っていき、「自身の回答と他人の回答の差異から気付きを得る事ができる」ものを作りました。

メンバー毎の役割

開発の役割としては以下の通りです。

名前役割
自分サーバサイド全般
1000ch回答画面
inappeマイページ画面(他人回答の状況

開発時期毎の状況


インターン期間中

この期間では主にアイディア出しを集中して行いました。
何故なら、自分は地方組のためにインターンが終わってしまうと対面での話し合いが不可能になってしまうため、コミュニケーションが重要なアイディア出しはこの期間中に終わらせたかったからです。
しかし、残念ながらアイディアの種は出てきたものの最終的に作るアイディアなどは決まらずに終わりました。

開発初週

決まらなかったアイディアを初週の頭でアイディアを固め、そこから開発開始。
1000chがUIモックを作成。
自分はデータベース設計、ダミーデータ作成、FacebookAPIに関する調査、回答画面のAPI設計などを行った。

開発2週目

最低限の動作をするものを作るのが目的。
1000chがAPIを叩いたバージョンを作成し、この時点で回答画面からDBに登録ができるようになった。
他にもUIなどの点で非常に力を注いでくれた。
ただ、inappeの予定が詰まっており、マイページの作成が進まず。
自分は回答、マイページのAPI作成を主に担当。また併せてFacebookの友達関連をDBに登録する処理も追加した。

開発3週目

とうとうMVPが完成。
inappeのマイページも1000chの助けもあって完成し、ようやくサービスの本質を試せる段階になった。
ただ、この時に自分がFacebookアプリの仕様を勘ぐってしまい、公開モードに出来ない、友達の情報取得が不可能など、一時期Slackにデマが流れたが、特にそんなことはなく、KeyUXである友達からの回答が得られない、という最悪の自体を回避する事が出来た。
そして、この週で開発終了。
開発終了後もリーンキャンバスの理解を1000chとすりあわせたりした。
プレゼン資料を作ってくれた1000chには感謝。
他の班はかなりデスマっていたようだが、こちらの班は早めに開発を始めていたため、終始落ち着いた流れで開発を行うことが出来た。

学び


アイディア出し

ユーザの課題が存在するのか、自分たちの開発するものが本当にユーザにとって良い物なのか。
話し合いだけではどうしても解決しないことが多い。
何故なら実際にサービスを開発する自分たちが、課題の仮説やサービスの実態に何かしらの共感を得ていないと、納得感を得られないためだ。
そのため、今回はSkype上でエニアグラムの問題を数問答えてみて、実際に自身と他人との差異からユーザに何か気づきが与えられるかを試してみることで、自分たちの仮説をその身をもって体験することができたのは、この先の開発においても大きかったのではないかと感じている。

API設計

今回、サーバサイド担当ということでAPI設計を行った。
しかし、今回のAPIの設計で良くなかったと感じている部分は、同じ処理が別のAPIにも登場するような設計を行ってしまったことだと思っている。
これには理由があり、マイページを開発するinappeが多忙なために、ページ毎にAPIを準備し、必要な情報がすべて帰ってくるような設計にした。
APIをリソースと考えるのであれば、指定されたURLから一つの情報(もしくは関連する情報群)が取れるようにしたほうが、名前を決定しやすく、処理の重複も少ない。
ただし、フロント側でデータの組み立てを行う必要がある。
逆に言えば、必要なリソースのURLさえ知っていれば、フロント側が自由にデータの形式を決められるため、こちらのほうがいいと思うのだが、実際の開発でどうなっているのかが非常に気になった。
そのため、検索したところ良さそうなサイトが見つかった。
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
これのChattyAPIsによれば、

・ Chatty API (おしゃべりな API, つまり情報が少なく何度も呼び出さないといけないもの) をいかに避けるか
・ まず RESTful に設計し, そのごショートカットを追加する

  • 複数API 呼び出しを組み合わせないと実現できない使い方を, 一度の呼び出しで実現できる API を追加してあげる
  • 先にショートカットを作ってはいけない. まずは RESTful なデザインで, 必要に応じてショートカットを追加する

・ partial response にドット演算子を導入して, 別のリソースのフィールドを参照できるようにする

  • `/owners/5678?fields=name,dogs.name`

なるほど。
大きい物から作っていき、その後小さいものを埋める。
プログラムのリファクタリングする流れに非常に近いものを感じる。
処理の効率的にもそちらの方が良さそうだ。
実際、今回のAPIで似たような処理を関数化しなかったという非常に大きな罪が自分にある。
これを機会にAPIに関する設計の本を一冊でいいから読みたい。

まとめ
  1. アイディア出しでは、サービスのメイン機能が簡単に実施できるならすぐにでも試してみる
  2. APIは大きなデータを返すものを作り。そこから、必要なら小さなデータを返すAPIを作成していく。
  3. リファクタリングはある一定をめどにして、定期的に行うように心がけたい。