ペペロンチーノ街道

無知を晒す

2023年1月の振り返り

あけましておめでとうございます。

2023年の目標を踏まえて今月を振り返ろうとおもいます。

chimpan.hateblo.jp

今年は技術的なブログはもちろんですが、お気持ち記事や振り返り記事も書いていきたいですね。 適当にリンクつけてますが、アフィじゃないのできにしないでください。

読書

最近は技術書やビジネス書を読むのが趣味の意識高い系になっている。

LeanとDevOpsの科学

仮説検証がすごくしっかりしていて信頼できる内容であるが故に、敷居が高く感じた。割とアカデミック寄りなので、ノリで通読しようとすると挫折すると思う(した)。その代わり、読みこなせればすごく濃厚な内容なので、いつか読み返したい。

SINGLE TASK 一点集中術

マルチタスクという幻想を打ち砕こうとする本。人間はそもそもマルチタスクなんてものはできなくて高速にタスクをスイッチングしているのであり、スイッチングコストが生じると作業効率が落ちるよって書いてあった。まぁそうやねと思った。作業中についついSNSを見ちゃったりするのをやめたいと思って読んだけれど、若干ためになった本でした。言われてみたら当たり前だけど出来てないことが結構書いてあった。

この部屋から東京タワーは永遠に見えない

最近Twitterで流行っている所謂「タワマン文学」の本。何者にもなれない厨二っぽさと苦しい感じを含みながらも読みやすくてオススメできる。

健康

スマートバスマット を導入して、お風呂上がりに体重を記録している。1ヶ月記録したけど 73±2 kgで推移していて一応安定(?)はしている(BMIは20ちょいなので普通体型ではある)。 年末年始で怠惰だったり、週2くらいで二郎食べてたのでギリ耐え。ただ、運動はしてないので2月は走って減少させていきたいですね。

英語

瞬間英作文をやってるけれど、モチベーション管理が難しい。自己学習の一番の失敗要因はモチベーション管理な気がする。ちょろっとコミュニケーション取れるレベルになるのが目標なので、継続的にやらねばという感じ。社内語学支援制度をいい感じに使いてぇ~と言って1年が経ちそうだけど、いきなりお金をかけてやらなくなるのはもったいないので、自分で英語学習の習慣がつけられたら始めようかなという感じ。えいやでお金かけてもったいない精神でやることもできるけども、自分の性格上やめておく。

来月のTry

  • 毎日3-5km走る
    • 冬なので怪我にも考慮して軽めに。習慣化することが目標
  • 移動中は音楽じゃなくて英語の何かを聞く・見る
  • 技術書以外に本を読む

2023年を考える

目標って立てるのは簡単だけど、達成度を定量的に評価するのが難しい。

敢えて仕事仕事しないような目標を挙げてみる

目標

  • コンタクトをつくる
    • 本当はレーシックかICLをしたいけどまずはコンタクトにしてみる。メガネが面倒なので
  • 新しい言語を1つ以上学ぶ
    • とりあえずHaskell が第一候補
    • Ocaml を大昔にやったけど忘れたので、何かしらの関数型言語ということで
  • 英語、英会話を勉強する
    • TOEIC 900 点を目標にする
      • TOEICの点数で英語力を測れるかは微妙だとわかっているけど、モチベーション管理のために適当にやってみる
      • 受けに行くのはめんどい
    • 英会話は何かしらのオンラインのやつを始めてみる
      • 年末まで継続させたい
  • 体重をもとに戻す
    • 具体的には -3kg くらい
    • 歩いたり走るぞ
      • 毎日1万歩あるきたい
    • この記事を書きながらお菓子を食べている
  • 月に1冊は技術書以外の本を読む
    • 話題の映画の原作とか読みたい
    • あとは日本史、世界史の本
  • ふるさと納税をする
  • なにかで発表する

いくつ達成できるかで賭けましょう

新卒入社としてサイボウズ生産性向上チームにジョインしました

新卒入社としてサイボウズ生産性向上チームにジョインしました

はじめに

2022年4月にサイボウズに新卒入社した @r4mimu です。 新卒史上2人目の生産性向上チームへのジョインした2022年の自分の心境を書き残しておきます。

この記事は Cybozu Advent Calendar 2022 の 2 日目の記事です 🎅

生産性向上チームとは

自分の所属する生産性向上チームは主に以下のような業務を行っています。

  • チームを横断した開発効率を高める基盤の整備
  • 開発チームの業務の自動化や効率化の支援
  • 最新技術のキャッチアップ・共有
    • 毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催
    • 勉強会の内容をまとめたものは Zenn で公開されています

一言でいうと「サイボウズの開発者が辛いと思っている部分を最高にしていく」活動をしている少し珍しい(?)チームです。

さらに詳しくはこちらの登壇資料を御覧ください。

また、 Cybozu Advent Calendar 2022 の 1 日目は自分と同じ生産性向上チームの @miyajan さんが生産性向上チームで構築・運用しているセルフホストランナーについて解説してくれていますので、生産性向上チームの活動を具体的に知りたい方は是非御覧ください。

チームにジョイン!(7月)

約1か月の新卒入社の研修と約2か月のエンジニア研修・チーム体験を終えた後、希望通り生産性向上チームに配属されました。 エンジニア研修については Cybozu Inside Out の記事 に詳細が公開されています。

自分が生産性向上チームを希望した理由としては、

だったと記憶しています。

生産性向上チームでは、普段のタスクをモブプログラミングで進めています。具体的には、1人のドライバーが画面共有をして、ナビゲーター(他の1,2人のメンバー)と議論しながら作業をします。 モブプログラミングはある程度チームに慣れているメンバー同士で行えば、認識齟齬の防止や属人性の解消に繋がり効果的です。 しかし、自分のようなジョインしたての迷える子羊の場合、ドライバーだとナビゲーターに言われるままの操り人形、ナビゲーターだと特に発言しない地蔵と化していました。

また、生産性向上チーム特有の幅広い技術領域とドメインもなんもわからない感に拍車をかけていました。 というのは、GitHub セルフホストランナーのタスクをしていたと思ったらすぐに CircleCI Server のタスクにも対応しないといけなくなったり、はたまたその途中で他チームからの依頼が舞い込んできたり、技術と業務のコンテキストスイッチがすごいです。 この頃はなんも分からん、と毎日思っていた気がします。毎日午前中の「探求タイム」で前日に分からなかったことをキャッチアップしていました。

インターン生がきた(9月)

9月にはインターンを2ターム行いました。

生産性向上チームでは、インターン生に取り組んでもらうタスクを別途用意せず、普段のタスクの中からインターン生に選んでもらい、モブ形式でタスクを進めました。 そのため、チームにジョインしたての自分はインターン生をがっつりリードしたりメンタリングは出来なさそうでしたが、それでも、ナビゲーターとして極力アドバイスしたり、インターン生の質問には自分から答えようと意識しました。 すると、このインターンのおかげで質問に答えたり、人に教えると自分の理解が捗ることを月並みですが実感しました。

ふと振り返ってみると、分からない状態を脱するためにインプットをして、そのインプットのせいで更に分からない・気になることが増えていくという悪循環に陥っていたなと気が付きました。 目的はタスクを解決することであって、タスクに必要な知識を隅々まで知ることではありません。そこで、アウトプットベースでインプットする方向に変えていきました。

この取り組みの一例として、インターンの第1ターム終了後の振り返りにおいて、オンボーディング資料が更に充実しているといいよね、と意見が出ました。 そこで、自分が次のインターン生を受け入れるまでの1週間の間にオンボーディング資料を用意することにしました。 インターン生向けのオンボーディング資料なので、社内ドメイン知識について共通のバックグラウンドがありません。そのような人にも理解できるような資料を短期間で作成するという目的を持ったインプットをしました。 すると、必要な情報を考えながら取捨選択していくので、ドメイン知識や情報の結びつきが明確になり自分の理解も捗りました。

といっても、自分のアウトプットが正確である自信はありませんでした。 そこで、進捗やアウトプットを小出しにして他のメンバーに共有して、フィードバックを細かく貰うように心がけました。

この経験で

  1. 必要な情報をインプットをする
  2. アウトプットを出す
  3. フィードバックをもらう
  4. フィードバックをもとに必要な情報を更新する
  5. 1へ戻る

というフローが自分に合っているなと気が付けました。 アウトプットがあれば何かしらコメントを貰ったりコミュニケーションが生まれます。どんなにだめでもアウトプットを出せないことが一番まずいと思っています。

ちなみに、インターン生が参加記ブログを書いてくれました。ありがとうございます!!(多分楽しんでくれています)

人が少ない(10月~)

少しずつできることが増えてきて、もりもり頑張るぞと思っていましたが、新規チームの活動に移るメンバーやしばらく兼務先にフルコミットするメンバーのためチームの人数が半分になりました。 人数が減ったため、自分が意思決定する場面も少しずつ遭遇するようになりました。格好つけて言えば責任ややりがいがあるとも言えますが、やはりまだまだ怖さがあります。 はやく一人前になりたいものです。

生産性向上チームのいいところ

個人的に感じている生産性向上チームのいいところをいくつか考えてみました。

いいところ

  • あらゆる活動を定期的に振り返り、改善アクションをすぐに実施する
    • イテレーションごとにプロジェクトの進捗を振り返ることは、どこのチームでも見られる取り組みだと思いますが、採用活動やチーム内1on1なども振り返りを行っています。 このときに出た問題に対する対応はすぐに話し合い、改善活動が実施されるプロセスの速さが印象的です。
  • 探求タイムと実践導入の検討
    • 毎日午前中に「探求タイム」を設けて、各々がタスクを進めたり、技術のキャッチアップを自由にできるという時間があります。業務時間内に業務で利用する技術をキャッチアップできるのですごく助かっています。
    • また、前述の Productivity Weekly という勉強会を行った後、チーム内で「Productivity Weekly で出た技術から導入できるものを検討する会」を行っています。これにより、新しい技術に詳しくなりつつ、既存の利用技術の理解も深まります。学んだ知識や新しい技術は使ってこそだと思うので、個人的に良いなと思う取り組みです。
  • モブでも個人でもタスクを行える
    • モブプログラミングは強い人からすると効率が悪くなるという意見もありますが、生産性向上チームでは一人でできそうなタスクは個人で巻き取ってやっておきましたというのもヨシ、普段のモブプログラミングで業務を進めていくのもヨシという雰囲気があります。
  • メンバーがおもしろい
    • そして皆さん強いので頼れる

おわりに

一丁前なことを書きましたが、技術力・ドメイン知識・お仕事力どれをとってもまだまだ足りないと感じる毎日です。 なにか1つ自信を持って取り組めるものを作って、そこから少しずつ領域を広げて行けたらなと思っています。

全体的に自分が大きく何か貢献した・成し遂げたというものではなく、一歩一歩地道にやってますという内容でした。

来年以降もチームの皆さんに助けられつつチーム・プロダクト・会社に自分の価値を還元していけるように精進します。

ビデオ会議していると ShiftIt が使えないよね

概要

ShiftIt とは macOS において、コマンド1つでウィンドウのサイズをいい感じにするアプリケーションです。

とても便利なのですが、ビデオ会議中には機能しない という致命的な不具合があります。自分は仕事で画面共有することが多いので、ビデオ会議中にShiftItが使えないと、手動でウィンドウをゴニョゴニョしなければならず結構ストレスです。 この不具合は2022年頃から報告されており2022年11月現在も直っていません(コントリビューションチャンス!)。詳しく原因調査はしていませんが、Monterey 以降の macOS でZoom・Meet・Teams などのビデオ会議中に機能しなくなりそうです。ちなみに、自分の環境では Android Studio Emulator を起動中にも ShiftIt が機能しなくなりました。

Android Studio Chipmunk | 2021.2.1 Patch 1
Build #AI-212.5712.43.2112.8609683, built on May 19, 2022
Runtime version: 11.0.12+0-b1504.28-7817840 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 12.6.1
GC: G1 Young Generation, G1 Old Generation
Memory: 1280M
Cores: 10
Registry: external.system.auto.import.disabled=true

代替アプリ

ShiftIt のリポジトリを見れば察するのですが、開発は止まっていそうです。どうやらメンテナーが Mac Book Pro を盗まれ、Linuxに乗り換えたら macOS には戻れないので誰かヨロシクとのことです。

参考:

github.com

地味に困っているので、代替アプリを探したところ Hammerspoon ShiftIt という、なんともなんともなアプリを見つけました。

インストール方法などはREADME に沿って手順を進めれば問題ないと思いますが、1点だけ、Step2 で解凍したディレクトリは .hammerspoon/Spoons に配置しなければ config の読み込みで失敗するので気をつけましょう。

おわりに

いまのところビデオ会議中にも画面分割が正常に行えています。ありがたい。

「技術書」の読書術を読んだ

「技術書」の読書術という本を本屋で見かけたので、えいやで買ってみた。

軽くメモっておきます

第一部 選び方

まずは、読む本をどのように選ぶか(出会うか)を紹介しています。 本屋の陳列の話、新刊情報の手に入れ方、目的別にどのように本を選ぶかの方法が述べられています。 面白かったのは「くじ引き読書法」というもので、無作為に本を選び読むというものです。くじ引き読書法の目的としては単純に知らないことを知るのは楽しいという知的好奇心的なものと、一発逆転を目指すなら何か特異な知識を持つと良いということです。無作為に本を選ぶために、ランダムでISBNを生成する方法を提案しているのですが、その過程でISBNの読み方(?)について書かれており、地味に知らなかったので学びでした。

第二部 読み方

実際に技術書の読み方を述べています。ただ、技術書に特化した内容ではなく文芸書以外の本なら大抵通ずる物がある内容だと思います。

自分が技術書を読む際に参考になりそうだった読み方を以下にメモっておきます。 個人的には一点突破読書法を実践しようと思いました

同じ本を何度も読む

  • 一度目は流し読み
  • 二度目は手を動かす
  • 三度目はまとめながら

何度も読むのは時間がかかりそうですが、しっかり身につけたいときに有用そうです。また、自分は一回読んだら放置して記憶を飛ばしたり、一回で完璧を目指そうとして途中で挫折したりしがちなので、何度も読むことを前提に読みすすめるのはアリだなと思います

時間を経た再読

再読することで、以前は分からなかったものがわかるようになったり、当たり前だなと感じるようになったり、初めて読んだときと違う感想を抱くことができる。これにより自身の成長が実感できる。

時間制限読書法

90分という制限時間で読み切る読書法。ビジネス書やキャッチアップ用の本に使えそう

一点突破読書法

特定の分野の本を複数揃えて集中的に読書する方法。1つの分野を強化することで周辺分野も同時に底上げされるという効果を期待している。

3年で20冊の本を読んで、最終的には論文を読むようになりたいよねって流れ。

3年後には大きな力が付いているはず!

第三部 情報発信と共有

せっかく身についた知識はアウトプットして成果にしてナンボみたいなことを言ってた。同意

おわりに

タイトルには技術書とあるけど、読書全般に使える考え方や方法論が多く書かれており汎用的な読書法が身につくと思います

これできっと3年後には特定の分野で大きな力が付いているはずです

gitコマンドで最新のコミットのchanged filesを取得


背景

最新コミットでのchanged filesとなったファイル名をコマンドで取得したい!

結論

git log -m -1 --name-only --pretty=format:

メモ

  • -n ${num} で表示件数を制御 ここでは最新コミットでの変更を見たいので1
  • --name-only はファイル名を表示

    Show only names of changed files. The file names are often encoded in UTF-8. For more information see the discussion about encoding in the git-log[1] manual page.

  • --pretty=format: 表示形式を制御する

    • 例えば --pretty=format:"%s" とすればコミットメッセージを表示できる

参考

git-scm.com

git-scm.com

Goでcatコマンドを実装をする

Unix catコマンドをGoで実装した

実利用するためではなくシステムプログラミングの理解の一環としてのプログラム

実装

package main

import (
    "flag"
    "fmt"
    "os"
)

const bufSize = 1024

func main() {
    flag.Parse()
    args := flag.Args()

    if len(args) < 1 {
        if err := cat(os.Stdin); err != nil {
            fmt.Fprintln(os.Stderr, err)
            os.Exit(1)
        }
    } else {
        for _, arg := range args {
            f, err := os.Open(arg)
            if err != nil {
                fmt.Fprintln(os.Stderr, err)
                os.Exit(1)
            }
            defer f.Close()
            if err := cat(f); err != nil {
                fmt.Fprintln(os.Stderr, err)
                os.Exit(1)
            }
        }
    }
    os.Exit(0)
}

func cat(f *os.File) error {
    buf := make([]byte, bufSize)
    for {
        n, err := f.Read(buf)
        if n == 0 {
            break
        }
        if err != nil {
            return err
        }

        fmt.Print(string(buf))
    }
    return nil
}
  • 任意個のファイルをコマンドライン引数で渡せる
  • ファイル名を引数で渡さなかった場合は標準入力を読む
  • ioutil を使えば若干簡略できるが、ここでは学習目的で os を使った

所感

  • os.Openos.OpenFile のラッパー
    • 基本的には os.Openos.Create で良い。 細かいパーミッション指定をするときには os.OpenFile を使う
  • file.Read はファイルの終端に達したら n = 0, err = io.EOF が返される
    • そのため、手癖で以下のようにエラー処理を先に書いてハマりかけた
 // 先にエラー処理をしているので、ファイル終端で `io.EOF` エラーとして落ちる
n, err := f.Read(buf)
if err != nil {
    return err
}
if n == 0 {
    break
}

次は head コマンドあたりを実装する