はてなで働くエンジニアにアンケートシリーズ第2回 onk
はてなで働くエンジニアにアンケートシリーズ第2回 onk:
こんにちは、
id:hitode909です。今回は、
id:onkに話を聞いてみます。
onkさんとはここ半年ほど隣の席に座っていて、マンガチームでの課題を足がかりに、CTO室の時間を使って全社的な問題を解決しようと日々活動しています。
はてな社内では「おんく」と発声されています。苗字どおりに「おおなか」と読むって人もいますね。java-ja 界隈では「おにく」と呼ばれていますし、前職では「おーえぬけー」が最大勢力でした。まぁ正解は無いってコトで適当に呼んでください。振り向きます。
アンケートの結果、社内では96%、twitterでは45%が「おんく」と発声している
京都にはある程度のユーザ規模がある Web っぽい会社が両手で数えられるぐらいしか無かったので、ほとんどの会社とお話をさせていただいて、その中で一番夢のある会社にしました。2000年代のインターネットオタクにとっては、はてなは夢の会社だったんですよ。徐々に過去形になりつつあって、それが傍から見ていても悔しかったので、元気を取り戻せたら最高にカッコイイじゃんと考えたからです。という熱意を語ったら採用していただけました。頑張ります。
マンガチームでは少年ジャンプ＋Web版やとなりのヤングジャンプ、ジャンプルーキー！、コミックDAYSなどの開発に携わり、主にサーバサイドの複雑さを克服する仕事をやっています。
GigaViewer は 1 年前には 2 サイト (少年ジャンプ＋、となりのヤングジャンプ) にしか使われていませんでしたが、今は 6 サイトに導入され、ストア機能やポイント購入システム、PWA のオフラインキャッシュ機能等も増えました。ある程度の規模になると複雑さの対価をリファクタリング、リアーキテクティングという形で支払い続ける必要があります。幸い、この規模のデータ・チームの運用に慣れていたので、開発・運用の改善を主導しています。
CTO 室ではアプリケーション開発のすこやかさの維持と、生産性の向上とを受け持っています。すこやか＝よくある週次のライブラリバージョンアップ当番の制度とか、エラー検知、パフォーマンス劣化の検知とかですね。生産性の向上は標準化、共通化を進めることだと考え、コーディング標準を整えたり、社内ライブラリを増やしたりといったところから始めています。
これは全社目線で、全チームと話をする方法がテックリード会という場しか無さそうだったので、肩書きを貰いました。もちろん社内チャット、社内ブログ、社内 Wiki、社内 Podcast といったコミュニケーションツールは充実しているんですが、定期的に開催される場があり、その場が会議体としての役割を果たすことは、方向性を指し示すために大事だと考えています。
今はメインのタスクとして、GigaViewer を導入してる各サイトで、それぞれどんな機能が利用できるかのフラグを整理しています。丸 2 週間かかっていて見積もりを遙かにオーバーしているんですが、歴史的経緯を今のうちに修正しておかないと今後大きな罠になってしまうので。
Slack での会話や Pull Request のレビュー等もあるので、メインタスクにかけられる時間は 4 時間ぐらいかな。平均してもこれぐらいだと思います。
マンガチームでのミーティング。画面の中の三人組は東京オフィスからつないでいる
「割れ窓直しタイム」が日常的に実施できるようになってきたことでしょうか。割れ窓っていうのは、だいたい字面から想像が付くと思いますが、ただちに影響は無い、けど塵が積もると改善すら回らない状態に成長してしまうアレです。
「ただちに影響が無い」って難しくて、例えば自動テストが確率的に落ちるのと、来週リリースする機能開発とどちらを優先して対応しようかみたいな状況は頻繁に発生します。このときにチームビルディングがうまくいってるとスッと会話が生まれてスッと決まるんですが、そういう割り込みタスクに備えた計画になっていなかったり、プロダクトオーナーとエンジニアとの信頼貯金が少なかったり諸々で、タスクとして上がったけど後回しになったり、そもそもタスクとして上がってこずに見ない振りされたりします。シュッとやればシュッと終わるのにね。
こういう問題を解決するために「14:00〜15:00 の 1 時間は毎日割れ窓直しタイムとする」というルールが元々ありました。開発が忙しくてこの時間が有名無実化していたんですが、また意識高い状態に戻ってきた、というのがうまくいったことだと思います。
次の目標は、これを「そもそも優先度を付けてやるタスクである」と定義し直すところですかねー。意識の高低が影響していると、また低くなったときに戻ってしまうので仕組み化したい。
社内では 2011 年にはてなブログを作ったとき の
simple な小さなライブラリを組み合わせて、組み合わせるときの数行は自分で書くという流れだと easy に寄っていかないですね。この「組み合わせるときの数行」というのは、社のライブラリとなっている状態の方が望ましい。薄いフレームワークという発想に加えて、信頼性の高いライブラリを使って書く/読む行数を減らしていくと更にメンテナビリティに優れるという流れに切り替えていきたい。
入社してまず驚いたことは、社内 CPAN, 社内 npm リポジトリ等が無かったことです。オープンソースにしていく文化は素晴らしいんですが、誰もが public に公開できるレベルに抽象化できるほど強くはないので、まずは社内の事情に強く結びついた状態でも共通化を図れる方が望ましいと考えています。
この辺りは言語の文化差もあるのかなとも思っています。Ruby には Rails という信頼できるフレームワークかつ≪レール≫があるので全員の認識が揃い、easy に寄せやすいんだけど、デファクトと言える Web アプリケーションフレームワークが無い言語の方が多そうですね。(はてなには Perl, Scala, Go, Python, Node, Ruby の Web アプリケーションがあり、それぞれ言語の特性を生かすために採用しているので、ちょっとずつ作り方や考え方が違います)
このバランスが崩れて仕事が 1 割を切ると良くなっていく未来が見えなくてしんどいですし、逆に 3 割を超えるとカイゼンにうつつを抜かしてる状態になってると思います。1.5〜2 割ぐらいが妥当。
8:2 を目指して、僕は判断者に押さえつけられるのを前提で 7:3 〜 6:4 ぐらいで話を持って行くので、いくつかは「やり過ぎ」と跳ね返すようにしてください(笑)。元が 8:2 だと全部肯定するだけになっちゃうじゃないですか。判断するのが仕事なので、これぐらいのバランスの方がちょうど良いと思う。
後ろに写っているのは無料で飲み物が出てくるフリードリンク自動販売機
技術が好き、挑戦が好き、笑顔が好き、はてなが好き、インターネットが大好き、という バリューズ は伊達じゃない。このメンバーで良いプロダクトが作れなかったら嘘ですし、勢いよく面白さを世に問うようなプロダクトもリリースしていきたいですね。
いかがでしたか？わたくしid:hitode909は夜になると疲れてきて、何もできなくなるのですが、onkさんは一日中活動できるタイプなのか、定時後もソファでひたすらコードを読んだり書いたりされていて、すごい、生きることとコードを書くことが同じ人だ、と思ったのが記憶に残っています。
次回はシスプラチームの
id:taketo957に話を聞いてみます。お楽しみに！
こんにちは、
id:hitode909です。今回は、id:onkに話を聞いてみます。 onkさんとはここ半年ほど隣の席に座っていて、マンガチームでの課題を足がかりに、CTO室の時間を使って全社的な問題を解決しようと日々活動しています。
id:onkにアンケート
はてなidとその由来を教えてください
苗字の大仲 (ONaKa) からです。2004-2005 年ぐらいに取得したはず。当時は (今も？) 母音を省略するのがカッコイイという雰囲気があったと思います。はてな社内では「おんく」と発声されています。苗字どおりに「おおなか」と読むって人もいますね。java-ja 界隈では「おにく」と呼ばれていますし、前職では「おーえぬけー」が最大勢力でした。まぁ正解は無いってコトで適当に呼んでください。振り向きます。
いつどんなきっかけで入社されましたか?
今年の 4 月に中途入社で、3 社目です。京都に引っ越すことが先に決まっていて、前職ではフルリモートの勤務ルールを作ることができなかったので、こちらで就活をしました。(参考: なんか京都に移住することになった - onk.ninja)京都にはある程度のユーザ規模がある Web っぽい会社が両手で数えられるぐらいしか無かったので、ほとんどの会社とお話をさせていただいて、その中で一番夢のある会社にしました。2000年代のインターネットオタクにとっては、はてなは夢の会社だったんですよ。徐々に過去形になりつつあって、それが傍から見ていても悔しかったので、元気を取り戻せたら最高にカッコイイじゃんと考えたからです。という熱意を語ったら採用していただけました。頑張ります。
現在の仕事を教えてください
マンガチームと、CTO 室とを兼務しています。マンガチームでは少年ジャンプ＋Web版やとなりのヤングジャンプ、ジャンプルーキー！、コミックDAYSなどの開発に携わり、主にサーバサイドの複雑さを克服する仕事をやっています。
GigaViewer は 1 年前には 2 サイト (少年ジャンプ＋、となりのヤングジャンプ) にしか使われていませんでしたが、今は 6 サイトに導入され、ストア機能やポイント購入システム、PWA のオフラインキャッシュ機能等も増えました。ある程度の規模になると複雑さの対価をリファクタリング、リアーキテクティングという形で支払い続ける必要があります。幸い、この規模のデータ・チームの運用に慣れていたので、開発・運用の改善を主導しています。
CTO 室ではアプリケーション開発のすこやかさの維持と、生産性の向上とを受け持っています。すこやか＝よくある週次のライブラリバージョンアップ当番の制度とか、エラー検知、パフォーマンス劣化の検知とかですね。生産性の向上は標準化、共通化を進めることだと考え、コーディング標準を整えたり、社内ライブラリを増やしたりといったところから始めています。
チーム内の立ち位置を教えてください
マンガチームでは前述のような活動を一プログラマとして行っています。CTO 室では Developer Productivity チーム (通称 大仲組) のテックリードという肩書きで動いています。これは全社目線で、全チームと話をする方法がテックリード会という場しか無さそうだったので、肩書きを貰いました。もちろん社内チャット、社内ブログ、社内 Wiki、社内 Podcast といったコミュニケーションツールは充実しているんですが、定期的に開催される場があり、その場が会議体としての役割を果たすことは、方向性を指し示すために大事だと考えています。
今日一日の流れを教えてください
いつも通り 10 時に出社して全社朝会に参加。午後は Issue の棚卸しに 1 時間、週次で行っている社内勉強会 の月次 KPT が 30 分 (運営チームに入っています)、あと今日は月 1 回ある全社共有会のタイミングなので、1 時間早く 18 時で切り上げです。今はメインのタスクとして、GigaViewer を導入してる各サイトで、それぞれどんな機能が利用できるかのフラグを整理しています。丸 2 週間かかっていて見積もりを遙かにオーバーしているんですが、歴史的経緯を今のうちに修正しておかないと今後大きな罠になってしまうので。
Slack での会話や Pull Request のレビュー等もあるので、メインタスクにかけられる時間は 4 時間ぐらいかな。平均してもこれぐらいだと思います。
最近うまくいったことは何ですか?
Perl プロダクトのリポジトリに Rake や ActiveRecord を混入するのに成功したこと、というのは置いておいて(笑)「割れ窓直しタイム」が日常的に実施できるようになってきたことでしょうか。割れ窓っていうのは、だいたい字面から想像が付くと思いますが、ただちに影響は無い、けど塵が積もると改善すら回らない状態に成長してしまうアレです。
「ただちに影響が無い」って難しくて、例えば自動テストが確率的に落ちるのと、来週リリースする機能開発とどちらを優先して対応しようかみたいな状況は頻繁に発生します。このときにチームビルディングがうまくいってるとスッと会話が生まれてスッと決まるんですが、そういう割り込みタスクに備えた計画になっていなかったり、プロダクトオーナーとエンジニアとの信頼貯金が少なかったり諸々で、タスクとして上がったけど後回しになったり、そもそもタスクとして上がってこずに見ない振りされたりします。シュッとやればシュッと終わるのにね。
こういう問題を解決するために「14:00〜15:00 の 1 時間は毎日割れ窓直しタイムとする」というルールが元々ありました。開発が忙しくてこの時間が有名無実化していたんですが、また意識高い状態に戻ってきた、というのがうまくいったことだと思います。
次の目標は、これを「そもそも優先度を付けてやるタスクである」と定義し直すところですかねー。意識の高低が影響していると、また低くなったときに戻ってしまうので仕組み化したい。
最近うまくいってないことは何ですか?
もっと標準化して、共通認識を持って加速したいと思っています。社内では 2011 年にはてなブログを作ったとき の
薄いフレームワークが良いという方針が引き継がれていて、これは 1 プロジェクトしか無い状況なら学習コストが低くて良いと思うんだけど、複数プロジェクトを持っているとプロジェクト間にコピペが生まれて、さらにコピペ後に修正されて差分が生じてしまうともう終わりの始まりです。全てライブラリに追い出して、1 行で書けるようになっていて欲しい。
安全で最小限な実装をプロジェクト内に持つ
simple な小さなライブラリを組み合わせて、組み合わせるときの数行は自分で書くという流れだと easy に寄っていかないですね。この「組み合わせるときの数行」というのは、社のライブラリとなっている状態の方が望ましい。薄いフレームワークという発想に加えて、信頼性の高いライブラリを使って書く/読む行数を減らしていくと更にメンテナビリティに優れるという流れに切り替えていきたい。
入社してまず驚いたことは、社内 CPAN, 社内 npm リポジトリ等が無かったことです。オープンソースにしていく文化は素晴らしいんですが、誰もが public に公開できるレベルに抽象化できるほど強くはないので、まずは社内の事情に強く結びついた状態でも共通化を図れる方が望ましいと考えています。
この辺りは言語の文化差もあるのかなとも思っています。Ruby には Rails という信頼できるフレームワークかつ≪レール≫があるので全員の認識が揃い、easy に寄せやすいんだけど、デファクトと言える Web アプリケーションフレームワークが無い言語の方が多そうですね。(はてなには Perl, Scala, Go, Python, Node, Ruby の Web アプリケーションがあり、それぞれ言語の特性を生かすために採用しているので、ちょっとずつ作り方や考え方が違います)
ふだん大切にしていることは何ですか?
「作業 8 割、仕事 2 割」の意識です。作業は今日の飯の種を得るための業務、仕事は未来のお金を作るための業務と位置づけています。未来のお金は≒時間かな。機械にやらせたり、一目で分かるようにしたり、誰でも判断できるようにしたり。このバランスが崩れて仕事が 1 割を切ると良くなっていく未来が見えなくてしんどいですし、逆に 3 割を超えるとカイゼンにうつつを抜かしてる状態になってると思います。1.5〜2 割ぐらいが妥当。
8:2 を目指して、僕は判断者に押さえつけられるのを前提で 7:3 〜 6:4 ぐらいで話を持って行くので、いくつかは「やり過ぎ」と跳ね返すようにしてください(笑)。元が 8:2 だと全部肯定するだけになっちゃうじゃないですか。判断するのが仕事なので、これぐらいのバランスの方がちょうど良いと思う。
はてなはどんな会社ですか?
「これはひどい」というタグを (古参) はてなブックマークユーザはよく知っていると思います。絶対に社の Slack にこの絵文字あると思ってたんですよ。でもいざ入ってみると無くてビックリしました。ポジティブな空気でインターネットサービスを運営している希有な会社だなぁと思っています。技術が好き、挑戦が好き、笑顔が好き、はてなが好き、インターネットが大好き、という バリューズ は伊達じゃない。このメンバーで良いプロダクトが作れなかったら嘘ですし、勢いよく面白さを世に問うようなプロダクトもリリースしていきたいですね。
おわりに
いかがでしたか？わたくしid:hitode909は夜になると疲れてきて、何もできなくなるのですが、onkさんは一日中活動できるタイプなのか、定時後もソファでひたすらコードを読んだり書いたりされていて、すごい、生きることとコードを書くことが同じ人だ、と思ったのが記憶に残っています。次回はシスプラチームの
id:taketo957に話を聞いてみます。お楽しみに！| オリジナルのエンクロージャ: |
| 20181116122239.jpg |
コメント
コメントを投稿