英会話を始めた

プログラマーとして生活をしていると、英語の読み書きは自然にできるようになってくるものと思うけども、日本人にありがちな話す聞くがすごく疎かというパターンに僕もハマっており、たまに海外旅行するとなんて話したのかは分かるけど脳内の語彙と今聞いたものを一致させる力が足りずだったりとかで歯痒い思いをすること数回、とうとう英会話サービスを使い始めてみることにした。

一応しばらく海外に滞在する予定もあることだし、もっと速く始めておくべきだったなあと自分の重い腰が恨めしい。

始めたのはネイティブキャンプです。

nativecamp.net

僕は学習においては「習うより慣れろ」と反復が肝要であると信じているので、回数が大事だと思って回数無制限サービスであるこちらへ。回数無制限でも随分安いらしいです。回数無制限以外にあまり比較検討してないので他サービスの詳細は知らない…

さすがに初めてのコースは詰まることなく終えられたけど、過信せず初級者コースから順番に進んでいこうと思う。

Joy, Inc. を読んだ

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

先月に出たばかりの本。原著は数年前のはず。先月の退職祝いで頂いた。

本書は日本語になる前から身の回りでこの会社のファンも数人いることを聞いていて、出たときには早めに読んでみたいなと思っていた。良いタイミングでいただけたので帰省で時間もあったので一気に読めた。

本書はエクストリーム・プログラミングを契機として、「喜び」のある仕事を目指した経営者の本である。アジャイル開発の話は出てこないが、いわゆるアジャイル開発・スクラムにとても近い考え方、実践が多く出てくる。なのでそれぞれは珍しくないかもしれない。それでもこの本は他のアジャイル開発・スクラム等の解説本と違い、それで実際に成功している会社であるという説得力がある。

原理主義的なところもありつつ、そのときどきの従業員の都合で新しい制度を「実験」するという姿勢がとても好感が持てた。私も「まずやってみて、だめだったらその時考えよう」と常に言うので、誰にも分からないのだからまずやってみよう、だめだったらだめだったというノウハウが残るわけで、とても合理的なことだと思う。

また、常に実験中であるという考え方もとても良いと思った。良いものは変わっていく。今みんなが良いと思っているものもそのうち変わってしまうかもしれない。「変化を抱擁せよ」の姿勢である。

あと、通り過ぎてきた「あるある」のネタが各所にある。自分で読んでひとつも「あるある」な感じにならないとしたら、よっぽど素晴らしい環境にいるか、鈍感すぎて問題を見れていないのだろうと思う…

ノウハウが細かく説明されているわけではないので、変わるためのきっかけづくりの読み物としてもオススメ。

プロテインとかBCAAとかHMBとかで混乱したので調べてみた

qiita.com

筋肉アドベントカレンダーに空きがあったのでちょっと前に書いたこの記事を滑り込ませてもらった!


私の趣味の一つに筋トレが挙げられるが、この界隈はいろんなサプリや栄養素にうるさい。にも関わらず多くのサイトには大雑把な説明で「~が最強」とか「これだけで十分」とか書いてあるところばかりで不信感が募ったので個人的にこれで良いのかなと思うぐらいに調べてみた。

これは独自研究です

栄養素の大元は一緒でより分解された状態かどうかが違う

吸収にかかる時間

プロテイン > BCAA ? HMB

栄養素の効果

  • プロテインは筋肉以外にも人体のあらゆる部分を構成する要素なのでそもそもとらないと体に異常が起こる。不足しがちな栄養素なため、筋トレする/しないに関わらず取ったほうが良いと思われる。ビタミン剤と同じような理由で摂取すべき。コラーゲンとかももちろんタンパク質である。
  • BCAAは前記の通りタンパク質を分解して得られる特定のアミノ酸のことであり、これらには即効性のエネルギー、疲労回復、筋力増強効果(タンパク質合成促進)、肝機能改善、髪や肌のハリ・ツヤの改善効果等がある。
  • HMBはBCAAのうち筋力増強効果を持つロイシンを吸収した結果生成されたものだけを抽出したもの。ロイシンの5%程度が生成されるそう。

結論

プロテインをとれば最終的には全ての栄養素が得られる。吸収速度と必要量の問題である。筋肉はトレーニング直後だけでなく、常に合成、分解を繰り返しているので、タンパク質(アミノ酸)は常に充足している事が必要。

筋トレ前にエネルギー源がある程度無いと筋肉が分解されてしまうので、計算した内容や時間で食事、プロテインでカバーできるならそれで良いし、無理なら代替燃料になるBCAAを取る必要があるだろう。

トレーニング直後の栄養素においても筋肉の生成に必要な栄養素が十分なら筋肉の成長には問題がないので、結局のところどれでも良い。個人的にはHMBは極端すぎてわざわざ摂取するにはコストパフォーマンスに劣る、かつ筋力増強以外の効果もある他の2つの摂取の結果、超過摂取につながることになると思われる。なお、HMBには超過摂取の結果筋力が落ちた、という実験結果もあるとのこと。

私としては、トレーニング前の筋肉分解を防ぐ目的のBCAAとタンパク質自体の不足を解消しつつ、筋肉を合成するために必要な栄養素として吸収時間の長いプロテインを飲んでれば十分かと思った。

参考リンクはめっちゃあるのだけど多すぎたのでまとめきれず。

リクルートジョブズを退職します

shishi.hatenablog.jp

上記エントリ冒頭の通り、リクルートジョブズを退職することにしました。現在は有給消化中です。

上記エントリの通り、もともとこれをやってほしいと言われていた仕事がなくなったことを初日に知ったり大変な幕開けで始まった今回の職場でしたが、大変なままあれやこれやとやり、大企業らしいあれやこれやにボコボコにされながら、会社に前例がないことばかりに取り組んで成果も残し、自分としてはやりきった感でいっぱいです。

理由の最初はリモートワークなど柔軟な働き方を重要視するようになってきたことです。弊グループはグループとしてリモートワークに取り組んでいることは既報の通りですが、もちろんそれぞれの会社、現場によって変わることがあり、それでは私の理想は実現できなかったからです。

次にはいわゆる音楽性の違いというやつです。現状の問題点、行動の仕方、組織のあり方、これからどうしていきたいかという色んな考えの向いている方向が合いませんでした。方向の違う主張が譲れないポイントが同じ者同士が同じ枠にいては組織が混乱します。話し合いはしたもののお互い折れることができない部分だったので、残念なことでしたが仕方ありません。

あとは評価制度の合わなさも理由としてあげられます。評価制度に囚われた人達を良く見ましたし、それは悲しいことだと思いました。上記エントリで僕のやってきたことの一部を紹介しましたが、何も評価にはつながりませんでした。もちろん私の思うこととは違う別軸の見方があるということは分かっていますが、それでは私はプロダクトやエンドユーザー、チームメンバーの方向を向いて働くことなく、評価のために働かなければならなくなるでしょうし、それは私のしたいことではありませんでした。

良かったところとしては福利厚生が一番かと思います。退職金制度があるという企業自体が初めてでしたが、なんと半年働いただけで退職金があったり、3年勤めれば30日の連続休暇があったり、子供のいる人には特別に有給休暇も多く与えられていたり、立派なものだと思います。あとはなんといってもオフィスの立地です。銀座のバーやクラブが集まり、飲食店がこれでもかとあるエリアにあり、さらには新橋や日比谷にも近く、ランチや飲みに行くのには全然困りませんでした。特にバーは有名でうまいところがオフィス近辺に集中しており、通っていくつも名前を覚えてもらったお店があるほどです。あれほど飲食に恵まれた立地は他にないでしょう。

これはどうだったの?ってのがある方は僕を飲みに連れていくと話せることは聞けるという特典があります。

今後はしばらくフリーランスとして過ごす予定です。遠くない将来に言語と文化を学ぶため海外にしばらく滞在したいという希望がありますが、現地に永住したいとも思っておらず、こちらに仕事を持ったままリモートワークさせてくれるところを探しており、フリーランスのほうが色々と都合が良さそうだったからです。このような条件でも受け入れてくださるお仕事、もしくは日本にいる間だけでもお仕事のお話あれば連絡いただければと思います!Railsを始めとするサーバーサイド、テスト、CI、開発手法、開発環境整備、チームビルディングなどをよくやってきましたのでその辺ですと特に貢献しやすいと思います。直近はSwiftもやっていました。委細は@shishi4twやFacebook、コメント等でご相談いただければ、職務経歴書等お送りします。

退職祝いだ!という方向けのリストはこちらになります。 http://www.amazon.co.jp/registry/wishlist/3BIKP4J827Y16/ref=cm_sw_r_tw_ws_x_kPbryb9NNM4SR

大規模サービス技術入門を読み直した

読み直したシリーズ。当時の仕事は規模や負荷がそんなでもない、というかフロントエンド側なのになぜか気になって読み直した。

本書はソーシャルゲームを始めとしたアクセスが膨大なウェブサービスはどのように設計されているかについてハードウェアやら実際のプログラミングやら現場やらについて書かれた本である。調べてみるともう約7年前の本…

本書に書かれていることは多くが今や当たり前のようになっているけども、当たり前ながら以前は多くの試行錯誤だらけのことの上に成り立っている。本書は僕を含め多くの人が阿鼻叫喚を上げながら積み上げてきたことのエッセンスが記されており、今の当たり前がなぜかを知るという意味で、今でもとても有用な本の一つであると思う。

本書は広く話題を扱っており、大規模サービスに触れる人への入門として良書であると思う。ある程度バックエンドに親しんだ人にも触れたことがない話題もたくさんあるだろう。著者が日本のウェブサービスが大規模になっていく黎明期において試行錯誤してきたことを覗けて、ある意味読み物としても面白い。

本書は良く必読の技術書としてあげられていることが多いように思うけども、僕も賛成する。どこまで基礎を知っておかなければいけないかというのはこの際置いておいて、本書は個人的にちょうど良いのではないかと思う。基礎は応用の源泉であり、基礎を知っておかなければ応用する発想自体が出てこなくなると思っている。とはいえCPUの原理とかまで納めていると時間が果てしなくかかるので割り切りが必要なのであるが、とりあえずバックエンド設計の基礎としてとりあえず知っててほしいと思うことがこの辺だからである。能力と時間のある限り、知らなくても良いということはそんなにないと思うので、興味を持ったらもっと広く深く学習すべきだとは思う。

プログラマーに広くおすすめできるので読んだことない人は是非。

Team Geakを読み直した

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

読んだけど読書録に書いてない本が増えてきた。最近は読み直した本が多い。特に何かを必要としたわけではなかったけど何となく読み直した本が幾つか。本書もその一つ。

本書は理想的なチームのあり方、作り方についての本である。出版当時には結構話題に出たことが多かったように思う。 Googleでの話ということもあり、ソフトウェア開発の人たちに向けての内容となっている。Geakというのはコンピューターマニアみたいな意味の言葉だけど、その言葉にはあまり意味があるわけじゃなく、良い開発チームとはといったことが説かれている。

本書は出た当時はさらっと読み流しただけだったけど今読み直してみるとほぼ私の普段意識していることと同じことが書かれていると思った。この本を流したときに覚えたことか、本書に影響された人達の言説に多く触れたからか分からないけども同じふうに賛同する人は多いと思う。

特によく目にするのはHRTの原則である。Humility、Respect、Trust、つまり謙虚、尊敬、信頼である。チームメンバーにはこれらの心がけを持って接すべしということである。自分の感覚としてもそのような態度で接されると仕事がやりやすいし、そのような相手には自然と同じようにHRTの気持ちを持つようになるということが分かる。こないだまでやっていたプロジェクトではプログラミングキャリアのないメンバーとばかりのチームであったが、まず必ず相手の話を聞き、それから自分の考えを話すことを心がけていた。それは謙虚や尊敬に当たると思う。頭ごなしにしたくなかったり、経験がなくともより良い考えが出てくることはあると思っていたからである。また、個々のタスクのマイクロマネジメントはしないようにも心がけた。たまに困ってないか聞くことはあったけど、信頼して任せたのであるから必要以上に干渉すべきでないと思ったからである。細かく進捗を気にされると煩わしいものでもあるし。どれも私自身の経験から今取っている行動だけれども良いチームを目指そうとすると行動は近くなるものかなと思った。

自分にはチームの理想像があって、だいたいが本書と一致していたので自分の考えがある程度受け入れてもらえるものかと思う本となったが、自分の理想を探している人や、開発チームが何を求めているのか分からない管理職の人にもおすすめできる本かと思う。というより私としては管理職の人にはぜひ読んで欲しい。現場と管理職の人とは考え方の乖離があるのが世の常であるので、開発チームにとって何が快適なのかを理解してもらうには良い本だと思う。

プログラミングキャリアなしのメンバーばかりと自分のチームでObjectiveCからSwiftへ移行したことについての日記

弊グループアドベントカレンダーの記事ですが本日最終出社を迎えますshishiです。

www.adventar.org

前置き

  • これは日記です
  • 技術的な詳細の話はしない
  • 特にためになりそうなことは書いてない

経緯

4月に入社。入社がそもそも紹介で、とある仕事のために僕が必要ということで誘われて入社したものの入社したときにその仕事はなくなってしまっていた。さて何をしたものかと思っていたらやったことないObjectiveCからやったことないSwiftへの移行プロジェクトをすることになった。なお僕個人は別の1人プロジェクトもやっている状態。

メンバー

私自身はRubyPHPPerl、あとは趣味で雑多に色々とやってきたプログラマー。開発リードをすることに。

実はもともとタイトルのような大変な感じのプロジェクトではなく、プロジェクトの話が出た頃にはObjectiveC版をメンテナンスしていた数人と一緒にやるはずだった。しかし、いざ始めましょうかという段取りになると不思議な力でもともとメンテナンスしていた人達が全員別プロジェクト(地理的にも別、アドバイスを求めることも諸事情で難しい状態に)へ行くことに。残ったのは新卒(プログラミング経験あり)2人、プログラマーへキャリアチェンジしたばかりの1人(プログラミング経験無し)と私。全員ObjectiveCもSwiftも経験無しというなんともワイルドな感じになる。

プロジェクトを始めた後にさすがになんともならんということで僕を弊社に誘った張本人の1人(Java、Groovyプログラマー)と、その人と一緒に別の仕事をすることになっていたプログラマーへキャリアチェンジしたばかりのもう1人(プログラミング経験無し)を引きずり込み、自分のツテでObjectiveCもSwiftもできるフリーランスiOSアプリケーションプログラマを1人業務委託で連れてくることに成功し最終的なメンバー構成に。

プロジェクトでやりたかったこと

  • アプリケーション自体はビュー数も多くなく、自社サーバーに用意されたAPIを利用してほげほげな操作をする。詳細は不思議な力で書けない。
  • 今後のメンテナンスを考えたObjectiveCからSwiftへの移行。移行すること自体が第一の目的。
  • アプリケーションの画面デザインを全画面変更。ビューの構成要素自体はあまり変わらないが見た目的なものはほぼ変わる。
  • 予定期間は4ヶ月強

やってきたこと

プロジェクト開始前の私が入社してすぐぐらいはメンバー達にプログラミング基礎教育をしていた。言語としてはRubyを使い、数冊のRubyの本を輪読したり、Railsチュートリアルを2週したり。この輪読は色んな所で好評なので興味があったらまた会ったときにでも聞いてみて欲しい。なのでメンバーは大きくパラダイムが変わるのでない限り、なんとなく書いてあることは理解できるぐらいだったと思う。僕自身はSwiftのチュートリアルや入門書をいくつか済ませておいた。ObjectiveCについてはなんとなく読めればいいや以上の学習はしていない。 メンバーにはさらっと文法だけでも理解しといてね、と自習する時間をとってもらった。

言語移行に際して段階的にObjectiveCのコードにSwiftを混ぜていくか一気に作り直すかという方法があり、一気にやったほうが良いのではと思い友人数名に相談してみたところ、ほぼ一気にやったほうが良いという返事をもらったのでSwift新規プロジェクトを作り直すことに。

ObjectiveC版のコードはまさに秘伝のソース状態。やはりプログラマーとしては移行したついでに綺麗に直してやるぜぐらいは思っていたんだけども、これを直せるようメンバーを教育しながら移行していくことは無理だと判断。移行するという目的自体を第一に優先すべく、分からない部分はとりあえず動くという状態のままSwiftコードへとしていこうということにした。この当時は新デザイン案もまだまだ固まっていないことも合わせて、既存の画面デザインのままとにかくSwiftへとコードを移すことを優先した。この先何が間に合わなかったとしても第一の目的だけはという感じ。

この「とりあえず移行しよう」を優先したときに付け加えたことは2つあり、一つはStoryboardをビューごとに分割すること。これは人間が自分で内容を管理するものではなく、生成されたものを受け入れるしかないのが基本のXMLにも関わらずアプリケーション全体で一つの状態であったので、これからの移植、チームでのメンテナンスの際にさすがに看過できないデメリットになると判断したためによる。もうひとつはデーターベースアクセス、及びモデルとして定義されている部分についてユニットテストを書くこと。ほとんどのロジックはコントローラーに書かれており、ちゃんと分割されているわけではなかったので効果としてそれほどのものは得られないだろうということは予測できたが最低限自動的に誤りが見つけられるようにということと、後々テストを全体に整備できるようにするための教育含み。あとは多々ある言語の機能の違いをどうするかというのは早い段階で話し合って決めた。(letやvar, StringとNSStringなど)

移行する単位は画面ごととした。いろいろな画面で使われている共通メソッドみたいなものもあるが、担当した画面に関係のないものは一切無視して構わないことにした。区切りを分かりやすくしたかったこと、画面をつなげて動かすことを優先したかったこと、移行元に不要なコードが多く予想できたので切れるコードは早期に切りたかったことによる。割りと機械的にであればこの程度の学習量でも進まないことはないなと思った。とはいえ当たり前ながら機械的な移植では動作が変わってしまうことは多くあり、その際には仕様を維持できるように相談して実装していた。ついでに実装がまともに近づくことになったのでこのある程度考えるプロセスがあったのも結果的に見れば良かったのだと思う。

メンバーみんなでうんうん唸りながら数画面移植できてきたところで、上記の唯一まともにプロジェクトに必要な技量を持つプログラマーである友人が参加してくれたので、そこから開発が加速した。言語の文化、常識を聞いてメンバーの作業も早くなり、彼本人の作業もあって移植が進むようになった。まさに救世主状態。

移行作業中にはライブラリ管理をやり直したり、非推奨メソッドを代替してみたら動作が変わって大変なことになったりとそれはもうみんな困ったのだがそこはまたいずれ。

そのまま期間の大半を移植に当て、それっぽくアプリケーション全体を動かせるようになったところでコード行数を計測したときは不要なコードの多さと言語を替えたことによる圧縮効果が凄まじく、30%程度になっていたと思う。

単純にコードを移し替える上記の移植がだいたい終わったところで画面デザインの変更に取り掛かったのだけども、こちらのデザインの人もスマホアプリのデザイン初挑戦という方とうこともあり、テイストを崩さないように、かつ開発のやりやすいようにだいぶいろいろとデザインを一緒に試行錯誤させてもらった。

実際にその新デザインをStoryboardに当てていく際にはだいたいのメンバーがつらい移植を乗りこえてきただけあり、スムーズにデザインの変更を当てていくことができた。これは私自身が思っていたよりメンバーが成長したなと思った部分だった。デザインの移行が早かったこともあり、この時点で全体にUIテストを書くことができた。なおこのUIテストはそもそもテストフレームワーク自体がものすごく不安定で遅く、ここまでの開発で積もり積もったXcodeへの憎しみが倍増するきっかけとなった。

今回はありがたいことに外部からQA用人員を呼んで良かったので、だいたいデザインが当てられた頃から細かい動作検証をしてもらえた。開発者テストさえ上記のように十分ではなかったこともあり、このQAがなかったらどんなひどいアプリケーションができていたか…

メンバーへ思うこと

実際プログラミングを学習し始めるには既に動いているアプリケーションの一部を改修していき、小さいところからより広げていくのが一般的な気がしているけども、今回は会社の都合とはいえハードなことをメンバーに課すことになってしまったと思う。できた教育も十分ではなく、終始OJTできつかったと思うが、1人も抜ける人なくリリースできて良かったと思う。

教える時間が十分ではなかったので一つ一つの知識を教えても覚えられないと思い、できるだけ考え方を終始伝え、そこからどうすれば良いんじゃないかと教えた。我田引水すれば長期的には考え方が大事で知識は都度覚えていけば良いものであると思うので、それが今後役に立てば良いなあと思う。

これから

本当はもっと整理して書くつもりだったんだけど書いてるうちにいろいろ思い出して完全に日記になってしまった。まあこういう変なのがアドベントカレンダーに紛れててもいいかと思いそのままにする。

このブログは12/2に予約公開設定してある。公開する頃にはもうアプリケーションは僕の手を離れているはず。十分にやりきれないことはあったけどもメンバーの努力で制限の多い中最上のものになったと思う。移植を通して未経験ばかりだったメンバーは大きく成長したし、リファクタリングの順序や方針、Realmへの移行等々直すべきことの方針は共有してあるし、これから今までの苦労を次にメンテナンスする人達に被せないようにする作業を通してアプリケーションがずっと良くなっていくことと思う。

なお冒頭の通り私は12月で退職する運びとなっている。しばらくフリーランスとして過ごす予定です。近い将来タイムゾーンがずれるリモートワークでも良いという条件でお仕事あればぜひご連絡ください!