mikanmarusanのブログ

テクノロジーとかダイビングとか

「その仕事、全部やめてみよう」をCTOの目線で読む

クレディセゾンCTOの小野 和俊さんから「その仕事、全部やめてみよう」 を献本いただいた。

自分にとって小野さんと言えば、未踏スーパークリエイターであり、エンジニアの多くが一度は読んだことがあるであろう「小野和俊のブログ」の中の人であり、スタートアップ創業を経て大企業のCTOをされている、伝説のエンジニアの一人だ。昨年からは、日本CTO協会で理事としてご一緒させていただいており、その熱量と経験にいつも圧倒されている。

前記の日本CTO協会の理事のみなさんが、非常にするどい書評を書かれていてこちらも大変勉強になる。

自分は少し別の角度から本書についてコメントしたい。

本質を抽出する

仕事柄、他社のCTOの方とディスカッションすることが多い。ディスカッションの内容は多岐に渡る。例えば、利用している技術、今後注力していきたい技術、エンジニア組織、採用、評価、ビジネスサイドとの関係性などだ。これらのディスカッションは実に学びが多い。

一方で、矛盾したような言い方となるが、その議論で知り得た知識や取り組みの多くは（残念ながら）参考にならない。もう少し正確にいうと、知り得た知識や取り組みを自社でそのまま適用しても大抵機能しないという意味だ。これは会社のフェーズや事業内容、規模、組織体系、扱っている技術、事業コンディション、マーケットサイズや市場環境、その全てが違うからだと思っている。 だからディスカッションで得た知識の根っこの部分を見抜くこと、本質が何かを抽出する ことが必要である。そして抽出された本質がそもそも自社にマッチするかを見極めて、さらにそれが最大限レバレッジが効くようにする、という作業を必要とする。

「本質を抽出する」と7文字で書くのは簡単だ。これが実に難しくて、CTOを4年務めていてもまだまだだと感じることが多い。ネタバレしてしまうので内容はここには書かないが、本書で一番びっくりしたのは、本質への追求のアプローチが序章の最初の最初で来るところ。ここは思わず3回読んでしまった。

シンプルでキャッチーなフレーズ

本書では「エンジニア風林火山」「バイモーダル戦略」「ラストマン戦略」といった、シンプルだけどキャッチーな言葉がいくつかある。これらはもともと前述の小野さんのブログでも書かれているものであるが、一度読んだり聞いたりしたらなかなか忘れることができない。

CTOとして何か大きな技術的なイニシアチブを動かそうとするとき、従業員にそのイニシアチブを理解してもらわないとならないし、少なくとも多くの従業員にそのイニシアチブの名前だけでもまず覚えてもらう必要がある。技術的なイニシアチブを実行するときについ技術用語を並べたくもなるが、サービスプロダクト開発に関わるメンバーはエンジニアだけではないから、平易な言葉で、忘れることなく、しかもそれが本質な意味を合わせもつものが要求される。だからシンプルでキャッチーなフレーズを作り出すアプローチは重要だ。シンプルにすればするほど本質を鋭く表せないといけないから。

ちょうど、いまヤフーではサービス開発環境を刷新する全社横断のイニシアチブを実行中だが、このプロジェクト名の考え方も小野さんのブログを見たことがきっかけだった。

本書ではまだまだシンプルでキャッチーなフレーズが出てくるが、どれも本質を鋭く表現していると思う。さらにいうと本質は大抵味気ないものになりやすい。これを小野さん調でわかりやすく、すーっと入って来やすいストーリーに仕上がっているように感じた。だから読みやすい。ネタバレしちゃうので続きはどうぞ手にとってもらえると！

まとめ

本書を最後まで読んだ感想は、ずばり現場の匂いがするということだ。CTOというポジションだけでなく多くのエンジニアを勇気づける一冊だと思う。また読み直そうと思う。

blogやtweetを英語で書いてみるということ

English

（最近英語でエントリを書くことにしているのですが、この記事は特性上日本語で書いています）

はじめに

今年度ぐらいから（この）hatanablogやtwitterのtweetを英語で書くことを意識的に多くしている。もしくは英語と日本語の両方で書いたりする。先に断っておくと、別に英語ができるわけではない。知り合いからは「外国かぶれ」とか「意識高い系」とか「令和になったからか」など散々言われている。

普段エンジニアとして何か調べ物などをしている時、日本語のサイトは読みやすいので優先的に見てしまうが、少し複雑な調べ物であったりレアなケースの場合、英語で書かれているサイトの情報が参考になることが多い。おそらくその記事を書かれた著者は日本人にも見て欲しい！と思って書いたわけではないだろうが、事実として一人の日本人の課題を解決したことになる。もし自分が英語でblogを書いたりtweetしたりした場合、それらのpostやtweetのリーチがどう変化するのか、どのような人が見てくれるのか、どのような人の課題を解決できるのだろうかを急に知りたくなった。さらには、自分にどのような変化があるのかも知りたくなった。それを（日本語でも）tweetしている。要は一人の人間の小さな社会実験だ。

この記事ではblogやtweetを英語で書いてみて気づいたこと、利用しているツール、自分自身への変化をまとめてみる。

hatenablogや twitter やへのアクセスはさほど変わらない

まず一番興味があったpostやtweetのリーチがどう変化するかについて。総じて言うととさほど変化しないという切ない結果に。

まずがhatenablogについて。海外かつ日本語以外の言語のアクセスは2-3%だった。日本からの総アクセスには変化がないので 2-3% 新規でトラフィックを獲得できたとも言えるが、統計的には誤差の範囲だろう。Medium, Wix, Tumblr, WordPressといった米国を中心にグローバルに利用されるブログサイトを使うと違った結果になるかもしれない。
そしてtwitter。プロフィールを見るに海外のエンジニアの方と思わしきアカウントからのフォローをいくつか頂いたし、DM経由で海外企業のオファーもいつか頂いた。もちろん英語。それにしても海外企業からのヘッドハンティングは役割と条件を明確に伝えてくるから本当によい。日本だとxxx候補、給与は当社規定とか現職をベースに要相談とかだし。リクルーティングにはtwitterはよさそう。

使っているツール類

英語が得意ではないのでツール選びは重要だと思っている。自分は下記の3つを使っている。

英和・和英辞典

利用する頻度が一番高いので、自分が使いやすいものがよさそう。自分は英辞郎のPro Liteモードにして利用している。

文法チェック

文法チェックにはGrammarlyを使っている。これは英語の文法的な間違い、スペルミス、句読点の間違いをリアルタイムにチェックしてくれるサービス。無料版と有料版があり自分は無料版を使っている。自分はa/the/複数形の訂正をよく参考にしている。Chrome拡張を使えばブラウザ上のフォームに書いている場合でもチェックできるようになるのもよき。iPadアプリもあるが純正キーボードをつけておくと動かないのは謎。

英英辞典

ネイティブでないので少ない単語で表現されているものがよいと聞いたことがある。自分は Longman Dictionary of Contemporary English Onlineを使っている。英英辞典の利用頻度は正直そこまでは高くないが、抽象度を高く説明する場合、英語でどう説明できるかがわかるのはとてもよい。例えば下記は「橋(bridge)」の例。構造物としての橋と、何かと何かを繋ぐ橋を英語がそれぞれ表現されていてとてもわかりやすい。

bridge

1 structure built over a river, road etc that allows people or vehicles to cross from one side to the other 2 something that provides a connection between two things 類義語 link （引用元: Longman Dictionary of Contemporary English Online)

自分にとっての変化

英語に向き合う上で大きな二つの変化に出会うことができたと思っている。

最初から英語で書き始めるようになった

いままでは先に伝えたいことを日本語で書き出し（もしくは脳内で考えておき）、それを英語の翻訳する作業をしていた。日本語だと複雑で抽象的な文章が容易に表現できてしまうが、これを英語で表現するには自分のスキルが圧倒的に足りない。できたとしても非常に時間がかかる。したがって最初から英語で書き始め、一度書いたあとで添削することにしている。非常に拙い英語の表現になっている可能性は極めて高いが、相手に伝わっていえばいいと信じてやっている。
そしてこちらは副産物になるが、難解・複雑・曖昧な英語表現を知らないので自ずとシンプルな英語表現にならざるを得ない。しかし逆にわかりやすいシンプルな日本語の文章を書くトレーニングにもなることも分かってきている。

文章を 返り読み/戻り読み しないようになった

返り読み/戻り読みという言葉が正しいのかも分かっていないが、これらは自然な日本語表現になるように翻訳しながら読んでいく読み方だと思ってもらえるとうれしい。例えば "I have a pen." という英文の場合、私は(I)ペンを(a pen)もつ(have)と文章の中を進んだり戻ったりして訳しながら進むものというとわかりやすいかもしれない。ただリアルで英語を使うシーンでは、このやりかただとスピードがでないし、自分が日本語を読むときにそのように読まず文頭から文末まで一気に読んでいくことを考えると返り読み/戻り読みはそもそも不自然なんだろうなと思うようになってきた。これを心がけてから英語で話される技術的なトピックスについても耳が追いつくようになってきたし、なにしろ論文が過去対比５倍ぐらいの速さで読めていて満足しつつある。
一方で技術的なトピックスなど自分の関心事は耳が追いついているが、同じ技術トピックスでも一度抽象的な話に突入すると？？？となることが多い。これは完全に経験とスキルが足りていないと実感するところである。

まとめ

blogやtweetを英語で書いてみると意外と面白い

Is there any function in JavaScript which is equivalent to PHP's array_column()?

(please find the Japanese translation after the English text)

Please let's me go easy because I'm a newbie about JavaScript :)
In order to transform my data, I looked for the function which is equivalent to PHP's array_column() in JavaScript.

array_column() returns the values from a single column in the input array:

<?php
$records = array(
    array(
        'id' => 1,
        'name' => 'mikan'
    ),
    array(
        'id' => 2,
        'name' => 'maru'
    )
);

$names = array_column($records, 'name');
?>

However, I couldn't find the function in JS, so I wrote the code myself. it was annoying...

function arrayColumn(input, columnKey) {
    return input.map(function(value, index) {
        return value[columnKey];
    })
}

Please tell me better and easily way!

JS初心者のため手加減してほしい :) データ変換をするために、PHPの array_column() に相当する関数を探していた。

array_column() は入力配列から単一のカラムの値を返す関数である。

<?php
$records = array(
    array(
        'id' => 1,
        'name' => 'mikan'
    ),
    array(
        'id' => 2,
        'name' => 'maru'
    )
);

$names = array_column($records, 'name');
?>

JSでそれを見つけることができなかったので、自分で書く羽目になった。微妙すぎる。

function arrayColumn(input, columnKey) {
    return input.map(function(value, index) {
        return value[columnKey];
    })
}

誰かもっといい方法があれば教えてほしい。

Argon2id: password hash algorithm which is introduced from PHP7.3

(please find the Japanese translation after the English text)

overview

This is the 3rd article about password hash function on php. I’m deeply in love with password hash function :) . In this article, I’d like to explain the Argon2id which is the password hash algorithm introduced into php7.3 launched on December 6th, 2018.

The following are the previous articles.

mikanmarusan.hatenablog.com
mikanmarusan.hatenablog.com

TL;DR

  • PHP7.3 introduced Argon2id as a password hash algorithm.
  • Argon2id is a hybrid of Argon2i and Argon2d. We should use Argon2id unless there is some particular reason.
  • Default password hash algorithom is NOT changed (bcrypt)

Argon2id

To put it simply, PHP7.3 introduced Argon2id as a password hash algorithm. Argon2id is a hybrid of Argon2i and Argon2d, using a combination of data-depending and data-independent memory accesses, which gives some of Argon2i's resistance to side-channel cache timing attacks and much of Argon2d's resistance to GPU cracking attacks.

There is some question. Why do we use Argon2i if Argon2id exists? Why does not PHP deprecate Argon2i? In RFCs for PHP , it's written as follows:

Should we deprecate Argon2i? [RESOLVED]

No, I do not believe we should deprecate Argon2i from password_*. Argon2i remains a perfectly secure and reasonable choice for password hashing. Argon2id simply provides better resistance to some form of attacks at the cost of time-memory tradeoffs. Argon2id is recommended at this point simply because it provides a blend of Argon2i and Argon2d. The existence of Argon2id does not negate the benefits of Argon2i.

I could not understand :P, then I'd like to deeply explorer.

In RFC draft, it's written as follows:

9.4. Recommendations

The Argon2id variant with t=1 and maximum available memory is recommended as a default setting for all environments. This setting is secure against side-channel attacks and maximizes adversarial costs on dedicated bruteforce hardware.

The draft RFC explicitly telling us that if we don't know which to use, we should pick Argon2id.

  1. Parameter Choice

    If you do not know the difference between them or you consider side-channel attacks as viable threat, choose Argon2id.

APIs

password_hash

Creates a password hash.

string password_hash ( string $password , integer $algo [, array $options ] )

The password_hash() function is altered to accept PASSWORD_ARGON2ID as the algorithm.

<?php
    $raw_passwd = '3kanmarusan_Passw0rd';

    $hashed_passwd = password_hash($raw_passwd, PASSWORD_ARGON2ID);

# generated hash
$argon2id$v=19$m=1024,t=2,p=2$SEJ2M2VNL3B5MXZNN0tDYg$44a3kX0OxiFzoy4bCtkHnAyy7/TVkvIVU7kdyj8ewCg

The password has been hashed using Argon2id since the beginning of hash string is "$argon2id". "$m=1024,t=2,p=2" means cost parameters. These are memory cost, time cost and threads. Argon2id will use the same default cost measures as the Argon2i implementation.

I confirmed the default of password hash algorithm. The default password hash algorithom is NOT changed, PASSWORD_DEFAULT use the bcrypt algorithm.

# confirm the default of password hash algorithm
<?php
  echo "[constants]" . PHP_EOL;
  echo " PASSWORD_BCYRPT: "  . PASSWORD_BCRYPT  . PHP_EOL;
  echo " PASSWORD_ARGON2I: "  . PASSWORD_ARGON2I  . PHP_EOL;
  echo " PASSWORD_ARGON2ID: "  . PASSWORD_ARGON2ID  . PHP_EOL;
  echo " PASSWORD_DEFAULT: " . PASSWORD_DEFAULT . PHP_EOL;

# result
[constants]
 PASSWORD_BCYRPT: 1
 PASSWORD_ARGON2I: 2
 PASSWORD_ARGON2ID: 3
 PASSWORD_DEFAULT: 1

password_verify, password_get_info, password_needs_rehash

The password_verify(), password_get_info() and password_needs_rehash() functions are altered to accept Argon2id hashes.

(Again) TL;DR

  • PHP7.3 introduced Argon2id as a password hash algorithm.
  • Argon2id is a hybrid of Argon2i and Argon2d. We should use Argon2id unless there is some particular reason.
  • Default password hash algorithom is NOT changed (bcrypt)

概要

PHPのパスワードハッシュ関数シリーズの第3弾。自分はどうもパスワードハッシュ関数を愛しているようだ。 2018/12/06にリリースされたPHP7.3で追加されたハッシュアルゴリズム Argon2id を調べてみた。

過去の記事はこちら
mikanmarusan.hatenablog.com
mikanmarusan.hatenablog.com

TL;DR

  • パスワードハッシュ関数(password_*)のハッシュアルゴリズムに Argon2id が追加
  • Argon2idはArdon2iとArgon2idのいいとこどりだが、今後はArgon2idを選ぶのがよさそう
  • PHP7.3でもデフォルトのハッシュアルゴリズムに変更なし（bcyrptのまま）

Argon2id

簡単にまとめると、サイドチャネル攻撃（side-channel timing attacks）耐性があるArgon2iと、GPUのような高性能マシンを使った攻撃に対する耐性があるArgon2dの2つで構成されるパスワードハッシュアルゴリズムである。今回はこのいいとこ取りをしたArgon2idがPHPで採用されたというものである。

ここで疑問が。Argon2idがArgon2dとArgon2iという2つのアルゴリズムがいいとこ取りされるのであれば、PHP7.2で追加されたArgon2iを使う必要はないのではないか？

RFCs for PHPには下記のように書かれていて

Should we deprecate Argon2i? [RESOLVED]

No, I do not believe we should deprecate Argon2i from password_*. Argon2i remains a perfectly secure and reasonable choice for password hashing. Argon2id simply provides better resistance to some form of attacks at the cost of time-memory tradeoffs. Argon2id is recommended at this point simply because it provides a blend of Argon2i and Argon2d. The existence of Argon2id does not negate the benefits of Argon2i.

と、玉虫色の回答が来たのでもう少し深掘り。

アルゴリズムのRFC draftにも下記のように書かれている。

9.4. Recommendations

The Argon2id variant with t=1 and maximum available memory is recommended as a default setting for all environments. This setting is secure against side-channel attacks and maximizes adversarial costs on dedicated bruteforce hardware.

もちろん、ユースケースやメモリの量・スレッドの量・必要な計算時間といったコンディションでArgon2iを選んだ方がリーズナブルなケースもあるかもしれないが、Argon2idを選んだ方が得策なようだ。実際、RFCをよく読んで見ると、明示的にArgon2idを選ぶべきという表現もある

  1. Parameter Choice

    If you do not know the difference between them or you consider side-channel attacks as viable threat, choose Argon2id.

API一覧

password_hash

ハッシュ生成関数。

string password_hash ( string $password , integer $algo [, array $options ] )

第1引数 $password は生パスワード、第2引数 $algo はハッシュアルゴリズム定数、第3引数は $options アルゴリズムがサポートするオプションを入力する。ハッシュアルゴリズムをArgon2idをするだけであれば、$algoに PASSWORD_ARGON2ID を指定するだけでよい。

<?php
    $raw_passwd = '3kanmarusan_Passw0rd';

    $hashed_passwd = password_hash($raw_passwd, PASSWORD_ARGON2ID);

# 生成されたハッシュ
$argon2id$v=19$m=1024,t=2,p=2$SEJ2M2VNL3B5MXZNN0tDYg$44a3kX0OxiFzoy4bCtkHnAyy7/TVkvIVU7kdyj8ewCg

$argon2idで始まっているので、Argon2idっぽい。$m=1024,t=2,p=2がハッシュ化時に使用しているパラメータ。これはPHPで定義されたデフォルト値そのものである（前述）。ハッシュアルゴリズムが使うメモリコスト（メモリ使用量）と時間コスト（回数）と並列度（ハッシュ化時に利用するCPUスレッドの数）をパラメータはArgon2iの時と同じである。

ちなみに、ハッシュアルゴリズムのデフォルト（PASSWORD_DEFAULT）に変更があるか調べたところ、PHP7.3の段階でも変更がないようだ。

# PASSWORD_DEFAULTはまだbcryptということを調べる
<?php
  echo "[constants]" . PHP_EOL;
  echo " PASSWORD_BCYRPT: "  . PASSWORD_BCRYPT  . PHP_EOL;
  echo " PASSWORD_ARGON2I: "  . PASSWORD_ARGON2I  . PHP_EOL;
  echo " PASSWORD_ARGON2ID: "  . PASSWORD_ARGON2ID  . PHP_EOL;
  echo " PASSWORD_DEFAULT: " . PASSWORD_DEFAULT . PHP_EOL;

# 実行結果
[constants]
 PASSWORD_BCYRPT: 1
 PASSWORD_ARGON2I: 2
 PASSWORD_ARGON2ID: 3
 PASSWORD_DEFAULT: 1

password_verify, password_get_info, password_needs_rehash

ここは変更なし

(再掲)TL;DR

  • パスワードハッシュ関数(password_*)のハッシュアルゴリズムに Argon2id が追加
  • Argon2idはArdon2iとArgon2idのいいとこどりだが、今後はArgon2idを選ぶのがよさそう
  • PHP7.3でもデフォルトのハッシュアルゴリズムに変更なし（bcyrptのまま）

visiting NTT history center of technologies

(please find the Japanese translation after the English text)

Last Friday, I visited the NTT history center of technologies with my family.
The telephone switchboard, the first generation pager and mobile phone, ISDN service, and so on, all their history and technologies excited me.

Especially, I was interested in two exhibit.
The first one was the incident of fire in a cable tunnel of the Setagaya office in 1984 and measures of preventing. I believe it would be helpful to my work.
The second one was the material of 'call processing state transition diagram and flowcharts'. The material fired up my heart as a professional engineer.

f:id:mikanmarusan:20190329135901j:plain:w400 f:id:mikanmarusan:20190329140258j:plain:h400

I recommend to visit 'NTT history center of technologies'. I think it's worth for you.

先週の金曜日、家族で NTT技術史料館 に行った。
電話の交換機、初期のポケベルや携帯電話、ISDNサービス、などなど、多くの歴史や技術に興奮した。

特に2つの展示に非常に興味を持った。
1つ目は、1984年に起きた世田谷のとう道の火災事故とその対策の話。これは自分の仕事にきっと役立つと思う。
2つ目は、呼制御の状態遷移図とフローチャートの資料である。これらの資料はエンジニア魂に火をつけるものだった。

f:id:mikanmarusan:20190329135901j:plain:w400 f:id:mikanmarusan:20190329140258j:plain:h400

NTT技術史料館はおすすめ、行く価値があると思う。

[メモ]geocitiesの静的サイトをGitHub Pagesでホスティングする

Yahoo! ジオシティーズが2019/3/31に終了する。 info-geocities.yahoo.co.jp

自分も20年近くのジオシティーズユーザーで、サイト上に黒歴史も沢山残っている。ただインターネットを彩った歴史の一部ではあると思っている。今回はこれ何かの形で残したい。

自分は、ジオシティーズの有料付加サービスであるジオプラスを利用していない。CGIを利用していないからである。つまり、HTML/CSS/JavaScript/画像のみで構成された静的サイトだということだ。ということは、さくらやロリポップ!などのレンタルサーバだと明らかにオーバースペックである。

また古い情報のHTMLといえども、エンジニアとしてバージョン管理をしないのは悲しい。ということで、GitHub Pagesでホスティングできないのかと考え、移行した時のメモを記す。作業環境は macOS High Sierraである。

ちなみにGitHubの What is GitHiub Pages? にも下記の通り書かれているので、okだと思う。

GitHub Pages is a static site hosting service designed to host your personal, organization, or project pages directly from a GitHub repository.

TL;DR

geocitiesの静的サイトはGitHub Pagesでホスティングすることが可能

手順はたったの4つ

  1. ftpでgeocitiesのファイルを吸い出す
  2. ホスティング用のプロジェクト（レポジトリ）を作り、ここに1で取得したファイルを置く
  3. ファイルを調整し（エンコーディングの変更、不要なファイルの削除など）masterへpush
  4. プロジェクトのsettingsで、masterブランチからGitHub Pagesを生成する

1. ftpでgeocitiesのファイルを吸い出す

まずはftpで思って叩いてみるといきなり死。
macOS High Sierraから/usr/bin配下のftpやtelnetなどはセキュリティ上の理由で廃止されたらしい。

bash-3.2$ ftp
bash: ftp: command not found

Homebrewでftpを復活させる。passiveモードになっていなくてファイヤウォールで叩き落とされていたりして解決まで時間がかかった。むしろ面倒だったら、CyberduckやFileZillaのようなftpソフトでやる方が早いし正確な気がする。

# ftpを使えるようにする
brew install inetutils

2. ホスティング用のプロジェクト（レポジトリ）を作り、ここに1で取得したファイルを置く

GitHub PagesでホスティングしたときのURLはこのようになるので（ドメインなど割り当てなければ）

https://{username}.github.io/{repos}

適したrepos名のレポジトリを作り、1で取得したファイルをそのまま置く。

3. ファイルを調整し（エンコーディングの変更、不要なファイルの削除など）masterへpush

自分の場合は、htmlファイルがShift_JISで書かれていた。GitHubのエンコーディングはUTF-8っぽい（あまり調べていない）のでUTF-8に変換。 必要があれば改行コードも変えておく。

# UTF-8に変換
find . -name "*.html" | xargs nkf --overwrite -w

さらにhtmlファイル内部のcharsetもutf-8に修正する。 ここで黒歴史を消すこともお忘れなく。

4. プロジェクトのsettingsで、masterブランチからGitHub Pagesを生成する

  1. https://github.com/{username}/{repos}/settings にアクセスし、下部にあるGitHub PagesのSelect sourceを"master brunch"にする。
  2. https://{username}.github.io/{repos} で確認する

デフォルトでhttpsになっているのがいい

まとめ

geocitiesの静的サイトはGitHub Pagesでホスティングすることが可能

CTO Night KANSAI に登壇者として参加した

自分の所属する会社が主催する、CTO Night KANSAI(2018/9/14)に登壇者として参加してきた。2週間たったのでほとぼりが冷めた頃に備忘録として。

概要

Osaka Mix Leap Study 特別編 - CTO Night KANSAI

CTO Nightの参加者は、株式会社はてなCTO の @motemen さん、株式会社ハカルスCTO の @tksmd さん、そして自分(@mikanmarusan) 。 内容については何人かの方がブログに書いてもらっているし、ハカルスさんのブログにでもあるので割愛。

“学び続けること”はエンジニアの宿命！！CTO Night KANSAIにハカルスのメンバーが登壇しました

経緯

自分は原則東京の紀尾井町オフィスに勤務することになっている。春に大阪オフィスに出張に行った時に、エンジニアの @bulbulpaul にイベントやるんで登壇してくださいよと言われ、その時は社交辞令かなぁなんて思っていたけど数日後に本当に依頼が来たのでびっくりした。

なんでも関西版CTO Nightというイベントをやるらしい。CTO Night というと TechCrunch や IVS（ともにAWSがスポンサーですね）が有名で、自分はそこまでCTO論を語れるまで至っているわけではないし、そういうところに出るのは天才CTOか選ばれしベンチャー企業のCTOだと今でも思っている。

感想

まずはじめに、他社CTOの話は会社の事業や規模に寄らず本当に学びが多い。同じ肩書きというバイアスももちろんあるのかもしれないが、悩むポイントが同じ時にはものすごく共感するし、異なるポイントでの悩みなんかはいろいろ考えさせられる。

ちょっと笑いそうだったのは、パネルディスカッションの最初のテーマである。「エンジニアのキャリアの魅力と覚悟」というテーマにおいて、3人とも「変化すること」「学び続けること」が重要というところに落ち着いたのは自分でもびっくりした。別に示し合わせたりしていないからだ。

自分にとってのおもしろい気づきは、CTOとしての役割というテーマで自分が話をさせてもらった「非技術の経営者に対して説明責任を果たす」という役割とその難しさについてである。その後の懇親会でもゲストの方から深く話を聞きたいと質問をもらった。普段毎日のようにやっていることが注目されるのは不思議だった。

どこかのブログに書かれていたが、"大阪でこのようなイベントが開催されたのは非常に良かった（イベントや勉強会についてはいつも東京にマウンティングされる）" は印象深い。弊社も東京・大阪・名古屋・福岡などを中心に開発拠点を構えているが、イベントは東京に偏りがちになる傾向がある。自分も地方出身者なわけだし、東京以外の拠点でも弊社主催のイベントを増やしていこうと改めて思った。なぜなら、エンジニアリングを取り巻く問題の多くは技術そのものが真因になっていることはほとんどなく、情報の不均衡や格差といったコミュニケーション問題が起因するものがほとんどだからである。