ついに「SOFT SKILLS」が読める。嬉しい。

昨年からかなり読みたかった本に、いよいよ日本語版が出ます！
見つけた瞬間に購入したうえ、テンションがおさまらず思わずブログにしちゃってますw

どんな本かというと、こちら「SOFT SKILLS ソフトウェア開発者の人生マニュアル」です。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

昨年9月に、原著である英語版をhigeponさんがブログで紹介されていたので、知っている方も多いのではないでしょうか。
d.hatena.ne.jp

今週末2016/5/21発売で、現在は予約注文が可能になっています。

どのようなことが書いてあるのでしょうか。
Amazonで見られる目次には以下のようになっています。

第1部 キャリアを築こう
第2部 自分を売り込め!
第3部 学ぶことを学ぼう
第4部 生産性を高めよう
第5部 お金に強くなろう
第6部 やっぱり、体が大事
第7部 負けない心を鍛えよう

付録A コードを書けるなら金融は理解できる
付録B 株式市場の仕組み
付録C 食事と栄養の基礎:ガラクタを入れればガラクタが出てくる
付録D 健康な食事の方法:ピザは食品群ではない

また、higeponさんのブログには以下のような内容も書かれています。

・雇用形態の選択肢
・会社で出世する
・リモートではたらく方法
・テクノロジーを宗教的にあつかうな
・コード書きのためのマーケティング
・ばかに見えるのを怖がるな
・メンターを探す
・燃えつき(burnout) は治せる
・hard work の価値とそれを避けてしまう理由
・入社時給与交渉
・不動産投資
・きちんと引退プランを理解していますか？
・彼氏・彼女の戦略的な見つけ方

私個人の話ですが、4月から社会人生活も5年目となり、プログラマひいてはIT業界人として、今後どう生きていくかを本格的に考え始める時期に入ってきたなーと感じています。
家族との関わりや、金銭面、技術的な強み、新技術への取り組み方、会社への貢献、転職や独立、副業などさまざまな思いが頭の中でぐるぐるしています。（もしかしたら今後もずっと続いていくのかもしれませんね）
同じような思いを持っている方もたくさんいるのではないでしょうか。

本書には、技術の話はほとんどなく、「プログラマとして生きていくための技術以外のほとんどのスキルがここで網羅されている」内容になっているようです。
これは今の私にとっては渡りに船、つまりものすごく欲しかった内容の本ではないかなーと想像しております。

本が届くのがとにかく楽しみです！
読んだら書評的な記事も書こうと思います！それでは！

アプリ開発にはGitlab flowが合うと思います

はじめに

みなさまのプロジェクトではどのようにバージョン管理を行っているでしょうか。
ここでのバージョン管理とは具体的にはどのようなブランチを作ってどこにマージするか、リリースはどのように進めるかといった事柄を指しています。

今日は数あるバージョン管理戦略の中で比較的新しく提唱されたGitlab flowというフローを中心にして話していきたいと思います。
最近アプリの開発においてこのGitlab flowが個人的には一番しっくり来ているのでオススメしたいです。

有名なフロー

gitは分散型のバージョン管理システムとして一世を風靡しており、いまや事実上のデファクトスタンダートです。
名前のとおり分散している（ローカル・リモートが明確に分かれている）ことやブランチ・コミットの編集も非常に容易で柔軟性が非常に高いです。
一方でその柔軟さゆえにルールをきちんと決めなければ各個人のフローが大きく異なって混乱を生んでしまうこともあるでしょう。

こうした問題に対して有名なものとして git flow と GitHub flow といった２つフローが提唱されてきました。
それぞれについて簡単に見ていきます。

git flow

git flowは古参なバージョン管理戦略の一つです。
git-flow cheatsheetでこのフローを実現するためのコマンドも配布されていたりします。

A successful Git branching model » nvie.com

git flowでは以下のようなブランチを使用します。

• master - リリース済みのバージョンをここで管理する。タグ付けもこのブランチで行う。
• development - 開発の中心となるブランチ。普段のPull Requestのマージ先はここ。
• hotfixes - リリース内容に問題があった場合に緊急対応を行うためのブランチ。
• release branch - リリース準備用のブランチ。
• feature branches - 開発作業を進めるためのブランチ。

メリット

git flowのメリットは管理が他のどのフローよりもしっかりしていることだと思います。
役割ごとに明確に使うタイミングや意図が分けられているためコミットツリーを見ることでどのように作業が進んだかを俯瞰して把握しやすいでしょう。

デメリット

一方で控えめに言ってもgit flowはかなり複雑であると言えるでしょう。
ブランチの種類が多いことやその開始地点やマージ先が多岐にわたっています。
毎回上記の図を見ながら作業できれば良いですが実際にはそうはいきません。
一度目を離すとどれが何を表していたかを思い出すことは至難の技でしょう。

GitHub flow

もう一つの有名な戦略であるGitHub flowを見ていきましょう。
このGitHub flowは他のどのバージョン管理戦略と比較しても最も単純でしょう。

端的に言うとmasterブランチとそれ以外、という２パターンの種別でブランチを管理します。
masterから派生したブランチで作業をしてmasterにマージする、ただそれだけです。
（図中のオレンジ色のブランチはrebaseした方が良いといった話もあるかもしれませんが今は細かいところは触れません。）

メリット

特にサーバサイドとの親和性が非常に高いように思います。
CIと絡めて「masterにマージするたびにデプロイ」といった運用も取れるので、うまくすればリリース作業そのものからほぼ解放されそうです。

デメリット

リリースのタイミングを調整したい場合は不向きではないでしょうか。
例えばアプリの場合は１つの作業単位ごとにリリースをするとも限らないのでどのブランチでリリース準備をすれば良いのか迷ってしまいます*1。
また、サーバサイドであっても例えば環境（ステージング環境、QA環境、広告配信テスト環境などなど）を分けてデプロイしたい場合はデプロイタイミングとブランチとの結びつきが不明確になってしまうでしょう。

Gitlab flow

それではGitlab flowです。

例１：

出典：GitLab Flow | GitLab

例２：

出典：GitLab Flow | GitLab

Gitlab flowはイメージとしては「GitHub flow + リリースに必要なブランチ」です。
masterブランチでリリースに向けた作業が終わった段階で上記図のようにproductionブランチやpre-productionブランチにマージを行いリリースの調整やリリース作業を行います。

図では省略されていますがmasterブランチに対する変更はGitHab flowと同じようにPull Requestをする形で気軽に行いましょう。

メリット

リリースに対してかなり柔軟に対応できます。
上記の図のpre-productionブランチ / productionブランチのように徐々に本番に近づけていくような形もブランチで可視化しながら進めることができます。
環境が増えるようであってもブランチを一つ足すだけで済むでしょう。
これはアプリであっても同じでリリースapk作成用、Apple審査対応用、社内配布用、本番用といった環境やリリース段階に応じた柔軟な運用ができます。

また細かい話ではありますが作業のマージ先はGitHub flowと同じく常にmasterブランチです。
git flowのような戦略を取っているとどうしても操作ミスで意図していないブランチにPull Requestを送ってしまうのですが、そうした心配もかなり少なくなります。

そのほか常にリリース関連のブランチは常に存在しているのでそれぞれに応じたCIも設定しやすいでしょう。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

まとめ

バージョン管理戦略の中で最近お気に入りのGitlab flowについて他の戦略と比較しながら紹介しました。
リリースまで含めた作業を考慮しやすいGitlab flowはアプリの開発においても適合しやすいのではないかと思います。

最後に、この記事ではGitlab flowをおすすめしましたが当然のことながらバージョン管理戦略に正解はないです。
実際の現場でのリリースや開発の進め方をよく考えた上でどのフローを選ぶか、選んだフローをどうカスタマイズしていくかはその時々考える必要があるでしょう。
提唱されている戦略の形にとらわれすぎずに効率よくかつ気分よく作業できることを目指しましょう！

*1:masterでそのままリリースを作業を行う方法もありますが、リリースしたコミットの確認をタグでしか行えなくなってしまいコミットツリーから判断しづらくなってしまいます

雑談を通してエンジニアとしての不安を取り除く

漠然とした不安

エンジニアとして生きているとほぼ毎日のように言語やフレームワーク、OSS、設計指針など様々な情報が流れ込んでいます。
うまくこうした情報と向き合い自分の中でコントロールしていければ問題ないですが、なかなかそうもいかないことが多いです。

世間のすごい人たちのスピード感はとにかくすごいので自分だけ置いてけぼりになってる気になってしまうこともあるでしょう。

本当にそう思ってるのは自分だけか

ふとした機会に会社の同期数名とちょっと深めの技術について雑談ベースで話すことがありました。（具体的にはリアクティブ周りの話です。）
その場にはiOSが得意な人、Web Devが得意な人、プロダクト志向の人など様々な人がいましたが「あれ、ほんと難しいよね。〇〇の箇所がよく分からない。」といった話で盛り上がることができました。
（みんな僕から見ると社内外で活躍中のすごい人達です。まず友達でいてくれてありがとうw）

この経験を通して「あー意外とみんな同じようなこと考えてるんだなー」とハッとしました。

共感だけでなく情報も得られた

話していく中で「わからない部分がある」という共感が得られただけでなく、
「Webでの〇〇の概念はアプリでも通じるもの？」や「iOSよりAndroidの方が若干温度感が高そう」などいろいろと情報交換もできました。
また「こういう本を読んでみると理解が進むかも」といった先につながる情報も得ることができました。

一人で考えていても得られない、もしくはかなり得るまでに時間がかなりかかりそうなことばかりでかなり有益でした。

雑談良い

巷には勉強会やLTが溢れています。
本気を出せばconpassなんかを見てまさに毎日どこかに参加できるでしょう。
（妻と娘がいるので僕は絶対やらないですが）
基本的には目的意識を持って行った方が良いと思うのと、しっかりした発表がされるので不安を持ってしまうという観点ではむしろマイナスこともあるかもしれません。

一方で例えばランチやカフェタイムといった時間での雑談であれば「ついで」に話せてしかも身近な共感や情報を得られます。
ぜひ周りのエンジニアやデザイナを誘って雑談してみてください！

一日一善エンジニア

私事ですが仕事で10月から希望を出させていただき100%エンジニアに戻りました。

この１年ぐらいはプロジェクト・マネージャとエンジニア兼務、もしくはマネージャ業だけに専念していました。
兼務といってもやはりコードを書けることはそう多くなくどうしてもエンジニアの手が足りない時に書く、といったことが多かったです。
（もちろんマネージャとしてかなり多くの経験を積ませてもらいました！そのあたりでも記事にできそうなことが思いつけば別途書きます。）

一日一善を実践する

せっかくエンジニアに戻ったので意識的に実践していることがあります。
それが「一日一善」です。
具体的には1日に30分程度で良いので時間を取ってプロダクトの改善や、周辺環境の整備、プロジェクト全体の効率化を考えた行動を何か一つは取ることです。

実際にこの１ヶ月で着手できたことをいくつか並べてみたいと思います。（順不同。思い出した順）
基本的には１行が１日に着手したものです。
Androidアプリを担当していますのでAndroid関連のものも多いです。

• Android Gradle Pluginのバージョンを上げる
• 社内のアプリ配布環境用のGradleプラグインを書く
• ユニットテストの環境を整備する（ app/src/test ）
• Jenkinsジョブの整理をする（未使用のものの削除やジョブの分割・統合など）
• 社内チャットにhubotを導入
• compileSdkVersionを上げる
• targetSdkVersionを上げようとして諦めて懸念点をコメントとして残す
• 社内の複数の別アプリをWatchしてノウハウ吸収の準備とする
• 初めてのユニットテストを書く
• 端末テストの整理をする（ app/src/androidTest 、現状と乖離のあるものの削除など）
• コードカバレッジ計測の準備（ apply plugin: "jacoco" ）
• コードカバレッジ計測をJenkinsで行うようにした
• 軽微だけどずっと出続けているクラッシュに対応（３〜４個ぐらい対応？）
• hubotでPull Request一覧を見られるようにする
• Jenkinsのビルド実行結果をGithub Enterpriseに表示する

自分的には「良いはず」と思ってやっているものなので実際に効果はそこまで出ていないものもいくつかはあります。
例えばhubotです。
最初の数日はping-pongして遊んでいたりしましたが実際に仕事のお手伝いまでできてはいない状況です。
（つい数日前にPull Requestを見られるようにしたので使われるか・効率化するかどうかを様子見中です。）

とはいえ個数としてはざっと20個近くでしょうか。
営業日とほぼ同じ個数ですので今のところはうまく一日一善できてるかなーといった状態です。

そもそも課題も多かった

見ていただくとわかるとは思いますが、各種バージョンの対応やテスト周りなど結構基本的なものも多いです。
続けられた理由の一つとして改善すべき箇所が多かったというのもかなりありますねw

最初１ヶ月はうまくいったのでこの先にどうしていけるかが重要そうです。

毎日何かを変えるということ

この記事を書いていて有名な自己啓発本「仕事は楽しいかね」のことを思い出しました。
ストーリー仕立てでかなり読みやすいのでぜひ一度読んでみてください。

仕事は楽しいかね？

この本の中で成長のために「明日は今日と違う自分になる」ということが語られています。
エンジニアとして決まった仕様を実装するだけでなく、能動的に動いて昨日より少しでも良い（と思う）状況にしていくことはこの思考とわりと近いのかなーなんて思います。

まとめ

一日一善することで気分は良いし成長にもつながるはず

１ヶ月続けてきて今のところはこんな感じの感想です。
hubotなど現段階では改善につながっているとは確信できていないものもありますが、着実に毎日いろいろなことに着手していき自分にとってもチームにとっても良いものを提供できる確率（ヒット率！）を上げていきたいです。

なぜJava以外のプログラミング言語でAndroidアプリを作ろうとするのか

こにふぁーさんのツイッターでこんな発言を発見しました。

AndroidをGoやRubyやHaskellやKotlinで書いたよって話、どうしたらそういう情熱がわき上がるのかわからないし本当すごいと思う

— こにふぁーあぁぁん？ (@konifar) 2015, 7月 24

自分もたまに「Java以外のプログラミング言語でAndroidアプリを作る」ということをするクチです。
（Androidに限らずいろんな環境でいろんな言語を使おうしますね。）

具体的には、最近だとKotlinで瞬間タイマーというアプリを作ったりしてます。

なぜ自分が他の言語で書こうとするのかを今ぱっと思いついた範囲でまとめてみます。

新しい言語を学ぶ機会として"ついでに"アプリを作っている

真っ先に思いついたのはこちらです。
一番の目的は「新しい言語を学ぶこと」で、その手段として「アプリ(などなど)を作りきってみる」という順ですね。

プログラマーのバイブルのひとつ「達人プログラマー」にも「毎年一つは新しい言語を学べ」といったことが書かれているのでこれを実践している感じですね。

達人プログラマー―システム開発の職人から名匠への道

実際にやってみると言語によってのなじみやすさや記述方法の違い、パラダイムの違いを感じられてかなり楽しいです。

自慢気に記事を書いたり他の人と話したい

次に思いつくとしたらこちらです。ゲスいww

あるプラットフォームにおいて標準以外の言語を使えるのは（当然ですが）プログラマー全体に対してかなりの少数派です。
となると他のそこに優位性が出てきます。

勉強会やQiita、Twitterでもその言語に関する話題で先導できて、ちょっとだけ嬉しい気持ちになります。

しかし良いことばかりではなく…

単純に一度別の言語で作るだけならとっても楽しくて良いんですが、やっぱり辛い面もあります。
大きくは以下の様な点です。

• テスト/インスペクション/ドキュメンテーションなどに少しでも踏み込むと情報が少なすぎる
• 時間を開けるとまともに開発できなくなる
• 他の人と作業しづらい

テスト/インスペクション/ドキュメンテーションなどに少しでも踏み込むと情報が少なすぎる

「ただ書いてただ動かす」だけなら困ることは少ないですが、アプリを一つ作るなどある程度の実用レベルで使おうとするとそうはいきません。

単体テストや結合テスト、システムテストは基本的には必須ですよね。
加えてFindbugs/PMD/Checkstyle/Lintなどの静的解析や、JavaDoc的なドキュメント生成もしたいです。

ところがこのレベル（そんなに高くないですが…）の話になってくると一気に情報量が少なくなるのも事実です。
公式ドキュメントなどに沿ってすんなり動けば良いのですが、よくわからない依存関係に陥ったりして解決までかなりの工数を要することもあります。
Javaを使ってればすぐできるのに…といったことも多く心が折れそうになります。

継続的インテグレーション入門

時間を開けるとまともに開発できなくなる

初回リリースまでなどは大丈夫なんですが、数週間〜数ヶ月空くだけで再度作業するのはかなり難しくなります。

理由としては「言語仕様を忘れる」と「ツールの対応状況が変わって動かすまでが大変になったりする」という２点です。

人間なので「言語仕様を忘れる」はしょうがないですよねw しばらく書いていないとすぐに細かい記述方法などは忘れますw

「ツールの対応状況が変わって動かすまでが大変になったりする」はAndroid StudioのバージョンやKotlinプラグインのバージョンの更新などです。（依存ライブラリの状況も変わったりしますね）
少しでも時間が空くとこのあたりを整理したうえで開発作業に入らなければいけなくなってしまって大変です。

他の人と作業しづらい

一人で作業するときは良いんですが、他の人ともソースを共有して一緒に開発しようとすると大変です。
当然ほとんどの人にはイチから言語仕様や独自環境などを把握してもらわないといけないですよね…

工数対効果などで絶対にその言語にする方が良い！と自信があれば良いですが、ほぼそこまでの自信を持てることはないのが実情です。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

まとめ

僕個人は基本的には「他の言語を学ぶため」にしばしば標準以外のプログラミング言語で開発をします。
この動きを通して他の言語での実用レベルの開発などを体感できてかなり楽しいです。

ただし実際の運用では難しい点がたくさんあるのも認識しているので、目的が「きちんとプロダクトを作る」であれば標準の言語を使うのかなーと思います。
（言い換えると記述が簡単やパラダイムが良いものだから、などの理由だけではプロダクトで標準以外の言語を使うことはほとんどないのかなーと思ってます。全体のバランスですね。）

以上です。

チームを、メンバーを、信頼する

ここ数年色々なチームに関わってきて、チームの結束にはどんなことが必要かを考える機会も多かったです。

具体的な表現は難しいですが、"信頼"というのが一つのキーワードにはなるだろうなーと思っています。

そこで今回は開発チームあるいはメンバー間における信頼にはどんなことが必要なのかを僕なりにまとめてみました。

頭ごなしに否定をしない

明確な理由なくメンバーの主張を否定してはいけません。

特に感情的な否定は最悪です。

否定する側は嫌われやすくなっていき、否定される側は「どのみち否定される」と思ってしまい意見を言いづらくなってしまいます。

まずは「そういう主張もあるんだなー」と中立的にとらえましょう。

否定する場合はきちんと数字、実績などの根拠を持って話しましょう。

監視をしない

他のメンバーの作業を監視し、「あれが足りない」「ここが良くない」と一方的な指摘をするのはやめましょう。

監視される側は自立できなくなってしまい、監視する側は監視に時間を取られて自分の仕事時間がどんどんなくなってしまいます。

もし目に止まってしまって何か気になることがあっても「あれのこと忘れてない？」「ここをこうするともっと良くなるよ！」と"確認"や"提案"のニュアンスでコミュニケーションするようにしましょう。

誰か一人のせいにしない

「あの問題は⚪︎⚪︎さんが◽︎◽︎した(しなかった)から起きた問題だ」といった問題点の属人化はやめましょう。

たとえそれが間違っていないとしても、言葉にしてしまうとお互いに敵対心が芽生えチームの雰囲気はどんどん悪くなってしまうでしょう。

問題点を個人ではなくチームのものとして言語化し、仕組み化するなどして着実に解消を目指しましょう。

隠さない

例えばチームに関して何か良くないことがあったときにマネージャーにだけ個別で言うのはやめましょう。（どう考えてもそれが適切な場合を除く）

そうしたことを続けているとどうしても「あの人は心に壁がある」「他のメンバーを信頼していない」と思われて、孤立していってしまいます。

基本的にはオープンな態度を取り続けましょう。

チームにあったことはマネージャーにも伝えつつ、チーム内で建設的な話し合いを持ちましょう。

傲慢にならない

「あの人には荷が重いから」「あの人はまだスキル不足だから」「自分がやった方が早いから」といった思考をベースにした行動（難しいタスクは常に自分が取ってしまうなど）は捨てましょう。

暗黙的に「自分はその人に比べて全てが優れている」と思い込んでいませんか？

こうした思考による行動を続けるとメンバーの成長は妨げられ、チームはある一人のための存在になっていってしまいます。

人は成長すること、人それぞれ能力は違うこと、を意識して行動を起こすようにしましょう。

まとめ

ライフハッカーの記事みたいになってしまいましたw

今回まとめてみて「数値化できないような人間の態度や思考が大切なんだろうな」ということを改めて感じました。

是非みなさんの意見も聞かせてください。

メモる機会を逃さない

僕は毎日片道約１時間の電車通勤をしています。

普通のサラリーマンなので通勤ラッシュ時間帯に電車に乗ることも多く、席に座れることはほとんどありません。

 

こうして１日２時間も電車に乗っていると、仕事や個人で関わっているプロジェクトのことを何気なく考えてしまうことも多いです。

 

そんな風に軽く考えているときに限って出てくるのがアイディア。

どんな風にそうしたアイディアをメモっているかをまとめておきます。

 

まずはスマホ

これはもやは当然ですね。

iPhoneとAndroidを二台持ちしているので、その日の気分によって端末を使い分けています。

 

実際にメモるときに一番よく使うアプリはevernoteです。

位置情報が入る、写真を入れられる、など色々と機能はありますが単純に「他のスマホやPCで後から見やすい（同期されている）」といった理由からこのアプリを使用しています。

 

（但し、evernoteでも正直そこまで満足いってないです。なんというか、スピード感はいまいちですよね...）

 

スマホだと絵や図が書けない！

テキストで表現できるような情報をメモる場合は前述したevernoteなどを使えば全く問題ありません。

 

ところがふっと思いつくアイディアなんかはテキストでは表せないようなこともかなり多いです。

イメージを絵や図で表現したくなることも多々あります。

そのあたりのニーズに対しては多数あるお絵かき系のアプリが合致しているのかなーとは思うのですが、思考そのままの表現・スピード感で書けるようなレベルのアプリはほぼ皆無ではないでしょうか。

 

ノートを持ち歩く

このようにスマホだけではメモりきれない問題に対して「スマホとほぼ変わらない大きさのノートを持ち歩く」僕は結局これに落ち着きました。

ノートはなんだかんだ言って2015年現在も非常に使いやすいツールです。
思ったことを絵や図で、しかもものの数分程度でササッを書くことができます。 

ノートを選ぶ際は、いつでも手軽にノートを取り出したい、ということからノート自体の大きさにもかなり注意をしています。

具体的には「スマホとそこまで変わらないような大きさ」を重視しています。

サイズで言うとB6などでしょうか。

ミドリ MDノート<文庫> 無罫

この大きさであれば電車内で使っていても人に当たってしまうことはほとんど無いでしょう。（真似される場合もペンの扱いには十分に注意しましょう！！）

うまくツールを使い分ける

ここまでで「スマホでメモる場合」と「ノートでメモる場合」の話をしました。

結局のところ「メモる」という行為に対しても銀の弾丸はない（状況次第で適切なツールは変わる。絶対的でいつでもかんたんに使えるような完璧なツールはない。）のだろうなーと思いました。