YAMAGUCHI::weblog

ジャイトニオ猪場のはからいで、全財産を失いました。トランスマスターケンちゃんこと、剣持です。

YAMAGUCHI::weblogの2018年を振り返る

はじめに

こんにちは、Stackdriver担当者です。今年も年の瀬の本日に一年歳を重ねました。毎年この時期になると「今年もおしまいですねー、早く新年にならないかなー」みたいな感じで、すごく消化試合感を出されるんですが、僕の誕生日が残ってるんでほんとにそういう雰囲気やめてください!あと例のやつを貼りました。よろしくお願いします。

毎年やってるので今年も1年振り返ります。

関連エントリ

ここまで続けると毎年やらないわけにいかない感じになってる。

ymotongpooの2018年

昨年立てた目標

  • FP技能検定2級
  • 自作キーボード
  • ジム
  • 書籍

FP技能検定2級

無事にFP技能検定の3級、2級と続けて合格し、晴れて「二級ファイナンシャル・プランニング技能士」となりました。*1

去年は、長いことやろうと思ってやっていなかった資産運用を考え始め、自分がFPの方に相談をし、実際に組んだポートフォリオ計画を実践し、ということを行った1年でしたが、今年はそれに飽き足らず資格を取りました。

ファイナンシャル・プランニング業務を行っている職種というのは非常に多く、たとえば金融商品の営業の一環として行っている方も多くいます。しかし、自分が興味があるのが純粋にファイナンシャル・プランニングを行う独立系の業務で、資格を取ったこともあり、興味が高じて友人や知人のファイナンシャル・プランニングのお手伝いを数多く行っていました。

そして、いろいろな活動を行っていた結果、ついに副業としてファイナンシャル・プランナー業務を始めることとなりました。(ファイナンシャルプランナーとして独立系の会社から業務委託を受けることとなりました。)これを読んでいる方でもファイナンシャル・プランニングや資産運用に関して相談をしたいけれど、どこに相談していいかわからないという方がいらしたらお気軽にご連絡ください。(TwitterのDMとか)相談料は応相談です。

自作キーボード

Let's Splitを作ったあと、購入してだけして作業に取り掛かれていない基盤がいくつか積まれた状態になってしまいました。

来年はfoobarをいくつか組んで、極小キーボードに慣れていこうかなと思います。

ジム

自作キーボードもそうなんですが、諸々なイベントが重なったことで今年はいろいろなことがあったので、だいぶこうした細かな活動を継続的に行うのが大変でした。しかしジムワークは生活に欠かせないものになっていたので、なるべく時間をとって、最低でも週1回、通常時は週2回、行けるときは週3回行くようにしていました。

おかげで体のサイズもだいぶ大きくなり、4年前は日本のサイズでMサイズのTシャツを着ていた体ですが、いまはUSサイズのXLでないと肩や胸周りにゆとりがないほどにサイズアップしました。来年はここからネジをキリキリと締めていくように絞りたいたいという思いがあり、現在計画中です!

書籍

翻訳書籍が無事発刊に至りました。

Go言語による並行処理

Go言語による並行処理

ymotongpoo.hatenablog.com

Go言語のユーザーもだいぶ増え、プロダクションでGo言語を使っている会社もだいぶ増えましたが、そんな状況においてもいまだにGo言語の特徴の一つである並行処理の方法に関してまとまった書籍がなかったため、この原著が市場にでたことは一定の影響があったと思っていました。そんな本の邦訳に携われたことはとてもありがたいことでした。

4年ぶりの書籍の翻訳でしたが、翻訳特有の2段階の正誤確認(翻訳そのものの正誤、原文の内容自体の正誤)はなかなかに大変な作業で、残念ながら今回の翻訳でも多くのerrataが登録されてしまいました。次回がいつあるかはわからないですが、今回の経験をもってよりよいものにしたいです。書籍翻訳のお話がありましたらぜひご連絡ください。

また翻訳とは別に書きたいと思っている内容があるので、こちらについては一度内容を詰めて企画を練ろうと思います。来年書き始められるといいな。

今年やっていたこと

仕事など

今年の上半期は去年に引き続きGoogleアシスタント関連の仕事をメインにしつつ、 ウェブ関連やAndroid関連の担当をしていました。

そして今年の6月にこれまで4年在籍したチームを離れて、7月からGoogle Cloud DevRelのチームに移り、オブザーバビリティ(担当製品としてはStackdriver)の担当となりました。ここ数年のインフラ周りの動きは個人的に非常に面白と思っていて、もともと5年ほどGoの普及などもやっていたこともあり、クラウドに移りたいなと考えていたところ、チームを拡大するということだったので手を挙げて移動しました。

久々にどっぷりインフラ系の領域に戻れるというのは自分としても嬉しい限りです。またオブザーバビリティの領域はこれから確実に盛り上がってくる領域なので、来年は温めていた企画などをできればと思っています。新年一発目、GCPUGでStackdriverの回があります!

gcpug-tokyo.connpass.com

出張/旅行

今年も多くの出張や旅行に行きました。

とくに7月後半からは一週間おきに出張だったので結構体力的にしんどいものがありました。来年もすでにいくつか出張が決まっていますが、うまくインターネットを使って解決できるところはしたいものです。

資格

上にファイナンシャル・プランニング技能士の資格を取得したことは書きましたが、ファイナンシャル・プランナーというのは別に資格を取らなくても名乗れる業種です。*2 さらに関連する細かな業務を行おうとすると、税理士、宅建士、保険外交員、証券外務員といった資格を取らなければなりません。もちろんファイナンシャル・プランニング技能士としてだけでもできることは十分ありますが、やはり自分が色々なことを知るほど、資格がないことでできないというのは残念で仕方がありません。

来年からまた新たに資格の勉強などを進めつつ、この領域での経験も積んでいければと思います。

来年に向けて

今年もゆるい目標を立てておきます。

  • ログに関する知見の向上
    • オブザーバビリティ領域でも特に来年はログの領域の知見を高めていきたいと思っています。
  • ジム
    • 2年半以上続けているので来年も頑張ります。来年は絞りたい。
  • 部屋の片付け
    • いろいろとものが増えてきたので不必要なものは捨てつつ、デッドスペースの有効活用などをしたいと思います。

*1:公に記載する場合の表記方法が定められています

*2:「ファイナンシャル・プランニング技能士」自体は有資格者のみが名乗れる資格ですが、「ファイナンシャル・プランナー」はだれでも名乗れます。

2018年に買ってよかったもの

はじめに

こんにちは、Stackdriver担当者です。今年も残すところあと2日ですがみなさんいかがお過ごしですか。さて、ここ2年続けて書いていたので今年も1年で買ってよかったものを書いていこうかと思います。

2018年に買ってよかったもの

KARCHER K3 サイレントベランダ

いまの家は住み始めて4年弱になりますが、これを買うまではベランダの掃除がなかなか面倒で、水道もないため水を撒いてはデッキブラシでこするというようなことをして頑張ってきれいにしていました。しかし、3年も過ぎた頃からベランダの壁や、窓のサッシ等々、ブラシで擦ったり雑巾で拭いてもなかなか取れない汚れが溜まってきました。

そこではじめはレンタルでケルヒャーを借りようと思ったんですが、1回数千円する上に返送の手間もあり面倒だなと思ったので、10回使えば元が取れるということで買ってしまいました。このモデルは日本の集合住宅で使うことを想定しているので、従来モデルと比較してもかなり音が静かになっていました。(K2とか、線路のガード下にいるくらいの音がする)

買ってみて、まずベランダがあっという間にきれいになったことに驚きました。本当にありきたりな感想になってしまいましたが、ベランダの3年半分のこびりついた汚れがあっという間に取れ、気持ちいいくらいにきれいな表面が見えるようになりました。またブラシで届かなかった壁や天井もきれいにできたのはおもったよりも達成感がありました。 更にベランダだけでなく、風呂場も取りづらかったカビや排水溝周りの汚れも一気に落とせたので、なかなかに使い所があります。

先に書いたようにベランダには水道の蛇口がないため、ため水を使って水を供給していますが、ケルヒャーのホースやガンの収納も兼ねて、次のような収納ボックスを使って水をためています。蛇口から直接汲んできた水の場合は問題はないはずですが、風呂場の水の再利用も考えてフィルターも使っています。

モレスキン ノートブックツールベルト + フリクションボールスリム ビズ

2018年は手書きメモをちょくちょく取るようになったんですが、その際にノート以外のものをたくさんバラバラと持つのが面倒だったので、モレスキン純正のツールベルトを使い始めました。ここにペンやら付箋やらを詰め込んでいます。

ボールペンなのに消せるというフリクションは結構好きで使っていて、最近はノベルティーとしてもらったフリクションはすべてインクがなくなるまで使い切ってしまいました。そんな経緯もあって、ノートにメモをとるためのペンはノベルティーのペンを使い切ってからもフリクションを使っていたのですが、ペンの太さが携帯するには少し太い印象があったので、このスリムを使い始めたのですが、重さといい細さといいすごく使いやすくて満足です。

Raspberry Pi 3 B+ +ハードディスクケース

玄人志向 3.5型HDDケース SATA接続 電源連動 USB2.0対応 マットブラック GW3.5AA-SUP/MB

玄人志向 3.5型HDDケース SATA接続 電源連動 USB2.0対応 マットブラック GW3.5AA-SUP/MB

Raspberry Piがかんたんなサーバーとして便利であることは言うまでもないのですが、唯一のネックは永続化ディスクがmicro SDカードであるため、ログの書き込み等々の設定をきちんと行わないとSDカードの書き込み回数の限界をすぐに超えてしまい常用サーバーとして利用することはできません。

そこで外部ストレージで起動できるように設定を変更してその心配をなくしました。起動速度がクリティカルになったりすることはないので、家に転がっていた3.5'' HDDを利用しました。今のところまったく問題なく安定して稼働しています。

iPad Pro 11'' 256GB + Apple Pencil

Apple 11インチ iPad Pro Wi-Fiモデル 256GB スペースグレイ MTXQ2J/A

Apple 11インチ iPad Pro Wi-Fiモデル 256GB スペースグレイ MTXQ2J/A

ノートを書き始めると同時に、自分が資料の作成時に使う挿絵も手描きで作りたくなりました。はじめは手でラフに書いてから、スライドの作図機能を使って書いていたのですが、どうせなら直接貼れる画像を作りたいと思うようになり、ちょうど発売になったiPad ProをApple Pencilとともに購入しました。

今回のiPadを使う前はiPad miniをずっと使っていたのですが、家にある常用端末のうちでLightningケーブルが必要になるものがそれしかなかったため、非常に不便に感じていました。しかし今回のアップデートでついに他社製品と共有できるUSB-Cケーブルの利用となったことは買うにあたって非常に大きなモチベーションとなりました。

またApple Pencilの充電方法も初代のものから進化し、本体に磁石で取り付けるだけで充電できるようになったのも、収納や安全性の観点から買うにあたっての安心感が大きくなりました。久々に文句なく使えるApple製ハードウェアです。挿絵だけでなく、PDFの添削など快適に利用しています。

メタルラック

自分は片付けが苦手なタイプです。サーバーとかアンプなんかもリビングの床にそのまま置いたりしていたんですが、いよいよ目障りになってきたので一箇所にまとめるべくメタルラックを購入しました。こうしたラックはいくつか有名な製品があって、エレクター「ホームエレクター」シリーズドウシシャ「ルミナス」シリーズ などが有名ですが、アイリスオーヤマのメタルラックシリーズを選んだのは、その値段の安さと製品の展開がちょうどよかったのが決め手でした。

おわりに

今年は去年ほどデジタルグッズを買いませんでしたが、この年末で大掃除をしていたらまた新たに自動化したりスマートホーム化したくなってきたので、来年は細かな購入が増えそうです。

golang.org/x/text/messageでI18N

はじめに

こんにちは、Stackdriver担当者です。この記事は Go Advent Calendar 2018 *1の最終日のエントリです。昨日は @yasuo-ozuさんの「Go言語は沼」 でした。

ところで今日はクリスマスですね。自分宛も含めてまだプレゼントを送っていない方はこの本を送るのがおすすめです。

Go言語による並行処理

Go言語による並行処理

年末年始休暇に読んでもらってGo言語による並行処理への理解を深めてもらいましょう!

さて、今日は準標準パッケージの "golang.org/x/text/message" の紹介です。本文に出てくる雑なサンプルのリンクを貼っておきます。

"golang.org/x/text/message" とは

godoc.org

Go準標準パッケージ内にある、国際化のためのパッケージです。履歴を見ればおわかりの通り、非常に地味に更新が続いているパッケージです。

Log - master - text - Git at Google

このパッケージは大きく分けて2つの使い方があって

  • フォーマットのローカライゼーション
  • メッセージの翻訳

の2種類があります。どちらもメッセージの出力をする際に fmt パッケージでなく、 message.Printer を使うようにするところがポイントです。

フォーマットのローカライゼーション

これはドキュメントのサンプルにあるとおりで、プリセット(CLDR, Common Locale Data Repositoryに準拠)で用意されているフォーマットを利用して、数字の3桁区切りやその区切り文字、通貨記号の取扱も可能です。*2

これらはパッケージの目的として golang.org/x/text 以下にあるデータフォーマットにはすべて対応するという目標があるようです。(まだやってない)

import (
    "golang.org/x/text/currency"
    "golang.org/x/text/language"
    "golang.org/x/text/message"
)

func localization() {
    jp := language.Japanese
    p := message.NewPrinter(jp)
    cur, _ := currency.FromTag(jp)
    // クリスマスには¥ 120000のiPadを買いました。(フォーマット引数が%dなのに通貨記号が入っているのがミソ。しかしカンマ区切りが反映されない)
    p.Printf("クリスマスには%dのiPadを買いました。\n", currency.NarrowSymbol(cur.Amount(120000.0)))
    // お年玉は10,000円あげるつもりです。(カンマ区切りが反映されている)
    p.Printf("お年玉は%d円あげるつもりです。\n", 10000)
}

メッセージの翻訳

正直ローカライゼーションのほうはまだまだ改善の余地ありという感じですが、一番良く使われるのはこちらのメッセージの翻訳機能の方でしょう。こちらは使い方が単純です。

ベースとなるフォーマット文字列をキーとして、各言語ごとに翻訳版のフォーマット文字列を指定するという形です。(message.Setmessage.SetString を使う) 指定した文字列は golang.org/x/text/message/catalog#Catalog に追加されていくだけので、アプリケーションなどで使う場合には独自のカタログを作っておくと良いでしょう。(例: エラーログメッセージなど)

import (
    "golang.org/x/text/language"
    "golang.org/x/text/message"
)

func init() {
    message.SetString(language.Japanese, "%d days to the new year day.\n",
        "新年まであと%d日\n")
    message.SetString(language.Japanese, "%s, I wish you a happy new year.\n",
        "%s、良いお年を\n")
    // フォーマット引数の順番を入れ替える場合には"[]"を使って指定する
    message.SetString(language.Japanese, "%s, %s\n", "%[2]s%[1]s\n")
}

func translation() {
    p := message.NewPrinter(language.Japanese)
    local, _ := time.LoadLocation("Local")
    nyd := time.Date(2019, 1, 1, 0, 0, 0, 0, local)
    days := nyd.Sub(time.Now()) / (time.Hour * 24)
    // 新年まであと6日
    p.Printf("%d days to the new year day.\n", days)
    // みなさん、良いお年を
    p.Printf("%s, I wish you a happy new year.\n", "みなさん")
    // 世界、こんにちは
    p.Printf("%s, %s\n", "こんにちは", "世界")
}

ただこちらもドキュメントにフォーマット引数の順番に関する記述がなかったり、plural.Selectf の動作がいまいち怪しかったりと、まだまだ改善の余地ありな状況なので、もし本番に使うなら message.SetString に限るなど限定的な使用方法が良いかもしれません。逆にContributeチャンスでもありますね。

おわりに

個人的な感想として golang.org/x/text 以下は需要の割に作りが甘い感じがしていて、今回も調べるにあたってつまずく部分がいくつかありました。このあたりのパッケージは技術的な困難さという部分よりも、テストケースをいかに作るかという部分が大きいと思いますので、これを機会にこのパッケージを使ってGo製アプリケーションの日本語化をどんどん行って、どんどんIssue登録がされると良いなと思いました。

今年も1年お疲れ様でした。Gopherのみなさん、良いお年を。

*1:ところで、オーバーフローしたGoのアドベントカレンダーが ”Go 2〜" "Go 3〜" となってるのに違和感を感じたのは僕だけでしょうか。"Go〜 その2” とかならわかるけど、最初 "Go 2〜" を見たときに、Go 2 に関するアドベントカレンダーかと思いました。

*2:ただ、このエントリを書いていてところどころ挙動が怪しいところを見つけてしまったので、これはcontributeチャンスですね。

リモートオフィス同士のコミュニケーション

はじめに

こんにちは、Stackdriver担当者です。この記事はpyspa Advent Calendar 2018 の24日目の記事です。メリークリスマス。昨日はインターネットワイドショーこと @tokoroten が担当でした。

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

現職と前職について

自分は前職は米国本社のソフトウェアパッケージベンダーの日本支社に勤務していて、現職は米国本社のソフトウェア企業の日本支社*1に務めています。2社ともカリフォルニア州シリコンバレーに本社を構える巨大な企業で、両社ともに世界中に支社を構えています。

前職では本社の製品開発チームに対して製品の検証結果を元にバグや機能要望などをフィードバックしたり、複数のパッケージ製品を用いたソリューション開発などを行っていました。

現職では、担当の製品や技術領域に関わるもの、特に最新技術を広くコミュニティや先進的取り組みを行っている企業に紹介し、技術支援をするというような仕事をしています。

2社を通じてほぼ常に*2開発チームが海外の別のオフィスにいて、特に現職では開発チームをはじめとする多くの海外のメンバーと日々やり取りをしながら仕事をしています。そうした中で、自分なりに会社で得たノウハウなどは得たけれど、意外にリモートワークをする上で気をつけていることやツールの使い方をこれまでまとめたことがなかったなと思ったので、この自由なアドベントカレンダーを機にまとめてみようと思います。

コミュニケーション手段やツールについて

現職において利用されるコミュニケーションツールは主に次のとおりです。

  • 対面での議論
    • 会議
    • 雑談
  • ビデオ会議(Hangout Meet)
  • チャット(Hangout Chat)
    • チャットルーム
    • ダイレクトメッセージ
  • メーリングリスト
  • メール
  • ドキュメント(Google DocsGoogle Slides、etc...)
  • Wiki
  • 電話
  • イシュートラッカー
    • バグ報告
    • 障害報告
  • コードレビューツール

人間のコミュニケーションにおいて、リアルタイムコミュニケーションが可能なときはそれが一番速いため、可能な限りをそれを利用したくなります。例えば、現職でよくあるのが「オフサイト」と呼ばれるイベントです。各地のオフィスにバラけているメンバーを一箇所に集めて、1日〜数日かけて集中的に普段出来ない議論を膝を突き合わせて行います。こうしたイベントが行われるのも、実際に会って相手の表情や身体的な表現を確認しながら話すということの重要性が認識されているからでしょう。

しかしながら、オフサイトはコストがかかるため、気軽にはできません。拠点が複数に分かれている場合、通常は補助的にツールを使うことになります。各ツールには一長一短があるので、状況に応じて使い分けをする必要があるでしょう。先に挙げたツールを次のような点を考慮しながら使い分けていくことになります。

  • メディア : 生、映像・音声、音声のみ、テキスト・画像、テキストのみ
  • 同期性 : その手段が同期的な(リアルタイム)コミュニケーションを求めるか
  • トピック独立性 : その手段でのコミュニケーションは話題ごとに区分けがされているか
  • 情報量 : 時間あたり or 1投稿あたりの情報量
  • 並行性 : 同時多発的に並行したコミュニケーションが可能か
  • 検索性 : あとからそのコミュニケーションの内容を検索できるか
  • 閲覧性 : その手段でのコミュニケーションの記録は第三者が見たときの閲覧性が高いか
  • 拡散性 : その手段でのコミュニケーションの記録を第三者に共有しやすいか
  • コスト : その手段を行うことの金銭的、時間的なコスト

他にもいろいろあると思いますが、とりあえずこんなところでしょう。

さて、以下は自分の環境において、いかにリモートオフィスの人たちとコミュニケーションするかという話です。ここではツールの選択に関して理由をわかりやすくするために、自分の置かれている状況を簡潔に共有します。

  • 世界各地にいる同僚と定常的にコミュニケーションを取らなければならない
  • ある担当領域において自分が常にタイムゾーン的に少数派(大多数は他のオフィスにいる)
  • 関係者はそこそこ多い

自分が気をつけていること

こうした状況でまず自分がなにに気をつけているかといえば「自分はここにいますよ」というアピールです。気をつけていると言ってもまだまだ足りていないのですが、でも目についたらやっています。たとえばある機能の仕様書や設計書のドキュメントレビューのタイミングでは、特に問題がないと思っても「ここは自分も良いと思った」などとポジティブなフィードバックを記録として残すようにしています。また、ビデオ会議やメーリングリストでも、同じ意見であったとしても「自分も同様に思った」と意見を言う、などです。海外オフィスに孤立していると容易に忘却されがちです。どんな些細なことでも意見をいうことで自分という人間が認識してもらえるようにしています。(単純接触効果)

また対面している人間のタイムゾーンを意識しています。たとえば日本時間を基準にすると、朝7-10時はアメリカ西海岸の人たちが終業に向けて仕事を終らせる時間(PSTで15-18時)なので、急ぎの場合はチャット、ゆったりめの場合はメールなどで朝一番(起きてすぐ)に連絡します。そのあと一通り仕事をしてから、身支度をして会社に行き、しばらくは自分の仕事をしていますが、今度は16-17時くらいにロンドンの人たちが起きて(GMTで7-8時)きます。帰宅したあと、早ければ夜10時過ぎ(ESTで8時過ぎ)くらいからアメリ東海岸の人に連絡をとり、深夜0時ころになるとアメリカ西海岸の人が起きて(PSTで8時)くるので、寝てる間にやってもらいたいことを連絡する、という具合です。 いつもがいつもこんな様子ではないですが、タイムゾーンはどうやっても解決できないので、運用でカバーするしかありません。逆に拠点間をうまく連携できれば効率よく仕事することも可能です。

あとはなるべくドキュメントやメールをベースにしてコミュニケーションを取るということです。最近ではメールを使っている会社は古く、チャットで仕事をすべき、というような発言を見かけることもありますが、先に挙げたような項目を考えたときに、チャットの閲覧性と検索性と情報量の少なさは時差を前提としたコミュニケーションでは致命的です。特にスレッド機能が弱いチャットシステムを利用する場合、その状況は悪化します。メールは依然としてスレッド形式である程度の分量のメッセージのやりとりをするには向いていると思います。しかしながら、議論をメールのみで行うのも効果的ではないと考えています。議論の経緯でなく、最終結果の確認する場合の閲覧性が低いからです。そこで骨子はGoogle Docsにたたき台を提供して、すり合わせが必要になる議論はそこでのコメントやメールスレッドを補完するという方法をなるべく採るようにしています。

同僚にお願いしていること

自分で気をつけていてもコミュニケーションというのは相手がいて成り立つものなので、相手にもお願いすることがあります。

たとえば、時差を考慮したミーティング時間の設定です。まだ他オフィスと協調して働くことに慣れていない同僚は、気軽に日本時間の夜中の3時とかにミーティングを設定してきます。自分がどうしても参加したいという場合には、まず最初に「そちらの時間帯での何時から何時でないと日本からは参加できない」という話を根気強くします。 もちろん、参加者の中で自分だけが違う時間帯であることが多々あるので気が引けることもありますが、単純に相手が意識していなかっただけのこともあるので、まずは言ってみます。また参加できない場合も議事録や会議の録画を最低でも依頼します。議事録用のドキュメントが用意されていれば事前に質問を書いておくこともできますし、録画が残っていれば会議の雰囲気も把握しやすくなります。事後に反論すれば結論が覆ることもあります。さらに、こちらが寝ている間にミーティングがキャンセルされることもよくあります。仕方ないとは言え、一言「直前のキャンセルでごめんね」といってくれればこちらの気持ちも違ってきます。ミーティングの無断欠席も同様です。

また、チャットでのコミュニケーションを多用しすぎないようにもお願いしています。先に挙げたように、チャットの記録というのは閲覧性が高くないため、事後に会話を追うことのコストが高くなります。会話の中で決まったことを拾うのも面倒です。また時差がある中でチャットを多用されると、よほど意思が強くなければFOMO (Fear of missing out)になることもあります。

最後で一番重要に思っているのがオフラインでの意思決定の記録です。こちらが手足を出せないのが別オフィスで行われるオフラインでの決議なので、これの記録が残されないと自分の仕事に対するモチベーションは著しく削られます。自分が関係ない部分であればまだしも、自分が関係ある部分に関しては面倒でもメールかドキュメントとして連絡してほしい旨は必ず念押しています。

最後に

いろいろ書いていましたが、こうした働き方ができるようになると自分の働き方の可能性が広がってくるのも実感できます。自分の職種が特殊なこともありますが、同僚がほとんど海外ということは日本にいる限りはネットにつながっている限り特に場所を選ばないということです。例えばキャンプ場で仕事することも可能でしょう。(実際に海の家で仕事をしたこともあります。)

リモートワークそのものは、会社としてはコストがかかる働き方だと思いますが、それでも成り立つ組織を実現できれば、より柔軟な生活が得られるようになると思いますし、それこそがITだと思います。もっと多くの人がリモートワークの知見を共有して、それが当たり前になる日が早く来ることを願っています。

明日は @hagino3000 です。

*1:しばしば私が勤務する東京オフィスはローカライゼーションしかしていないという誤解を持っている人がいますが、東京オフィスは非常に重要な開発拠点で、世界中のユーザー向けにサービスや製品を開発しています。

*2:現職で関わったいくつかの制品は東京オフィスで開発していました

「Go言語による並行処理」という本が出版されました #cingo

はじめに

こんにちは、Stackdriver担当者です。このたび私の印刷書籍としては2冊めの翻訳本「Go言語による並行処理」がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

Go言語による並行処理

Go言語による並行処理

電子書籍版についてはオライリー・ジャパンのサイトよりePub、mobi、PDFの各種フォーマットにてご購入いただけます。 www.oreilly.co.jp

誤字脱字等を見つけた場合にはこちらのレポジトリまでご報告ください。 github.com

「Go言語による並行処理」はどのような本か

本書はKatherine Cox-Budayが2017年に執筆した "Concurrency in Go" の日本語訳書籍です。

Concurrency in Go: Tools and Techniques for Developers

Concurrency in Go: Tools and Techniques for Developers

この本はこれまで多くの場所で議論されたり語られたりされてはいたものの、書籍のようなまとまったボリュームで記述されることが少なかったGoでの並行処理についてのあれこれを1冊にまとめた本です。 Goの特徴といえば、並行処理を前提とした言語仕様および標準ライブラリでのサポートが挙げられますが、本書ではそれらの前提にある理論の説明と、実際にそれらを使った並行処理のパターンを記述方法についての説明、さらにはランタイムの内部動作に至るまでを触れています。

ともすると並行処理に関する理論などはそれだけでも非常に多くの説明を要し、このサイズの本には収まりきらない内容になってしまうところですが、本書では説明に必要な最低限の部分だけをうまく切り出し、それらを抑えた上でGoでの実装に多くの分量を費やしています。最低限とはいいつつも、必要な内容に関してはうまく導入しているので、理論的な内容を知りたい方も本文や脚注で触れられている参考文献を参照することで、より深い内容を理解するきっかけにもなることと思います。

また本書ではGoでの並行処理で陥りやすい失敗はなにか、紹介するテクニックがなぜ必要になるのか、といった内容も失敗例も含めて記述されているので、実際にコードを書いてはまったことがある人にはより実感を持ってご理解いただけるのではないでしょうか。

すでに @mattn_jp さんや @lestrrat さんより書評をいただいていますので、そちらもあわせてご覧いただけると、どのような本かよりイメージしやすいかと思います。

mattn.kaoriya.net

medium.com

出版に至るまでの話

私がGoを知ったのは、2010年2月ごろで、まだGoに go tools がなく、Makefileでビルドし、クロスビルドはできていたものの、対象アーキテクチャごとに 6g8g などの専用コンパイラを使う、まるでPlan 9そのままといった様子でした。

その後私がGoogleに転職し日常的にGoに触れるようになり、Goを本格的に使いだしたのはGo 1.0がリリースされる前後でした。その後もGoは今日に至るまで発展を続け、Makefileアーキテクチャごとのコンパイラをいちいち叩きながら使っていたビルド環境も徐々に go tools として一つにまとめ上げられ、またかつては数少なかったサードパーティーパッケージも、いまや実用に耐えうるものが潤沢になりました。そしてGoを本番環境システムの開発用言語として採用する企業もいまや当たり前となりました。はじめてのGoConであるGoCon 2013 spring を開催したときには、まだ採用している企業が日本ではほとんどなかったことを考えると、言語自身だけでなくコミュニティもものすごい勢いで拡大してきたことがおわかりでしょう。

そんなGoですが、オープンソースとしてリリースされた当初から変わらず、それでいてもっともGoをGoたらしめているもの、それが goroutinechannelselect といった並行処理に関するプリミティブです。 Goがこれほどまでに急速な発展を遂げたのも、Goの並行処理のプリミティブが非常に強力であったことと、マルチコアCPU時代かつ分散処理が当たり前になりつつあった時代の要請とが見事に噛み合ったことが大きな要因の一つでしょう。*1

そうしたプリミティブは使い始めるには非常に簡単ではあったのですが、どんな道具でもそうであるように「使いこなす」ためには経験が必要となります。他言語での経験があった開発者も、スレッドプールなどを用いた並行処理のパターンをゴルーチンに当てはめて使うことは容易だったとは思いますが、それでもGo独特の並行処理の記述方法やパターンなどは標準パッケージ内での記述や、 golang-nuts のような開発者メーリングリストでシェアされたことで広まったものも少なくありません。

私自身もそうしたところから学んでいった一方で、2年ほど前に、こうした一箇所にまとまっていない情報が整理された書籍があればいいなと考えていたところでした。そんな折に原著である Concurrency in Go の出版の話を知り、以前よりお世話になっていたオライリー・ジャパンの瀧澤さんにその翻訳ができないか聞いてみました。最初のお返事では訳者と編集のご担当の方がすでにいらっしゃるということでしたので、私もそれを楽しみにしていたのですが、その後紆余曲折あり6年ぶりにオライリージャパンでの翻訳を瀧澤さんとご一緒させてもらえることとなりました。

かねてより瀧澤さんのお仕事は間近に見ていたので、今回も翻訳開始前から非常に頼もしく、実際編集に関しても非常にやりやすい環境を提供していただけました。初校、レビュアーによるレビュー、二校、三校と各段階で間に原稿が進まない時期もあったのですが、瀧澤さんにスケジュールをご調整いただき無事に年内に発刊に至りました。

謝辞

訳者序文でも謝辞として執筆させていただきましたが、本書では多くの方々よりレビューをいただきました。 あらためて本書の出版にあたり、忙しい業務や私生活の合間を縫ってレビューに参加してくださった皆様に感謝いたします。

レビュアーの皆様(五十音順)

  • 伊藤友気さん (@mururururu)
  • 上田拓也さん (@tenntenn)
  • 上西康太さん (@kuenishi)
  • 小泉守義さん (@moriyoshit)
  • 渋川よしきさん (@shibu_jp)
  • 知久翼さん (@_achiku)
  • 中島大一さん (@deeeet)
  • 松木雅幸さん (@Songmu)

オライリー・ジャパン

  • 瀧澤昭広さん (@turky)

特に、上西さん、知久さんには英語の細かなニュアンスの差異などを指摘していただき、大いに参考になりました。また小泉さん、渋川さんには訳注として追加すべき情報や技術的な考慮点などを共有いただいたことで、本書の内容がより充実したものとなりました。@mattn_jp さんには書評をいただいただけでなく、本書の告知にも多分にご協力いただきました。あらためて、ありがとうございました。

参照

*1:他にも多くの開発者が慣れている手続き型指向の言語であったこと、実行速度が速いこと、標準のツールが充実していること、シングルバイナリにビルドされること、メモリフットプリントが小さいこと、ランタイムの起動が速いこと、ビルドが継続開発に耐えうる時間で完了すること、など理由は様々だと思います。