こんにちは @zaru です。2020 年の振り返りをしようと思っていたらもう 2021 年が 1 週間も過ぎてしまいました。と言うわけで、2020 年の部分的な振り返りとして、テック系 YouTuber デビューした活動を振り返ってみようと思います。

誰?

@zaru という ID で活動をしています。Web 系の会社で CTO をやっています。CTO のタイプとしては現場でコードを書くタイプです。2020 年後半はチームの中でも一番コード書いてコミットしているくらいなので、現役プログラマだと思います。今日も、とある API 処理速度を5倍ほど高速化しました。やったね!

YouTube の活動

2020 年 5 月からムーザルちゃんねるという名前で、僕ともう一人、相方のムーさん二人でやっています。ムー + zaru = ムーザルという感じ。


結論から書くと、Mac mini 2018 モデルに eGPU : Razer Core X + Radeon RX 5700 を突っ込むと、あらゆるストレスが改善しましたと言う話です。

ストレスだったこと

  • IntelliJ の文字入力が極端に遅い
  • Zoom のデスクトップ共有が重い
  • OBS のライブ配信が重い
  • Civ6 の画面が黒い影に覆われ、おどろおどろしい雰囲気に

これらが全て改善し、今のところは安定稼働をしています(Civ6 は改善しない方が生産性的には良かったのかもしれない)。

ここからは時系列での話

僕は Mac mini 2018 モデルが発表された直後に、これはいいぞ!と思い即購入しました。それまではずっと iMac を乗り換えて行ってたのですが、ディスプレイが自由に選びたいなと思って Mac min …


僕はお酒が大好きで基本毎日お酒を飲んでる。ビールだったりワインだったり日本酒だったり焼酎だったり。家で一人ちびちび飲むのも、外で美味しいツマミと一緒に飲むのも好き。

好きなんだけど、しばらくは意味のないアルコール摂取をやめてみようと思う。理由は特にない。敢えていうとすると、最近アルコール依存症の漫画を読んだのがキッカケかもしれない。

僕自身はアルコール依存症ではないと思うけど(自意識がないだけかもしれない)、なんか正直に怖いなと思った。そう思った気持ちを冷静に見ると、ストレスなくアルコール摂取をやめられそうに感じたので、じゃあやめてみるかという感じ。

ただ、完全にアルコール摂取をなくすのではなく、まずは意味のないアルコール摂取をやめることにした。

意味のないアルコールとは何かというのを整理すると、

  • 仕事から帰ってきて家で飲むビール
  • 夜、コードを書きながらのビール
  • 作業を終えた後の一服的なビール
  • 土日にお昼ご飯を食べながらのビール
  • ちょっと空いた時間にカフェで飲むビール
  • 飛行機や新幹線の中でのビール
  • 映画を見ながらのビール

ビールは他のアルコールに置き換えるとして、シーンとしてはこんな感じ。つまり、アルコールを摂取するのが目的なのではなく、なんとなく飲んでいる状態。これを意味のないアルコールと定義することにする。

悩ましいのは飲み会で、雑な飲み会だったら飲まなくてもいいかなと思っている。食事とお酒がメインの飲み会だったら飲みたい。

この行動の変化に何の意味があるのかは今はわからないけど、とりあえず1ヶ月ほどは様子を見てみようと思う。健康になるのかもしれないし、なんにも変化がないかもしれない。1週間持たずに意味なくアルコール摂取をしているかもしれない。

と、このブログをビールを飲みながら書いている…というオチはない。


2017年1月の Twitter を見るとこんなことつぶやいてた。

ちなみにけん玉はまったく上手くなっていない。とめけんができるレベル止まり。姪っ子がけん玉が上手で、会う度に対決しようと言われていたわけだが、僕の腕を見て鼻で笑われ、勝負しようと誘われることがなくなった程度である。悲しい。

そんなわけで2017年を振り返りつつ2018年の抱負を書いておこと思います。

CTO として

エンジニアブログを開発した

会社で開発部ブログというのを数年ほど運営していたのだけど、書きにくいシステム(jekyll を使って git 管理&デプロイ)ということで長らく不評であった。jekyll が悪いのではなくメンテナンスをしていなかったのが原因で、ローカルでの動作確認がまともにできなかったりしていた。jekyll は大好きだ。

そこで、ブログをゼロベースで作るか …


先日、会社で初めてスクラムを導入してみた。

以前から開発プロセスをもっと改善できないかなーと思っていて、前々から気になっていたスクラムを取り入れたいと思って提案したら、なんかめちゃでかいプロジェクトのスクラムマスターになってしまった…😇

なんとか無事にスタートを切れたので今後の改善のために現時点での状況や気持ちを書いておこうと思う。

前提条件

スクラムチームの規模

開発チームが9名。スクラムではギリギリな大所帯。かつ、1名リモートワークがいる。

プロダクトオーナーは元々プロダクトを管理していた方にやってもらった。決定権限も持つような形にできたので良かった。

スクラムマスターの俺は対象プロジェクトの開発はやっていなかったので逆に第3者的な目線で入れてやりやすかったかもしれない。

対象プロジェクトの状況

機能開発をガツガツやっていくようなフェーズで、関係者やユーザさんから改善要望がひたすら上がってくるような感じ。差し込みタスクが頻繁に入ったり、依頼フローもばらばらの印象。

プロダクトメンバー全員がすごい頑張ってプロジェクトを進めているような状況(これを読んでる関係者、そこは違うよ!😎と思われたら、すいません)。

スクラム導入に向けてやったこと

スクラムを調べれば調べるほど失敗事例なんちゃってスクラムというものが大量にあることがわかった。これは、学び実践し改善する心構えが必要だと感じた。

インプット

まず、@ryuzeeさんのブログやスライドを読んだ。

あと本を3冊ほど読んだ。

身近にスクラムを実践している人が居なかったので、こういう形でインプットしていった。理解はしやすかったと思う。

本当は認定スクラムマスター研修なども受けたかったが時間がなかったので今回は見送った。今後、検討したい。あと@ryuzeeさんのセミナーとかも良さそう。

アウトプット

チームにスクラムの理解を促進するために導入スライドをつくって共有した。これで正解というものではないと思っていて、スクラムをやっていく中でわかったことがあれば改善していきたい。

スクラムを導入してみて

スプリント計画会議

今回のスプリントは2週間にしたので、初日4時間とって、第一部と第二部に分けて開催した。開催する前は、膨大なプロダクトバックログ・複雑な要件に対して時間内に見積もりができるのかと不安だったが、やってみたら意外とできた。

プロダクトオーナーが事前にバックログを整理してくれていたのと、開発メンバーが自分が知っている情報をちゃんと共有してくれて、無駄な議論の時間を消耗せずにいけたのが良かったのかもしれない。

スクラムマスターとしては場が膠着しないように時間を意識しながら声をかけて進行していった。

プランニングポーカー

プロダクトバックログの相対見積もりには定番のプランニングポーカーを使った。購入が間に合わなかったのでトランプと紙に書いて行った。

9人もいるので相当ばらばらになるんじゃないかと予想したけど、予想通りバラバラ…2を出す人もいればBigを出す人もいて、収束するのかこれ?と正直思った😂

でも、大きいカードを出した人に「なぜこのカードにしたのか?」と意見を聞くと、他のメンバーが「あー、それも考慮しなきゃなのか」と納得したり、小さいカードを出した人の場合は「以前に作ったことがあるので、それがほぼ使えます」という情報を知ったりすることができた。

これによって多少のばらつきはあるものの、ほぼほぼ一致した。プランニングポーカーは、開発メンバー同士での意見交換が短時間で行えるので良い取り組みだと感じた。

ただ、集中するからかめっちゃ疲れる!

プロダクトとスプリントの見積もりが乖離する?

ちょっと分からないのが、第一部でプロダクトバックログをプランニングポーカーでポイント見積もりしたものと、第二部でタスクに細分化し時間で見積もりしたものが乖離しているタスクがあった。

例えば、ポイント13で5時間のタスクもあれば、ポイント8で8時間のタスクもあるといった感じ。

ポイント見積もりは詳細に見積もらないので、実際にタスクに落とし込んでいったら意外と簡単だった…というのはよくある事なので、そういうものかと思うが、ベロシティとしてポイントを使っていく際に、乖離が大きいと予測の精度が上がりにくい気がした。

ここらへんはどうしたらいいんだろう?

デイリースクラム

カンバン

ポストイットで紙でペタペタやっていくカンバンでタスク管理することにした。ポストイットにはGitHubに登録されているプロダクトバックログIDと見積もりした時間工数と内容が書かれている。上から順に優先度が高い。

開発メンバーはタスクを対応する時は、自分の名前が書いてDoingにうつす。終わったらDoneへ。


今、個人プロジェクトでCIサービスを作っている。CIサービスというとTravisCIやCircleCI、ツールだとJenkinsとかが有名。それらは汎用的なCIだが、俺が作っているのはベンチマーク・パフォーマンス計測に特化したCIだ。そんなCIサービス開発について今の気持ちや状況を記事にしておこうと思う。

サービスの名前は raysCI という。

サービスのロゴ案

なぜ作ろうと思ったのか

コードレビューで、計測せずにコードのパフォーマンス議論をしているのを見かけて、これはあまり意味ないなと思い「推測するな、計測せよ」の精神でベンチマークとって結果をコメントしたことがあった。

その時、人間がいちいち計測するのではなく、自動で計測してくれればアプリケーションの品質可視化に一役買えるのでは?と思ったのがキッカケだと思う。

つまり、プルリクを出したらCIがベンチマーク取ってレポートしてくれる。最高だ。

どのように計測するのか

ベンチマーク対象のアプリをDockerコンテナとして動かし、計測用のDockerコンテナからベンチマークを実行するようにしている。単純だ。クラスタ管理にはkubernetesを、クラウドはGKEを利用している。

今はapache benchなどの外部からのトラフィックに対するレスポンスや、プロファイラを埋め込んだ解析レポート、ヘッドレスブラウザでのHTML DOMロードなどのパフォーマンスを計測するように実装している。

将来的には、プルリクで変更したコードに関わる部分を局所的にベンチマーク取れれば良いのだが、そこまで細かいチューニングはまだできていない。やりたい。

さらに欲をいえばパフォーマンスが悪い時には具体的なコードの改善案を出せれば最高だ。

いつリリースするのか

2017年7月中にはプライベートベータという形でリリースしたい。そもそもこのCIサービスにニーズがあるのか、あったとして開発の改善につながるのか見えていないので、それを試したいと考えている。

そのため機能は最低限、対象もRailsアプリをメインで開発をしている。無事、リリースできることを祈って…ある意味、この記事が宣言的というか書いたからには出さねばならぬという感じである。

また、オプションの機能として以下のものも考えているが、それはまだもう少し先の話。

  • プルリク単位でのステージング環境の自動構築
  • プロダクション環境の定期パフォーマンス計測

どうやって作っているのか

普通に会社員なので、平日は家に帰ってから2〜3時間、休日に4〜5時間ほど時間を作って開発している。また、最近は週に1日くらい休んで時間を作ったりしている。

最初のコミットが5月15日なので今日で51日たっていることになる。51日間、毎日開発しているのにまだ完成しないのかと軽く絶望しかけること数百回だが、じょじょに形にはなってきている。

こうやって書くと、しんどそうに感じるかもしれないが、1年くらい前にもpushnateというWebプッシュを配信するサービスを個人開発してたこともあり、リズムができているのか無理は感じていない。知らないことをたくさん知れて単純に楽しいというのもある。

(ただ、さすがに一人じゃ厳しい…というのは正直な所)

開発における課題ってなんだろう?と思いを巡らす時、個人的にはそれはデプロイであったり、コードレビューであったりするのだけど、それをより良くできる可能性があるサービスを開発していることに非常に興奮している。楽しい!

無事にサービスをリリースし、開発者に活用してもらい、世の中のWebアプリケーション速度が向上して、インターネットがより快適になる世界を信じ今日もコードを書く。そういう感じ。


2016年、俺がCTOとして、一人のプログラマとしてやってきたことを振り返ろうと思う。結構雑に書いてるのでアレ。

CTOとして

インプットとアウトプットの促進

Qiitaアドベントカレンダーへの参加や、皆が書いた記事をSlackのチャンネルに自動ポストするようにbot作ったり(自分が書いた記事を皆が読んでフィードバックしてくれるの単純に嬉しいよね?)、自分が知った良さ気な情報を積極的にシェアしたり、インプット・アウトプットがされるように意識して行動した。

最近ではメンバーがつぶやき勉強会なるものを頻度高く開催していて、小さい技術ネタを気軽に話せる場ができたりして非常に良い雰囲気になっていると思う。

機械学習を扱えるようなエンジニアを増やすために、機械学習ハッカソンをやったりして、今すぐ業務では必要ないけれど、この先必要になるようなものにふれる機会を作ったりした。メンバーが興味はあるけれど、なかなかできないなーというのを解消していきたい気持ちがある。そしてそのパワーを業務に還元したい。

毎月やってる社内LT、年末には12人も登壇する感じで最高な雰囲気ある。内容も非技術からガチ技術までバラエティ豊か。

コードレビューファースト

メンバーに「コードレビューファースト」推進委員会がいて、彼に触発され全てのプロジェクト(たぶん10個以上ある)のGitHubでプルリクを見てコードレビューをするようにした。それで得られたものとして、自分が知らないコードの書き方や、メンバーの思想。後はあまりないけれど無意識な技術的負債。意識して負債産むのはまだマシで無意識だと後で詰む。

レビューを通して本当に痛感したのは、プログラマは皆フィードバックを求めているのだということ。それが自身の成長に大きく寄与すると分かっているんだろう。これはまだ組織としてちゃんとできている部分ではないので、どうにかしていきたいと思っている。

理想はメンバーが他のプロジェクトのリポジトリを覗いてちょっかいを出しに行けるような感じ。

新しい技術やツールの導入

プロダクトの成長を促進できるような技術やツールは積極的に取り入れていきたいので、色々調べたり実際に取り入れたりしてみた。

例えば、Re:Dashはよく企画から「◯◯の数字だして〜」とお願いされるようなことを避けるためのツールで、ブラウザ上でSQL書いてグラフ化できる。理想は企画がSQL書いて自分で分析できるようにすることなんだけど、そこまでは求められてない感じある。

他にCircleCIやSentry、Itamaeなどよくある定番系ツールを導入して社内標準化したりした。Itamaeに関してはChefと比べてサードパーティが貧弱なので、自分たちで必要なものは積極的にプラグイン化してOSSとして公開したりした。また、他の人が作ったプラグインにもプルリクを投げたりして運用できるようにした。

開発フローや言語・フレームワーク自体はRails・GitHub・AWS・CircleCI・RSpecとけっこう小慣れてきているようなきがする。次標準化していきたいのはインフラとフロント。インフラはDockerを中心にして、フロントはReactを一部のプロジェクトで導入しているけど、どうかなぁ。2017年にもう少し考える。

テストコードはJavaScript含めてもっとしっかりやっていきたい。

スーパーサブ

複数のプロダクトを少人数で回しているため、瞬間的に人員が足りない時がある。そんなときに、ヘルプとしてガツッとコードを書いていった。近い距離で一緒にコードを書くことでメンバーの育成もいっしょにやった感じだ。本来であれば人員計画と育成計画をちゃんとやらないと行けないところだったが、後手に回ってしまった感じでメンバーには申し訳ないと思っている。

CTOが前線でコードガリガリ書いているのどうなんだ?とか思うかもしれないけど、個人的にはまったくコードを書いてない人(技術者でないなら全然良い)があれこれ言ってくるの非常に嫌なので、なるべく書くようにしている。でもできればもっと良いコードを書ける人を増やしていった方が良いと思っているので、採用や育成を強化していく必要がある。

技術力のないCTOなんて精神論だけをかざすだけの人になるので、技術力を持ってヴィジョンを伝えられるようにしたい。両方大事。

炊飯器とコーヒーメーカーと酒の導入

炊きたてご飯が食べたかったので炊飯器をオフィスに導入した(メンバーが使ってないの持ってきてくれた!)。米を皆で買ってお昼に食べたりしてたけど、最近は使っていない。なぜなら…俺が炊くの面倒くさいから…。みんなもっと使ってもいいのよ。

あと挽きたて淹れたてコーヒーが飲みたかったので、全自動コーヒーメーカーを買って導入した。豆を挽く音がけっこうウルサイけど非常に美味しいコーヒーが飲める。最高。

オフィスの端っこでスーパーで買ってきた酒をチョット飲んだりしながら雑な技術トークやくだらない話をしたりした。雑っていうのが適度に良くて色んな人の意見を気軽に聞けたりする。面白い。

… 特にCTOとしての仕事というより個人的な趣味ではあるけど、こういった動きもまぁもしかしたらなんらかの雰囲気作りに寄与しているのかもしれない。

事業と技術

弊社のプロダクトは特定の技術によって成り立つような性質ではないので「この技術があるから他社に勝てる」とかではない。これは恐らくたいていのサービスはそうで「手段と目的の違い」的な話だろう。もちろん技術によって成り立つ機能でより良いサービスにできるのは事実だけど。

そういったわけで、ユーザの問題を解決するプロダクトそのものを成長させるために、必要十分な技術力を持った開発チームにしていく必要があると思っている。普通にちゃんと作れる集団。これが結構難しい。

メンバーのスキルを下支えして、各チームの中でも醸成されていくように技術リーダーを作っていったり、知見が共有されるように横の動きも出るようにキッカケ作りをしたり、ペアプロやレビューを通して思想を伝播させていったり。時間はかかるけれど、少しづつ進んでいる気がする。

みんなサービスをより良くしたい、開発環境を良くしたいというモチベーションは非常に高いので、あとは適切な機会提供と給与という報酬があれば問題なく成長していけると思っている。ここは改善していきたい。

社内ネットワーク改善

CTOとしてというか単純に社員としてって感じだけど、社内ネットワークの改善をしたりした。席替えとかレイアウト変更とかいろいろな歴史を経てこんがらがって変になっていたネットワークを調査したり、ルータとLANケーブルをベリベリバリバリやったり大変だったけど面白かった。ネットワークの基礎を改めて勉強できた気がする。手伝ってくれたメンバーにも色々と教えられたので良かった。

こういった普段の業務とは少し離れたところで技術について学べると、ちょっとラッキーみたいな感覚がある。面倒臭がっていると機会が減っちゃうんだろう。逆に損切りみたいのができないと面倒で面白くもない仕事ばかりが増えるから、そこは気をつけるポイントだと思う。

こういう風に知見を社内に共有できるし良い。

心理的安全性とコミュニケーション

メンバーがフラットにストレスなく自分の意見を言えるようにしたいと思ってて、相手の発言を否定から入らないように気をつけている。また、メンバーが「◯◯をやりたい」と提案してきたときも、「それいいね」と前向きに捉えて一緒にやるようにしている。

もちろん、訂正すべき意見や行動などはきちんと伝える。仕事であればなおさら。ただ、人格を否定されたと相手が感じるようなコミュニケーションは害悪でしかないと思っている。

ZARU

I’m programmer. I love code.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store