アプリ開発者なら書籍「Web API: The Good Parts」は読んでおくべき
最近のアプリ開発においてクライアントサイドだけで完結するようなものはかなり少なくなってきたと思います。 おそらく何らかのAPIを直接もしくはSDK経由で呼び出すことがほとんどではないでしょうか。 そういった背景がある以上、すぐれたWeb APIがどうあるべきかというのはサーバサイドを担当するエンジニアだけでなく、 クライアントサイドを担当するエンジニアであっても知っておくべきでしょう。
今回読んだ「Web API: The Good Parts」はWeb APIを美しく設計する重要性、そして美しく設計するための指針を すでに公開されている様々なWebサービスのAPIを例に挙げながら、よりよい方法を提案してくれています。
個人的に印象に残っている内容をいくつか挙げておきます。
- エンドポイントの設計において重要な原則として「覚えやすく、どんな機能を持つURIなのかがひと目でわかる」こと
- RESTを意識しすぎない
- REST APIの設計レベルにはREST LEVEL3(HATEOASの概念の導入)まである
- 仕様が存在していないものに関してはデファクトスタンダードに従う
- レスポンスデータの設計において一部例外はあるがエンベロープは不要(理由としてはHTTPプロトコルというエンベロープがあるから)
- レスポンスデータはなるべくフラットにすべきだけど階層化したほうが絶対によい場合は階層化もあり
- エラー時は適切なステータスコードを返し、エラーの詳細はレスポンスボディにデータを入れる方法がクライアントの利便性が高い
- 配列データを返す場合、そのまま配列として返すよりオブジェクトに配列を包んでキーをつけて返す方がおすすめ
- HTTPの仕様をしっかり理解してなるべくそれを活用する（たとえば正しいステータスコードを返すなど）
- APIのバージョン管理はURIにバージョンを入れるタイプを推奨している(Twitter、Facebook、Tumblrなどが採用している)
Web APIを提供する側、使う側ともにすぐれた設計を共通認識として持つことで 開発の効率化につながりますし、Web APIを公開した際に変な設計をさらして恥をかくこともなくなりますw
正直もっと早く読んでおくべき本でした。
本書は全体で224ページと内容はコンパクトにまとまっており、 全てを読むのにさほど時間もかからないので是非一読してみることをお勧めします。
「SwiftではじめるUI設計&プログラミング」を読んだ
タイトルから期待して２ヶ月くらい前に購入したのをようやく読みました。 でもUI設計の話はほとんどなくて、 Auto Layout、Dynamic TypeやiOS8で新たに登場したインターフェイスの話がメインの内容で少し残念という印象。 ただこれからAuto Layoutを勉強したい人には、 インターフェイスビルダーだけでなくソースコードでの実装やVisual Format Language(VFL)にも触れていてよさそうな印象でした。
圧縮抵抗と内容ハギングについても分かりやすい説明があり、 個人的にはSize ClassesはConstraintだけでなくViewもインストールするかどうか選択できるという発見もあって個人的に助かりました。
その他には主要なビューやコントロールのリファレンスもあり、 これからアプリを作りたい人やAuto Layoutを初めて使う人なら読んでおいて損のない内容です。
これぞUI設計の教科書！みたいな書籍があればうれしいけど、これが正解みたいなのは無いんだろうなぁ。
それにしても久々にブログ書いた。
３日で作った「Facebookの未読メッセージを既読にせず読める」iPhoneアプリを公開しました！
タイトル通り３日間で作ってApp Storeに公開しました。
https://itunes.apple.com/jp/app/wei-dumessenja-facebookno/id949191056?mt=8&at=10l8JW&ct=hatenablog
これまで出したアプリの中でも開発期間は最短だと思います。 未読メッセンジャーというアプリでFacebookの新着メッセージを既読にすることなく未読のまま確認できるようになっています。 メッセージを確認して返信したい場合はアプリから直接Messengerアプリを起動できるので、メッセージの送信はMessengerから行ってください。
といういたってシンプルな内容ですが、実際使ってみると結構便利です。 実はアプリ自体は２、３ヶ月前に作っていて一人で使ってたんですが、便利なのでApp Storeに申請してみたらすんなり通ったという感じでした。
今回すぐに作れた理由の一つに JSQMessagesViewControllerを使ったのがあります。 このライブラリ使うことでチャット風の画面を作るのにほとんど時間かける必要がありませんでした。
申請してから審査通るまでは8日かかりました。 内容が内容だけに審査に入って3時間程度で審査は終わったようです。
ちなみにこのアプリ、利用できる期間が限られてましてFacebook API ver1.0が使用できるのが2015/4/30までと現状はなっています。 ですのでその期間を過ぎて実際にAPIが使えなくなった時点でアプリの公開もストップします。 ソースコードも公開予定なので準備ができ次第、App Storeのアプリ説明文にURLを掲載しておきます。
ちなみにこのアプリ12月22日のランキング見るとこんな感じでした。
ソーシャルネットワーク カテゴリのランキングで国内では357位と全くふるいませんが、Mongoliaでは35位でした。 (Mongoliaってどこにあるんでしょう・・・)
期間限定アプリではありますが、まだ時間がありますし既読疲れを防ぐためにも是非ご利用ください！
追記： Mongoliaはモンゴルでした。言われてみると確かにその通りですね。 honeybe さんありがとうございます。
「ビジネスモデル・ジェネレーション ビジネスモデル設計書」を読んでみた
同僚に紹介されて読んでみました。
率直な感想を書きます。
そもそもビジネスモデルって何？という段階で読んだ私には中々頭に入ってこない内容でした・・・。 (本のサイズも横長で持ちにくい上、構成も変わっていて読みにくかった) また本書の内容もいきなりビジネスモデルキャンバスというフレームワークの説明から始まり、このフレームワークがなぜよいのか、特に記述がなかったのも理由かもしれません。 他の方法と比較しようもないのですが、もしかするとそもそもビジネスモデルを構築していく手法が全然確立されていないから、このビジネスモデルキャンバスが有効なのかも？と勝手に納得しています。 ただそれらを抜きにしてもチームでいっしょにビジネスモデルを考えるやり方としてはよさそうな印象でした。
そしてそんなに私にビジネスモデルの定義を本書は明確に書いてくれています。
ビジネスモデルとは、どのように価値を創造し、顧客に届けるかを論理的に記述したもの。
元々私はビジネスモデルというのはこれまでの成功事例のやり方をいくつかの似た方法に分類してまとめたものだと勝手に思っていました。 ですが既存のビジネスモデルを定期的に評価して調整していくことこそが重要だというが本書を通して分かります。
例えばP. 258のデルの例は非常に分かりやすいです。
デルは、受注生産の形態やオンラインでのダイレクト販売を導入することで、PC業界に波乱を起こしました。その成功によりデルは、長年にわたり業界のリーダーとして成長してきました。しかし、その破壊的なビジネスモデルを再考することに失敗しました。今では、業界の状況も変わってしまい、デルはコモディティ化してしまったPC市場で立ち往生するリスクを抱えています。
またビジネスキャンバスを使って既存のビジネスモデルを体系的に整理して説明してくれているので、自分たちのビジネスモデルを考える上でも参考になる部分も多く、純粋におもしろいです。
一度読んで終わりの書籍ではなく、何度も読み返しながら実際にためしていくのが一番よいと思います。
「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」を読んでみた
新たにアジャイル関連の書籍を入手したので読んでみました。
この書籍は経営層や管理職の方、またはアジャイル開発の導入を会社へ提案したい人が読むとよいのではという印象です。 特に第２部ではいくつか国内の事例を紹介しており、これからアジャイル開発を検討する方には参考になる部分が多そうです。 スクラムがどのようなものかについても触れていますが、具体的にスクラムでの開発のやり方を知りたい方は以前の書評で紹介した「SCRUM BOOT CAMP THE BOOK」がおすすめです。
印象に残った箇所にP.54のコラムで触れているウォータフォールの問題点があります。
このアプローチでは途中で計画外のよりよいやり方がみつかっても採用できない。すべてのよいアイディアは、プロジェクトの最初で計画する必要がある。
これは全ての要件を最初に固めてしまうのが前提のウォーターフォールでは、後からの仕様変更に柔軟に対応しにくく、開発者側からすると仕様変更は悪みたいなことになりがちです。
しかし、ウォーターフォールが極めて論理的であるため、「もっと上手にやっていたら、うまくいったはずだ。もっと文書化し、変更を最小限に抑えれば、すべてもっとスムーズにいくはずだ」と思い込んでしまう。残念ながら、多くのチームでは逆の結果になる。しっかり管理すればするほど、さらに悪い結果になるのだ。
これは正にその通りだと思います。しっかりやろうとすればするほど悪循環になりやすく、変更を最小限に抑えようとして本当に必要なものが作れなくなるなど、本末転倒な結果にもなったりします。 ウォータフォールはよくないとまでは思いませんが、最初に全てを決めようとするプロセスは特に技術革新の激しいソフトウェア開発においては適応するのが難しくなってきていると言えます。
P.129のリクルートの事例の部分も的確に問題点を捉えています。
SWATでは、「持ち帰りは禁句」という原則を打ち出した。従来のように会議の席上で100%の確約を要求するのをやめ、「可能性80%ならOKと答えてもよい。その代わり、持ち帰って検討は禁句」と関係者全員に理解をもとめたのだ。
全てを最初に決めようとするとあとから技術的に難しいものや、見積もりが思った以上にかかることが後から発覚しても「あの時そういったじゃないか！」と揉める原因になることも多いです。 そのため100%の確認をするために一旦持ち帰らせてもらうことは私もよくありました。ですがその場で決定できないため、スピード感が落ちることはどうしても止む終えない状態になりました。 それを解決するたのルールとしてはとてもよいと思いますが、この80%と調整の部分はさじ加減が難しいとも思います。
そして一番印象に残ったのはP.241のこの部分です。
このことで、筆者はアジャイルを目的ではなく手段だと考えるようになったし、また、「アジャイル対ウォーターフォール」とか、「プログラマ対管理者」といった敵・味方の味方ではなく「現場をよくしたい」という気持ちで活動することが大切だと実感した。
アジャイルを意識するばかりアジャイルでやることが目的になってしまうというのは本末転倒です。 常に手段が目的になってしまわないよう気をつけないといけません。 また開発が人ありきで進む以上、敵・味方とか関係なく常によくして行こうという気持ちをメンバー全員が持てるようにすることが一番重要だと改めて認識しました。
「強いチームはオフィスを捨てる」を読んでリモートワークのメリット／デメリットについて考えてみた
私は京都で働くようになるまでは元々広島で仕事をしていたので、以前からリモートワークに興味がありました。 広島に居ながら東京の会社に就職して仕事ができたらいいなぁーと漠然と思っていた時期もあります。 ただ実際にリモートワークをやるにしても正直不安な部分も多いし、難しいだろうなぁという程度で実現するまでには至りませんでした。
まだ実践できていない段階ではありますが、「強いチームはオフィスを捨てる」を読んだ感想も踏まえメリット／デメリットを書く事で、リモートワークを検討中の方に参考になる事があれば幸いです。
まず本書を読んだ中から思いつく限りメリットを書き出してみました。
リモートワークのメリット
- 通勤時間の短縮、自宅なら通勤が必要なくなるので時間を節約できる
- ９時５時などの時間の制約から解放される
- 東京など仕事の集中している地域に住む必要がなくなるので、住む場所は自由に選べる
- オフィス面積の節約など経費削減に貢献、極端な話オフィスがなくても大丈夫
- 会議や雑談を減らしやすいので作業に集中しやすい
- 対面での影響力が減る代わりに、成果での評価がしやすくなる(謙虚だけど仕事は着実にこなす人によいかも)
- 優秀な人間を場所の制約なく採用できる
さらっとメリットを書きましたが、場所の制約がなくなるのと時間を自由に使える部分が増えるというのは、人によってものすごく人生を豊かにできる可能性があります。
リモートワークのデメリット
- 会社や同僚の協力がないとリモートワークをしている人が孤立しやすい(島流し状態？)
- 部下が見張っていないと仕事をしないのではという考えが根本にあると成立しない
- 働かなくなる人よりもむしろ働き過ぎになる人が多い
- 文章力が無い人がやるのは難しい
- 同僚との会話が減る分、仕事の成果に注目が集まるので成果を出せる人でないと難しい？(むしろメリットかも)
こうしてデメリットをあげていくと見える成果を出せる人でないとリモートワークはやりにくい印象です。 また周りが一緒にリモートワークを成功させようというスタンスでのぞまないとリモートワークをしている人が孤立してしまう可能性が高いです。 安易な考えでリモートワークを取り入れてしまうと失敗するだろうなというのが率直な感想です。
また本書では触れてませんがセキュリティ上の理由から情報を外に出せない会社では成立しにくいです。 昨今セキュリティ関連の事件が明るみに出ているので、リモートワークを難しくする一因になっているかもしれません。
デメリットだけみると難しいのかな？と思われる方もいると思いますが、本書には問題点を解決する方法もふんだんに書いてあるので変に心配はしない方がいいです。 セキュリティに関しても対策をきっちり行っていれば問題ないはずです。 孤立する問題に関しては同僚もそうですが、経営者や上司がリモートワークを実際に体験することで何をサポートするべきか分かりやすくなります。 部下を見張る必要など実際はほとんどなく、仕事をしているかどうかの問題は目標をはっきりさせてその成果をちゃんと精査することで解決できます。 毎日顔を会わせることがないために孤独に落ち入ってしまう人もいるかもしれませんが、それは家族がいる方ならその可能性はあまりないでしょうし、家族がいない人は地元の交流イベントやなどに参加することで人との交流をもつなどできることはたくさんあります。
リモートワーク礼讃というわけではありませんが、社員の幸福、社員一人一人の成果についてきちんと考えてみるなら導入するメリットは計り知れないです。 優秀な人を雇うのに近くの人だけという制約もなくなりますから。
また本書で紹介しているリモートワークを支援するツールもそうですが、最近はかなりそういったツールが増えてきているので、いいものがあればすぐ導入して日頃から業務で使う文化があるとリモートワークが成功しやすいと思いました。 それにいきなり遠く離れたところでやり始めるのではなく、オフィスに通勤できる圏内に住んで、 週に２、３日とか午前中だけ出社するなど、段階的な導入がより現実的な気がします。
最後にリモートワークを実際にしている人の情報ほど役に立つものはないと思うので、そういった方のブログのリンクを掲載しておきます。
リモートワークの魅力が存分に伝わってきて素敵なブログです http://blog.jnito.com/entry/2012/09/28/083205
上記ブログの方が働いている会社の社長の方がリモートワークについて書かれている内容でとても参考になります http://kuranuki.sonicgarden.jp/2014/04/%E5%BC%B7%E3%81%84%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AF%E3%82%AA%E3%83%95%E3%82%A3%E3%82%B9%E3%82%92%E6%8D%A8%E3%81%A6%E3%82%8B.html
リモートワークにすることで成果が上がり始めた話です http://d.hatena.ne.jp/ogin_s57/20130715/1373892663
最近高知に引っ越して話題になったイケダハヤトさんのアドバイス http://www.ikedahayato.com/20140131/2889348.html
アジャイル開発をより良く知るために「SCRUM BOOT CAMP THE BOOK」を読んでみた
アジャイル開発の手法の一つであるスクラムについて知るために読んでみました。
本の内容はマンガ付きでとても分かりやすくスクラムについて説明してあり、２時間程度でさっと読める内容でした。 短時間で読めるからといって内容がないわけでは無く、実際にプロジェクトで起きそうな問題をスクラムマスターの主人公とプロダクトオーナー、開発チームが解決していくストーリーは実用的でありスクラムのメリットを十分に知ることができるものでした。
個人的な感想としてはやはりスクラムは予算や納期の決まった受託開発より、ウェブサービス、スマートフォンアプリ開発に向いているなぁという印象です。 逆にいえばウェブサービスやアプリ開発をウォータフォールでやってしまうとうまくいかないだろうなと改めて思いました。
例えばベロシティはスプリント毎に終わらせられるポイント数であり、ある程度プロジェクトを進めることによって見えてくる数値なので、予算・納期を前もって決めないといけない場合、ベロシティが分からないためかなり見積もりがつらくなってしまいます。 受託開発で採用する場合、納品のない受託開発がベストなのかなぁーと思います。(このフレーズ最近よく聞きます)
本書を読んだ中で特に印象に残ったフレーズとして、「そのロールで求められていることに一生懸命とりくんでくれるかどうかだ」という箇所があります。 これってかなり根本的な話で、スクラムやそれ以外の手法関係なくちゃんと熱意をもってとりくまないと何やってもうまくいかないし、ちゃんと取り組んでくれる人達が集まればそれなりにうまく回るととも言えます。 ただスクラムの場合、どんな人が集まってもどこかのポジションには当てはまる人がいるはずで、プロジェクトを動かしながら手探りで進められる部分もあるので他の手法より成功率は高くなるかもと思いました。
それからもう一つ「Scrumでは、開発チームは自己組織化されていて、機能横断的であることが求められている」も印象に残っています。 これができるメンバーが揃っていればスクラムだろうと何だろうとうまく回るの当たり前だろうなーと思いましたw ただスクラムの手法をちゃんと取り入れることができれば自己組織化していくことも可能なので結局やり方しだいですかね。
あと個人的に痛かったのは「それぐらいはできるよね！？」というところで実際の作業に関係ない人の意見は参考意見程度にしておかないといけないというところです。 実際に作業をする人やチームの意見でないと現場のさまざまな情報をもとにきちんとした判断はできないので、作業に関係無い人に何を言われようと自分やチームのメンバーがちゃんと約束をして取り組んでいくことで責任感もうまれ、それがよい結果につながると改めて認識しました。 周りに振り回されないようにしたいものです。
最後に言えることは、どんな手法を取り入れようとチームメンバーに対する信頼が無い場合や、失敗の責任を個人に押し付けるような組織では何やってもうまくいきません。 特にスクラムは自己組織化されていることが前提であるならばそれはかなり重要な要素です。 そういった信頼関係を築きつつスクラムを試してみるのが一番よいのかなと思いました。
この本はプロジェクトで困った時などにヒントになることがたくさんあるので、そういった時などに見返してみるとまた得るものがあって更によいのでオススメです。
