console.blog(self);

技術、読んだ本、いろいろ。

半年のふりかえり

あっというまに半年が過ぎた。今年もあと半分。ふりかえり。

ダイジェスト

1月に入社した。フロントエンドもサーバサイドもがりごり書いていこう思っていた。ちゃんと初心が残っているのがよい。

いろいろ書きつつインフラも見つつ、デプロイやコードチェックをしながら毎日を過ごしていたらあっという間に1ヶ月が過ぎた。

そのうちシステム全体のいろいろなことを任され、コードを書く時間がちょっと減ってきて、なんだか変だなーと思っていた。そして2月中旬にこれまでメインで開発していたエンジニアの方が退職すると聞いて、びっくりするとともにちょっと納得した。

まあ、いろんなことがあるよね、と思いつつ、3月以降の業務はマネージメントが中心になった。以前はまったく楽しくなかったマネージメントが、このチームではけっこう楽しかった。チームのエンジニアはみんな優秀な人たちで、自分は現在のチームに足りない部分を補っている感じがした。とはいえなかなか大変だった。

その後、大きな機能を2つリリースして、ちょっと落ち着いて、マネージメント以外の技術的なこともあれこれしながら日々を過ごしている。

毎日があっという間に過ぎていく。もう2年くらい経った気がする。

開発のあれこれ

ちょっとまえに、取材してもらった。どうやって開発しているか、よくまとまっていると思う。

Prottではこんなものを使ってる。最先端とはいかないけど、けっこうモダンな開発環境だと思う。

この半年、チームでいろいろなことやってきた。大きなリリース。

Prottは正式リリースから10ヶ月くらい経った。ちょっとずつたまってきた技術的負債を、ちょっとずつ返済するため、いろいろバージョンアップしている。セキュリティのhotfixにも対応している。

これまでは機能開発を優先していたけど、いまはパフォーマンスチューニングを頑張っている。

Railsのレイヤーではbulletやstatsprofを使って、測定と改善をしている。インフラもSPDYいれたり、チューニングしたり、バージョンアップしたり。New RelicやMackerelを使ってサービス全体の計測も行っている。フロントエンドはChrome Developer ToolsでTimelineみたり、Profileとったり、HARとったりして計測と改善をしている。

自分自身がコードを書いたり作業したものは少なくて、チームメンバーが対応してくれている。僕だけでは、これだけのことをとてもこなせない。チームや会社を巻き込んで、こういったことに取り組んでいけるのがとてもよい。継続的なメンテンナンスの重要性を説明して、それを理解してもらえている。

マネージメントのあれこれ

プロダクトマネージャー、プロジェクトマネージャー、プロジェクトリーダー、とかマネージメントをする立場の人の呼び方はいろいろあるけど、自分にとってはスクラムマスターかアーキテクトがしっくりくる。

入社したときは12名くらいだったチームが、いまは18名くらい。半年で1.5倍になった。

これまで経験したプロジェクトでは、エンジニアが増えるのはあまり嬉しいことではなかった。プロジェクトのスケジュールを守るために、帳尻を合わせるために、頭数としてエンジニアを追加するという意図が明確だったから。

でもいまはエンジニアが増えるたびに、チームとしてできることが増えている。メンバーが増えたら、できることが増えるようなチームにしたいと思っている。

こんなことを考えながら、マネージメントしている。

相手がエンジニアでもデザイナーでもセールスでも、マネージメントってそれぞれの人が最高のパフォーマンスを発揮できる環境を作ることだと思っている。メンバーには得意なことを存分にやってもらう。それ以外のことを引き受けるのがマネージャーの仕事になる。かなり大変で、とても難しいけど。

もちろん大変なことはそれなりにある。いろいろなものが揃っていないけど、無いものを嘆いてもしかたないし、ある程度わかって入社しているし、足りないなら揃えていけばいいと思っている。

6月から毎週金曜日を bug fix & document day にしている。 金曜日にバグを潰したり、ドキュメント書いたりすることを推奨している。特に決まりはないけど、いい感じにバグを潰して、ドキュメントを書いている。未修正のバグはたまっていくし、開発しているけどドキュメントがあまりないし、いろいろ揃っていなかったから、揃えていきたかった。

こういうことを考えて、実行していけるのは楽しいし、やりがいもある。

まとめ

僕はデザインの大切さを意識するし、経営層は技術の重要性を理解してくれる。そしてお互いに品質を大切にする。そこで不毛な議論がなく、根底の部分での認識にずれが少ない。こういった認識が通底しているのはとてもやりやすい。

自分の技術者としてのバックボーンがマネージメントを支えていると思う。いまはあまりコードを書いていないので、技術的な成長は鈍化している。これまでの貯金を使っている感じ。

でも貯金が減ったら、また貯めればいいじゃないか、と思っている。好きな技術調べて、勝手にコードやblog書いて、また勉強すればいい。そうやってエンジニアとしてやってきたんだし。

いまは、いましかできないことをやっている感じがある。プロダクトととも成長するというより、プロダクトを成長させたい。

アラン・ケイのこの言葉をたまに思い出す。

未来を予測する最善の方法は、それを発明することだ

The best way to predict the future is to invent it.

アラン・ケイ - Wikipedia

この先どうなるのかさっぱりわからないけど、試行錯誤を続けながらよいサービスを作りたい。

We are hiring!!

いろんな職種で募集している。

一緒にProttのサーバサイドを担当してくれる人が来てくれるとうれしい!興味があればぜひ。

おまけ

もう半年たったら年末になる。いったい何をやっているのか想像もつかなくて楽しい。

UIデザインの心理学―わかりやすさ・使いやすさの法則

「UIデザインの心理学―わかりやすさ・使いやすさの法則」を読了した。 書籍はインプレスさんからいただいた。ありがとうございます。

心理学というより、認知心理学といったほうがしっくりくる内容だった。

認知心理学(にんちしんりがく、英語: cognitive psychology)は、情報処理の観点から生体の認知活動を研究する学問である。20世紀前半のゲシュタルト心理学やバートレット、ピアジェヴィゴツキーらの認知論的研究の流れを汲む分野であり、同時にハル、トールマンらの新行動主義心理学の発展形と見ることもできる。20世紀最後の四半世紀以来、現代心理学の主流の座にあると言える。

認知心理学 - Wikipedia

デザイナーではないので、認知心理学をどうやってUIに活かすかというよりも、自分はこうやってUIを認識しているのかという驚きと気付きが多かった。

例えば「第5章 周辺視野」ではこんな図(中心窩が[ログイン]ボタンに向けられているときのユーザの視野の様子を再現したもの)があって、納得した。 ログインボタンだけはっきり見えて、その中心から外れるほどぼやけていく。

これまでに「ノンデザイナーズ・デザインブック」や「誰のためのデザイン?」といった本を読んでいたり、認知心理学認知療法の本を読んだこともあったので、ある程度背景知識があったことで、わかりやすく読めた。また図表が多く理解しやすかった。さまざまな事例や研究結果がまとまっていて、これだけの内容をこの薄さに収めているのはすごい。

自分や他者がUIをどういったプロセスを経て認識しているのかを知ることで、タイトルにもあるように「わかりやすさ・使いやすさの法則」がちょっとずつ見えてくると思う。

34歳になった

34はなんとなく落ち着きのある数字に思える。33はしっくりこなかった。

中学生のころから本を読むようになった。寝る間を惜しんで小説を読んで、授業中に寝ていた。中学生から大学生の間がいちばん本を読んだ時期だった。時間がたっぷりあった。

登場人物のほとんどは年上で、高校生や大学生や社会人だった。だんだんと登場人物の年齢を越えていった。ダンス・ダンス・ダンスでは主人公も五反田くんも34歳だった。僕の34歳では、13歳の女の子とハワイに行ったり、23歳のホテルのフロントの女の子と寝たりすることなさそう。たぶん。

本を読む時間も減って、文章に感動すること減った。18年くらい同じ文章を読み続けて感じ方は変わっていった。感動は減ったけど、懐かしさが増えた。文章は変わっていないから、自分が変わったんだということを実感する。

本を読む時間が減ったぶん、写真と芸術に時間を費やすようになった。小説、写真、芸術と、関心が移っていった。いろいろな展示を観るようになって、もうちょっと理解したくなった。ある程度体系的な知識が欲しくなって、通信制芸術大学の学生になった。ちゃんと勉強しなくては。

2年前に撮った1枚の写真を、いまでもはっきりと覚えている。何年も同じこと考えたりもする。全然変わらない部分と大きく変化する部分の両方があって、たまによくわからなくなるけど、それでも時間は勝手に進むから難しくも楽しい。変わらないところ、変わるところ、それぞれによさがある。きっと。

ターニング・ポイントの35歳まで、あと1年。なにができるかな。