島根に移住してエンジニアとして働くメリット＆デメリット
気が付けばあっという間に島根(松江)に移住して３ヶ月が立ちました。 せっかくですので、こちらで働き始めて自分が感じた島根に移住して働くことのメリット＆デメリットを書いてみます。
メリット
- 雑音が入りにくくプログラミングに集中できる環境になった(個人的にすごくうれしい)
- 勉強会などが少ない分、刺激は少ないがその分本来やるべき仕事に集中できる
- 流行とか最新の情報をひたすら追っかる必要に迫られなくなった分、純粋に興味のある分野の勉強をできるようになった
- 首都圏と比べると遊ぶところが少ない分、仕事に集中できる
- 松江駅からならバスで30分程度で出雲空港まで行けるので、仕事で東京へ行く際も移動が楽 www.ichibata.co.jp
- 物価が安いので、生活しやすい
- 家賃安いし、食材も全般的に安くてうまい
デメリット
- 勉強会などが少ないので最新の情報を気軽にキャッチアップする機会が減った
- 情報が周りから自然に入ってきにくくなったので、自分で頑張ってアンテナをはる必要がある
- 東京の仕事が多いので自分だけでなく、一緒に仕事をするメンバーもリモートワークに慣れていないとつらい
- 社内のリモートワークをする体制が十分ではないので課題がある
- 音声が聞き取れないとかそういう細かい部分が結構ストレスになる
- 人が少ない分仕事のジャンルも少ないので、仕事の幅が広がりにくい
- 車はほぼ必須といえる
と上記のようにまとめてみましたが、自分にとって島根で働くという選択はめっちゃ正解でした。 常に最新の技術を追わないといけない不安から抜け出すことができて、 これからどうすべきか？という本質な部分についてちゃんと考えるきっかけにもなりました。 あと私的には妻の実家が近くなった分、子育ての負担が減って純粋に仕事に集中できるようになったのもでかいです。
ごっそり環境を変えることができるという意味でも移住という選択肢はいいなぁと感じます。
東京の方がたくさんの刺激があって楽しいし、田舎はつまらないなんて思ってる人には ぜひ本当にそうなのか？と振りかってみてほしいです。 何が楽しいかなんて実際やってみないと分からないですし、無いなら作ろうと思える気概がある人なら絶対大丈夫です。
私のように県外の方で島根で働きたいというエンジニアの方は是非弊社の島根事業所にお越しください。 ご連絡さえいただければ見学はいつでも大丈夫です！ もちろん地元の方でも大歓迎ですのでよろしくお願い致します！
株式会社はてなを退職して島根に移住しました
６月に退職してそれと同時に島根に移住しました。 移住するにあたっての決定打となったのは子育てを妻の実家の近くでしたいということだったんですが、 僕自身も広島の片田舎出身ということもあり過疎が進むような地域でいかに働いていくかということに非常に興味がありました。 そもそも東京に全てが集中してしまい、地方との格差が広がるばかりの状況ですが リモートワークを含め場所を選ばない働き方の選択肢が広がってきています。 そんな状況の中で今なら地方からでももっと面白い仕事ができるのではないかという可能性にかけてみようと思った次第です。
これまでを振り返ってみるとサラリーマンやってフリーランスやってまたサラリーマンに戻って転職みたいな側から見ると心配されそうな生き方ではありますが、自分の中には一本の道があってその道をちゃんと前進しています。
ちなみに島根ではすでにRubyを使ったまちおこしをやってますが、 僕が得意なiOSの開発でも何か違った貢献ができないかと考えたりしてます。
退職してから改めて思うのは、はてなという会社の文化は本当にすごかったなぁということです。 エンジニアの技術や仕事に対するスピード感もですが みんながいかに働きやすい環境を作るかというところをちゃんと考え、いい方法があればすぐに実践するというスピード感も関心するばかりでした。 こういったことを学ばせてもらったことに感謝しつつ、新たな場所でそれらの経験を活かしていくつもりです。
７月からは株式会社ソニックムーブの島根事業所で働いております。 本社は東京なのですが昨年11月に島根事業所を新設したばかりで、僕は島根では６人目のメンバーとしてジョインしました。 おそらく島根では数少ないiOSやAndroidの開発も手がける会社であり、 地元のエンジニアの方々と一緒に島根をもっと盛り上げていきたいです。
もし弊社、島根事業所の採用について興味のある方は是非こちらを見てみてください。 http://www.sonicmoov.com/recruit/shimane/
島根は思った以上に住みやすく特に松江はとてもお気に入りの場所です。 今後はこのブログにも島根アピールを書いていく予定ですので、何卒よろしくお願いします！
アプリ開発者なら書籍「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のこの部分です。
このことで、筆者はアジャイルを目的ではなく手段だと考えるようになったし、また、「アジャイル対ウォーターフォール」とか、「プログラマ対管理者」といった敵・味方の味方ではなく「現場をよくしたい」という気持ちで活動することが大切だと実感した。
アジャイルを意識するばかりアジャイルでやることが目的になってしまうというのは本末転倒です。 常に手段が目的になってしまわないよう気をつけないといけません。 また開発が人ありきで進む以上、敵・味方とか関係なく常によくして行こうという気持ちをメンバー全員が持てるようにすることが一番重要だと改めて認識しました。
