STORES.jp(hey)に入社して10ヶ月が経ちました
背景
最近、チームの内外でSTORES.jpの入社後の記事を書くのが流行っていて、自分も最近の心境を言葉にしてみたいと思ったので書きます。
前の会社の人からも転職記事を見てみたいと言われていて、その人たちへのメッセージでもあります。 全く違う文化が東京にはあってそこにいてこういう風に感じているということを伝えられれば、少しは離れてしまったことへの恩返しになるのかなという気持ちもあります。
他のメンバーの記事はこちらです。
また、フリーランスの方もチームについて書いてくれました。ありがたいです。
書きたいこと
特にフロントエンドの仲間は現状の会社の仕組み、チームの仕組み、チームの雰囲気について書いてくれました。 会社の宣伝が必要なタイミングで必要な記事を書いてくれる優秀な人たちだと思います。
みんなが書いてくれたことを繰り返しても仕方ないですから、自分としてはその行間を縫うような個人的な体験について書こうと思います。
自分が体験してきたことを通じてチームの根本的な考え方だったり、あるいは技術者としての成長、転職についての思いが伝わればいいなと思います。
転職の動機
前の会社への不満は特になかったです。 給与、待遇、仕事内容、人間関係、地理的なもの諸々の全てがよかったと思っています。
ただ、どうも関東の開発者は業務ではお客さんからの電話を取らずにひたすらプログラミングに集中できるらしい、毎日勉強会をしていてすごいスピードで成長しているらしいという話を聞いてどんな世界なんだろうなという気持ちが大きくなりました。
特に勉強量はそれなりだった自信があったので、プログラミング単体でも勝負できるのかなぁというのが気になりました。
ちょうど高校時代の同窓生に会ってそういう話を繰り返すうちに憧れが芽生えて、もしその世界を経験するには今しかないと思って、転職をしようと思いました。 STORES.jp(hey)は流行りのWeb系で、前の業務エンジニアとは対照的でとてもいいなという印象でした。
会社で経験したこと
違う文化に苦戦
転職自体が初めてだったので、どれだけのレベルを要求されているかわからずに色々苦戦していたような記憶があります。 仕事の仕方について色々考えながら、他の人の一人前になるべくとにかく真似したり、工夫したりしていました。
途中参加のプロジェクトに慣れるまで - How IT Works
特に驚いたのは「仕事は自分で見つけて、自分でやりきる」という文化だったと思います。 前の会社だと仕事を工夫するということは合間の時間でやることでしたが、STORES.jpのフロントエンドはあらゆることが自主性に任せられていました。
あとはSlackでほとんどの会話、コミュニケーションが完結するという仕組みが衝撃的でした。 隣にいてもSlack経由で話すということを理解するのに1週間ぐらいかかった記憶があります。
前の会社では疑問があると、すぐにペアプログラミングしながら会話していたので、電子情報で会話するという文化はほぼなかったです。
今は入社キットが整備されてきたり、積極的に新入社員にはサポートでつくようになったので、こんなカルチャーショックへの戸惑いは少ないと思います。黎明期だった気がします。
技術的な挑戦
転職の時に技術のことばかり喋っていたせいか、最初の頃は何となく技術担当みたいな仕事が振ってきていた気がします。 転職動機が技術最初の頃からKPTとかで技術面で気になるところを忖度なしに言っていたので、それならということで任されたのかもしれません。
やったのは共通コンポーネントと呼ばれるコンポーネントライブラリ作成です。 ここら辺はkskymst1さんが詳しいです。
Storybook、Webpack、Vue.js、Jestあたりの設定をごにょごにょしながら、仕事をしていました。 不安はありましたが、意外に何とかなったので当初描いていた『プログラマーとして通用するのか』という疑問について考えることはなくなりました。
デザインとの邂逅
共通コンポーネントを作っているとデザイナーと話をする機会が増えました。 ですが、自分は前の会社ではデザイナーがおらず、自分もデザインに自信がなく、コミュニケーションで一方通行になりがちでした。
他のフロントエンドチームのメンバーは割りとデザインの話をして意見を言っているので、自分ももっと対等に話したいなと思って勉強を始めたのがその次だったように記憶しています。
デザイナーの考え方、思想を知るのはとても刺激的で勉強したのはすごく良かったです。
エンジニアはコンポーネントをまとめようとしますが、デザイナーはユーザー体験を考えて、それが良くなるならコンポーネントを増やしてもいいと考えます。 そういう発想が知れて、やっとプログラマーではなくてフロントエンドエンジニアになれた気がしました。
見積もり問題とスクラム
共通コンポーネントを作ったので、次は本格的にリプレースをしようということで動き出しました。 しかし、端的にいうと全然見積もりが当たりませんでした。数字でいうと10倍ぐらい違いました。
これは次回のMeetupで話すので、終わったら詳しく書くかも知れません。 hey.connpass.com
簡単に書くと下記のような感じです。
- タスクの洗い出しが不十分でやるべきことが全て出ていない
- デザイナー、バックエンドとの要求の調整がうまくいっていない
- 数字を使わない開発者の経験で見積もりをしている
見積もりに必要なプロセス、前提知識あらゆるものがなかったと言ってもいいでしょう。
前の会社だとWBSベースだったのでそっちの方面がいいのかなという思いもありましたが、他のチームはどうもスクラムをやっているらしいので、そこからやってみてダメなら考えるということにしました。
それをやってみると、人が対面的に集まることが多くなり、上手く行くことが増えた気がします。 今まではSlack上で会話が多かったですが、フロントエンド、デザイナー、バックエンドの面々が対面で集まって、共同で同じものを見るという体験ができて、いろんな認識の齟齬が減りました。
それを企図してスクラムをやったというわけではおそらくないと思いますが、「場」ができて、それに数字を使った見積もりができるようになって、大分進歩したと思います。 大事だったのはオレオレスクラムではなく、とりあえず完璧なスクラムをやってそこから調整しようとしたことで、スクラムの恩恵をフルで受けれたように感じます。
スクラムを始めてからは結構、その仕組みの調整を頑張りました。
ルールを考える人
スクラムをやる傍ら、コーディングルール、テストのルール、あるいは新入社員向けのドキュメントを書く時間が増えました。 あとは、Meetupでdaitasuさんが話してくれると思いますが、フロントエンド全体の設計とかを考えていました。
これを見るとコーディングの時間が減って、他の人が働きやすい為に何ができるのかという視点で働いている時間が増えてきた気がします。
「仕事は自分で見つけて、自分でやりきる」という文化は色々なところにあって、コーディング、テスト、その他諸々の作業は各人の力量次第というのが個人的にはどうにも気になるし、自分一人で複数人が助かればそっちの方がチームのためになるしなぁという気持ちが大きいです。
これを見るとリーダーを志向しているみたいな感じがしますが、どうなんでしょう、今のチームは全員が似たようなことをしていて、開発だけしているという人は少ない気がします。
ただ、ドキュメントに興味を持つ人、タスク管理に興味を持つ人、コーディングに興味を持つ人、新技術に興味を持つ人がいて、それぞれが混ざり合って組織を作っているという感触が大きいです。
そもそも入社記事についても誰かに言われて書いているというか全員が自発的に書いています。後から聞いて驚くことが多いですね。
振り返って
プログラミング単体でも勝負できるのかなぁ、という疑問から始まった今の仕事ですが、この疑問についてはとうに決着がついていると思います。 振り返って見るとやっとフロントエンドの全体が見えてきて、足りないところは大分減ってきたのではないかなと感じます。
チームに関しては「仕事は自分で見つけて、自分でやりきる」に尽きて、情熱があり、守備範囲が広く、それに伴って求められる能力が多いという一文に尽きます。 入ってからずっとこの文化と良くも悪くも戦っています。
それにしても、東京のひとの情熱の大きさ、広さは本当にすごいですね。
今後やりたいこと
流れからしてこれからはマネージャーとかリーダーを目指すんだろうなぁという風に思われそうですが、別にそういった要求も必要性も感じていません。
今考えているのはルールで足並みを揃えるようにしているけど、それが通用するのは今の一瞬だけだよなぁという思いです。 人が増えて、メンバーが変わって、仕事が変わって、それでも残るものって何なのかなぁと漠然と考えます。
強いルール、強いリーダー、強いメンバーのいずれも今はよくても持続して行くものではないので、もっとあるかないかわからないような弱いルール、弱いリーダー、弱いメンバーで戦えるような何かがあってもいいのかなぁと。
今でも役割を聞かれても全部と答えるしかないような感じですし、色んな曖昧性を残しながらそれでいてしっかりとした線が通っているような自分、チーム、ルールが残って行ったらいいなぁと思います。
今まであった恩師はみんな静かで、弱そうに見えて、それでいて抑えるところは抑えていてみんなを上手く回していたので、これからは強い人ではなく弱い人を目指して頑張っていけたらなぁと思います。
宣伝
フロントエンドのミートアップが近々あります。現状埋まっていますが、スライドとかも早めに公開して行くので見たら面白いかもしれません。
テーマがバラバラで人を集めにくいなぁと正直思うのですが、今考えるとうちのチームはなんだかんだ皆が何でもやるので、どうしてもこうなるんですよね。 だから、これはこれでうちのチームのあり方を象徴していて面白いなと思うのです。
具体的な技術、プラクティス、解決策はどうでもよくて、なぜそうしたのか、なにが背景にあったのかに注目して見るのが個人的には楽しいのかなと思います。個人ではなく、会社単位でそういう発表をするのはなかなかに珍しいので。
デザインとの邂逅
デザインとどう触れ合ってきたか
前の仕事
前の仕事ではデザインは一緒に働いていたエンジニアが主にやっていました。
やりかたはたぶん似たようなデザインのサイトを探してきて、それに近い構図、テーマ、配色を持ってきて、それを微妙にアレンジするという感じでした。
自分はたまに色についてだったり、配置するコンポーネントの種類について聞かれて答えているぐらいで、興味もほとんどなかったです。
バックエンドだったり、フロントエンドのデータのフローをどうやってきれいに設計するかというのが好きでそちらにのめりこんでいました。
今の仕事
デザイナーとの出会い
そんな感じの人間なのになぜかフロントエンドが仕事の中心になっていて、デザイナーと一緒に仕事することになりました。JavaScript自体は好きなので、何とかうまくはやれるだろうと思っていました。
最初のデザイナーとの話し合いは確か、ダイアローグの余白と文章の見せ方がこれでいいかというもので、普通に中央寄せと余白を12pxぐらいとっておいてぐらいの助言をもらいました。
そこまで細かく見るんだと思いながらも、前のエンジニアもそれぐらいは考えていたので、正直なところこの時点ではデザイナーのすごさが実感としてありませんでした。
デザインシステム
そのあと、デザインシステムを本格的に作ろうというプロジェクトに入りました。
既存のデザインを色んなコンポーネントに落とし込んでいたのですが、細やかさの極致でした。
- フォーカスが入った時の挙動や、アクティブな挙動をすべて設定する
- 余白を何段階にも設定する(余白のpxも必ず8の倍数)
- コンポーネントの丸みも統一する
- 似通った色を統一しつつ、近い色でインタラクティブな挙動を定義する
- 使うアイコンの線の太さ、角度、雰囲気、余白を統一する
- PCとモバイルでフォント周りの設定をすべて切り替える
このうち一つ二つは前職でやった可能性はあったとしても、すべてを統一しようとは間違いなく考えなかったと思います。
これを見ると、自分はデザインしていたんじゃなくて、見た目で思い付きで整えていただけだったんだなぁと感じ、デザイナーすごい!という思いが出てきました。
ブランドイメージ
自分はまだ関わっていないですが、デザイナーたちの話のなかで、ブランドイメージの話がよく出てきます。
サイト全体をこういう風に印象付けたいから、ここはこうしたいとか。この画面ではこういうことをしてほしいから、こういうUIにすべきだみたいな話です。
先に書いたように前の仕事では何となく他のサイトの見栄えをまねしているだけで、統一感はあったものの、目的意識はありません。
ただ、コンポーネントをきれいに配置しているだけで、上から考えるのではなく下から考えている気配が強いかったんだなぁと今になって感じています。
デザインの勉強
デザインの方法
周りのフロントエンドエンジニアは結構UIに意見を言うことが多かったのですが、自分は思いついたことを言えませんでした。なぜかというと、何が正しいのかがいまいちわかっていないので、説得ができなかったからです。
だから、基礎的なところから本を読み直しました。
読んだ本
ここら辺の本を読みました。
『ノンデザイナーズ・デザインブック』は構図の整列の仕方だったり、強調の仕方だったりを教えてくれます。デザインの初歩の初歩にはいい本でした。
『フラットデザインで考える 新しいUIデザインのセオリー』はコンポーネントの目的だったり、思想を教えてくれる本で、ちょうどプログラマにとってはわかりやすかったです。
『インタフェースデザインの教科書』はユーザーはどういうふうにUIを見るかという心理学的な話がまとまっていて、抽象的ではありますが、UXって何?というところが少し感じられるようになりました。
デザインの思想
問題意識
デザイナーの手法とか考え方がずいぶんわかってきたなぁという段階になりました。その折に、GoogleのMaterial Designのガイドラインを見るといいよと言われたので見てみました。
それで事例みたいなものを見ていたのですが、驚きました。
ナビゲーションの遷移の発想と美しさ、コンポーネントの造形、配色しかたのどれをとっても自分に作れるとは思えなかったからです。
下のようなUIの事例集の本を見ていても、やっぱり自分の頭からこうしたデザインが出てくるのは想像できません。
ビー・エヌ・エヌ新社 (2018-10-19)
売り上げランキング: 13,670
実世界のデザインは基本的なテクニックのはるか先にあるように感じられるのです。
それでデザインに関係しそうな領域の本を色々と読み流しました。
読んだ本
もっといい本があるだろと言われそうですが、自分はデザインとは何かという根本的なところが知りたくてこんな感じのところに手を出しました。
これ以外にも色々本を読んで、とにかくデザインとは?というところについて考えました。
デザインとは何か
色々定義はありましたが、例えば「現在ある問題に対する最適な回答」といった定義が印象に残っています。
これに続く言葉は、問題を徹底的に観察して、新しい見方を探し続けること、というものでした。
配色について考えるなら、色を見た時に自分はどういう風に感じるのかを観察し、ユーザーを見るときはユーザーの言葉を聞くのではなく行動、環境を観察すること。
時間が変われば問題は変わり、その時自分はどう感じているのかを観察すること。
そして、それらに対する徹底的な洞察。
これを見た時に知識がないのが問題ではなくて、単に世界のUI、自分の行動、あらゆるものを観察すらしていない自分自身の態度が問題だったのではないかと思いました。
デザインは答えではなくそれを見る人、使う人への問いかけである、そういう言葉も見てとても腑に落ちたような感覚を覚えました。
フロントエンドとデザイン
コンポーネントで考える
何度か書いているようにエンジニアはコンポーネントに画面を分割して作り始めます。サイドにナビゲーションを置いて、こっちはメインで、こっちにはカードを置けばいいかというふうに。
デザイナーの人はそうではなくて、こう考えます。
ユーザーにどういう行動をしてほしいのか、そのためにはどのような感情の起伏をさせればいいのか、そのためにはどういう風にナビゲーションを設置すればいいのか。
その結果、ナビゲーションがいらない場合だったあるかもしれませんし、あるページ内のナビゲーションは他のページのナビゲーションとは違うかもしれない。
ユーザーは誰だろう。料理中だったら、タッチ数を減らしながら操作できないとだめだ、そもそもインターフェースは画面なのか? 音声のほうがよい?
こういう発想の違いは知識としては知っていましたが、最近ようやく共感できるようになってきました。
パーツの種類
Material Designを初めとするUIを眺めていて、色々なテキストボックスを見ました。
背景色が紫、読み込み中に罫線が点滅する、アイコンが中に入っているだけ、hoverで色が全く変わるもの……
こういうものを書き出してスケッチに集めてみると、数10種類はありましたが、自分の中では完全にBootstrapがテキストボックスの代表で、テキストボックスの可能性について何にも考えていないことに気づきました。
コンポーネントは再利用しておけばいいという考えがありましたが、本当にそれでいいのかと考えるようになりました。
生活とデザイン
デザインを勉強し始めて、生活もよりよくなるようになりました。
メモもKeepあたりに適当に箇条書きしていたのですが、スケッチブックを使って強調、配列、アイコン、その他もろもろを使うようになりました。
自分の頭の中をデザインとして整理することで、すごく色々なアイデアが出ますし、問題を分析することができるようになりました。配色の研究にもなります。
家の中もレイアウトや配置に慎重になり、自分の行動に対して一番短い経路にモノを置いたり、ずぼらながらも整理整頓ぐらいはするようになりました。
料理をするときもそうで、何が主役で何をサポート役にすえるかと考えることで、調味料のバランスなどをスムーズに考え付くようになりました。
トレーニングも自分の感情の起伏だったり、意味に応じて練習を分類・整理することで自信をもっていいという練習メニューを作れるようになりました。
残念ながらファッションは興味がないのであんまりですが、どうしてこの組み合わせなのかを見ながら考えたりはします。
デザインは生活自体に対する挑戦であり、問いであると思います。
まとめ
デザインという思考を取り入れることでとても新しい世界が開けたようでとても楽しいです。
設計は見栄えでしょうとか、センスでしょう、あるいはもしかしてロジックでやっていけばうまく行くんじゃないかと適当なことを考えていた過去の自分を説教したい気持ちです。
これからもっと自分の思考、自分の考えを見つめ直して、もっと本質的な可能性を問うていくようなそんな生活・思考がして行けたらとてもすてきだなと思います。
デザインの領域はアートだったり、編集だったり、音楽だったり、色々な領域にとびとびで学ぶことも多いですが、その分楽しんで生活できる日が続くんだろうという期待があります。
フロントエンドエンジニアになってよかったなと思います。
禅プログラミング
きっかけ
最近の仕事は難しい仕事が増えてきました。
例えば、あまり触ったことのないプログラミング言語のコードを読んだり、新しい機能のレビューを任されたり、新しいプロジェクトの開発環境の整備を1から作るなどです。
全く知識がないというわけでないので、頭をひねったり、多少調べれば解くことができるのですが、QCDが安定しないのでさてどうしたものかなと考えていました。
前の仕事では1つ1つのステップを設定し対策案を実施し、うまくいったら次に行くを繰り返す方法を習いました。
仮定を立ててそれを実証することを繰り返していればいいよというのは科学的で正しいとは思うのですが、時間がかかりすぎるので、このやり方には限界がありそうでした。
そういう問題意識を抱えていたところ、たまたま禅の本を読んでいて「自分を観察(=瞑想)すると仕事が捗るよ」という内容を見つけました。
面白そうだなと思って何気なしにやってみると意外とうまくいって、問題に冷静に当たれるようになってきたのでそれについて紹介します。
実務でよくあること
横道に逸れる問題
何か技術的な調査をしているときに、このツールをNPMで入れたらいいんじゃないか、という話を見つけます。
思考停止でそれをいれると、エラーで動きません。原因を調べると、さらに他のパッケージがないとエラーが出て動かないとか、バージョンが上がったら不具合があるよという様々な原因が見つかります。
そういう指摘を検証してやっと動いた!と思ったら、当初の問題を解決するものではなかったりします。そもそもうまく動けばいいほうです。
こんな風に技術調査をしていると別の問題がどんどん起きて、最初の課題ではないところに時間をとられて、時間が溶けていたりします。
また、業務で使っているSlackでレビュー依頼や別のIssueが挙がっていて、そっちを見ていると思考が流されたり、割り込みが入ったりで、気づいたら何をしているかわからなくなります。
検索がやめられない問題
こちらも技術調査でとにかく不具合があって直さないといけないということがあります。原因はとりあえずライブラリにありそうというケースを考えます。
最近だとStack Overflowに出てくるような問題の解法はあまりなく、どちらかというとGitHubのIssueにあることが多いです。
しかし新しいバグを踏むと、Issueで議論中で結論が出ているような出ていないような状態で放置されていたり、人によって違うことを書いていたりします。
こういう時に検索すれば答えがでるかもと思って調べていると、永遠に答えが見つからず辞め時を失うことがあります。
コードを見ればわかるといえばわかりますが、どれぐらいそこにコストがかかるのかを考えるといい塩梅というものがあるはずです。
禅
禅の正式な定義は知らないので何となくで言葉を使っています。マインドフルネス、瞑想、ヨーガとの違いはこの際、聞かないでください。この記事についてはすべて同じ意味で置き換えてもいいと思います。
シンプルに「自分の考えていること、自分のやっていること、自分の体の状態をすべて正確に観察するように努める」という意味でとらえてください。
具体的に言うと、自分がいまどういう感情なのか、自分が何に集中しているのか、その時体に変化はあるのかということに意識を置きます。
もう少し細かいことについてはこれから書いていきます。
やっていること
『いかにして問題をとくか』を考える
はるか昔に買ったはいいのですが、こんなの当たり前じゃないかと思って眠っていた本です。
本の詳細は書きませんが、問題を解くためのフレームワークのようなものが書かれています。例えば、
- 未知なものは何か?
- 与件(データ)は何か?
- 条件は何か?
などです。
今、技術調査をするときはこうしたことを先に大きく目につくところに書くようにします。「この関数が偽を返すことが証明できれば、不具合は必ずこのスタックトレース内にある」とか、そういう具合です。
レビューの時も反復作業系なら「抜け漏れがないことを証明する」、新機能なら「既存の機能に影響がないことを証明する」という観点をぶらさないようにしています(もちろん、意図は複数ありますが)。
この何を解いているのかということを基準に思考を観察していると、いつ思考が横道にそれたか、今どこまで調査が完了しているかが把握できるので、思考が散漫になることが減りました。
また、レビューでも自信を持って、問題がないということを言えるようになった風に思います。
他の優秀な方たちはどうしているのかはわかりませんが(脳内で整理できているのかな)、自分は紙に頼ることが今でも多いです。
感情を観察する
問題が解けずに2,3時間たつと、イライラし始めます。レビューで指摘されて感情的になることはありませんが、同時に修正が大量に来ると頭がかっとなることがあります。
できる限り客観的に対応しますし、外にも出しませんが、かといって仕事中に感情を消すことは少なくとも自分にはできそうにないです。
ただ、感情を観察するようになって、いつそれが出てくるのかがわかるようになってきました。
そうやってメタ的に見ていると、「あ、今頭に血が上ったな」「胸から上に重心が上がった気がする」という兆候がわかるようになってきます。
さらにそれを深めて「普段の状態はどんな状態だろう」「どこから血が上がったのかな」「この状態で思考するとどういう思考になるのか」という観察を進めていると、気が付いたら冷静になっています。
また、今自分は問題についてではなくて、相手によく思われることに注意を向けていたなということがわかると、自然に問題のほうに思考を戻せます。
つまり言い方を変えると感情を観察することで、問題と感情を整理つけてとらえることができるようになったと思います。
これはノートに書くよりも、適当にSlackで自分にDMを打つようにしています。そうやって外に書いていると何となく傾向が見えてきます。
Vimを使う
今はVSCodeのVimバインドですが、Vimは禅にとっていいエディタです。というのも、自分が今何をしているのか、何をしたいのかを正しく認識しないと、操作できないからです。
Emacsでもなんでもいいですが、Vimが顕著な気はします。
選択肢はどれだけあるか、今使うべきキーは何か、設定を変えることで最短を更新できないかなどを考えて作業することで、より禅の世界に近づけるという風に思います。
この分野は自分が語るほど強くなくて、周囲の人は、キーボード、画面分割、エディタの改造、シェルの改造、ブラウザの拡張などをかなりやりこんでいます。
いいエンジニアはそもそも自分のやっていることを把握しているものなのかもしれません。
やってみた感想
何かを考えるとき必ず他の人はどうしているか、ベストプラクティスは何かを探る癖がついています。
それも前職の思考のトレースに近いものですが、そうではなくて自分の軸を作ってそれに従う場面も必要なはずです。そこの優先順位が低いなぁと自分の思考をたどりながら、思ったりします。
そして感情が表に出ているときはパフォーマンスが悪いです。
悲しいはそもそもあまり思わない質ですが、怒りであったり、恐れ、焦り、あるいは愉快さであっても、明瞭に問題を解くときには役に立っていません。
「仕事は 楽しいかね」と最近色々な人に聞かれるのですが、うまく働けているときは問題のこと以外に注意が向いていないのでよくわかりませんという答えになります。
そのための環境は提供できていますかという意図の設問だと思うのですが、そこに入る過程は自分の注意力の向け方が正しいかどうかなので、自分自身の問題だよなぁと感じてやはり回答が難しいです。
自分は満員電車でもあまり苦に思わず、電車の揺れ、人の動き、体にかかる力などを味わうのが最近は気に入っているので、やはり心の持ち方次第ですとしか言えないです。客観的にみて、満員電車の環境がいいとは思いませんし。
今後
いかにも悟りましたという感じで書いていますが、実際は相変わらずSlackに注意をとられたりしますし、自席で仕事をしていれば紙やメモで頭を整理できますが、会話や会議になるとちょっと難しいところがあってまだまだです。
そういう問題に対しても深く観察して整理することで挑める部分もあると思うので、もう少し禅プログラミングを頑張ってみたいなと思っています。
RailsDM2019の振り返り(2日目)
前書き
前日に続いて参加したので書きます。
聞いたもの
操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践
論理削除や削除テーブルなど、操作履歴をどう残すかという議論でした。
最近はフロントエンドが中心でこういう議論を全然していないなと思いつつ、以前はここらへんのやつを大体試せる環境にあったので懐かしく聞いていました。
要求によりますねという当たり前のことしか言えませんが、バージョニングと更新サインで管理しているとテーブルの結合とかがとにかくしんどかった記憶があります。
プログラミングスクールを作ってみた
前に教育担当をしていたので、技術的なところに関しては詰め込めば詰め込めるというのはわかっていました。
なので、カリキュラム内容は充実しているなぁと思いつつ、同時に納得感がありました。
そこから先のビジネス的に利益になりづらいみたいなところは聞いたことがなかったので参考になりました。
ユーザー層も主婦や引きこもりの方が多いということで、知りませんでした。
How framework and buildtool handle webpack?
WebPackerやcreate-react-appなどがどうやってWebpackを扱っていて、どうやって拡張しているかみたいな話でした。
業務で出てくる技術ではありますが、比較して考えたことがなかったので勉強になりました。
ある程度ブラックボックスにしておいたほうが確かにアップデートの時に楽だなぁとは思いつつ、1度ejectしてあとは自己責任という態度はまさしくReactらしくいいなぁと。
Evolution of Enumerator
RubyのEnumeratorを使ったことがなかったです。Enumerableあたりでなんとかできることが多くて、そこまで使い込んでなかったので。
なので聞いた後でもEnumeratorはすごい便利!とは思いませんでしたが、Rubyのループ処理能力の高さとその実装方法が興味深かったです。
Rubyがブロックの中でループを打ち切る能力があるところとか意識してなかったです。よく考えると結構頑張っているのに、推されたことがないので意識してなかったです。
この発表を聞いたことでシンプルに書けることがありそうなので良かったです。
巨大なモノリシック Rails アプリケーションのマイクロサービス化戦略
話としてはシンプルで環境をDockerにしたり、マイクロサービスにしたよぐらいで見返すと難しい話は少なかったです。
ただコードベースがここまで巨大になった時にどうなるかというのは想像できない領域で聞いていて参考になりました。
スライドを見ていてもわかりませんが、実際に聞いていると基本的には技術的に解決できそう、という自信にみなぎっていてすごかったです。
まとめ
2日目は多様なテーマを聞きすぎていて、あまりこれだというまとめが思いつかないです。。
しいて言うと、1日目に比べると1度は経験したことがあるか考えたことがあるテーマが多かったです。
仕事でこういう解決方法をしてうまくいったなぁと思ってはいましたが、自分で納得して終わっていました。
知識の整理をしてみると、誰かにとって役に立つ何かがでてくるかもしれないなと思いました。
あとは、意外に普段話している会話の内容が意外に偏っている?感じがしたので、色んなテーマについて触れることを意識してもいいかもというところでしょうか。
RailsDM2019の振り返り(1日目)
前書き
業務の一環としてRailsDM2019に参加しました。その際にレポートの提出が必須ということで、忘れる前にメモしておきます。
基本的には自分の知らない分野に参加しました。
聞いたもの
"Ask Me Anything" by DHH
名前は知っていましたが、あまり本人が語っているのを聞いたことがなかったです。
「JavaScriptは塩のようなもの」「マイクロサービスは複雑さをもたらす」という持論を延々と展開していて痛快でした。
現在の仕事がフロントエンドな自分としてはあまり大きい声では言えませんが、SPAが過剰な分野はあると思っていて共感できる部分が大きかったです。
発言ではBasecamp社では……という前置きが多かったです。Basecamp社といえば、先日「NO HARD WORK!」を読んでいたので思い出せました。
あの内容も大体「最低限必要なことをやればいい。過剰にするな」という趣旨だったので、まさにBasecamp社の哲学そのものなんだよなぁと。
Railsへの見方が変わる講演でよかったです。
PR
こういうPRも軽い口調のところが多いのは意外でした。
採用目的が多かったですが、楽しさを強調するのがエンジニアにとっての福利厚生というとらえ方が多いのでしょうか。
行き過ぎ感と愉快さが半々ぐらいです。
OpalでつくるBrowserアプリケーション
OpalはRubyライクな記法で書けて、JavaScriptに変換できる言語らしいです。
詳しいことをあまり話していませんでしたが、Virtual DOM、Isomorphic、Web Socketあたりができるという話でした。
ここらへんに関しては、ClojureScript、Elmあたりも見てきているので、Virtual DOMやっぱりあるんだ、そっかぁぐらいの感覚になってきました。
IsomorphicやSSRについては確かに考えたことがなかったです。前に挙げた言語もできるのかどうか記憶にないので、そこまで調べてなかったですね。
見ていて何度もリロードしていて開発体験がよくなさそだったので、自分としては採用しない気配があります。勉強にはなりました。
Active Record Oracle enhanced adapterのこれまでとこれから
Active Recordの詳しいところは知らないし、聞いてみようかなぐらいのモチベーションでした。
中身はRails、OracleのDBに追従するためにどのような戦略をとっているか、というOSSのバージョニングの話が多かったです。
ライブラリを使う側としては早くパッチを……という気持ちだけがあって、作る側の意見を聞いてみると本当に大変だなぁというところで思うところがありました。
作る側からするとずっとRCの時からずっとリリース計画を見つつ、変更に追従しないといけないと考えるとすぐに出せるほうがすごいだけというのがよくわかりました。
破壊的な変更も仕方ないから入れるというところもあり、OSSの辛さとか作っている人の気持ちがよく伝わってくる発表で内容的にはエモくないはずなのに、とてもエモく感じました。
Power-Nap(ランチセッション)
聞き取りづらかったのと、動画の目的がよくわからず、不完全燃焼でした。
個人的には技術的な発表のほうが好きです。ご飯は健康的でおいしかったです。
What's new in RubyGems 3.0
www.slideshare.net
Gemが更新されているということ自体あまり意識したことがなかったです。なので、バージョンごとに破壊的な変更が入ることがあるということも知りませんでした。
細かいインターフェースの変更もしているということで、わかる人にはどんどん使いやすくなっているということらしいです。
ここもOSS開発の分業の仕方(フルコミッターがいるとか、セキュリティ担当者がいるとか)が印象に残っています。
SQLQL は GraphQL にとってなんなのか
www.slideshare.net
GraphQL を勉強中だったので、今ならよくわかるかもと思って聞きに行ったのですが、GraphQL の話していませんでした。
とはいえ、GraphQL の勉強をした際に、「なぜわざわざクエリ言語の再発明が必要なんだ。。」という気持ちはあり、同じ問題意識はありました。
中身はSQLを代わりのクエリ言語として使うというもので、結構DBの仕組みや扱い方を深く扱っていて面白かったです。
OSSというとがんがんロジックを書くというイメージがありましたが、結構他のライブラリやミドルウェアの仕様と戦うところが多く、見方が少し変わりました。
To make Ruby ready-to-use in the data science field. And the impact that it has on Rails applications.
データ分析領域でRubyを使うためにライブラリを書いているという話でした。
Apatch Arrowsというライブラリがあって、C++で書かれているそうで、それをCに変換してRubyから呼び出すみたいな話があった記憶があります。
実際にそのデータ構造を使うと、Railsが早くなったとか。
去年Ruby Kaigiに行ったときにひたすらCのコードが出てきていたので、そういう系統の話には慣れつつありますが、改めてRubyOSSのコミッターの強さを感じました。
万葉のRails新人研修のコードレビューコメントを分析してみました
最近、レビューに時間をかけているので何かヒントを、と思い見に行きました。
分析の手法や見方は好きだったのですが、分類や答えが何となく科学的というよりは、自分たちにとって都合のいい方法でやっている気がしてあまりうまく共感できなかったです。
それ自体が悪いというよりは、そのまま自分たちに流用できない気配だったので、自分たちの組織でやり直してみるのがよさそうという気持ちです。
"雑" / Almost Microservices
必要な設定は全部DBのテーブルに入れてしまえというのは前の仕事では当たり前だったので、すらすら入ってきました。
逆に今の仕事でこれもこれも、オンコードでいいんだと思うところが多くて、戸惑う気持ちがあります。RubyやJSはそんな文化を特に感じます。
テストの仕方や、ユーザーを絞ってリリースするという発想は面白かったです。難しさはありますが、覚えておきたいところです。
作って学ぶ RDBMS
理解できた気もするし、全く理解できていない気もします。
オープンソースとしてのDBは見たいなぁと思い領域でありつつ、C系統だしなぁとか、数学的なアルゴリズムが全開だとどちらにせよわからないし。。と思いながら放置していました。
聞いているとそういう心配はなく、読めるだけの下知識はもらえました。
小さく真似して書いてみるというアプローチも含め、OSSから学ぶ学習法を聞けて良かったです。
Thrifty Rails - How to run a production app on a budget
メモリやパフォーマンスを計測して、自力で直すとお金で殴るよりはいいよねみたいな話でした。
今日は難しい話ばかり聞いていたのでシンプルで聞きやすかったです。
パフォーマンス計測、メモリ監視、全部Gemで行けるよみたいなところで、驚いたところはあります。
特にN + 1問題について、Gemでチェックできるよと聞いてそこまでできるんだという感想でした。そもそもできると思っていないので、検索することもなかったです。
毎日の開発に役立つRailsプラグインづくりの秘訣
人が多くてびっくりしました。今日は人が少ないところばかりにいたので、このテーマでこんなに人が集まるんだというのが発見でした。
中身はRailsのコンソールでの操作が難しければ、WebをGUIにすればいいじゃないみたいなところでこれは盲点でした。
コンソールのWrapperを書くとしてもRailsは選びませんし、そもそもCUIで頑張るほうを選ぶのでその発想がでてこなかったです。
そういうわがままさと技術的な詰め方というところが何となく自分にない感覚が多かったです。
感想
OSSの開発者が普段なにを考えて、なぜ物を作って、どうやって技術を選定しているのかというところを知れたのがよかったです。
自分で作ってみたいという気持ちもありますし、使う側としても背景を知ることで理解や共感ができるようになったように思います。
周りにOSSを書いている人は少なく、本格的なものになるともっと少ないので、今日でだいぶ身近なものになりました。
今回はフロントエンド関係の話をあまり聞いていませんが、発想は活かせそうなので参加してよかったです(と書いたら同僚は納得してくれないだろうか)。
明日もおそらく参加しますが、がちがちのOSS系統は少なそう?なので、別の視野を広げられそうで楽しみです。
2つの文化、2つの世界
背景
これまで自分はシステム開発において、大きく分けて2つの世界で開発に携わってきました。どちらも要件定義~テスト、保守までかかわったことがあります。
前者はユーザー企業の業務系で主に業務改善に関わるところで、よく揶揄されるCOBOL、Excel、VBといういずれの文化を持っていて、古いIT企業のイメージを当てはめると大体当たっているような気がします。
ただし、新しいプロジェクトではC#(ASP.NET Core)、Angular、TypeScriptあたりを触っていたので、すべてが古いというわけではなく歴史的な問題も大きいです。保守対象が明らかに広いので、古い資産が残るのはどうしようもないです。
ユーザー数は最大で数千人ですが、基本的には事業部単位でシステムを組んでいたので、普段は100人未満ぐらいだったと記憶しています。
後者はWeb系で厳密なところは置いておいて、toCの会社です。持っているサービスはいくつかありますが、現状ではほぼ1つのサービスで収益を上げています。
こちらも一般的なWeb系のイメージで考えてもらえればよくて、フレックス、リモートが可能で、Rails、Nuxt.jsでゴリゴリ新機能を追加していくという感じです。
ユーザー数はアクティブかどうかは置いておいて、数10万という単位なので、少なくとも前者とは桁が違います。
前者にいた経験が長くてWeb系への憧れがとても強かったのですが、今少し時間が経ってきて前者の戦略に理解ができてきたので、その世界を中心に考察してみたいと思います。
ちなみに、会社(システム部門)の人数はどちらも100人足らずぐらいで同じです。
ユーザー系の世界
他のユーザー系の事情もそれなりに聞いているので、ユーザー系という主語が大きいのは承知の上ですが、いい名づけが思いつかなかったので、許してください。
開発技術の選定
選定ポイントはいくつかあって、まずは開発している組織が大きいかどうか、サポートを受けられるかどうかに大きな比重が置かれていたように思います。
データベースはOracleが最も多く、開発環境はVisual Studio、言語はC#、OSはWindowsです。Micorsoftとべたべたです。
実際メールで問い合わせをして確認したり、営業の方と話をする機会は多かったです。
ここにはグループウェアがOffice365で、新しい不具合を毎回踏まされるという事情もあるにはありました。ついでにWindows Updateによる影響も切実でした。
ライブラリ選定も基本的には大多数に合わせろ、です。なぜかというと、マイナーなOSSを使って将来的に更新されなくなった時に直す技術力がないからです。
個人的にはVisual Studioの機能の豊富さがすごくて、ほとんどの作業がGUIでできる経験がつめたのは大きい経験でした。
あのエディタのおかげで会社の技術力が底上げされていた感があります。Vimとか、VSCodeでは環境すら作れなかったと思います。
Microsoft縛りで辛かったのは認証回りと、IEがサポートから絶対に外せないことぐらいですかね。(あとはiPhone対応が辛かった)
もう1つあったのは、組織で技術を統一しようという文化がありました。プログラミング言語、ライブラリ、エディタ等々を全部統一して、勉強範囲と開発範囲を最小限にしようという考えです。
当時は反発がありましたが、戦略として今ではわからなくもないです。
社内ライブラリ
実は結構作っていました。プログラミング言語が統一されているのでスケールしやすかったのもあるでしょう。
あとは、技術力が高い人が数人いて、その人たちで他の人の分の作業をすべてするにはどうするかみたいな話があったように思います。
その結論としてできる限り、超高性能なライブラリを作って、それ以外の人は詳細をほとんど知らなくても済むようにしようというそういうプロジェクトがありました。
例えば、新しい管理画面を作るときは、テーブル定義をGUIで設定すると、自動でスキャフォールディングが走って画面の大体ができるみたいな仕組みがありました。
コンポーネント集もあって、それでほとんど賄えるようにしていました。
作っているのは数人で、使っているユーザー数はその10倍くらいいたんですかね。
ただ、中身をみると結構地道なコードで書かれていて、新しい技術は使わないという方針がありました。
なので、OSSをforkして作ったとかそういうことはしてないです。
コーディングの作法
ルールを作って縛る、これが大原則です。
Linterはもちろん、変数名のルールが決まっていましたし、画面ごとのメソッドのインターフェースも決まっていました。細かいことを言うと、テーブル名、カラム名も誰がつけても同じになるようなシステムがありました。
使える技術的な範囲(新しい構文は使わない)も制限されていて、これも優秀な人がレビューして、全部そろえるという原則がありました。
忙しい時は週末に出勤して1日中リファクタリングしている時もあった気がします。
ルールが世間一般と同じかというとそうでもなく、独自インターフェースみたいなものがあったように思います。
それはWeb、デスクトップの両方で統一された世界観でした。ここでも技術的な統一が果たされていました。
機能面
業務系はとにかくビューを作る仕事が多かったです。
作った画面の8割ぐらいは検索系でこんな見方をしたい、こんな出力をしたいという要望(最初はCSVですが、必ずExcelになる)でした。
ここも自動化が進んでいた理由になる気はします。
更新系の画面もありましたが、これは入力項目がひたすら多く、デザイン以前に並べるのがしんどかったです。
ユーザー系の会社だと入力項目をいかに増やすかという要望が大半だったかもしれないですね。
非機能要件については、パフォーマンス要件がかなり厳しくて、レスポンスが何ミリ秒以下みたいな基準がありました。
しかし、社内ネットワークから出さないことも多いので、セキュリティなどはそこまで厳しくなく、サーバーも1台あればさばくのに問題はなかったです。
要件定義、設計
人材の半分以上をここに突っ込んでいて、年長者は軒並みここに配置されているので力の入れ方が違います。
要件定義で数年というケースもあるほどで、どれぐらい正確にやるかというものでした。
こういう分け方をするということはアジャイルではなく、ウォーターフォールということですが、現実にアジャイルでは無理だと思います。
文化として納期の正確さ、機能の欠落が許されないところがあり、調査をかなり綿密にやらないとうまくいかなかったです。作りながらではやはりもれました。
業務を分析して、どこを直すと業務を直すかというのをフローを書いたり、というので専門性があったように思います。
技術と同様にその事業について詳しくないととてもではないが、口にだせる領域ではなかったです。
人材育成
基本的には新卒から育成でした。文系、理系も特に問わなかったので、対人能力と論理的に話せることあたりが採用方針だったと思います。
勉強熱心さはそこまで求められていなかったです。
ただ優秀な数人の半分ぐらいは外部でしたので、優秀な技術力を持つ人を育てることは最終的にできていなかったかもしれないです。
そもそも採用のための広報もほとんどしていなかったので、通年で応募が数十件もなかったです。
仕事の振り方
自分でどんどん見つけたことをやるというよりは、基本的な方針が上から振ってくるのでそれに従います。
もちろん新しい提案はしてもいいのですが、承認プロセスが結構上まで行かないとだめなことも多かったです。
Web系の世界
皆さん知っていそうなので、あまり詳しくは書きません(力尽きている)。
基本的には技術力志向が強いように思います。
レビューもありますが、それを踏まえても最低限のコーディングルールしか注意されず、機能面でのレビューが多い気がします。
開発環境はOSこそMa統一ですが、エディタなどは自由でVSCode派が多いですが、Vim、Emacsなど色々いるみたいです。
言語やライブラリはマイナーすぎるものは選びませんが、サポートなどはあまり気にしていない様子です。
特にフロントエンドについてはいざとなれば自分たちで置き換えたり、直したりできる技量があるので、よければ採用ぐらいの方針です。
社内共通ライブラリは今のところないです。改善する可能性は高いですが、前ほど大規模にやることはないように思います。
画面はコピーで作れるものも少ないのでスクラッチでコツコツ書くという形です。要件定義は誰でも参加できるので、自由に意見を言えます。
業界のルールや知識はありますが、ユーザー系ほど専門領域ではないです。
採用も今の段階では自分たちと同レベルの人をとるというのが基本方針です。
仕事も上からほとんど降ってこないので、自分たちで見つけてすぐに手を出すというやりかたです。
振り返って感じること
ユーザー系の企業のやりかたはシンプルで「技術は優秀な個人に任せて、他は専門領域で勝負しよう」です。
一方Web系の企業は「優秀な個人の数を増やして、全員が多くの領域に参加しよう」でした。
Web系で仕事をする前はとてもうらやましいという気持ちがありましたが、優秀な人のレベルは大きく変わりませんでした。
なので、もし前者で優秀な技術者が多ければ、下のような戦略を取っていた可能性はある気がしています。
Web系の企業は特殊な技術を採用すると人が集まりづらいのはあると思っています。個人の技術力の向上の機会を会社が提供することが一種の福利厚生になっているからです。
特殊な技術ができても、中途で他のところに移るのが難しいですからね。
どんな技術にも好きな人はいるので、そういう会社には行けると思いますが、幅となると辛いのかなという思いはあります。
そういうところで一般的な技術を使いこなしているのすごいなぁ、技術力が高いなぁと思って見ていたのですが、ユーザー系のやり方は一般的ではないやり方をしているだけで知恵がありました。
今のIT界隈は基本的には有名な技術を知っていることを技術力が高いと評価していますが、その評価は正当なのかなと思いを馳せます。
前の会社には技術力を上げたいと言って抜けさせてもらった手前、申し訳ないなという思いがあります。今はとても勉強になっていますが、ユーザー系の会社にとってはやりかたが違うので参考になる部分は少ないでしょう。
だから、自分がWeb系に入って優秀になったということはなく、ただ今のやり方の中から学べることを真摯に学んで、折衷点みたいなところを探したいなと思っています。
Perlに夢中
きっかけ
最近、Perlに目覚めてしまいました。
きっかけはMacbookで開発するようになり、ちょっとしたスクリプトを書かないといけない機会がぼちぼちでてきたことです。
これまでWindowsマシンで仕事してきていたので、何となく調べながらやっているとシェルスクリプトの話になって、そこから芋づる式にPerlに当たったように思います。
前に一度文法書を読んだ時はしっくりこなかったので継続していませんでしたが、今勉強し直すときれいに線でつながるようになり、とても楽しく学べています。
あと、「Let Over Lambda」でダグ・ホイト氏が学ぶべき言語に挙げていたのもあります(他はCとHaskellもあったような)。
やったこと
文法書を何冊か読んで、リポジトリをちらちら覗いています。入門書ではないですが、「Perl Hacks」がメタプログラミングとか、テスト駆動的なトピックも多くて面白かったです。
あとは、「初めてのPerl 」が入門としてはよかったです。
Perlについて思ったこと
機能が意外に多い
Perl6は機能がモダンになっていると聞いていたのですが、Perl5についてはあまり期待しておらずVB6ぐらいの印象を持っていました。Perlで関数型、Perlでオブジェクト指向という文章を見たことがなかったので、シェルスクリプトより少し書きやすい言語なのかなと。
調べていくと関数を値として渡すことも、オブジェクト指向的に扱うこともできました。
分配束縛みたいなこともできますし、タプル、ストリームに近いこともできますし、自分の中でモダンに近いと思えることは大体できました。
細かい差はあるのでコールではないのですが、どうしてこうなっているかという仕組みがわかりやすい分Perlのやりかたは気に入っています。
他の言語との共通点が見つかる
これがPerlを見ていて一番楽しいところです。
PHPは個人的に好印象ではなかったのですが、Perlの文法を見てからとらえ直すと「だから、こういうやり方になったのか」とハッとすることが多いです。変数の宣言もそうですし、スカラーという概念などもここから来ているのかというのを感じる瞬間がとても楽しいです。
Rubyは最初期ほどPerlの影響を受けていないと聞いていますが、それでも正規表現リテラルとか文字列の生成あたりにPerlっぽいシンタックスあったりして、そういうのを見つけた時、にやりとします。
Lispとの共通点で言うとダイナミック変数を使うところとかでしょうか。一時的に設定を上書きするというやりかたをPerlではそこそこ使うので、前に勉強したぞとなりました。
まだ、本格的に勉強していないですが、ソースフィルターをつかえばマクロ的なこともできそうな気はします。Lispほど直感的にはならない気はしますが、ハックとしては楽しそうです。
Perlの後付けオブジェクト指向も、Lispの後付け文法(マクロ)に近い感じがしますね。そういうことを考えるのが楽しい言語です。
読みやすい、書きやすい
Perlというと好きなように書けるので読みづらい、暗黙的なコンテキストに依存するから保守しにくいと聞いていました。個人的にはそういうハックは普通に好きなので、なんだそれ最高だなと。
とはいえ学んでみた感じだと、規則性もしっかりしているので慣れたらそこまで黒魔術ではないんじゃないかという気持ちです。何が起きているのかわからないということはないです。
RubyやJavaScriptでも黒魔術めいたコードをこっそり書く人もいますし、程度の問題ですかね。
Perlは言語学者が設計していて、読みやすく書きやすいようにしているという話があって、慣れてくると自然に読めるという意味でも完成度は高いと感じます。
基本的には大いなる責任が伴ってもいいので、自由に使える言語が好きです。
シェルスクリプトと同時に学べる
シェルスクリプトの延長に近い言語なので、今学ぶと相互的に理解できていいです。
今まで学んだ言語は抽象化されていてあたかも言語の機能みたいになっているところが、Perlでは隠されていなかったりするので、それが見えるのは面白い体験です。
今後とまとめ
文法やこんなモジュールがあるよ!というのを見ているだけで楽しいんですけど、もう少し深堀りしたいなぁという思いがあります。
リポジトリを何個かあたりをつけて研究しつつ、何か作るとすればコンソール系のスクリプトをさらさらと書けるところまで練習するつもりです。
まだまだ未知なことも多いので、一つずつ先人が切り開いた世界を見てみたいです。
あと、昔Perlを書いていたプログラマの人は今Goを書いているという現象を何度か観測しているので、そっちもどこかで手を出すかもなぁと思っています。