delirious thoughts

by Kentaro Kuribayashi

書評『Webエンジニアの教科書』

ヒトメディアの3人による『Webエンジニアの教科書』をご恵贈いただきました。ありがとうございます。

Webエンジニアの教科書

Webエンジニアの教科書

桜の満開に咲き誇る今日このごろ、新入社員が入ってくる季節です。やることに濃淡はあれ、各社それぞれで新人研修をどう行っていくか、あれこれと考えを尽くしているところでしょう。ペパボでも「GMOペパボのエンジニア新人研修」に書いた通り力を入れていて、今年もまた、新しく入ってくる人々に対して円滑な組織社会化をもたらせるよう、受け入れ準備をしているところです。

エンジニアの研修カリキュラムとしては、大きくはRailsによるWebアプリケーションの基礎、構成管理ツールを用いたサーバ構築のふたつをやっていたのですが、今年はモバイルについてもやるようにしました。このご時世にモバイルについてまったくやらないのはさすがにありえないだろういうことで追加したわけですが、それで十分というわけではありません。

Webエンジニアとして「一人前」になるには、あれもこれもと言い出すとキリがない分量の知識を学ぶ必要が出てきます。

ここまで見てきたように、基本的にWebエンジニアがやる内容は多岐にわたります。技術的な移り変わりも激しいので、3年後、5年後というスパンで見ると、「今と同じ技術を使って同じことをやっている」と自信を持って答えられるひとは少ないでしょう。常に新しい技術や手法を学習することが必要になってくるのがWebエンジニアという職業だと筆者は考えます。

(p.16)

そう述べながら本書が例として挙げるのは以下の通り。

  • HTML
  • CSS
  • フロントエンド
  • サーバサイド
  • データベース
  • Webサーバ
  • AWS
  • GitHub

これらのうち、章を割いて解説されるものもあれば、少し触れられるだけのものもありますが、いずれにせよ「Webエンジニア」に求められる知識が、まさに「多岐にわたる」ことはよくわかります。我々も、研修の過程におけるおしゃべりや、先輩エンジニアたちによる講義、はたまた「Webアプリケーションは難しい」というスライドを示すことでもって、新人エンジニアに対して、求められるスキルの多様性を伝えてきました。

とはいえまあ、あんまり大変だとばかりいっていてもしかたないので、大変なことに変わりはないにしても、それなりに道をつけて一歩ずつ成長していってもらわないことには「研修」にはなりません。そういう意味で本書は、Webエンジニアとして入門したばかりの人々が、まず最初に一読してすべてを理解することは難しいかもしれないにせよ、その求められる領域の広さを、しかし要を得た選択と解説による記述でもって概観するには、ちょうどいい分量かもしれません。

当たり前ですが、この本だけで何かを完全に把握できるほどWebエンジニアは甘いものではないにせよ、右も左も分からないという初学者が、ひと通りあたりをつけ、次に何を学習するべきかを知るための道標として、役立つように思われました。その上で、コンピュータサイエンスの基礎についてもまた、移り変わりが激しい業界だからこそ長く役立つものだろうことは確かなのですから、それはそれでパタヘネ(コンピュータの構成と設計 第5版 上)や『詳解UNIXプログラミング 第3版』といった本をあわせて読むとよいのだろうと思います。

Webエンジニアの教科書

Webエンジニアの教科書

T-fal フライパン「ディフューザル」バジル 27cm

長いこと使っていたフライパンの、経年劣化していたのをだましだまし使っていたのだが、いよいよ耐えがたくなってきたので、近所のドンキホーテで日用品を買ったりしたついでに買い替えた。Amazonの方が数百円安いけど、まあよし。

かっこいい感じでそろえたいという気持ちもあるのだけど、面倒なのも嫌だしなあ。T-falは間違いないし、快適でよい。

GMOペパボ株式会社の執行役員CTOに就任しました

昨日(3/21)、GMOペパボ株式会社の執行役員CTO*1に就任しました。昨年8月に技術責任者に就任したのですが、今後はより一層、経営に近い立場で「技術」という切り口において会社の成長に貢献していきたいと思います。

今後やっていくこと

今後やっていきたいことを整理すると、以下の3つになります。

  1. 成長のための技術戦略の策定・実行
  2. 1.を実現するための技術基盤づくり
  3. 1.を実現するための組織づくり

これまでも「GMOペパボ攻勢の裏側にあった「技術的負債を抱えない開発体制づくり」3つの布石 - エンジニアtype」にある通り、あれこれやってきましたが、より踏み込んだ戦略を立て、実行していくつもりです。また、それぞれにおいて各論的にいろいろ考えていることはあるのですが、細かいことをここで述べてもしかたないでしょう。このブログでもこの1年あまり、上記についてあれこれと書いてきたので、是非そちらをご覧いただければと思います。

技術戦略

blog.kentarok.org blog.kentarok.org blog.kentarok.org

技術選択

blog.kentarok.org blog.kentarok.org

技術組織

blog.kentarok.org blog.kentarok.org

ところで

組織づくりにおいて最も重要なのは、いうまでもなく「ひと」です。minneへの大規模投資を始めとする各サービスでの事業遂行に際して、もっと大きく成長するためには、一緒にサービスを作ってくれる仲間が必要です。是非、以下よりご応募ください。

pepabo.com

まずは話を聞いてみたいという方は、ペパランチョン | 採用情報 | GMOペパボ株式会社という機会もご用意しています。ご飯を食べながら、おしゃべりしましょう。

*1:この役職が会社組織上どういう意味については「CTOとか役員とかに関する基本的な知識 - UNIX的なアレ」がわかりやすいと思いますので、気になる方はご参照ください。

全社的に使っているチャットツールをSlackに移行した話

ペパボでは、チャットツールとしてIRCを長らく使っていたのですが、先日、Slackに全面的に移行しました。その話を少し書いてみようと思います。

追記: 社長的にSlackに移行したほうがいい理由 | ペパボ社長ブログというエントリが出ていたので、そちらもご参照ください。

IRCの利用程度

そもそもIRCをどの程度使っていたかというと、職種や役職等を問わず、全スタッフ(アルバイト等も含む)が使っていました。つまり、エンジニアも総務も、マネージャーも社長もみんなIRCにいて、そこでフローのコミュニケーションを行っていたということです(ちなみに、情報のストックや、チャットには向かないような共有にはGitHub Enterpriseを使っています)。また、サーバの状態監視等の様々な通知や、いわゆるChatOps的なこともIRCでやっていたので、人間もbotもとにかくたくさんいて、賑やかな状態です。

IRCの問題

それぐらい活用しまくっていたIRCでしたが、たとえば以下のような問題があったため、解決策を模索していました。

  • ログを共有された形で保存し、検索するのが難しい
  • そのため、過去のチャット上での議論に基づいた発展が難しい
  • マルチデバイス対応が難しい。特にスマホアプリが使いづらい
  • IRCに接続していない間のメンションに気づけない

また、個人でSlackのようなツールを既に使っているひとにとっては、さくさく動いてリッチなUIを提供するアプリ、アイコンの表示されるモダンなチャット体験、豊富なインテグレーションなどの魅力もあり、IRCのシンプルさが、かえって見劣りするものであるとも感じられてきたりもしたのでした。

Slackへの移行プロセス

そこで、Slackに移行を目論む勢力が発生、Slack上にpepaboチームを開設し、自生を始めました。新しもの好きのメンバーたちがあれこれと試していく中で、これなら移行できそうなのでは?という機運が醸成されてきた流れで、経営会議において「移行するぞ!!1」ということになり、もろもろの手続き・計画・利用ルール作り(お金周りや情報セキュリティなどなど)を僕の方で取りまとめ、移行が実施される運びとなりました。その後の流れは以下の通り。

  • 2月25日: 情報セキュリティを担保した上で、移行計画の告知
  • 同日: Slack用のIkachanを作成
  • 2月27日: 開発関連の人々はほぼ移行完了
  • 3月上旬: 通知周りがほぼ移行完了
  • 3月9日: バックオフィスやカスタマーサポートも含めて移行完了
  • 3月18日: 有料プラン開始
  • 同日: 各種インテグレーション完了

以下のグラフを見るとわかる通り、上述のほとんどは3月初頭にはほぼ移行が完了しており、あれだけ活用しまくっていたIRCからの、通知まわりなども含めての移行に、1週間もかからなかったということになります。

f:id:antipop:20150319233255p:plain

これは、それなりのアカウント数(現時点で260超)を持ち、多様な職種、2拠点からなる組織としては、相当のスピードを出せたといえるのではないでしょうか。この会社も長い間いろんなことをやってきており、蓄積されてきた経験に基いて安定した業務を行ってきており、それはそれで非常に素晴らしいことですが、いざ「大きな変化を起こすぞ!」という時にも、こうして全社を上げて素早い動きを見せることができるのは、誇らしいことであるとあらためて思います。

ところで

そんなペパボでは、さらなる飛躍的変化を起こしてくれる、エンジニアを始めとする各職種において、新たな仲間を求めています。是非以下をご覧になって、ご応募ください。ただいるだけですら知らずしらずのうちに(もちろん積極的にアウトプットすればさらに)成長してしまうような意欲的な環境を用意して、お待ちしています。

pepabo.com

メイソンジャー

最近いくつか本が出たりして話題のメイソンジャー、ちょうどガラス製の保存容器をいくつか欲しかったので、流行りモノに手を出してみました。Amazonに出店しているショップで注文したのだけど、大人気っぽくて出荷が延びて、届くまで1ヶ月ほどかかりました。さらには、注文した時は480mlのものが594円だったけど、いま見たら1,050円になっていますね。

とりあえず、まずはサラダを仕込まないと、ってんで、さっそくやってみました。適当に買ってきた野菜を切って、適当に調合したドレッシングを入れたあと、固いものから順番に入れていくだけ。簡単。しかし、どれぐらい入るか正確に読めてなくて、買ったけど入れられなかった野菜がいくつか……。まぁ、それはそれで別の楽しみにとっておこう。

façadeでGitのようなサブコマンドをディスパッチする

Gitには、git fooと実行すると、$PATH内のgit-fooを実行するというサブコマンドの機能がある。そのため、その規約に則りさえすれば、Gitのサブコマンドをいろんな言語で書けるというメリットがある。それを簡単に実現するために、façadeというごく単純なライブラリを書いた。

使い方

これを使うと以下のように書くだけで、コマンド名がyour-commandだったとして、your-command foo bar bazと実行すると、your-command-foo bar bazという呼び出しに変わる。

package main

import (
    "github.com/pepabo/facade"
)

func main() {
    facade.Run()
}

なぜ作ったか

ある目的に利用するツール群があるとして(たとえばEC2を操作するような各種コマンド群)、以下のような問題を解消するためである。

  1. ひとつの言語に限らず、実装する人々が得意な言語によって、それらのツールを書きたい
  2. しかし、それらがフラットな名前でだらだらーっとあると、見た目に悪い感じがする
  3. また、どのツールでも使うような、たとえば色付けされたロギングだとかそういうのを提供する際に、各コマンドでいちいち実装していると統一感がなくてよくない

そのため、入り口 = dispatcherのみを提供するライブラリとしてfaçadeを作った。これにより、統一的な名前、機能を提供できるようになった。

SUZURI APIとNW.js(旧node-webkit)を使ってTシャツを作る

オリジナルグッズを手軽に作成・販売 | SUZURI(スズリ)に、APIができました。SUZURI Developer Centerから詳細を見ることができます。さっそく遊んでみようってんで、NW.js(旧node-webkit)を使って、Tシャツを作るということを試みてみました。

コードが雑過ぎてアレなんですが、気にしません。

起動方法

  1. NW.js(旧node-webkit)をインストールします。
  2. Macの場合、以下のようにして起動します。
$ /Applications/nwjs.app/Contents/MacOS/nwjs . API_TOKEN

API_TOKENは、SUZURI Developer Centerから取得してください。

画面

こんな感じの画面が出るので、

f:id:antipop:20150312081829p:plain

ボタンを適当に押すと、SUZURI上でTシャツが作成されて、以下のように結果が表示されます。

f:id:antipop:20150312081856p:plain

んでもって、こんな感じのURLで実際にTシャツができて、販売できます。

まとめ

簡単に使えて楽しいですね。是非みなさんも、SUZURI APIを使って遊んでみてください。