comixスマートフォン用の表示で見るcomixジャンプみたいなブログになりたい。エントリーになります。年の瀬ですし、今年は公私と共に色々あったので1年の振り返り的なことを書くよ。仕事での一番の大きな変化はやはりCTOになったこと!CTOは組織の中の一ロールに過ぎないと考えていますが、それでもやはり責任や管掌領域が一気に増えたせいか、それともただの加齢のせいなのかは分かりませんが白髪が増えました。言え、基本的にやったことがないことに対して、面白さを感じるタイプなので迷ったり悩んだりすることはありつつも愉しくやっています。露出をたくさん増やしてくれたので、今年は例年以上に発信する機会が多かったです。喧々諤々の議論をした(嘘です)インタビュー記事です。CTOになる前は色々偉そうに意見してたんですが、いざ自分がなってみるとたつしむの偉大さが分かりました。さんと一緒にパネルディスカッションさせていただいたイベントの記事です。二人とも僕とは違うタイプのCTOでとても刺激的なイベントだったので、今でも二人の発言を時々思い返したり、反芻したりしています。エンジニアとしてもめちゃくちゃ尊敬出来る二人なので負けないように頑張るぞ〜という気持ちもあります。2019で登壇させてもらう機会もいただきました。喋りはまだまだですが発信していくことの重要さを感じたので、引き続き頑張っていこうと思います。aws.amazon.comもちろん、CTOとしての最大の責務はテクノロジーの力で、事業を成長させ、ひいては社会を良くすることだと思っています。そこに対してはまだまだバリューを発揮出来ていないので、来年はもっと攻めていくことで、そこにコミット出来るようにしていきたいなと考えています。アウトプット前半のトピックは人生初の技術書を出版させてもらったことです。itosho525.hatenablog.comお陰様でけっこう?売れているようで、誰かのエンジニア人生を支えるものになっていれば作者冥利に尽きます。後半のトピックは国際カンファレンスであるCakeFestで登壇したことです。speakerdeck.comまた、せっかくの機会なのでCakePHPについてのインタビューを受けました。www.wantedly.com個人的にはここ数年で一番チャレンジングなイベントでめっちゃ大変でしたが、少しは自信がついたので来年は海外で開催されているカンファレンス絶対参加するぞ!という気持ちを新たにしました。あとはGoについての記事を書いたり、ス・マイル制度についての発信をしたりしていました。itosho525.hatenablog.comtech.connehito.comGoについては、これまで個人的に使ってるレベルでしたが、コネヒト社のプロダクション環境に導入するレベルになったので、またどこかでちゃんと書きたいと思います。・マイル制度については今のところ評判も良く、順調にマイルも貯まったり、使われたりしています。この手の制度は放っておくと経年劣化していくものなので、来年が勝負かなと感じています。speakerdeck.comインプットブクログさんによるとは今年は21冊読んだらしい。役割が増えて、技術書はあんまり読めなかったのですが、その分いろんなジャンルの本を読めたのはよかったかな。面白かった本5選を挙げると...という感じです。『エンジニアのためのマネジメントキャリアパス』は正月に読んでて、この時はまさかCTOになっているとは思っていなかったのですが、結果的に読んでおいた良かったです。いま読んでいる『両利きの経営』も面白いので、来年はもっと読書する時間を増やしたいな〜。あとは、英会話に通ったり、技術的なところで言うと最近はPython(というかデータ分析周り)を勉強したりしています。プライベート家を買いました。去年の振り返りで書いた今年の目標と結果はこんな感じでした。新居最高〜!達成度で言うと、60点くらいという感じですね。今年は社会人11年目ということでこれまでの10年間の経験や知見を棚卸ししたり、大放出したりした1年でした。新しい役割の中、ややインプット不足を感じることも多く、やや無理くりこすったというか擦り減らした感もあるので、来年はもう少しインプットに割く時間を増やしたいなと思っています。あと、今年は久しぶりにインディー開発で新しいサービスをリリース出来なかったので、来年こそという気持ちで...インディー開発で2本以上リリースする一緒にやりたい人Wanted!本を最低でも24冊以上読む技術書は10冊以上読む!海外に3回以上行く1回はカンファレンスに参加!あわよくば登壇!楽器か運動をはじめるという感じで来年は頑張りたいと思います。2019の23日目のエントリーになります。今日はマネジメントの話がしたくなったのでマネジメントの話をします。マネジメントは「ナマモノ」なので、その人のパーソナリティはもちろん、関係性や状況によって、有効な手段が変わるので銀の弾丸はないのですが、ナマモノだからこそ、現場のノウハウを公開していく必要があると考えています。マネジメントのテクニックを公開すること=手の内をメンバーに見せることになるので、公開することを敬遠するマネージャーもいますが、僕は正直でいることが最大の戦略だと思っているので、自分の考えの整理も兼ねて書いてみたいと思います。いうわけで誰かの一助になれば幸いです。Management)というのがあります。どんな時でも誰とでもいつも同じようなコミュニケーションのインターフェイスでメンバーと接することです。冪等性と表現するとロボットっぽいコミュニケーションを想像するかもしれませんが、ここで言う冪等性はテンションや態度のことを指します。冪等性が大事なのか?例えば、ある時は優しかったのに、またある時は冷たいといったような日によって態度にムラがあるマネージャーがいたとしましょう。いうマネージャーの場合、メンバーからするとマネージャーの様子を伺って「今日は機嫌悪そうだから話しかけるの止めておこうかな〜」という力学が働いてしまいます。このような状況が常態化すると、マネージャーとメンバーの関係性が希薄になります。個人的にマネージャーとしてメンバーとのコミュニケーションの総量を増やすことは、メンバーの成果を最大化させる上で非常に重要だと考えています。アカデミックな理論に裏打ちされたハウツーやコーチングのスキルもマネージャーには必要不可欠だと思いますが、それらの習得には一定時間がかかります。コミュニケーションをとることは誰でも今日からはじめられます。それらのスキルが有効になるのも一定以上の関係性を築いたうえでの話ですので、そのためにも日々のコミュニケーションは欠かせません。関わらず、ムラのある態度を取ると、その日々のコミュニケーションの総量が減るリスクがあります。毎回返ってくる値が違うようなメソッドを誰も使いたくないのと同様に毎回態度が違うマネージャーとは誰も仕事をしたくはありませんよね。少なくとも僕は嫌です。冪等性を保つ難しさとその方法とは言うものの人間はシステムではないので、冪等性を保つのはなかなか大変です。僕はよく人から「いつも穏やかねですね〜」と言われるくらいには、良くも悪くも気分の浮き沈みが少なく、あんまりイライラしないタイプではあります。パーソナリティ的に冪等性を保ちやすいタイプだとは思うのですが、それでもこれまで人とのコミュニケーションで失敗してきたことは当然ありますし、聖人ではないので今でも日々の暮らしの中でテンションの移り変わりがあります。いう人間味を開示していくこともマネージャーには必要な要素だとは思っていますが、冪等性マネジメントという観点ではなるべく自分の感情と上手く付き合っていく必要があります。いうわけで、冪等性を保ったり高めたりするために僕が普段意識していることを紹介してみたいと思います。講釈を垂れましたが、要は穏やかに過ごすための心構えみたいなものとして読んでいただければと幸いです。一時の感情で判断しないアンガーマネジメントに近いかもしれませんが、人間である以上どうしてもイライラしたりプライベートの事情などで落ち込んだりすることは避けられません。いった状況で、例えば批判のようなものを受けるとカッとなります。いう状況ではまず正常な言動が出来ないと思っているので、一時的な感情で判断しないことが大切です。経験則ですが、次の日になればほとんどの出来事は取るに足りないことです。逆に次の日もその感情が残っていれば、何らかのアクションを取ればよいと思います。多少は冷静になっているので、昨日よりも筋のよいアクションをとれるはずです。エンジニアの三大美徳である「短気」の逆の考え方なので、マッチしないケースもあるかもしれませんが、少なくともマネジメントでは一時の感情で判断しないことが大切かなと考えています。0か1ではなくグラデーションで考えるこれは主に対人関係の話ですが、仮にちょっと合わないなというか自分をイライラさせる人がいた場合に、一時の感情で判断しなかったけどやっぱり「イライラする!」となった時でもそのイライラさせる要因はその人の一面に過ぎないことを意識することが大切だと思います。ゼロサムで一つの出来事だけで「この人は嫌い!」というレッテルを貼る人もいますが、個人的にはもったいなと思っています。基本的に僕は他人のことなんて分からないという前提でコミュニケーションをとっていて、この人のこの部分は好き、あの部分はちょっと考えが違う、でも見えていない部分がたくさんあると思っているので、その人を嫌いと判断するのは難しいなぁと思ってしまうし、そういう考えのほうが個人的にはその人と仲良くなる可能性が残っているし、わくわく感があって楽しいなと考えています。性善説で相手を信じる先程、人を嫌いと判断するのは難しいと書きましたがこれは性善説ありきの考え方なので、性善説で相手を信じることが冪等性マネジメントでは重要なことなのかなと思っています。性善説で物事を考えると仮にイライラさせるような人がいても、別に悪気があるわけではないという考えになるので「ヒト」ではなく本質的な「コト」に向かいやすくなると考えています。相手のことを信じると向こうも信じてくれる可能性が高まると感じていて、そうするとコミュニケーションコストが下がるので、冪等性マネジメントもやりやすくなる気がしています。ちなみに全く別の話ですが、世の中には本当にEvilな人もいる(幸い僕の周りにはいませんが)ので、そういう人からは逃げるようにしましょう。問題を自分側に置くここまでイライラを相手に問題があるかのように書いてきましたが、そもそもイライラしているのは自分なので問題を自分にある前提で考えるのも有効な手段と思います。いわゆる、自分ごと化というやつですが、個人的には自分ごと化したほうが楽なことが多いと思っていて、それは自分に問題があるのであれば、それはコントロール可能な問題なので、何らかの対処が出来るからです。すれば傲慢な考えかもしれませんが、世の中の全ての出来事に全ての人が関与していると僕は考えていて、そんな感じで何でも自分ごと化して、問題がコントローラブルになると、ある程度感情もコントローラブルになると思います。(もちろん、解決出来るどうかは別ですが...!)たくさん寝る凄く当たり前のことですが、めちゃくちゃ大事なことなので書いておきます。今まで書いた方法は十分な睡眠時間を確保した上で実践出来るものだと思いますし、睡眠不足の時は本当に気分にムラが出やすいので、きちんと睡眠時間を確保をすることはどんなに強調してもしすぎることはないと思います。言いつつ、僕はよく夜ふかしをしてしまうので自戒を込めて...。最後にそれっぽく書きましたが、冪等性マネジメントという言葉自体は(たぶん)造語で2秒で考えました。登壇させていただきました。人生初の英語でのプレゼンテーションということもあり、ここ数ヶ月プレッシャーが凄かったのですが何とか無事終えることが出来ました!(たぶん)終わってみればとても良い経験が出来たと思いますし(生存バイアス)、「英語で登壇をしてみたいな」と考えているエンジニアの方も多いのかな?と思うので、振り返りも兼ねて英語で登壇をするためにやったことをまとめてみたいと思います。ちなみに、本旨ではないので登壇内容やプレゼン自体のテクニックについては触れませんが、スライドはこちらです。最初に前提となる情報を簡単に紹介します。変わったバックグラウンドがあったり、特殊なシチュエーションがあったりするわけではないので、ある程度一般化出来るかなと思っています。「そりゃプレゼンぐらい出来るやろ!」ってなると思うので、念のため、僕の英語レベルをお伝えしておきます。please.」*1普段、英語のドキュメントはGoogle翻訳を駆使して読んでいるGoogle翻訳に甘えて、英語の勉強が捗らないことがありますというわけで、典型的な英語話せないタイプの日本人です。準備期間ちなみに、cfpを出したのは今年の元旦で登壇が決まったのが5月でした。ぶっちゃけcfpが通ると思っておらず、勝手に落ちたと思っていたので、準備期間は半年ぐらいでした。この時点でだいぶヤバい。年越しでテンションが高まった挙げ句cfpを提出した模様CakeFestについて改めてになりますが、CakeFestはPHPのフレームワークであるCakePHPの国際イベントです。これまでは海外で開催されていたのですが、初めての日本(東京)開催となりました。規模としては全体で100人ぐらいで、今回は半分ぐらいの方が海外からの参加者だったと思います。*2英語力向上編では、ここから具体的にやったことを紹介していきます。皆さんが大好きな?英語の勉強方法について。英会話スクールに通うとりあえず「このままじゃアカン!」と思ったので6月から某英会話スクールBに通い始めました。最初はDMM英会話のようなオンラインの英会話にしようと思ったのですが、自分の性格的に怠けて受けなくなりそうだなと思ったので、ある程度の強制力のある英会話スクールを選びました。ちなみに、いくつかスクールの体験レッスンを受けたのですが、その中で一番厳しいレベル判定をされた英会話スクールに通うことにしました。*3しかし、正直英会話スクールは直接的な効果はあんまりなかったです。これは英会話スクールが悪いわけではなく単純に自分の英語力が低いのが原因で、英会話スクールで習っている内容がまだ日常会話中心で、登壇で必要な英語力は鍛えられなかったからです。*4とは言え、英語を話すことに慣れることが出来た点は良かったと思っているので、間接的には効果があったのかなと思います。直前に買い切りのレッスンでプレゼンの練習をすることが出来て、そこで先生に褒めてもらえたので自信がつきました。日常的に英語の接点を増やすまた、ありきたりですが英会話スクールに加え、通勤中に英語のPodcastを聴いたり、スキマ時間で英語のアプリをやったり、休日に参考書を読んだりしていました。こんな風に書くと「めっちゃ勉強やってんじゃん!」という感じなのですが、モチベーションにムラがあったので、1ヶ月を切るまでは気が向いた時にやるレベルでした。登壇が近づくにつれ「何でもっと勉強しなかったんや...」と過去の自分を呪いましたが、その中でよく使っていたアプリやサービスは以下です。無料apps.apple.com他には映画を吹き替え版で観たり、YouTubeで過去のCakeFestの動画を観たりしていました。YouTubeには字幕表示機能があって、それが結構スピーチの作成に役立ちました。あとは英語用のTwitterアカウントを作成しましたが、これはあんまり上手く活用出来なかったな...。次に本丸のプレゼンテーションの資料をどうやって作成したかについて。プレゼン資料を作成するまず、プレゼン資料については最初から英語で作成しました。ちなみに資料は1ヶ月を切ってから作り始めましたが、心臓に良くないので2ヶ月前くらいから作ったほうが絶対いいです。一通り作った後は、社内の英語が堪能な方にお願いして*5、添削をしてもらいました。Googleスライドで作成していたので、スライドに直接コメントを貰えて便利でした。スピーチ原稿を作成する日本語の場合、軽く箇条書き程度に原稿を用意すればOKなのですが、今回はガチガチに話す内容を用意しないと詰むと思ったので、まず、日本語でスピーチの原稿を作成して、その後、翻訳経験のある方や識者の方に全面的にサポートしてもらいながら英語の原稿を作成するというステップを踏みました。ちなみにアストロズのくだりは滑りました。一通り資料が出来たのが本番5日前だった(白目)のですが、そこから猛烈な勢いでプレゼンの練習をしました。話すこれは日本語のプレゼンでもやることだと思うのですが、英語の場合は丸暗記するぐらいので勢いで何回もやったほうがいいなと思いました。僕みたいな普段英語を喋っていない人は口が英語に慣れていないので、実際にきちんと声を出して、身体に英語を染み込ませていく必要があります。最終的に5回以上は本番と同じ感じで練習をしたのですが、振り返るともっとやったほうがよかったなと思っています。練習する時は録音をしておいて、後で聞き返すようにしていました。*6どれくらいのペースで話せるのかを確認するまた、自分が1分間にどれくらい単語を話せるのかを確認しておくと当日慌てないかなと思います。日本人が英語でプレゼンをする場合は、1分間で120〜150単語くらいが適切なスピードらしいのですが、僕は最終的に130〜140単語くらいが限界だったので、それに合わせて、原稿の内容を調整しました。発音を確認するあとは各単語の発音を確認するために、スピーチを読み上げてくれるサイトやアプリを使って何度も(と言ってもラスト3日くらいですが...)自分の原稿を耳に叩き込みました。実際に使ったサイトやアプリは以下になります。無料apps.apple.comちなみにこれらのサービスでもこのスピードだと1分間に何語ぐらい話しているのかを確認して、自分の話すスピードの参考にしました。当日編では、最後に当日やったことを紹介します。翻訳者さんとコミュニケーションをとる実は直前に英語の発表でも通訳(同時通訳ではなく逐次通訳)が入ることが決まったため、事前に提出していた資料から内容をかなり削りました。当日最新の原稿を通訳さんにお渡ししたのですが、結果的にこれはやっておいてよかったなと思っています。事前に通訳さんがそれに目を通してくれて、僕が話す内容と通訳さんが見ている原稿にdiffがないため、逐次通訳のコミュニケーションも比較的上手くいったかなと思います。*7発表する発表する時は、座ってやるスタイルと立ってやるスタイルが選べたのですが、せっかくだから立ってやったほうがそれっぽい?と思ったので、立ってやりました。立ってやるとスライドのカンペが見れないので、予め原稿をPDF化してiPhoneのKindleアプリに突っ込んで、プレゼン中はそれを見るようにしていました。反省点としては割と丸暗記したつもりだったのですが、緊張であんまり前を見ながら話せなかったことなので、このあたりは次回に生かしていきたいです。2019こんなつぶやきをするなど1ヶ月前くらいからプレッシャーが凄かったのですが、途中から「世界で英語で喋れる人は15億人もいるし、自分も喋れるやろ」という謎理論でメンタルを保っていました。あとは、同じく登壇者だったBASEの東口さんとランサーズの金澤さんとSlackでお互いの進捗を共有させてもらったのはメンタル的にとても助かりました。Query」をCakePHPのコアコミッターの方に褒めていただいたのは非常に嬉しかったです。褒められた瞬間ただ、今回無事終えることが出来たのはCakeFestがアットホームな雰囲気の暖かいカンファレンスであったことが一番の要因かなと思います。凄く話しやすい空間を作っていただき、本当に運営の方には感謝の気持ちでいっぱいです。初の国際カンファレンスの登壇の場が東京だったのは非常に運が良かったなと感じています。個人的にはやはりQ&Aは英語で回答出来なかったり、上手く話せないこともあったりして反省点もあるのですが、やはり一人のエンジニアとして世界で勝負していきたいという想いが更に強くなったので、引き続き英語の学習を続けて、来年は海外カンファレンスでの登壇にチャレンジしたいと思います!CakeFestの戦利品*1:完全に間違った英語なので、皆さん真似しないでください。*2:公式情報ではないので、間違っていたらごめんなさい。*3:週イチ80分の少人数のレッスンを受講しています。*4:誤解なきようにお伝えしておくと、レッスンの内容自体は非常に素晴らしく、純粋な英語力は上がっていると感じているので今も通っています。*5:協力してくれた方には頭が下がる思いでいっぱいです。*6:自分の声が嫌いなので苦行でしたが、発音の確認のために絶対やったほうがいいです。*7:もちろん、これは通訳さんの技量によるところが大きいです。*8:おそらく今後登壇の映像が配信されると思うので、全然無事じゃない可能性がありますが...。フライボール革命のメカニズム』という本を献本いただきました。*1やきう好きとして、最高に面白かったのでネタバレしない程度に感想を書きたいと思います。いう本なの?昨今話題の「フライボール革命」をはじめとする野球理論を膨大なデータやスポーツ科学の観点から検証・考察する本です。EPILOGE(あとがき)にも書かれている通り「分かりやすさより」も「正しさ」を重視して書かれているそうなので、少し難しい箇所もありましたが、野球の知識があるソフトウェアエンジニアなら「ふむふむなるほど」といった感じでサクッと楽しく読めると思います。現役のプロ野球選手がデータとどう向き合っているのかを知ることも出来ました。面白かったところ個人的には「上から叩いて打つ」とか「ヘッドを立てる」とか「低めに投げる」とか「球持ちを長くする」といった、これまで正しいとされてきた定説や感覚に基づいた指導法が本当にそうなのか?をしっかりとデータを利用して、検証している点が非常に面白かった。その中で感覚が正しかったものもあれば、実は正しくなかったものもあるんだけど、大切なのは正しい/正しくないの二元論ではなく、そうやってデータや科学を上手に活用することで、再現性を高めて進化していくことなんだなと思いました。アスリートに限らず、僕はデキる人≒再現力が高い人だと思っているので、野球の世界でも、試行錯誤を繰り返しながら、変化をし続けられる選手が超一流になれるのかな〜なんて想像しました。いうわけで、素敵な本をありがとうございました!*1:献本をいただく、という表現は正しくない表現っぽいけど、すっとぼけておきます。フライボール革命のメカニズム』を読みましたTweet広告を非表示にするコメントを書くもっと読む2019-07-04コネヒト株式会社の二代目CTOに就任していましたTweetいわゆる退職エントリーというやつです。この度4月末にSupership株式会社を退職し、6月にコネヒト株式会社の執行役員CTOに就任しました!*1ちなみに、コネヒト社におけるCTO交代の経緯や意気込みについては以下の記事にまとまってるので、ここではどちらかというとパーソナルな話を書こうと思います。今回のCTO就任によるプレスリリースや対談記事で、唯一の心残りがお世話になったSupership(nanapi)についてあまり言及出来なかったことなので、最初にSupershipでの話をします。ちなみにSupershipへの転職エントリーもあるので、ご興味がある方はどうぞ。itosho525.hatenablog.com個人的にSupershipで働けたことは、自分のキャリアの中で大きなターニングポイントだったかなと思います。Supershipに入社する前は受託のお仕事が多かったので「リリース≒ゴール」のような感覚が強かったのですが、Supershipに入ってからは180°変わって「リリース≒スタート」という考えをすることが多くなりました。それは日夜オンライン/オフライン問わず、みんながプロダクトについて議論をわいわい交わしていた影響が大きく、「人の生活に彩りを与えられるプロダクトをつくりたい」と思っていた僕にとってそういった環境は正に求めていたものであり、非常に刺激的な毎日でした。その中で辛いこともありました。僕は入社後「アンサー」というコミュニティサービスに長く携わっていて、非常にやりがいを持って開発をしていたのですが、最終的にサービスクローズという結果になってしまいました。クローズした理由は様々あったとは言え、サービスを継続させることが出来なかったという事実に対して自分の力不足を痛感したのを昨日のことように思い出します。その後、コネヒトでは「ママリ」という別の種類ではあるものの同じコミュニティサービスを開発しているのは何か縁かなと思うし、ママリへのモチベーションはいくつかあるのですが、あの時の悔しさと哀しさを二度と味わいたくないというのも原動力の一つになっています。いった辛いこともありましたが、その中でもSupershipは優しい人や面白い人が多く、いい意味でプライベートと仕事の線引なく仲良くしてくれて、トータルで考えると本当にたのしく働けたなと思ってます。いうわけで、Supershipでお世話になった皆さんには本当に感謝しかありません。ありがとうございました&これからもよろしくお願いします!次の10年をどう生きるか?次に今回何故CTOを引き継いだのかという話をします。最初に紹介した対談記事でも少し触れているのですが、今回CTOの打診を受けた時、ちょうど社会人丸10年で(ソフトウェア)エンジニア歴も10年になったので、次の10年をどう生きるのがよいのだろう?ということを結構真面目に考えていました。嬉しいことにいくつかお声がけもいただいたり、選択肢として起業というのも割とリアルにあったりしました。*2しかし、そういった選択肢を考える一方で、今の場所でもう少しエンジニアとしてやるべきことがあるのでは?という気持ちやもっとエンジニアとして頑張りたい!という思いが意外にも沸々と湧いて来ました。「意外にも」と書いたのは、自分からこういう感情が生まれてくることが単純に驚きだったからです。言うのも、僕は元来エンジニアになりたいという気持ちが学生の頃はそこまで大きくはなく、転職活動が上手くいかない中で「ものつくるのは好きだからエンジニアも面白いかもな〜このままだとどこも決まらないから受けてみよう!」ぐらいの気持ちでこの世界に飛び込んだので、エンジニアとしての拘りはあんまりないと思ってました。思わないです(念の為言っておくと、エンジニアである以上そこを目指してます)が、10年エンジニアをやって、いつの間にかエンジニアとしての矜持が自分の中に芽生えていたのは一つの発見であり、今はエンジニアになって心から良かったと思ってます。そんなこともあり、次の10年の最初の一歩をエンジニアとして新しいチャレンジをするというのは自分にとって、チャレンジングではあるものの自然な選択なのかと思うし、あとはやはり、コネヒト社の「人の生活になくてはならないものをつくる」というミッションに自分の人生を捧げる価値があると思ったのが大きいかなと考えてます。CTOはゴールではない最後にこれからの話を少し。CTOになってちょうど一ヶ月経ったのですが一ヶ月の感想は、思った以上に目先のことばかりやってるとあっという間に忙殺されるな!という感じです。*3よくあるマトリクスこういうよくあるマトリックスで言うと、CTOは「重要だが緊急ではない」課題に対して、きちんと時間を確保しないといけないんだろうなぁということを改めて感じたので、これからそういう時間を増やしていく所存です。いう課題を考える時間を増やすためにも、自分が組織の中でボトルネックにならないようするためにも業務でコードを書く時間は徐々に減らしていければいいなと考えています。ちなみに、今年のGitHubの草の様子はこんな感じ。草の状況から分かるかもしれませんが、4月くらいからそれっぽい仕事が増えてました。いわゆるマネジメント業務が増えるとコードが書けなくなる問題はあり、腕がなまらないようにする必要性は一エンジニアとして感じてます。*4ですが、やはりCTOとしての役割の一つは経営にエンジニアリングの力を反映させて、事業を成長させていくことだと思います。CTOになる少し前あたりから会計やファイナンス、会社法あたりをざっとですが勉強したり、先月から英会話もはじめたりしているのですが、これからはそういうエンジニアリング以外のスキルや知識も伸ばしていかねばと思ってます。言え、CTOになったからと言って、いきなり何でも出来るスーパーマンになれるわけではないので、変に自分を大きくみせることも小さくみせることもせず、粛々と努力していきたいなと考えてます。*1:職務経歴上は転職になると思いますが、2年ほど前からSupershipからコネヒトに出向してて、5月に転籍した感じなので働く環境という面では大きな変化はありません。*2:余談ですが、起業すると社会的信用失いそうだな〜と思ったので、家を買ったのもこの時期。*3:6月は引き継ぎのなんやかんやもあったのでそれも忙しさの原因の一つではありましたが、思った以上に忙しかった!*4:元々インディー開発が趣味なので、週末は割と変わらずコードを書いていますが。PHP7対応』というタイトル(以下、プロフェッショナル本)で2019年2月26日(火)に秀和システムさんから発売されます。会社の同僚と書いたので、是非買ってください!(石直球)しかし「せっかく買ったのに思ってたんと全然違うやんけ!」となるのも申し訳ないので、プロフェッショナル本がどういう本なのか簡単に紹介したいと思います。ボリュームは実質390ページほどになります。4つのパートで構成されています。最初の導入編では昨今のPHPとそれを取り巻くエコシステムを紹介しており、具体的にはPSRやComposer、PHP7の新機能などを解説しています。入門編ではPHP質問広場というオリジナルのQAサイトを実際に作っていきます。実装以外にもDockerを利用した開発環境構築があり、設計やユニットテストの方法についての解説もあります。ちなみに、Webアプリケーションの開発にはCakePHP(3系)を採用しています。実践編ではチーム開発にフォーカスを当て、GitHubやSlackの使い方を紹介しつつ、チーム開発でも特に重要なコードレビューについて解説をしています。複数人での開発に役立つツールとしてPHP_CodeSnifferとPHPStanの紹介や昨今のトレンドであるコンテナベースのCI/CDについても触れています。最後の発展編ではPHPの枠を越えて、障害への向き合い方やSQLチューニングの解説に始まり、実際の運用では重要なセキュリティの話にも触れています。最後にOSSへのコントリビュートについても簡単に紹介しています。盛り沢山な内容になっております!もう少し知りたい方は最後に目次をまとめておきましたのでそちらも併せてご覧ください。プロフェッショナル本の立ち位置まえがきでも触れているのですが、プロフェッショナル本は初心者向けの入門書ではありません。言って、PHPの文法書やCakePHPの専門書でもありません。PHPの本ではあるのですが、扱っているトピックが多いので、ややもすると「帯に短し襷に長し」という印象を持たれるかもしれません。いう問題意識から企画が始まっています。プロフェッショナル本は最新のPHPを学びながら入門書と個別具体的な技術の専門書との架け橋となる本を目指して書きました。上述の内容を踏まえつつ、主な読者としては以下のような方をイメージしています。昨今の開発現場で多く採用されているツールや開発プロセス、考え方を一通り知りたい人もちろん、上記以外の方にも是非読んでいただきたいなと思っています。ちなみに、個人的にはPHPer以外の方にも読んでいただけると嬉しいです。逆に以下の人は難しく感じたり、逆に物足りなく感じたりするかもしれません。初心者の方でも理解出来るよう工夫はしていますが、フレームワークって何?Gitって何?というレベルだと少し厳しいかもしれません。モダンな開発現場で何不自由なくバリバリ働いている人コードレビューやテストを日常的に行っており、開発プロセスも自動化されているような現場で働いている人は特に得るものがないかもしれません。CakePHPの詳細な解説を求めている人CakePHPを利用してWebアプリケーションの開発を行っていますが、それだけを目当てに読むと説明が浅いと感じるかもしれません。フィードバックについて少しでも誰かの役に立てばという気持ちで一生懸命書きましたが、今回技術書の執筆は全員が初めての経験だったので、もしかしたら読み辛い箇所や間違いがあるかもしれません。いうことに関して言い訳するつもりはないのですが、イケていないところは真摯に受け止めてきちんと改善していきたいと思っています。僕のTwitterでもAmazonのレビューでも何でもよいので感想などフィードバックいただけると嬉しいです。Requestを作成していただいても構いません。正誤表に関してもリポジトリ内のWikiを随時更新していく予定です。最後に目次を紹介します。前述の通り、幅広いトピックを扱っているので気になる章だけ読むことも可能な構成になっています。一応、僕が担当した章は★マークをつけておきます。GoTweetこの記事は?インディー開発をしたり、本を読んだり、勉強会に参加したりして、GoのWebAPI開発における自分なりの実装パターンが固まってきたので現状を整理します。具体的にはORM、フレームワーク、パッケージ構成あたりの話。ある程度アンチパターンを踏んできてますが、僕自身プロダクションレベルでのGo開発経験がバリバリあるわけではないので、ここは間違ってるぞ!とか自分はこうしてる!など(建設的な)マサカリや大歓迎でございます。以下のような小〜中規模程度のJSONで話すWebAPIを想定。APIの数は20本前後シンプルなCRUDベースのAPIが多いが、ちょっと複雑なリレーションやビジネスロジックも多少あり。外部システムとの連携は(システム内の)DBがメイン。Push通知など外部のAPIと連携する箇所も。ちなみにインディー開発中心なので、ミッションクリティカルなシステムであることは想定してません。言え、ある程度の規模までプロダクションレベルに耐えうるものを想定。(と言うより、そこを目指しています...!)テクノロジースタックこのあたりは好みもあると思いますが、僕は以下の構成でやることが多いです。上記の環境をDockerで作って開発してます。使っており、ファイル保存時に自動でビルドが走るようにしてます。*1なお、環境というかインフラはAWSやHeroku、VPS想定。GAE/GCPだとDatastoreを使うことが多いと思うので、また違ってきそう。銀の弾丸はないので、何が正しいか正しくないかは状況次第ですが、アーキテクチャやライブラリの選定基準や開発方針としては以下の2つを意識してます。前置きが長くなりましたが、ここからGo界隈でよく盛り上がるトピック別に現状を書いていきます。パッケージをいい感じに使えるようにしたライブラリ。パッケージで頑張るのがGoっぽいとは思うのですが、structへのマッピングを自分でやるのは大変なので、メンテもきちんとされているsqlxを使うようになりました。アリだとは思うのですが...と言うか自分も最初使ってました。エラーハンドリングが重要なGoの世界観と合わないと思ってるのと便利な分コードが複雑なので、慣れてきたら薄いライブラリを使うのがいいかなと思ってます。MySQLならschemalexが枯れてて安心感があります。その他の選択肢xoxoDBから直接Goのモデルを生成してくれる便利なやつ。Recordっぽいものを使いたい人向け。フレームワーク関連いわゆるWAFは使ってません。フレームワークを採用するのも良いと思いますが、個人的には余計なDSLを覚えずに可能な限りGoだけで書きたいので、現状は使ってません。RubyにおけるRailsみたいなデファクトスタンダードとなるフレームワークが誕生すれば、また別かもしれない。JSONではなくHTMLをレンダリングするような場合だと、これだけだと辛いかもしれませんが、JSON形式のWebAPIならこれで充分かなと思ってます。その他の選択肢go-json-restフレームワークと言うよりルーティングとミドルウェアのライブラリ集+JSONがいい感じに扱えるライブラリって感じです。コードも読みやすいので、最初の選択肢としてはアリかなと思ってます。echoフレームワークを使うなら、パフォーマンスが良好&コミュニティも活発なのでこれが一番いいかな〜。GAE用のドキュメントが分かりやすかったので、GAEを利用する時にも良いかもしれません。個人的にはGoに慣れてきて、一番困るのがこれかなと思ってます。フレームワークを利用していればまだいいのですが、使ってないと自由過ぎて困ります。これは今も試行錯誤していますが、最近はいわゆる?レイヤードアーキテクチャ+ポートパターンを採用しています。*4概要図こういうやつです。レイヤードアーキテクチャ+ポートパターン基本的に通常のレイヤードアーキテクチャのように上から下に流れるようにしてる(下位のレイヤは上位のレイヤに依存しない)のですが、ドメインレイヤーにインターフェイス(ポート)を置くことで、ドメインレイヤだけどこにも依存しないようにしてます。破線部分については後述します。フォルダ構成こんな感じでやってます。僕がよく使うRailsやCakePHPのようなMVCモデルと比較しながら説明していきます。プレゼンテーション層MVCで言うコントローラーとビューにあたる箇所。コントローラーの責務はリクエストを受け取り、それをアプリケーションレイヤで利用出来る形にしてアプリケーションレイヤを操作すること。その結果を(ビューと連携して)レンダリングすること。ここは極力コード量が少なくなるように意識しています。ビューの責務はレンダリングに関すること全般。JSON形式のWebAPIだとコントローラー側でJSONを出力するだけで事足りることが多いので、あんまり書かないことが多いかも。僕は汎用的なレンダリングのロジックだけ書くことが多いです。アプリケーションレイヤいわゆるサービスクラスっぽい役割をする箇所。アプリケーションレイヤの責務はドメインレイヤとインフラストラクチャレイヤのビジネスロジックを操作すること。ちなみに、DBのトランザクションはここで制御しています。ドメインレイヤみんな大好きモデルを扱う箇所。ドメインレイヤの責務はビジネスロジックの実装を持つことですが、技術的な実装(直接的なDBの操作やPush通知の送信など)は行ってません。先述の通り通常のレイヤードアーキテクチャとは異なり、ドメインレイヤとインフラストラクチャレイヤとの間にインターフェイスを設け、技術と実装を分離するようにしています。定義することもあります。*5インフラストラクチャレイヤ技術的な実装を扱う箇所。インフラストラクチャレイヤの責務は直接的なDB操作(SQLの実行)やPush通知の送信など技術的な実装を行うこと。通常のレイヤードアーキテクチャでは、インフラストラクチャレイヤはどこのレイヤにも依存しませんが、技術と実装を分離するために必要に応じてドメインレイヤのインターフェイスに依存させています。オレオレルール厳密なレイヤードアーキテクチャでは直下のレイヤにのみ依存すると思うのですが、2個下のレイヤに依存するのはある程度OKにしています。これが上記概要図の破線の意味です。理想は直下のレイヤにのみ依存させるのがベストだと思うのですが、現実問題として厳密にやりすぎると辛いときがあるのである程度は許容してます。muchかなと思っています。言え、薄いライブラリしか使っていないとMVCモデルでは少し辛いケースが多く、また、テスト観点から技術と実装を分離したくなることが多いので、このようなアーキテクチャにしています。逆に言うと、フルスタックなフレームワークやORMを使っている場合はMVC(+サービスクラス的なもの)で充分なケースも多いと思います。テスト観点だけであれば、インフラストラクチャレイヤがDBのみの場合は、インターフェイスを置かず通常のレイヤードアーキテクチャでもいいかなと思ってます。単体テスト時のDBアクセスは低速でアンチパターンですが、RailsやCakePHPをこれまで使ってきた身からすると、そこまで違和感ないので。縦割りパッケージ構成レイヤではなく、機能で分けるパターン。packageを作るパターン。microservies化を想定しているならアリかなと思います。Goっぽいなと思いつつ、個人的には共通処理の扱いが難しいなと思ってます。言え、今後はvgoを使うのが主流になっていくはず。最後に書いてみて、コードがないと分かりづらい気がしたので次はコード編を書いてみたい。その時は今回書けなかったログとかエラーハンドリングのことも書くぞ。あと、冒頭にも述べましたが、Goは導入事例が増えてきたとは言え、RubyやJavaに比べると枯れておらず、ベストプラクティスがそこまで世に出回っていないので、自分なりの考えや現状を書くことで誰かのためになったり、議論のきっかけになったりすればいいなと思ってます。−脚注*1:単純にMakefike経由でビルドしているだけ。達人に学ぶソフトウェアの構造と設計』でも言及されている通り、技術的な実装に引っ張られないアーキテクチャが本当は理想なのでしょうが...。*3:ただ、フレームワークはそんなにたくさんは試していないので、他にもっと良い選択肢があるかもしれない。*4:この用語は『pospomeのサーバサイドアーキテクチャ』を参考にしています。*5:このあたりは現在進行系で悩み中です...リポジトリパターンやDAOをどうやって使うとか...難しい...。*6:もちろん開発するプロダクトや個人/チームのスキルにも依るとは思います。*7:翻って、そこからまた自分が成長出来ればいいなとこっそりと思ってます。日常Tweetみんなが2018年の振り返りをやっているので、僕もやってみよう。いいけど、昔はみんながやってることはあんまりやらないタイプだったのに、最近流行っているものをやっていないと、自分の感性や感覚がズレて来てるんじゃないか?と思って不安になる。2018年のよかったこと7回登壇することができた!ほとんどLTだけど、年末にPHPカンファレンスという大きなカンファレンスで登壇出来たのは、とても良い経験になった。takattata.github.io南山大学の公開講座が最高of最高だった!ここ数年で最高の学びがあった。体験学習に勝るものなし。itosho525.hatenablog.com30冊ぐらい本を読めた!今年は読書を習慣付けるために1スプリント(2週間)に1冊本を読むというのにトライしたけど、波はありつつ数はクリア出来たのでよかったかな。自由と責任の文化を築く』NETFLIXの本に「人をいい気分にさせたいって言うじゃない〜?でもそれ正しいことをしたいからじゃなくて、自分もいい気分になりたいだけですから〜残念!」みたいなことがいっぱい書いてあって、身につまされる。2018年11月17日2018年のわるかったことあんまり技術的な挑戦が出来なかった...特に後半はとあるプロジェクト(これはもうすぐお話出来るのでもう少し待ってけろ!)で忙殺されて、成長実感が関西人くらい薄味。Gopher道場に参加したりGoでインディー開発をしたりしたぐらいかなぁ。インディー開発のリリースが1つだけだった...しかもチームのやつだけなので、個人では何も出せなかった!これまたあかん。いうわけで年末年始は早速インディーやってます。相変わらず英語を学んでいない...先月あたりにflamingoデビューしたけど継続していない。石原さとみさん!僕に英語を!教えて!海外旅行に行けなかった...というか今年は国内もあんまり行けなかった!お金を貯めないと〜!来年は海外のカンファレンス行きがてら、観光とかしたい。(仕事はちゃんとやるという前提)ひとこと今年も大変お世話になりました〜。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。