2018年12月28日に『GoとSAMで学ぶAWS Lambda』が発売します!

内容としては技術書5で書いた『Goで学ぶAWS Lambda』に少し追記したり、いくつかいただいたフィードバックを元に改善したりしたものです。

フィードバックは僕が前々職で営業として働いているときにプログラミングを教えてくれた師匠である@ms2satoさん、前職の同僚である@Shuheiktgwさんにいただきました。

技術書典5の後にインプレスR&Dの山城さんにお声がけいただき、言葉遣い的なところを直していただき複数のプラットフォームでの出版にいたりました。

https://nextpublishing.jp/book/10326.html より

そして表紙を描いてくださったのはわかばちゃんと学ぶシリーズでおなじみの湊川あいさんです。

出版を目前にした今でもお話ししたことはないにもかかわらず、これほどまでに素晴らしいカエルに出会えると思っておらず感動しました。

技術書典5、BOOTHから読んでくださってるみなさん含めありがとうございました。

宣伝媒体

色々と出していただいてます。

同人版

技術書典5の後に出し始めたBOOTHでも先日とうとう50部を超えました。

技術書典5の『Goで学ぶAWS Lambda』の振り返りとフィードバックのお願い #技術書典でも書いているとおりアップデートがあるときは商業版とは別にアップデートは続けます。

句読点の使い方等僕の好きな表現の仕方もあるので、細々とやっていけたらと。

この記事は裏freee Developers Advent Calender 2018の24日目です。

こんにちは!かつてfreeeに在籍しニャンちゅうと呼ばれていた者です。

最近ではトシと呼ばれています。自分の寿憲(としのり)という名前がとても好きなのと、ニャンちゅうと呼ばれることでキャラ付けに下駄を履かせていただいていた過去の自分を乗り越え、純粋にエンジニアとして闘争したいという思いからニャンちゅうはアイコンにとどめることにしました。

エンジニアとして成長したい方向性と今のロール

自分がエンジニアとしてどう成長したいかを表現する局面でかつてこんな風に書いていました。

技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニア(になる)

時期によって担当するプロダクトの方向性を考えるPdM的な役割も担いサービスを考えることもありました。しかし、ここ1年くらいはそういうことは少なく、上記の「作り、変え」にあたりインフラも含めてどう設計するとよいかを考えることが多いです。

9月からはメルペイという会社で信用を創造して、なめらかな社会を造るべくその足がかりとしての決済システムを開発しています。

メルペイではマイクロサービスを開発するチームの1つでテックリードをしています。きっと組織によって「テックリード」の位置付けは異なると思いますし、少なくともfreeeにかつていた(?)テックリードとは異なります。

メルペイのテックリードの役割はこの記事で触れられているとおりこんな感じです。

エンジニアたちにとって開発の妨げになっているものを取り除くほか、全体設計や技術にある課題を解決する。

エンジニアと立ち話。Vol.19 @foghost(メルペイBackend)ちょっとお話いいですか?

メルペイに転職したのは自分が技術で解決したいと思うものが会社の方向性と合致しているからです。そこでどう貢献するか形は色々とある中、テックリードとして技術課題に立ち向かうのは自分がエンジニアとして成長する上でもとても重要なことだと捉えています。

とはいえ、ロール以前にGoやGCP、最初から全体的にマイクロサービスなどそもそも技術的に初めてしっかりと触れることが多く、想像以上に難しい・わからんと感じる局面が多いです。

全方位的に完璧を目指すのは現実的でない雰囲気な中、何を解決すればメルペイ(特に自分が担当するマイクロサービス)をリリースでき、安定して運用をできるのかを考えそのときそのとき一番大事っぽいことに集中して取り組む必要があります。

来年よりいい感じでチーム開発を進めるために、注意し続けたいことや改善したいことをまとめます。

設計

方針的な実装と詳細な実装、アーキテクチャを暫定的にでも決定しないと実装できないところとそうでないところをきちんと分けないと進みません。

マイクロサービスに対し、入社前はそのマイクロサービスのドメインをきっちり深め運用までしっかりしていく必要がある一方であまり他のサービスのことを知らなくてもよいというイメージがありました。

そのイメージの正誤はおいておいて、他のサービスの設計にどうしても依存せざるを得ないケースがあります。さらに複数のサービスが関係することもあり、設計・仕様の調整を待っていては進まんみたいな状況もありえます。

ただ、本当にそれが決まり切らないと全ての作業が無駄になるということもないので、影響を受ける部分とそうでない部分の境界を見極める、影響を受ける部分を分離するということが大事そうです。

仕様を決める時点で複数のサービスが拘るならその部分はその後も他のサービスの影響を受けるかもしれませんし、自サービスの都合で自由に変更し辛いかもしれません。

このあたりの設計を考える上では今年Clean Architecture 達人に学ぶソフトウェアの構造と設計に最も影響を受けました。

本にも出てくる「できる限り決定を遅延できる設計」というのは自由にコントロールできない部分がありかつ不確実なものに立ち向かう上では肝に銘じたい言葉です。

一方で、今の技術スタックに十分に馴染みのないまま考えて実装の現実味がない部分もあったので実装力にある程度裏付けされた設計ができないと辛いです。

個人開発でコード書けば済む部分もあれば、ある程度大きめのコードベース・複雑な前提で試さないと現実味がいつまで経ってもわかない部分もあります。なので、調整系のタスクの優先度が高いにしても自分で実装するのも必ず残すよう心がけます。

意思決定

「こういう設計で行こう!」と決めないと進まないという思いと、詳細な実装を進める上で困るようであれば自由に変えてよいのではという思いは同居しています。

しかしそのふわっとした感じだと、メンバーに決まってるのか決まってないのかようわからん、とモヤモヤが生じることもあります。

やり方まで押し付けるのは嫌な一方でどこかのタイミングで結論(それが未来永劫変わらないというものではない)を出さないといけないし、そうせざるをいけないといけないこともあります。

その上でやるべきことは

  • そう決定した根拠を整理し、 腹落ち感があるまで 説明したり議論したりする
  • 根拠はその仕様を決めないといけない背景・コンテキスト、仕様面、技術的制約、社内外問わないコミュニティの動向、社内的な議論を構成要素とする
  • 腹落ち感がありそうかなさそうかリアクションを見てわかる程度の関係を構築する

だと感じていて、全てが技術そのものに閉じるわけではなさそうです。

あと決定するにあたっては、自分のサービス的にはとても重要だけども他のサービスにとってはの優先度は異なるケースで、適切に「こういう仕様でないと困りそう」だったり、「こういう仕様をそっちのサービスで検討してないと困ると思うよ」だったり議論をリードしたり検討を促すことも大事そうです。

AはBがやると思っていて、BはAがやると思っていた、など認識の齟齬や浮いてしまっていた仕様にも気づけます。

プロジェクトマネジメント

不確定な要素が多いが期限があるものにどう向き合うべきか?これはこれまでエンジニアが向き合ってきたものの中でも最も手強い課題の1つではないでしょうか。

細かい工夫はいろいろとできるとは思うのですが、とにかくチームが意識して追うべきものと前提が揃ってないときつそうです。

と言いつつこれがまだまだできてなさそう。

アジャイルな感じでJIRAでチケット管理しているのですが、もうちょっといい感じにしたいのはこの辺りです。

  • バーンダウンチャートの残StoryPointが0になる = リリースできてる状態
    • リリースまでに必要なタスクが全てチケットになっている
    • 必要な作業が出てきたら足して見積もる
    • 遅れてると足すことが悪いように自分でも感じてしまうけど必要なものは必要
    • ただそれが過剰でないかは議論の余地があるのでまずはチケットにする
    • 各チケットの粒度が多少違ってもレビューを含む・含まないは最低限揃っている
  • バーンダウンチャートではバージョンのフィルターをかけて増減を追う
  • 「各Sprintにはバージョンに直接貢献しないがやるべき作業(研修や同僚の評価など)がある」のでStoryPointを入れてチケットにする
    • バージョン以外の作業も含むチームのベロシティはスプリントあたりどれだけStoryPointを消化できるかがわかり、次Sprintに積むチケットの量を考える基準になる
  • 厳密にはやらないもののSprintのプランニングで積むチケットはやりきるというコミットでやりきるべき、逆に差し込まれたタスクはやらなくていい or その場で判断しなくていい、差し込まれないように 誰か が守るべき
    • そのために自分はPRレビューを最優先する(Todo -> InReview -> Doneのブロッカーを作らない)
    • Sprint内やまたいで滞留しているチケットに対してアクションをとる
    • 自分が実装タスク持つとほぼその週で終わらん…!
  • StoryPointで各チケットに工数を入れ、便宜的に2StoryPoint = 1人日としているが関心事はあくまでも
    • 1SprintでこなせるStoryPointを最大化すること
    • 1Sprintの平均ベロシティからプランニング時に積めるチケットの妥当なStoryPoint合計を見ること
    • n人いるので2 * 5(営業日) * n = 10n StoryPointには必ずしもならない(なることもある)
    • 相対値であり、大きければ大きいほど不正確・作業内容の変更リスクが大きいのでプライニング時に毎回見直す

前職でアジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~を教えてもらって読んで1度サービスのリリース(直前)までチームリードしたことはあるものの、そのときの経験がまるっと活かせるものでもありませんでした。

ただ言えるのは、これそのものがなんとなく場当たり的にやるのでは身につかない専門性ある技術なのと、バーンダウンチャートのリリース予測がパッと見計算間違いではって思えるようなものでも的確に現実の問題を明らかにしていることです。

「自分が全ての問題を解決しきる」のが目的でも求められていることでもないので、厳しかったり答えが見つけられないなら助けを求め、その結果を全体に還元できるように尽力します。

なかなか痺れる毎日ですが日々闘争し、いいサービス出します。

10/8(月/祝日)開催の技術書典5で『Goで学ぶAWS Lambda』という本を出展します。76ページです。

カエルと空というサークル名で場所は「か76」です。

ぜひ遊びに来てください!!

興味ある方はサークルのチェックリストに登録しておいていただけると助かります。印刷数の参考にします。

本の紹介

Goで実装したAWS Lambdaのユースケースを見ながら開発方法を学んでいく構成になっています。

目次はこんな感じです。

  • 第1章 環境構築
    • anyenv
    • anyenvupdate
    • goenvとGo
    • pyenvとPython
    • aws-cli
    • aws-sam-cli
    • インストールトラブルシューティング
    • direnv
    • dep
    • gig
  • 第2章 S3イベントの活用
    • 概要
    • S3
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • デプロイ
    • 削除
  • 第3章 SNSとSQSによるファンアウト
    • 概要
    • SQS
    • SNS
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • デプロイ
    • CloudFormationトラブルシューティング
    • 削除
  • 第4章 API GatewayとDynamoDBを使ったURL短縮サービス
    • 概要
    • API Gateway
    • DynamoDB
    • シーケンス
    • フォルダ構成
    • ソースコード
    • テスト
    • LambdaとAPI Gatewayのローカル実行
    • デプロイ
    • DynamoDBのテーブル定義変更
    • 削除

ユースケースは3つです。

3つともSAM(AWS Serverless Application Model)で定義を書いていて、Lambdaはもちろん、関連するAWSのサービスのデプロイはすべてコマンドで完結します。

勢いでシーケンス図も載せてみます。

  • 2章

  • 3章

  • 4章

執筆のモチベーション

Lambda好きや!!!

なんというか、AWS Lambdaがかわいくてしかたがないです。

趣味で触り始め、前職ではC#で書いて本番運用してました。

Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話

今のお仕事ではAWSは触らなくなったものの今年に入ってからGoに出会い、Goを書いたら書いたで幸せな気持ちになることができました。

つまり、GoでLambdaを書けばよいのでは?ということで、他の言語に比べたらGoのサンプルも少ないし布教したい!という ~~名目~~ 一心で書いてみることにしました。

ただ、Lambdaの制限はーとか、実行方法はーとか、AWS公式チュートリアルを見ればおしまいなことだけを書いても悲しいのでとにかく実装に寄せることにしました。

よく見るアイコンが並べられたアーキテクチャ の図を眺めてふんふん言ってるのではなくて実装するのです。自分で手を動かすのです。

SAMなりCloudFormationなりも各リソースのプロパティをYAML・JSONで定義すれば終わりでしょうとは言わず、エラーにハマりまくってInfrastructure as codeを体得するのです。

そんな気持ちで書きました。

勉強になるかは知りません。ちょっとでもこのLambda(とGo)への愛情が伝わり、興味を持ち、触るきっかけを掴む方が増えたら嬉しいです。

「技術」書、単著

技術書3の頃にちょうど前職でXamarinでMacアプリを開発していたこともあり、Xamaritansというサークルの『Extensive Xamarin』の出典・販売に携わりました。そして技術書典4では同サークルの本のレビューにちょこっと携わり、当日売り子をさせてもらいました。

技術書典3で『Extensive Xamarin』という同人誌の出展・販売に携わりました

技術書典3で携わった『Extensive Xamarin』が3月に商業出版されました。そして間近な技術書典4

やっぱ技術書典は!書かないと!!寂しいの!!!

というわけで技術書典5の申し込みが開始されてから秒で申し込みました。

ここ半年の社会生活に鑑み単著で、『Extensive Xamarin』では全然技術書っぽい章にできなくて(他の著者はちゃんとした内容でしたよ)不甲斐なかったので思いっっっ切り実装してから書く前提で。

ルールを調べてまとめただけの記事をもう書いてはいけないの!!!

つまりモチベーションはエンジニアとしての愛と憎しみです。

あと年初目標的には年間執筆数があります。

カエルと空

前々職のCMで一時期カエルを使っていたことから今も惰性でカエルグッズを集めています。

机はカエルでいっぱいです。

蛙(かわず)から連想するものの1つに、「井の中の蛙大海を知らず」という諺があるじゃないですか?

一方で、日本の後付けで「井の中の蛙大海を知らず、されど空の深さ(青さ)を知る」というのもあります。

由来の真偽はどうでもいいです。

自分にカエル属性があるかどうでもいいです。

ただ、思い上がるのも卑下するのも時間の無駄で、自分が見識を深めるべきもの、解決すべきものにひたすら向き合うのだという思いがあります。

その象徴としてカエルと空というサークル名にしました。

今向き合うべきはLambdaではない可能性があります。

現在はBOOTHでも頒布中です。

今年はAdvent Calendarを4本書きました。

記事の内容自体を勉強したり広めたいというよりも、テーマの部分に自分のエンジニアとしてのあり方をこう変えていきたいという思いを込めていたのでその辺りをまとめることにしました。

概要

テーマ(ブログ内リンク) 記事タイトル Advent Calendar
OSS、ドキュメントじゃなくてコードでコミットしたい! CloudWatch Logsに書き込まれた内容をSlackとGoogle Homeで通知するAWS Lambda using dotnet AWS Lambda Advent Calendar 2017
ライブラリ、使い方のお勉強ばっかりしてないで自分でビルドして追いたい! XAMLの基本(Xamarin公式XAMLページ全訳)と基礎の入り口 Xamarin その1 Advent Calendar 2017
導入からリリースまで自力でやり抜きたい! Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話 freee developers Advent Calendar 2017
エディターにも学習時間もっと割きたい! VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できる「REST Client」拡張の紹介 Visual Studio Code Advent Calendar 2017

本題

OSS、ドキュメントじゃなくてコードでコミットしたい!

CloudWatch Logsに書き込まれた内容をSlackとGoogle Homeで通知するAWS Lambda using dotnet @ AWS Lambda Advent Calendar 2017

11月に会社のOSS Fridayという取り組みで、Microsoftの公式リポジトリに出したプルリクエスト(以下PR)がマージされました。

freeeのOpen Source FridayでMicrosoft公式リポジトリに出したPRがマージされて嬉しかったけど、ドキュメント翻訳で微妙にモニョるおはなし

ただ、それはチュートリアルの全訳でした。自分が必要だからやっているとはいえ、エンジニアならコードでコミットしたいなぁというのが正直な感想でした。

そこで、12月のOSS Fridayではアドベントカレンダー記事のようなコードを公開するのを世間体対策とし、なんとしてもこのリポジトリに自分が書いたコードをぶっ込むことを真の目標にしていました。

aws/aws-lambda-dotnet

AWS Lambda の.NET Core実装です。

自分がリポジトリに対して出す予定のPRに含める予定のコードをとりあえずは自分が公開するコードでユースケースとして妥当で実際に動作することを確認しました。

アドベントカレンダー記事にコードも掲載しています。

そして送ったPRがこちら。

add cloudwatch logs event #188

自力では何も実装してないに等しいですが、足りてないかつ自分が足せそうな部分がわかる程度ライブラリの実装を読んで、マージされるまでやりとりなり修正なりするのは今後もやっていきたいです。

最終的に本家に別途足されたデータのデコード部分(アドベントカレンダー記事に書いてる)や、PRの方向性が間違ってなかったら足そうと思っていたテストも足すべきなのはちょっと考えたらわかる話だったなぁという反省はあります。

実際に公式のライブラリから自分が足した部分がダウンロードでき、自分のプロジェクトで置き換えて見るのは思った以上に嬉しかったです。

CloudWatch Logs用のクラスに差し替える #3

今は特にserverless/serverlessAzure/azure-functions-durable-extensionに興味があるので、その辺りで何かやっていきたいです。

ライブラリ、使い方のお勉強ばっかりしてないで自分でビルドして追いたい!

XAMLの基本(Xamarin公式XAMLページ全訳)と基礎の入り口 @ Xamarin その1 Advent Calendar 2017

今年は「ライブラリ製作者」「ライブラリ利用者」という対立構造?が印象的でした。

僕は多くの人が利用するライブラリを作っているわけでも作れるわけでもないです。

しかし、「ライブラリ利用者」であってもライブラリの設計を理解し、足りなければ足し、「基礎」から理解しないと単なる消費者だし、それは嫌だなぁと思いました。

そして、そうかそういう原理で動いてるのかみたいなの追うのは楽しいです。

これはOSSへのコミットでも強く意識していたことですし、XAMLの記事でも同じスタンスです。

最近読んでいるSOFT SKILLS ソフトウェア開発者の人生マニュアルを読んで思うのは、技術の身につけ方のフォームを持ちたいなぁということです。

技術書を買ったら最初から最後までじっくり読みたくなってしまう派ですが、実現したいことベースで学習スコープを決め、技術書であれ何であれ学習リソースを確保し、試行環境が構築できて実現したいことに対する最低限の情報が揃ったら手を動かして実験したり、コード書いて公開したり、よりアウトプットに時間かけたいです。

来年は副業もしようと思っているので、自分に足りない技術を身につける速度を上げて、本業にもプラスになったみたいな流れを作ります。

導入からリリースまで自力でやり抜きたい!

Rubyがマジョリティな会社でC#を使ってAWS Lambdaの本番運用を開始した話 @ freee developers Advent Calendar 2017

自分のする仕事の大半は既存システムのメンテナンスだったり、機能追加やUI改善と言ってもやはり既存のシステムの枠組みの中での作業だったりです。

そんな中でもう少し解決したい課題に対して設計し、実装し、解決するという一連の流れを運用も考慮し「システムを構築」したいです。

そのためにちっさくてもいいので、「プロジェクトの追加」みたいな部分からCI/CD(CIサービスでボタンクリックしてビルド・デプロイできればいい)まで一気通貫でやりきるみたいな経験ができたというのが結果的にアドベントカレンダーの記事になりました。

※人の手を借りていないという意味ではないです

仕事に限らず、アウトプットは記事自体を目的にせず、何かしらサービスやライブラリを落としどころにしてその過程を技術記事でも出すくらいのスタンスにします。

エディターにも学習時間もっと割きたい!

VS Code上でHTTPリクエストを送信し、VS Code上でレスポンスを確認できる「REST Client」拡張の紹介 @ Visual Studio Code Advent Calendar 2017

これは新装版 達人プログラマー 職人から名匠への道に影響を受けています。

職人たるもの道具こだわってなんぼ的なやつです。

非効率と思いつつも無駄にキー連打で解決みたいなことやりがちなので、ショートカット覚えるなり、特定のユースケースのためのツール使いこなせるようになるだったりの意識が強まりました。

アドベントカレンダーの記事も、「便利な機能あったですごいやんな?」的なものではなくて、使いこなせるようになるために公式ドキュメント読み込んだ際の副産物という位置づけです。

まとめ

今年もやっとしてたいろいろなことを次に進めるための一歩がそれぞれ踏み出せてよかったです。

今年はまだ残っているとは言え、もう少し広い範囲で振り返ったり、来年のための準備に時間を割こうと思います。

6月7日(火)

28歳になりました。

hbd

会社でのいただきものです。カエルとガルボが好きです!といった結果…!

チアシードドリンクのラベルを外してもってくることでカエルの卵感が出ていてセンスを感じざるを得ませんでした。

毎年、年末年初と誕生日には振り返り、先のことをなんとなく考えるので則ります。(去年のコピペ)

エンジニア編

今のチームに移ってもう1年経ってしまいました…。

ざっくり振り返ると、腕力の伸び、遅くて心苦しいという感じです。

比較的手をつけやすい修正ですぐ片付くものは片付くものの、

  • 自分が所属するチームの関わる部分の全体像の描けてなさ
  • 大事なバリデーション追いきれてなさ
  • 調査やりきれなさ
  • これがダメなら次はこれ!の試す速さと切り替えの速さの足りなさ
  • 手に負えなくて(量的にも技術的にも)運用カバーという甘え
  • 使う技術の思想への踏み込まなさ
  • 自動化やらなさ

こう見るとエンジニアとしてショボいとしか言いようがなくて辛いですね…

今チームにはAとBプロジェクトがあり、僕はBプロジェクトにいるという想定で書きます。

昨年末Bプロジェクトではアーキテクチャを変更し、1〜3月はその精度向上に取り組んでいました。

とは言うものの、季節柄どうしてもA関連の対応に追われ後手後手に。

一度はそのいずれでもないプロジェクトでがっつりフロント周りを触ることになったものの、今はまたBプロジェクトに戻っています。

上で挙げた、自身に足りないと感じる部分はBプロジェクトで日々実感していることです。5月以降はまず改めてBプロジェクトの課題を洗い出すことからはじめ、優先度をつけ、1つずつ潰していく日々です。

チームに新しく入ってくるメンバー用にまとめたキャッチアップ用のドキュメントも結局は自分が一定以上理解している部分しかまとまってない感があります。というのも、書いてある以外の部分でも聞かれるものの、「この辺の処理読んでください…」とか簡潔に説明できないか、動かしながらでないとこういうもんですって言えない。

プロダクトの全てを深く理解しろ!!みたいなものが要求されてるわけでもないのに、チームが主に守る範囲ですら追いきれていないのもこの1年って何やたんやろう?ってなります。

Bプロジェクトの根本技術の理解深化、サンプル書きながら要素技術を導入していく、チーム向けのドキュメントブラッシュアップ(それ自体意味はあるものの、どちらかと言うと自分の鍛錬として仕様理解してる部分増やす)をここ2ヶ月くらいはしっかりやっていきます。

今年はじめ時点の目標は

  • JavaScriptと真剣に向き合う
  • android触る
  • API!

ということでしたが、ここは腰を据えてC#関連やりきるところだと最近思い直したところです。

ただ、JavaScriptと真剣に向き合うは年末からやっていて、この辺の本を写経したりしつつ勉強しました。

(途中)

(途中)

(途中)

(途中)

JS怖い、みたいなところがありましたが、教えてもらったりサンプル動かしたりで少し好きになりました。あと、最近主に書いてるC#もイベント云々扱うので活きてます。ただ前線はひたすら遠い…

でもねでもね!できないこといっぱいなんですけど、できるようになったことも…!みたいなことを言う気も起きないので、次記事書くときにはこれはなんとかできるようになった!を言えるようにやるしかないです。

音楽編

今年は90年代溌剌ミスチルソングを歌えるように!年末までに5曲くらいしっかり!が目標ですが、その土台はしっかりしつつあるような感じです。

歌い方を変えた去年のままでは弱々しくなってしまう部分を再度鍛えて地声寄りで張れるように少しずつよくなってきました。

少しずつ…

5月末のライブ動画は比較的落ち着いて聴けます。

課題に感じる部分とそれを解消するための歌い方の調整がうまくいきつつあるので、引き続き練習していこうと思ってます。

ピアノは1曲もやってない…

プライベート編

28歳を迎えた日に入籍しました。戸籍を引っこ抜いて新しい戸籍を作る、という行為に重みを感じました。

新居は8月〜、式は来年?という感じでまだまだイベントも残っていて生活の土台もできてないです。

仕事一層しっかりせんとなぁという思いを強くしました。

エンジニア同士仕事面でも高めあっていけるといいなぁ…!

プライベートの目標の「許す」もこの本

が期待以上によくて一時期捗りましたが最近進捗ダメなのでもう少し落ち着きます。

さいごに

仕事は特に不甲斐なくて何やってるんだ感が強いですが、公私のサポートが手厚く気持ちは前向き落ち着いているのでやっていこうと思っています。

明けましておめでとうございます!昨年は公私共々人生が変わった1年でした。

それを振り返り、今年1年をどうしたいか考える。そんなことをしながら元旦の午前を過ごそうと思います。

2015年

隔月〜四半期くらいのペースで記事を書いて振り返っていました。改めて全部読んでみると、そのときそのときに必死に考えてること、その次の3ヶ月くらいでどうしたいか、その前に思い描いたことが実現できたのかがわかってよいなぁと思いました。

ただ、それだけではなくてやっぱりこんな風に1年とかそれくらいのスパンを振り返り、次を思い描くのもあるとなおよいなぁという感じです。

1月〜10月

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます : 0ヶ月

転職して3ヶ月が経ちました。もっと速く修正したい。 : 3ヶ月

27歳になりました : 6ヶ月

転職して半年が経ちました。「技術だけで生きるというのは幻想である」だなんて僕は言えない。 : 7ヶ月

freeeへの闘争、終結。正社員になりました。 : 8ヶ月

転職して9ヶ月、面接受けて1年が経ちました。ここは求めた場所なんやろか? : 9ヶ月

転職して10ヶ月、内定もらって1年が経ちました。この1年で何が身についたんでしょう? : 10ヶ月

スタートラインに立つまでのお話。自分の技術的な成長のボトルネックは技術そのものでなく、人との関わり方(頼る、自分を過度に卑下しない)にありました。

11〜12月

10月にはじまったプロジェクトが12月でひと段落しました。大事な目標を掲げるときはダルマを買う、いわゆるDDD(Daruma Driven Development)を実践しているのですが去年2つのDDDを達成しました。

daruma

5月頃既に立ち上がっていたプロジェクトではあったのですが、追加機能をリリースするのはもちろん、今後の拡大を見据えて再設計し、バグやKPIのトラッキング、開発体制を大きく変更するというもの。

それまで主に書いていた言語と異なるのも自分にとってはチャレンジでしたが、エンジニアになるときに掲げたこと、昨年はこんな風なことやりたいと掲げたこともあってビジネス上の文脈以上の意味を持たせていました。

リリース後に…があり、力不足は隠せなかったものの周囲の方々にだいぶ助けてもらって文字通りひと段落というところです。

6月の記事には目指す姿としてこんなことを書いていました。

  1. 今目の前にある、まさに必要とされることを何でもこなせる
  2. 今の体制では手薄になってしまう、けれどもみんな必要と思っていること部分の仕組みを一から(とは言わなくても「自分がやったった」って言えるくらいの貢献度で)作りたい
  3. 特定の分野と、逆に誰もやってないけど誰がやるといいやろう?みたいなときにアイツや!って声かけてもらえるようになりたい

それぞれ振り返ると、

  1. 社内に知見が少ない分野(聞いたら分かったこともあるかもですが、結局調べないとどうにもならないみたいなことが多かった期がする)でしたが、最低限動かすのに必要はことは調べ切りました
  2. 他のプロジェクト参考にしたものの、意識的に時間とらないと入れられない仕組みをいれました
  3. 8月か9月くらいの面談?での「この分野はニャンちゅう(※社内での呼称)が育てたって言える分野として育ててくれ!」という言葉と共にアサインしてもらったプロジェクト

という感じです。

単にコードを書くだけでなく、ほんの少しだけエンジニアリングに近づいた気がしました。

ただ、他のプロジェクトと同じように運用しようとするにはまだ足りていない部分が多いです。悔しいです。次の四半期でまたよい報告ができるようにがんばります。

朝会

4月頃?からみんなの前に立って担当し始めた全体朝会。忘年会にて特別賞枠で表彰してもらいました。

オフィス移転前には100人前後の前で話す感じで気分はさながらライブ。日付言うときにはずっと手震えてたし(日付以外はそうでもない)、未だにそうだし、きっとこんな時間無駄って思う人いっぱいいるし、それ言う?言っちゃう?みたいなことも言われたし…

駄菓子菓子1人あたりの時間×人数分自分が社員を拘束するのはそれだけの責任が生じて当然。体を張って(?)滑ることを恐れず(いや恐い)、声も多少集めつつよいと思ったことはとりあえず試してみる日々でした。

効率化できることがあったり、もう一歩踏み込むべきところがあったり、朝会司会を仰せつかった頃とは大きく異なる規模に見合った朝会を設計する(やめる、も一選択肢として考えるべき)ことがあったり、これはこれで大切な仕事だと思うので人の力も借りつつ続けていきたいです。

情報発信

チキって書けなかったQiita記事。freee Engineers Advent Calendar 2015をきっかけにとうとう年末2本書きました。

ここで紹介されているGrowing Rails Applications in Practiceという海外本の全訳もGW前にやった気がします。

自分くらいのレベルだと、こういうの書いてる暇あればコード書けって思われそうな気がしてついつい控えてしまいますが、特にC#とかほんとMSDN読んでもあてにならないことも多く、こういう善意で発信された情報に支えられたと思っているので、今度は自分も貢献したいと思う気持ちは強いです。

エンジニアやってていいなーと思うのは、大して価値があると思えない知識の有無で無駄に削られたりしないことです。属人的になってしまう部分やさすがに公にできない情報ももちろんあります。それでも、根本はオープンな情報の元でコミュニテイが存在し、オンライン/オフライン問わず門戸が開かれているという世界はほんとに好きです。好きです。好きです。

総括

というわけで、

職業としてエンジニアを選んでほんとによかった

会社楽しい部活も全力でやった

会社組織の一員として解決すべき問題はあるのでそっちもがんばった

最後までやりきれなかったことも…………

そしてこの会社でエンジニアとして今も変わらず(よい方向にはもっと変われ)働き続けていられるのが昨年一番の成果です。

対外的な部分で判断してなんぼやろ、と思うのですが去年の目標はひとまずそこなのでよしとしましょう次元低くてさーせん。

one more thing

2015年振り返るという文脈でどう考えても欠かせないのがルームシェア。大学入学と共に東京に引っ越し一人暮らしを始めましたが、縁あって1月半ばから3人で暮らしています。

2014年からプログラミングを教えてもらっている師匠と、一緒に教えてもらってた人です。

いろいろ思うところはあるものの、まとめると意外にもこんな感じで変わりはありません。

『ぼくは明日、昨日のきみとデートする』を読んで

7月の頭に書いた読書感想文でですが、人が大切だと思う感ってこんな風なんか…と今更ながら気付かされました。

全員プログラムを書いたり、エンジニアリングをしたりする人なのでそっちの話をするのが筋かもですが、より強く思うのはこっちです。

そういう感じの話も別の機会にできたら嬉しいです。

 

2016年

1年スパンで目指したいことを。

エンジニアとして

「エンジニアとして具体的に直近こうしたい」は11月〜12月で書いた通り10月からのプロジェクト、より体制として確立させることです。

その他は、

「ニャンちゅう圧倒的にこれできないからこのプロジェクトはなしかなぁ」をなくす!!!

です。

そういうと語弊しかないので言い直すと、フロントもちゃんと書きたいということです。

サーバサイド満足に書けないし、設計もできない、言語の周辺も知識/経験すべてが不足しているのはわかっているけど今年はそこなんとかしたい。

フロントに限らず、QAテスト的な文脈やいろんなプラットフォームで使えるクライアントアプリという文脈でJavaScriptと真剣に向き合いたい。

あと、クライアントアプリ書いたよしみでandroid触りたい。

API整備できる人になりたい。

他の細かいところはこの記事に書いたのとあんまり変わってません。

転職して10ヶ月、内定もらって1年が経ちました。この1年で何が身についたんでしょう?

ただ、1年大枠としては

  • JavaScriptと真剣に向き合う
  • android触る
  • API!

というのをやっていきたいです。バックエンドとフロントエンドちゃんとつなぎたい…

このやり方即戦力にはなれなさそう…と思いつつ、今そういうプロジェクトに携われたら勢いでどうにかなるという思い込みも込みでこの順番でやり直してます。

JavaScriptの学習本をレベル分け!入門、中級、上級全6冊

過剰な苦手意識とこれまで学んだことを活かして概念に馴染むところから。

最新動向は社内の圧倒的革命家たちの記事とコード読みながらいつの間にかキャッチアップします。

音楽

昨日振り返り、思い描いていました。こんな感じ。

ギターを弾く、ピアノを弾く、ミスチルを歌う、今年1年の音楽を振り返る

元気ハツラツ90年代をたくさん歌うこと

久石譲さんの曲をピアノで1曲ちゃんと弾けるようになること

心の底から歌い、届けること

以上!

人間として

人としてですね。大学のときから1年に1つテーマ的なものがあったんですが、昨年は定めず?定められず?でした。

今年のテーマは「許す」です。

昨年は楽しいことがとことん楽しい1年だっただけに、イラッとすることはほんとにイラッとしてた気がします。今でも思い出すだけでいろいろとイラッとします。体調まで崩すのほんと誰得。

とはいえ、イラッとしたところで結局状況は何一つ変わらなかったし、その環境から別の環境に移動するのに腐心するくらいならもっとエンジニアリングや価値の創出に集中したいので、受け入れも対峙もせず、ただ「許す」です。

きっとその状況の中で自分だけこんな思いして飲み込まねばらないのか…とか考えると思います。いや、きっとなんてことはなく絶対思います。

駄菓子菓子、この記事を読んで吹っ切れました。

【岩田 聡氏 追悼企画】岩田さんは最後の最後まで“問題解決”に取り組んだエンジニアだった。「ゲーマーはもっと経営者を目指すべき!」特別編 –

岩田さん、エンジニアとしてすごいのは別に誰が見てもそうでしょうという感じなのですが、とことん問題にフォーカスする姿勢、記事の最後のページに出てくる

「志向性が違えば衝突するのは当たり前です。それをわざわざぶつけさせるやり方を取るのが悪い」みたいに発想して,一つ一つ問題を解決していくんですよ。

というのに痺れました。社内にもその辺含めてすごい尊敬する人がいます。直近プロジェクトが無事乗り切れたのもその人に認められたいみたいな感情があったことは否定できません。

というわけで、外面としては「問題にもっとフォーカスして解決できる人になる!」ということにしておきつつ、その前提として「許す」ことができる人になりたいです。人間への闘争。

 

最後に。仕事はもちろんですが、プライベートでも本気出して幸せな感じの1年にします。

今年もよろしくお願いします!

11月1日

に書いたことにしとこう。

内定もらったのがちょうど去年の10月28日(火)23:22。電話にて。条件付きではあったものの、ただただ嬉しくて師匠にすぐ連絡した気がする。

それはおいといて、そこから実務でエンジニアとしてやっていくための準備が始まりました。

bsPAK86_codeing20140517

それまではCakePHPとjQueryとRailsをほんの少し触っていたものの、いざ業務となると話は別です。

内定もらってすぐ会社に行って、こんな本読んだらいいよ!みたいなのを教えてもらって修行が始まりました。

いわゆるfreeeへの闘争というやつです。

前職では引継ぎや挨拶回りした後有給に突入し、それから入社まで大体の時間は課題図書を読んだり、ものをつくったりして過ごしました。

今回はこの1年で
・どんな勉強して(何読んで)
・何ができるようになって
・何ができてないのか

を書きたいと思います。業務より少し広い範囲でエンジニアとしての道のりを定点観測する大事な時期だったり。

入社前の課題(11月〜1月半ば)

内定とほぼ同時に言い渡された(表現的に受け身ですがとてもとてもありがたかったです)課題図書、3ヶ月でマスターしようシリーズ。

毎週会社に報告に行ってKPTを振り返り、今週はこんだけやります!って宣言してまた次の週、みたいなのを繰り返してました。

そのときの内容、Evernoteに「精神と時の部屋@freee」ってタイトルで丸々残っててそっ閉じせざるをえなかったです。

Webサイト

Railsチュートリアル4.0版
jnchitoさんのRspecに関するQiitaまとめ
Railsガイド

書籍

Everyday Rails

ものづくり

・二次会会場検索
・端末管理システム
・書籍管理システム

まず最初の1週間でRailsチュートリアルをやりました。実質4日くらいでひーひー言いつつ…。

途中から全然わからなくなってきて、でもこれ次行くときまでに最後まで動かせんかったら未来はないと思え…みたいなテンションでとりあえず出てくるエラーを潰しつつ最後までやりました。

結局半年くらいで4周写経しました。

1周の写経と写経の間にいろんな知識が身についてて(Rspec勉強する時期がったり、都度Rubyのメソッド調べたり)、やるたびに理解は深まってるのを感じたものの、最後に写経したとき、最後の方やっぱ難しいと思った覚えがあります。

1周目で
・マジRspecわかんねぇ
・RailsとRubyの境目どこだよ…

って思ったので、次に
jnchitoさんのRspecに関するQiitaまとめを読んだ上でEveryday Rails(Rspecのチュートリアル的な本の邦訳PDF。先に書いたjnchitoさんが翻訳)とパーフェクトRubyをやるという流れです。

こんな感じで特にわからないと感じた部分に関連する関連書籍を週3冊程度、それぞれ100〜250pずつくらい読み進めました。

11月末からは社内の端末を管理するシステムを設計して作り、Rspecも足してみるというのをやり、正月には書籍管理システムと作りながら年越しました。

バーコードリーダーでISDN読んで楽天APIをたたいて書籍名を引いてくる、というのをどうしてもやりたくて(こんくらいできないと未来はないと思えと思いながら)必死だった気がします。

1月からは業務も始まりつつということで、12月までに大体読み終えて(わからんものはわからんと割り切って)入社という形になりました。

当時通っていたプログラミングのスクールは年末でゼミが終わるということで卒業制作に勤しんでました。

こっちはこっちで必死で、
・食べログAPI
・GooleMapAPI
・ページ下部でクリックしたら上部まで戻るjQuery
・非同期通信
・UIの何かしらのライブラリ
をなんとか使いたくて、これはやる!って言ったものはとりあえず全部動かしたと思います。

結果できたのが、現在の近くにある飲み屋さんをマップ上に表示しれくれる、二次会会場検索サービス各参(かくさん)。※ふりではない

Github
各参

Qiita teamとか振り返ってみると、なんかすごい遠慮してる感じ…(1月半ば〜3月)

入社してすぐはあまりにもコード書けなくて、このままではあれですね的な面談を受けつつ社内向けの機能をリリースしたりしてた気がします。

private APIをいじって、クライアントも準備してみたいな感じでチームをまたぐ開発をしました。一歩一歩調べつつ。

コードの実行を途中で止めてデバッグする、というのを最初に教えてもらっていっぱい止めて動きを追いかけてました。

一方でどういう書き方がいいものか他社のコーディング規約を読んだりしたり、リファクタリングの本読んだりしたものの、
・cookpadコーディング規約

周りの人に相談してやっぱ手動かさないとどうにもならんよねってことで基礎振り返りつつとにかく写経してたっぽい。
・パーフェクトRuby(再)
・楽しいRuby
・パーフェクトRuby on Rails

あと、メタプログラミングRubyとか読んでて、よくわからんかった。

2015年10月10日に新版発売。

転職3ヶ月経った直後の記事、こちら

ただ、なんかこの辺りのQiita teamの記事1つ1つに空回り感というか、できない負い目みたいなのを感じられて胸がすごい苦しくなった。

まわりを頼れ!!!(4〜5月)

上でも触れたものの、なんかこうできない自分の負い目で過度に遠慮してまわりにあまりもの聞けないみたいな時期があって。

もちろんコード書くのはまだまだだったものの、それ以上に仕事のスタンスとしてある程度調べてわからなかったら周りに頼って聞く。自分で調べてどうにかするのが大事なんじゃなくて、ちゃんとリリースすること、聞くことを通じて爆速で成長することが大事やから!っていう話をしてもらった。

その流れもあって全社の朝会と社内イベント企画みたいの担当させてもらうことになった。

そこから少し肩の力が抜けて変わり始めた気がします。

この時期は
・Railsチュートリアルもう1周
・リファクタリング案件向けにEveryday Railsもう1周
Code SchoolのRubyシリーズ講座毎晩
・お決まりの書き方が知りたくてRails3レシピブック
Growing Rails Applications in Practice訳して読んだ
をやってました。

やることががらっと変わる(6〜8月)

紆余曲折を経てチームが変わりました。それまで馴染みのあまりなかったseleniumをたくさんたくさんたくたくさん触って、コードを書く量は少し増えたと思います。

それにプラスして、同じ技術を使って他のチームをサポートするコードを完全に自力で書き、その過程で技術選定もやってみました。

それまでは既存のコードに足して機能を追加したり、リファクタリングしたり、バグ直したり、調査したりと一から書くことはあまりなかったのでものすごい勉強になりました。

通常業務にもだいぶいい影響があったり、もう少しインフラ周りも勉強しないとと実感したり。

そのとき一番お世話になったのがこの本でめちゃくちゃ面白かったです。

それと、Railsチュートリアルよりももう少し実践的で具体的なサンプルあるもの写経したいと思ってこの本やりました。

プロジェクトでも目にするような設計になぜなっているのかシンプルな作りのものを作り変えながら進めていくのですごいよかったです。これはもう2周くらいしたい。

続編はKindleのみ。

あとseleniumの基礎とQAについて。

自分が主に育てていく領域をもつ(9〜10月)

新しいチームにも漸く慣れ始めてきたとき、それまで使ったことのない、型のある言語でクライアントアプリを書くことに。

わからないながらも短期間であほほど調べて何とかリリースを重ねるうちに、いつの間にがこれまでで一番大きな開発をやることになっていました。

まだ出たばかりのものを引き継いで、単にコード書くだけでなく拡張性を考慮して設計したり、修正のフローやサポートのしかたを考えていく楽しいプロジェクトです。

周りには何年もプログラミングを経験している人がいる中で思い切った開発させてもらうにはきっと社内に知見がそんなにない分野でもオーナーシップをもって諦めずにやりきるしかなくて、チャンスがあれば食い気味に案件取りに行くしかないと思っています。

そうやってもらった案件には愛着しかなくて毎日楽しいです。

最近はこの本も読んでて、本当に楽しい。

ある程度馴染みのある分野ならなかなか手を出せなかったJavaScriptとも仲良くなれるかも…という淡い期待があるからこその楽しみですが、QA的な分野にも活かせたらなぁなんて思っています。

ただ、やっぱりJavaScript書くならがっつりフロントやりたくてまだまだ距離あるなぁと感じつつ。

今の案件だとそこまでフロント書く感じではないですが、apiがっつり触れるタスクやらせてもらって詳しくなった上で、それ使いこなしてフロントへ…みたいな流れになるようお仕事もらおうと企んでます。

そういう意味だと.NETのWPFがけっこうイベントイベントしているので前よりは理解しやすくなってるのではとも期待しています。

身に付いたこと

という流れでこの1年で何が身についたんでしょう?

Rubyの基礎

・とりあえず今やりたいことは普通に調べて出てくる程度のメソッドでやりくりできる程度。
・メタメタしていると一切理解不能。

Railsの基礎

・処理の流れはbinding.pry挟みながら何とか追える程度。
・Railsコミュニテイで盛んな設計(formとかpresenterとかserviceとか)は何となく真似する程度。
・いやでも画面とかフロントエンド絡むと途端に手止まるなぁ…

まとめると、処理の流れは何とか追って既存のコードの真似して何とかコード書いているものの、設計思想とかパターンへの理解が曖昧で書くのも読むのもいまいち確信が持てない状態。

フロントはからっきしダメ。

直近身に付けたいこと

オブジェクト指向

・C#書いててどかっと新しい機能足すときに「ザ・オブジェクト指向」なところで完全に手が止まる。

設計

・こういうときはこういう設計するよね、みたいなの知りたい。
・なんでこういうフォルダの切り方するの?みたいなの普通によくあるデザインパターンだったみたいな事例があった。

フロントエンド

・この期待感を形にする

まとめると、少し実装は追えるようになったきたからこそなぜそうなっているのかを理解して自由度を上げたい。

身につけるべきこと

あれもこれも多すぎてもはや分野列挙することしかできない…
・CSS
・テスト
・SQL
・UNIX
・DB、モデリング
・git
・コンピュータのしくみ
・セキュリティ
・ネットワーク
・サーバ、インフラ

うわぁ…テストとCSSはさすがに情けなくなってきたので早めに…

まとめ

できるようになってきたかも…!みたいに思い始めてきたことって単にひたすら似たようなこと繰り返してるだけで以上でも以下でもないです。

だからこそ特定の分野は割り切ってその期間ひらすら没頭して成果を上げて、新しいことできる機会があれば絶対逃さないの繰り返しの気がします。

なんとなく全体感の中で足りないこと、足らせたいことは意識しつつ。

結局最高に気持ち良く没頭できることがしたい、できるようになって気持ちよくなりたいに尽きる。

10月18日(日)

転職してから9ヶ月とちょっと。そして何より面接を受けて1年が経ちました。

Wantedlyで話を聞いてみたい!みたいなのを押したらどこよりも早く返事がきたfreee。

早速オフィスに言ってカジュアル(半)に話を聞き、面接を受けてみることに、みたいなやりとりしてたのがちょうど10月の半ばでした。

当時、こんなサービス作って〜みたいな感じで話していたサービス、今コード見てみたら何書いてるのかわからないというか何も書いてなくてよくこれでエンジニアなるって言ったな!笑みたいな気持ちになる。

けど当方はそれでいて楽しくてしかたがなくて、先方はよくわからんが目を輝かせて何か言ってる若者に何かしら可能性を見出したんやからもうええやろって思う。

職業としてのエンジニア

営業(というラベルのついた何かしらの仕事)をやりつつ、週末や平日仕事から帰ってからコードを書く。人と一緒にサービスを育てる。

限りある時間の中で精一杯やってきたものの、これから仕事でやるのとまた違うはず。

学生を終えて社会に出る直前に見た、ビジネスも作れてプログラムも書ける人への憧れ。

会社から提示された条件は何の心配もなかったと言えば嘘になるけど、それ以上に自分の憧れるエンジニアになれるのか、職業としてのエンジニアに違和感なく没頭し続けられるのか。

そっちの方が遥かに本質的な関心事項でした。

1年経って

実際どうやろう。

まず仕事を仕事と感じずにしている感があります。

もちろん、リリースの日はリリースの日だし、サービスを守り、未来を築いていく責務はあります。

駄菓子菓子、かつてプログラミングに感じていた、小さい頃1日無心で組み立てたレゴとか、発表会の前だけひらすら練習したピアノとか、そういう類の没頭感。

週末プログラマーのときに感じたものはそのままに、体力的に問題なければずっと触れていたい程度には好きみたいです。

よかったよかった。

憧れ

エンジニアであることに違和感ななくとも、憧れのエンジニアになれているか。

9c88e25a5315273851e8b9c523d4e224_s

それは何重にもダメなところがあるなぁと思ってます。

「自分の手でサービス作れる人かっこいい!」という憧れは目指すには必要な要素が多すぎるし、具体的に考えてもないし。

「技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニア」になりたい!!とか言ってエンジニアになったものの、それが測れる程度に考えてもない。

それゆえ漠然と成長足りてないなぁとか思うのはそれ自体ダメダメやなぁと思うものの、1年経ったらもう少し色々できるものと思ったのも事実です。

闘争

だからこそ目の前のお仕事しっかりやる!分野好き嫌いせず!というのは当然としてプラスで色々やってみたいと思いやってたりやってなかったりします。

メンテ系のタスクが重なると、コード自体は書くしプルリクもいっぱい出すしで仕事している気になります。

エラーでサービス受けられない人減らしていくのそれはそれで大事。

でもより大きな価値を届けたり、エンジニアとして成長するにはそれだけでは足りない…

そういうわけでいろいろと。

・他のチームのお仕事請け負う
メインのタスクには絶対支障出さない!絶対!絶対出さない!!という(個人的な)約束の下で1つのプロジェクト。

メインのタスクと近い分野でも、そこまでの設計にする必要なかったり、そもそもメインのタスクのアーキテクチャってなんでそうやってるんやっけ?みたいなことを調べたり、技術選定したりしながらほぼ一から構築。

コード書けばとりあえずは目の前の成果が出るという劇薬的な性格も相俟って、最初の方は土日も朝手つけ始めて気づいたら夜だったみたいな感じでした。

7月末に声をかけてもらって、「試しでやります!やりたいっす!」と言ったもののほんとにできるかわからず、無理なら外部に…みたいな状況だったので、なんとか形にできてよかった。

新しく立ち上がったプロジェクトがいい感じに進んでいくのは最高だし、日常のタスクにもいい影響があって、何というか
ほんとにやってよかったです。

・予約管理システム請負
社外案件ですが、できないかなぁ?みたいな話があり。上のとは若干毛色が違って、一から設計して業務システム作って運用まで持っていくみたいな機会なかなかなさそう!的なもの。何があっても本業優先という条件付きで受けようとしたものの、当面は無料のシステム使うことになりいったんペンディング。

作りたくなりがちではあるけれども、ユーザが気持ちよくサービス受けられて事業運営がうまくいくのが本旨。無料システムが思うようにいかなければ改めて一から構築する意義があるし、そもそもの業務フローってどうなんでしょ?って話もシステムありきでなくできると思うので見守ってます。

・新しいプロジェクト
これはメインのタスクですが、自身の経験の無い技術を使用しているかつ立ち上がりたてのプロジェクトを引き継いでサポート体制含め作っていくみたいなプロジェクトにアサインしてもらいました。

数字を見て改善しながらサービスを作り、変え、大きくしていくってまさに自分がやりたかったことで、経験豊富なエンジニアがたくさんいる中で携われるとは思ってませんでした。

だからこういう案件が並びでは、何としても新しいプロジェクトはやり切って成功させたいと思ってます。

成功させた日には少しだけ憧れのエンジニアに近づいてる気がします。

前回の記事の最後に触れた次の目標はまさにこれ。

は?みたいなこともなくはないし、触れたこと無い技術ではまったときの絶望感はすごいけど、求めた場所で理想的な挑戦ができて幸せやなぁと思います。

ひと息

同じように自身のアウトプットに不足を感じている人がいて、話していたら、
今週はここまでできたらOKとか決めて毎週振り返ったら少しでも進んでる感もあって健全!自分を認めるのも大事!
というすごく前向きな意見をもらいました。

素敵やと思います。

ただ、週次のまとめで、あれ?今週俺なんもやってない風?みたいにならない程度の客観性も確保してがんばりたい〜

SIerの営業をやめ、職業としてプログラミングに携わるようになって半年が経ちました。

0db43aa2f298cce2c4d0302a4a02cfcf_s

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます

転職して3ヶ月が経ちました。もっと速く修正したい。

いや、経ってしまったとか、経たれた(受け身)とか、そういう感じです。

半年経って何ができるようになって、何ができるようになってるはずだったのにできてないんでしょう。

近況報告

まだ働かせてもらってます。

タスクの期限に間に合わなかったり、思うように価値を生み出せなかったりする度に明日自分はこの会社にいるのだろうか…なんてよく思ってましたが、その辺の心配はもう少ししたらいらなくなりそうです。

その部分は改めて来月くらいに。

6月の2週目から新しいチームで開発しています。

最初の1ヶ月を冷や汗かきながら過ごしたチーム、いよいよ会計に関わる部分に携わったチームに引き続き3チーム目です。

組織の形は会社が大きくなったり、集中すべき部分が新しくなったりするタイミングで最適なもの(を模索しつつ)変わり、人は柔軟に動く。

前の会社では配属以来2年以上ずっと全く同じ(周りは変わりつつ…)プロジェクトだったのでコントラストがすごいですが、もはや何にも動じなくなってきました。

もう何でもやります、喜んで!みたいな感じです。

最初は変化に対して、これからどうなっていくんだろう…みたいなことは多少は思うものの束の間で、行く先にはチャンスしかないことを知る。

まだまだ改良の余地があったり、仕組みが整備途上のものだったり、自分がやり遂げることですごい喜ぶ人がいる。

「もう何でもやります、喜んで!」という言葉は別にそう思ってなくても言えるし、本心でいつかそう言えたらな、みたいな思い出無理無理口にすることがずっとずっと前にはあったかもしれないけれど、今は本心で言えるなぁなんて思います。

フォーカスすべきこと

何でもやるし、誰でも人が喜んでくれたらそれはとても素晴らしいです。

大事なのは、最終的に生み出される価値です。

駄菓子菓子、やっぱり、何でもよくないと思っているし、誰でもよくないと思っているのだと思います。

ただ、それが合理的にであり得るのは、そういう選り好みをすることによって人がより喜び、その喜びと自分(たち)の手段がよく結びついているときだけです。

リスクをとって価値ある大きな挑戦をしようとしている人を自分も一プレイヤーとして支えたい。プレイヤーとしてはエンジニアとしていられたら最高。みたいな感じです。

この自分の核のようなものは本心も含まれているのだろうし、判断基準がほしくて半ば強引に標語化しているところもあるだろうし、脆い。

特に「エンジニアとして」の意図するところが曖昧すぎて大事な部分ですごく判断がぶれています。

というのは、自分の思うエンジニアとしての行為が思ったより発達が遅い負い目のようなものがきっとあること、そもそもエンジニアとしての行為に対する思想な未熟なことがあるのだろうと思っています。

エンジニアって何?技術って何?

エンジニアとして生きる!なんて言うものの、プログラミングは没頭出来てめっちゃ楽しい!くらいの感覚しかないたぶん。

それでも、求める結果を得るための手段自体が没頭できるものであれば、最終的にその手段で生み出せる結果が他の手段でやるよりも高くなると期待している。

期待しているというか、わからないので試しているという状況です。

好きなことやってる方が生命としていきいきしているし、直感的に成果は高くなる気がする。けどそれは直感でしかない。

ただ、それを手段とする、と言っても
・その手段で何をやるのか(アプリを作る、インフラを支える、テスト体制を作る、エンジニアの生産性を高める)
・どの程度頼るのか(ツール作る程度、コードで息をする、運用でカバー、ドキュメントや会話でカバー)

とか、やることなすことものすごい変わる気がする。

今自分は駆け出しだし、とは言え半年でこれというのはちょっと出直してきた方がいい気もするし、人と話すのもドキュメント(文章)を書くのもすごい好きだし、意識しなければコードバリバリ書けてハックできる人、には絶対ならないと思う。

それでいいのか?それでも人が喜べばいいのか?

結果を求める手段としての技術との距離感を測りかねています。

単に技術技術ーと言っていても厳しそうなのは下の記事を読むと如実に感じます。

まつもとゆきひろ氏が「生涯プログラマー」でやっていきたい若手に贈る3つの言葉【特集:エンジニア育成の本質】

さらに、「プレイヤーとして生き残るために必要な3つのこと」読めば技術技術ーとかでわけわからなくならないだろうし、本来の目的だったり、そもそも解決したいものは何か、解決することで人はどうなるのかにフォーカスすることがよさそうというのが伝わってきます。

その上で新しいことはそつなく使いこなして、前提としてコンピュータサイエンスやれと。

コンピュータサイエンスって何の捻りもなく何だろう!!!

自分がフォーカスすべきこと

以上を踏まえて自分がとるべきスタンスを考えると、
・まずはどうあってほしいかを考える
・それを達成するための手段を選ぶ基準として、「今はやや技術に重みをつけて」考える。安易に「ドキュメント書けばなんとかなる!」とか、「根性でなんとかする!」とかしない。
・基礎なるものを身につける。やってるときに焦らない焦らないって10回言う。
・そのときそのときの中核技術をとことんやる。たとえばselenium使うならseleniumラップしたメソッド使うだけでなくで、そもそも何で生まれたのか、どういう実装があるのか、とかまでたどる。

みたいなのがいいと思いました。

技術だけで生きるなんて言えないし、技術だけで生きるのは幻想なんて言ってたら技術身につかなさそうだし、今は多少遅くなっても技術力を高めるべき。

悩むのおしまい。

今年の目標

毎年設定してるはずなのに、今年はしてない。きっとする余裕なかったんやと思う。

そう思いつつも、きっと会社の一員(少なくとも形式的な)として認められることだけ考えていたはず。

次は「これ主に自分が技術駆使してやりとげました!」みたいなのを新しく作るというのをやりたい。

闘争は続く。

6月7日(日)

27歳になりました。毎年、年末年初と誕生日には振り返り、先のことをなんとなく考えるので則ります。

エンジニア編

この1年間

26歳なりたての記事、とにかくワクワクしていて楽しそう。

初めてスクー登壇(ってほどのことはしてない)した日でもあります。

26歳で見えたこと、見えないこと(前編)

26歳で見えたこと、見えないこと(後編)

まだブログ書くの楽しいー!って言いつつ、初めてのサービス開発にひーひー言いつつも、何もかも自分たちで考えて、自分たちで作り上げることにただただ没頭していました。

目標に掲げてた、3つサービス作ってダルマに目を入れるというのもやりきったっぽいです。

そこから1年経った今、職業プログラマーとして目下修行中です。

自分が没頭できるのは何か考えた結果、それはプログラミングだというところに落ち着いて、それが趣味にとどまらず職業になりました。

SIer企画営業をやめ、クラウド会計ソフトのfreeeでエンジニアとして働きます

なんて幸せなことなんだろうとつくづく思います。

エンジニアとして目指すもの

個人の趣味としてやるにはマジ楽しい!ヤバい!でいいのかもしれません。

駄菓子菓子、人と、チームの一員としてサービスを作るにはチーム開発もできないといけないし、自分が楽しい、だけでは当然済みません。

自分の外、対外的に価値がないとダメです。

その上でエンジニアとして何を目指すのか。

記事では、「技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニア」って書いてますね。

・作れって言われたもの作れるのは当然として、どうあるべきかを考えて設計して実装に落とせる
・ダメな部分はユーザの反応(数値)を見た上で変えれる
・ビジネス的な数値を追いながら変えていける

とかを意識してのことだと思います。

目指したいですね。でも、それに必要な技術要素を列挙して、逆算して、身につくように取り組む案件や使う技術を調整する、というものでもない気がします。

今はただただエンジニアとして存在する理由がほしいです。

新しいチーム

6/8(月)から新しいチームの一員として働きます。

一時的なアサインになるかは状況によって変わるかもしれないけれど、そこでいい仕事したい。

そこで身につけた技術をその次(?)のチームで活かして、もっともっと意味あることがしたい。

言葉にすると本当によく耳にする言い回しになってしまうけれど、

・今目の前にある、まさに必要とされることを何でもこなせる
・今の体制では手薄になってしまう、けれどもみんな必要と思っていること部分の仕組みを一から(とは言わなくても「自分がやったった」って言えるくらいの貢献度で)作りたい
・特定の分野と、逆に誰もやってないけど誰がやるといいやろう?みたいなときにアイツや!って声かけてもらえるようになりたい

という姿を目指したい。

「自分はこういう分野をこう作りたい」は、上みたいな姿勢で取り組んだ末に特に力を発揮できる分野として見つかればいいし、足りないことを分析して課題としてまとめ、それを「技術」で解決していける人みたいなポジションも素敵。

技術的な視点(実装まで考えられてはじめて具体的に判断できるような視点)で組織を見て変えていくことができるみたいな人もいたら役立てるのでは。

目の前のことに没頭できる(没頭できることに取り組むことができる状況に身を置いた)からこそ、その先にどういう価値を生み出すべきかは引き続き考えて実践していこうと思います。

思い通りに進まなかったり、自分が触っている部分・技術はどれだけ局所的なのかだったり、周囲を見回したり、なんやねん自分って腹立たしい毎日やけど、エンジニアリングも会社もほんとに楽しいのでどないかなると思います。

27歳はCTOが起業した歳でもある。

音楽編

2年半ぶりのミスチルのアルバム、久々に観に行ったライブで、やっぱりミスチルはバンドでやりたい!という思いが強まっています。

REFLECTION、すさまじい完成度。

音楽面でもこの1年で大きな変化がありました。

ミスチルという呪縛の向こう側にある音楽

無理に高い声を張り上げるのをやめることで秦さんの歌を歌う。

そして、新しい歌い方でまたミスチルを…というところに差し掛かっています。

新しい歌い方だとどうしても弱々しくなってしまうので、それをなんとかしつつ、曲毎に調整していきます。

年末までに5曲(ミスチル)、さっと歌える引き語りのレパートリーに追加できていたら最高というところでしょうか。

ピアノ

たまたま歌・ギターを練習するブースにピアノがあったので数年ぶりに触ってみたらとても気持ちよかったので、寝る前とかにヘッドホンつけて触るようになりました。

年末には1曲引き語りでライブ出れたらと思います。

あと、久石譲の曲、1曲しっかり弾けたら最高ですね。

ルームシェアのこととか、たまには旅したいとか、改めて奈良の家族大事にしたいとか挙げればきりがありませんが、機会があればまた今度!