How IT Works

プログラマーやっています。技術よりも人間学的なところが好きです。

Webエンジニアが効率よく成長をするために心がけるべきこと

こんにちは、STORES.jpのUI改善チームに所属する@dexia2です!

普段は文字通りUIを改善したり、古いフレームワークで書かれたページをリプレースしたりしています。

STORES.jp Advent Calendar 2019の4日目は、「Webエンジニアが効率よく成長をするために心がけるべきこと」というテーマについてです。

よく語られるテーマなのでハードルがなかなか高いですが、経験を交えながら頑張って書こうと思います!

要約

  • 書を読む際は心を虚しくして、熟読すべし
  • 博く学び、問い、思い、弁じ、行うことを通じて、道を明らかにする
  • 知っていて行わないのは、知らないということ
  • 学の広さと深さを同時に求める

背景

この業界ではWebエンジニアへの要求が日々高まっており、学ぶべき領域は広がり続けています。 目にする情報量は増大し、学べば学ぶほどその広さに愕然します。

そうした背景からWebエンジニアは広く学ぶことへの執着を深め、何を学ぶべきか、新しい技術は何かについて探し続けているように見えます。

しかし、広い情報をいかに学んでいくか、についてよく語られている一方で、深い情報をいかに獲得すべきかについて語られることは少ないように思います。

そこで本稿では、生涯をかけて「いかにして学ぶべきか」を突き詰めた偉大な先人たちの論を振り返りながら、改めて学ぶことについて思索していくことにします。

論拠

中国思想

本稿では中国思想を元に論じていくことにします。
科学偏重の時代にあるからこそ、科学でない哲学体系から学ぶものは大きいですし、自分自身が実践していない哲学の論を述べることは誠実な態度ではないと思うからです。

中国の哲学体系は広範で捉えどころがないですが、本稿ではその中でも朱子学、中庸、陽明学の三つを取り上げます。

中国思想に抵抗がある方は「本を読む本」という書籍があるので、そちらを参考にしてもらえばいいと思います。 こちらは技巧の面から書かれていて、誰でも読みやすいです。

朱子学

朱子学朱熹(以下、朱子)が成立させた宇宙論まで含んだ巨大な哲学体系です。朱子南宋の時代にこれまでの中国哲学を省み、それらを統合するという計り知れない偉業を成し遂げました。
したがって、学ぶということに関して朱子より適した人物はいないのではないでしょうか。

中庸

中庸は朱子やその後の論争に当たってよく取り上げられる書の名前です。 成立自体は朱子よりかなり古く、作者もはっきりと確定していませんが、朱子学やその後の論争を振り返る際に中庸を知らずして語るのは難しいように思います。

陽明学

陽明学王陽明の論述を基に築かれた哲学体系です。 王陽明は元々、朱子学の徒でしたが、朱子学を突き詰めるうちにその限界に突き当たり、それを乗り越えるために新しい学を説きました。これが陽明学です。

本稿では朱子学を中心にした論を展開しますが、あえてそれを批判した陽明学を知ることで、かえって広く思想を理解することができるのではないかと思います。

先人たちの学び方

朱子学

本項では朱子の読書法を通じて、その学び方に触れていきます。

一つの書を徹底して読む

朱子の説く読書では、作者の心が自分に重なるまで徹底して一つの書を読みます。 一文字、一段の意味を追求し、その本がなくても書いてあったことが心に刻まれ、全て口に出して言えるという段階を求めます。

また、知識をひけらかすことをよしとせず、書の伝えんとすることを自分ごとのように理解するように努めます。読書は知識の追求ではなく、自分自身を追求することと捉えます。

論語」を読むときは「孟子」は存在しないと思いつめ、いたずらに本を読まずに、ひたすら丹念に繰り返し読むのが朱子の読書の特徴です。

心を虚にする

朱子の読書では一つの本をひたすら読むわけですが、その際は心を虚にします。 心を虚にするということは自分の意見を立てず、新説を立てず、著者の心に寸分の狂いもなく従うということです。

理解できないところも一字一字噛みしめながら読み、分かるまで読みます。 全体像がわかっても、詳細を理解するまで細心を払います。

全てを理解する前に自分の意見を先取りしてしまえば、学ぶところがなく、結局何にもならないというのが朱子の主張です。

中庸

中庸は学び方がよくまとまっている一節があり、そこから得るものが多いためそこに絞って紹介します。

学問思弁行

博くこれを学び、審らかにこれを問い、慎みてこれを思い、明らかにこれを弁じ、篤くこれを行なう。

「何事でもひろく学んで知識をひろめ、くわしく綿密に質問し、慎重にわが身について考え、明確に分析して判断し、ていねいにゆきとどいた実行をする」(『大学・中庸』金谷治訳)

中庸の学び方はこれらの学、問、思、弁、行の実践を説いています。 ただ実践するというだけではなく、学んでいないことがあれば十分になるまでやめず、分析していないことがあれば分析し尽くすまでやめないという徹底的な態度です。

朱子の読書は一つの書に集中し、自然に思いが湧いてくるまで読みふけるというものでしたが、中庸では学ぶだけでなく分析的、行動的な態度が強調されています。

とはいえ、それは朱子から見たときの相対的な物の見方であり、中庸自体の考えを素直にとれば、中国哲学らしいバランスを重視した思想という見方ができると思います。 学ぶだけでなく、問うこと、思うことが必要であり、さらに考えるだけでは不十分で、実践までしなくてはいけないというところは五行の思想に通じるものを感じます。

陽明学

先述した通り、王陽明朱子学を学んでいましたが、その限界に突きあたって新しい学問を開きました。 本稿では朱子学に対抗した陽明学の考えを紹介します。

ただし、陽明学朱子学の一部を問題にしているだけであって、朱子学の全体を批判しているわけではありません。

知行合一

朱子はどちらかといえば知が先立つことを考えていました。徹底して理を追求し、物事の自然とは何かを悟るまで学んだのちに行動するという態度を徹底していました。

しかし王陽明は自身の経験から、物事の自然は自分自身にあり、それは知の後にくるものではないということを主張しました。 これが有名な知行合一という考え方です。

陽明学の立場からすると、「知るということは必ず行うことに結びつくはずであり、知っていながら行わないというのはまだ知っていないことだ」と主張します。 どんなものでも自分が体験してこそ知ることができ、いかに語ることができたとしても知っているとは言えない、という態度は朱子、中庸の考えと比べてもかなり激しいものです。

事上練磨

知行合一と並んで陽明学でよく取り上げられるのは事上練磨という考え方です。 事上は日々の生活、日々の仕事のことを指し、練磨というのは自分の能力を磨くことを意味します。 これも読書、静坐につとめて学を深めようとした朱子に対抗した学説と捉えることができます。

静かな環境に浸っていても、いざ事に対した時に自分を見失うのであり、むしろ日常の中で培ったものが静かな環境でも生きてくると説きます。 知行合一と合わせて陽明学の行動学的な側面が強く伺えます。

先人たちから何を学ぶべきか

徹底して学ぶ

ここまで朱子学、中庸、陽明学の三つを取り上げましたが、いずれも広く浅く学ぶべきだと説くものはありません。 朱子は徹底した学を、中庸は徹底したバランスを、陽明学は徹底した行動を説いていますが、どれも苛烈で集中した態度を求めています。

学ぶための道筋はいくつかあるとしても、徹底して学ぶ態度がなければ深く道を悟るのは難しいのではないかと思います。

学ぶことに留まらない

中庸あるいは陽明学から朱子学を捉えるなら行動が弱いように見えますが、朱子も書を読むときは自分ごととして読まないといけないと主張しており、決して学だけを尊んでいるわけではありません。

それぞれが、自分の問題として学を捉え、その上でどのように自分を練磨していくかということを問うています。 また、中庸ではその手段として問い、議論、分別も挙げており、知ることは過程のうちの一つに過ぎないという見方をしています。

よって、学を極めようとするなら、知ることを前提としていかに自身を変えていけるかまで追求していく必要があると言えます。

いかにして学んでいくべきか

以上まで、先人たちがいかに学を捉えてきたか、そこから何を学ぶべきかについて論じてきました。 しかし、実際の問題に立ち向かうにあたっては、以上の議論は実践には不十分であり、朱子が論じるところの「自分ごと」として認識を深めなくてはいけません。

本項では、先人たちの学と自分たちの問題を繋げる接点について考えようと思います。

広さと深さの統合

科学から発した学問領域は全ての分野で拡大しており、科学の性質を踏まえれば今後もその傾向が変わることは考えづらいです。 かといって、深さのない学問は用に足らないため、学習者はこの矛盾した要求を成立させなくてはいけません。

矛盾の論理

この矛盾を統合する際にも、中国の哲学思想である陰陽思想が役に立ちます。 以前書いた記事が詳しいですが、端的に書けば「どんな時でも矛盾の関係はなくならないけれども、互いに助け合って存在する」というものです。

広さと深さにこの論理を適用すると、広さと深さは矛盾していますが、かといって広さと深さは独立して存在するものではないということになります。 ここから導かれる結論は、どちらも両立させるように調整し、どちらかを完全に無くしてはいけないということです。

基本的に中国の哲学の底には有りか無しかという二元論ではなく、割合を変えていくという発想が流れています。

初学と老練

具体的にこの問題を解決するにあたって、熟練度による切り分けがあると思います。 特に初学の段階であれば、ひたすら深さだけを追求しても仕事をなすことができないため、広さが要求されます。

そこで最初の段階であれば広く学ぶことを尊びながら、その上で深く学ぶ領域を少しだけ残しておくというのが良いかなと思います。 初学の段階を過ぎれば、そこから広く学ぶことを減らし、深く学ぶ方法を追求していくというのが現実的な解になります。

また、広く学ぶ中でも学、問、思、弁、行を欠かすことはしてはならず、知って終わりということはしないようにします。 ただし、徹底的にやり尽くすのではなく、広さを維持できる程度に行うというバランス感覚が大事です。

何を学ぶべきか

学問領域には深さを追求できるものと追求できないものがあります。 端的に言えば、具体的なものは浅く、抽象的なものは深さを持ちます。

良いコーディングスタイルを何かを知ろうとすれば追求が難しいですが、エンジニアはコードをどのように認知しているかという問いには深さがあります。 あるいはBOTの実装方法はこれまた単純な問題になりますが、良いBOTとは何か、BOTは開発業務をいかにして改善するかという問いを立てれば、深さに限りがありません。

したがって、学を深めるためには高い抽象に取り組み、それを実践していくことが求められています。 高い抽象、すなわち原理原則は科学の方向で論述されることが多いですが、哲学、東洋哲学などの思想領域にも高い抽象は存在します。

そうした学について朱子学、中庸、陽明学の学び方ができれば得ることは甚大になると思います。

STORES.jpはいかにして学んでいるのか

知行合一の重視

STORES.jpは、陽明学を遵守するような立場をとっています。 すなわち、知っていることと行動することに差異がない状態を目指しています。

レビューが溜まりがちだと感じたらすぐにBOTで状態を通知するようにし、テストのやり方がまずいと思えば体系的なテストの方法をすぐに適用するようにします。

行おうとする気持ちと行うことに差がなく、全員が今のこの瞬間を観察し、咄嗟に動いてしまう性格がチームをどれだけ良くしているのか計り知るのは難しいです。

読書会

また具体的な学習方法として、チーム・社内では時折、読書会を行っています。具体的な手順としては、下記のように実施しています。

  • 事前に書を読み、問いを立てる
  • 当日読み合わせ、問いに対して議論する
  • 自分たちを改善するための行動まで落とし込む
  • 著者の意図を汲んで改変はせず、できる限りそのまま実行する
  • 反省する
  • 自分の言葉で経験をまとめ、社内外で発表する

朱子学、中庸、陽明学のいずれの立場から見てもそれなりの学習方法が実践できていると思います。 内容としてはセキュリティだったり、スクラムだったりです。具体的なものもありますが、その中でも抽象的な原理にも着目するようにしています。

課題

陽明学を遵守すると前述したように、STORES.jpは何より実践を重視します。分からないことはやっていないから分からないのだと考えます。

一方で朱子学のような特定の分野に対する徹底した態度にかける面があり、一部ではようやく深い追求が始まりましたが、まだまだ広く浅くという面が残っています。

また、中庸が説くところの「問う、思う」よりも先に行動が来ることがあり、早すぎる行動が目立つように感じています。

よって、現在の学習態度に甘んじず、どうすればより深く学べるのか、背景にある根本原理は何か、についてさらに考え、実践していきたいと思っています。

まとめ

この記事は自分の失敗経験を踏まえて書きました。 以前は広さを求めて、知識と行うことが離れてしまい、学んでいるのに何も学んでいないような状態でした。 学の広さは十分になりましたが、遠くにいるエンジニアと差はまるで埋まらないようでした。

そこから思い直して、深さを求めながら実践を心がけるようにし、議論を行い、それを自分ごとになるまで言葉を練っていくというのを続けました。 幸い、会社の文化もそれに合っていたため、それが実現し、得るものは多大でした。

繰り返しているように、学ぶべき情報は依然として多くなるでしょう。 ゆえに枝葉と幹を見極め、より深い幹を涵養することがWebエンジニアに求められるのではと思います。

以上から、深く学ぶための哲学を理解、実践していくことが、結果的にWebエンジニアが効率よく成長していくことに繋がるのではと考えています。

広告宣伝

今回の記事はどうでしたか? 少しでも心に響くものがあったなら嬉しいです。

明日のSTORES.jp Advent Calendar 2019の担当は@thamamurです。

楽しみにしていてください!

参考文献

参考文献は以下によりました。

三浦國雄「朱子語類」抄

金谷治大学・中庸

守屋洋新釈 伝習録

要はバランス

背景

なんとなく界隈のなかで「要はバランス」という言葉に好意的でないニュアンスが広がっているような気がします。 自分自身は中国哲学の陰陽理論がとても好きでできる限り発想をそこに寄せている立場なので、「要はバランス」に対して誤解されていることに対して補足を加えたいと思います。

ここでは中国哲学の陰陽理論の解説を以って、バランスとは何か、誤解の元は何かを説きます。

出典

陰陽理論といえば『易経』がもっとも有名な出典ですが、理論自体が中国哲学の一部となっている感があって、色んなところにこの話が出てきます。

自分はどちらかというと武術のなかでそれを見ることが多くて、太極拳の『太極拳論』などを通して陰陽理論を体認しています。

なので、明確な出典から理論を持ち出していないことに注意してください。

あとは似た概念に五行、中庸もありますが、今回は紹介しません。

陰陽理論

すべてのものは陰陽でできている

この理論の基本的な考え方はすべてのものは陰陽でできている捉えます。朝と夜、男と女、火と水、長いと短いなどすべてのものは相対的に逆のものからなります。

例外的なものは存在せず、この陰陽の関係を理解し、助けていくことがこの理論の根本にあります。

動的平衡

陰陽はそれぞれ5:5のような印象を持たれますが、実際には完全な平衡を嫌います。この理論の背景は動的平衡であって、静的平衡ではありません。

陰陽理論の長である『易経』の易という漢字の意味は「変化」であり、絶えることの滔々とした変化を前提にしています。 その変化は陰が強くなればそれを補うように陽が強くなり、陽が強くなれば陰が強くなってそれを支えるというものです。

武術でも重心を5:5で固定することは居つくことになり変化が弱まるため、咎められます。 そのように陰陽の平衡はむしろ陰と陽を明確にするものです。あるときは陽が主で陰が従になり、次の瞬間にはそれが逆になっている、そういう動的な関係性を大事にします。

陰陽相済

すべてのものは陰陽でできていると書いた通り、完全なる陰もなければ完全なる陽も存在しません。陰と陽は支え合っているものです。 また、「陰極まれば陽となり、陽極まれば陰となる」というように互いの基となるものは同じで、陽は陰になるし、陰は陽にも転じます。

したがって、陰と陽は一見対立関係にありますが、一方で補完関係にあります。

他の概念との比較

近い概念にはトレードオフアウフヘーベン止揚弁証法)がありますが、これらは対立関係に重きを置いているように思います。 対立関係を強調し、それらを解決する第三案を出すという印象で、陰と陽の基は同じものである、動的平衡の中で常に関係性は変わると言ったダイナミックさはないように思います。

とはいえ根本にある原理をみると実用上はそう変わらないように思います。

なぜ誤解されるのか

陰陽の世界に絶対的なものはせず、全ては相対的なものです。具体的なものは全てその時点での陰陽の平衡であって、次の瞬間には別の形で平衡します。 なので、「要はバランス」おじさんになれば、毎回言う事やることが変わります。その時々で判断するのでどうしてもそうなります。

また、バランスという概念はどちらかが強くなればもう片方も強くなる道理があるのですが、なんとなく静的な平衡に捉えられがちなように感じます。 したがって、発展性がない議論、行動に思われがちです。ですが、バランスのない成長はなく、必ず両者が助け合って進んでいくものです。

あるいは今話題になっているのは対立関係を止揚して相補関係であることを発見したという言論ですが、対立するものが完全に相補関係だけになることはありません。必ず対立性・矛盾性が同時に存在します。 意見が割れているのは相補関係を強調する人と、対立関係を強調する人がいるからだと思いますが、それらは同時に存在するものです。

これらの哲学から、自分は「要はバランス」というのは一つの真理を付いていると考えるのですが、それが抽象的で捉えどころのないものだから、正確に認識されていないのではないかと思います。

ただ、自分は数千年続く中国哲学に傾倒していて、それを以って物事を認識しているので、西洋哲学、科学哲学、あるいは他のどこかにもっと素晴らしい哲学体系があって、そこから見ると間違った、偏った認識であることは否定できません。

とはいえ、自分としてはまだ中国哲学の認識が甘いので、もっと原典などに当たりながら認識を深めていけたらいいなと考えています。

STORES.jp(hey)に入社して10ヶ月が経ちました

背景

最近、チームの内外でSTORES.jpの入社後の記事を書くのが流行っていて、自分も最近の心境を言葉にしてみたいと思ったので書きます。

前の会社の人からも転職記事を見てみたいと言われていて、その人たちへのメッセージでもあります。 全く違う文化が東京にはあってそこにいてこういう風に感じているということを伝えられれば、少しは離れてしまったことへの恩返しになるのかなという気持ちもあります。

他のメンバーの記事はこちらです。

note.mu

note.mu

また、フリーランスの方もチームについて書いてくれました。ありがたいです。

blog.inouetakuya.info

書きたいこと

特にフロントエンドの仲間は現状の会社の仕組み、チームの仕組み、チームの雰囲気について書いてくれました。 会社の宣伝が必要なタイミングで必要な記事を書いてくれる優秀な人たちだと思います。

みんなが書いてくれたことを繰り返しても仕方ないですから、自分としてはその行間を縫うような個人的な体験について書こうと思います。

自分が体験してきたことを通じてチームの根本的な考え方だったり、あるいは技術者としての成長、転職についての思いが伝わればいいなと思います。

転職の動機

前の会社への不満は特になかったです。 給与、待遇、仕事内容、人間関係、地理的なもの諸々の全てがよかったと思っています。

ただ、どうも関東の開発者は業務ではお客さんからの電話を取らずにひたすらプログラミングに集中できるらしい、毎日勉強会をしていてすごいスピードで成長しているらしいという話を聞いてどんな世界なんだろうなという気持ちが大きくなりました。

特に勉強量はそれなりだった自信があったので、プログラミング単体でも勝負できるのかなぁというのが気になりました。

ちょうど高校時代の同窓生に会ってそういう話を繰り返すうちに憧れが芽生えて、もしその世界を経験するには今しかないと思って、転職をしようと思いました。 STORES.jp(hey)は流行りのWeb系で、前の業務エンジニアとは対照的でとてもいいなという印象でした。

会社で経験したこと

違う文化に苦戦

転職自体が初めてだったので、どれだけのレベルを要求されているかわからずに色々苦戦していたような記憶があります。 仕事の仕方について色々考えながら、他の人の一人前になるべくとにかく真似したり、工夫したりしていました。

途中参加のプロジェクトに慣れるまで - How IT Works

特に驚いたのは「仕事は自分で見つけて、自分でやりきる」という文化だったと思います。 前の会社だと仕事を工夫するということは合間の時間でやることでしたが、STORES.jpのフロントエンドはあらゆることが自主性に任せられていました。

2つの文化、2つの世界 - How IT Works

あとはSlackでほとんどの会話、コミュニケーションが完結するという仕組みが衝撃的でした。 隣にいてもSlack経由で話すということを理解するのに1週間ぐらいかかった記憶があります。

前の会社では疑問があると、すぐにペアプログラミングしながら会話していたので、電子情報で会話するという文化はほぼなかったです。

今は入社キットが整備されてきたり、積極的に新入社員にはサポートでつくようになったので、こんなカルチャーショックへの戸惑いは少ないと思います。黎明期だった気がします。

技術的な挑戦

転職の時に技術のことばかり喋っていたせいか、最初の頃は何となく技術担当みたいな仕事が振ってきていた気がします。 転職動機が技術最初の頃からKPTとかで技術面で気になるところを忖度なしに言っていたので、それならということで任されたのかもしれません。

やったのは共通コンポーネントと呼ばれるコンポーネントライブラリ作成です。 ここら辺はkskymst1さんが詳しいです。

logmi.jp

speakerdeck.com

Storybook、Webpack、Vue.js、Jestあたりの設定をごにょごにょしながら、仕事をしていました。 不安はありましたが、意外に何とかなったので当初描いていた『プログラマーとして通用するのか』という疑問について考えることはなくなりました。

デザインとの邂逅

共通コンポーネントを作っているとデザイナーと話をする機会が増えました。 ですが、自分は前の会社ではデザイナーがおらず、自分もデザインに自信がなく、コミュニケーションで一方通行になりがちでした。

他のフロントエンドチームのメンバーは割りとデザインの話をして意見を言っているので、自分ももっと対等に話したいなと思って勉強を始めたのがその次だったように記憶しています。

デザインとの邂逅 - How IT Works

デザイナーの考え方、思想を知るのはとても刺激的で勉強したのはすごく良かったです。

エンジニアはコンポーネントをまとめようとしますが、デザイナーはユーザー体験を考えて、それが良くなるならコンポーネントを増やしてもいいと考えます。 そういう発想が知れて、やっとプログラマーではなくてフロントエンドエンジニアになれた気がしました。

見積もり問題とスクラム

共通コンポーネントを作ったので、次は本格的にリプレースをしようということで動き出しました。 しかし、端的にいうと全然見積もりが当たりませんでした。数字でいうと10倍ぐらい違いました。

これは次回のMeetupで話すので、終わったら詳しく書くかも知れません。 hey.connpass.com

簡単に書くと下記のような感じです。

  • タスクの洗い出しが不十分でやるべきことが全て出ていない
  • デザイナー、バックエンドとの要求の調整がうまくいっていない
  • 数字を使わない開発者の経験で見積もりをしている

見積もりに必要なプロセス、前提知識あらゆるものがなかったと言ってもいいでしょう。

前の会社だとWBSベースだったのでそっちの方面がいいのかなという思いもありましたが、他のチームはどうもスクラムをやっているらしいので、そこからやってみてダメなら考えるということにしました。

それをやってみると、人が対面的に集まることが多くなり、上手く行くことが増えた気がします。 今まではSlack上で会話が多かったですが、フロントエンド、デザイナー、バックエンドの面々が対面で集まって、共同で同じものを見るという体験ができて、いろんな認識の齟齬が減りました。

それを企図してスクラムをやったというわけではおそらくないと思いますが、「場」ができて、それに数字を使った見積もりができるようになって、大分進歩したと思います。 大事だったのはオレオレスクラムではなく、とりあえず完璧なスクラムをやってそこから調整しようとしたことで、スクラムの恩恵をフルで受けれたように感じます。

スクラムを始めてからは結構、その仕組みの調整を頑張りました。

ルールを考える人

スクラムをやる傍ら、コーディングルール、テストのルール、あるいは新入社員向けのドキュメントを書く時間が増えました。 あとは、Meetupでdaitasuさんが話してくれると思いますが、フロントエンド全体の設計とかを考えていました。

これを見るとコーディングの時間が減って、他の人が働きやすい為に何ができるのかという視点で働いている時間が増えてきた気がします。

「仕事は自分で見つけて、自分でやりきる」という文化は色々なところにあって、コーディング、テスト、その他諸々の作業は各人の力量次第というのが個人的にはどうにも気になるし、自分一人で複数人が助かればそっちの方がチームのためになるしなぁという気持ちが大きいです。

これを見るとリーダーを志向しているみたいな感じがしますが、どうなんでしょう、今のチームは全員が似たようなことをしていて、開発だけしているという人は少ない気がします。

ただ、ドキュメントに興味を持つ人、タスク管理に興味を持つ人、コーディングに興味を持つ人、新技術に興味を持つ人がいて、それぞれが混ざり合って組織を作っているという感触が大きいです。

そもそも入社記事についても誰かに言われて書いているというか全員が自発的に書いています。後から聞いて驚くことが多いですね。

振り返って

プログラミング単体でも勝負できるのかなぁ、という疑問から始まった今の仕事ですが、この疑問についてはとうに決着がついていると思います。 振り返って見るとやっとフロントエンドの全体が見えてきて、足りないところは大分減ってきたのではないかなと感じます。

チームに関しては「仕事は自分で見つけて、自分でやりきる」に尽きて、情熱があり、守備範囲が広く、それに伴って求められる能力が多いという一文に尽きます。 入ってからずっとこの文化と良くも悪くも戦っています。

それにしても、東京のひとの情熱の大きさ、広さは本当にすごいですね。

今後やりたいこと

流れからしてこれからはマネージャーとかリーダーを目指すんだろうなぁという風に思われそうですが、別にそういった要求も必要性も感じていません。

今考えているのはルールで足並みを揃えるようにしているけど、それが通用するのは今の一瞬だけだよなぁという思いです。 人が増えて、メンバーが変わって、仕事が変わって、それでも残るものって何なのかなぁと漠然と考えます。

強いルール、強いリーダー、強いメンバーのいずれも今はよくても持続して行くものではないので、もっとあるかないかわからないような弱いルール、弱いリーダー、弱いメンバーで戦えるような何かがあってもいいのかなぁと。

今でも役割を聞かれても全部と答えるしかないような感じですし、色んな曖昧性を残しながらそれでいてしっかりとした線が通っているような自分、チーム、ルールが残って行ったらいいなぁと思います。

今まであった恩師はみんな静かで、弱そうに見えて、それでいて抑えるところは抑えていてみんなを上手く回していたので、これからは強い人ではなく弱い人を目指して頑張っていけたらなぁと思います。

めざせ老子、めざせ荘子

宣伝

フロントエンドのミートアップが近々あります。現状埋まっていますが、スライドとかも早めに公開して行くので見たら面白いかもしれません。

テーマがバラバラで人を集めにくいなぁと正直思うのですが、今考えるとうちのチームはなんだかんだ皆が何でもやるので、どうしてもこうなるんですよね。 だから、これはこれでうちのチームのあり方を象徴していて面白いなと思うのです。

具体的な技術、プラクティス、解決策はどうでもよくて、なぜそうしたのか、なにが背景にあったのかに注目して見るのが個人的には楽しいのかなと思います。個人ではなく、会社単位でそういう発表をするのはなかなかに珍しいので。

hey.connpass.com

デザインとの邂逅

デザインとどう触れ合ってきたか

前の仕事

前の仕事ではデザインは一緒に働いていたエンジニアが主にやっていました。

やりかたはたぶん似たようなデザインのサイトを探してきて、それに近い構図、テーマ、配色を持ってきて、それを微妙にアレンジするという感じでした。

自分はたまに色についてだったり、配置するコンポーネントの種類について聞かれて答えているぐらいで、興味もほとんどなかったです。

バックエンドだったり、フロントエンドのデータのフローをどうやってきれいに設計するかというのが好きでそちらにのめりこんでいました。

今の仕事

デザイナーとの出会い

そんな感じの人間なのになぜかフロントエンドが仕事の中心になっていて、デザイナーと一緒に仕事することになりました。JavaScript自体は好きなので、何とかうまくはやれるだろうと思っていました。

最初のデザイナーとの話し合いは確か、ダイアローグの余白と文章の見せ方がこれでいいかというもので、普通に中央寄せと余白を12pxぐらいとっておいてぐらいの助言をもらいました。

そこまで細かく見るんだと思いながらも、前のエンジニアもそれぐらいは考えていたので、正直なところこの時点ではデザイナーのすごさが実感としてありませんでした。

デザインシステム

そのあと、デザインシステムを本格的に作ろうというプロジェクトに入りました。

既存のデザインを色んなコンポーネントに落とし込んでいたのですが、細やかさの極致でした。

  • フォーカスが入った時の挙動や、アクティブな挙動をすべて設定する
  • 余白を何段階にも設定する(余白のpxも必ず8の倍数)
  • コンポーネントの丸みも統一する
  • 似通った色を統一しつつ、近い色でインタラクティブな挙動を定義する
  • 使うアイコンの線の太さ、角度、雰囲気、余白を統一する
  • PCとモバイルでフォント周りの設定をすべて切り替える

このうち一つ二つは前職でやった可能性はあったとしても、すべてを統一しようとは間違いなく考えなかったと思います。

これを見ると、自分はデザインしていたんじゃなくて、見た目で思い付きで整えていただけだったんだなぁと感じ、デザイナーすごい!という思いが出てきました。

ブランドイメージ

自分はまだ関わっていないですが、デザイナーたちの話のなかで、ブランドイメージの話がよく出てきます。

サイト全体をこういう風に印象付けたいから、ここはこうしたいとか。この画面ではこういうことをしてほしいから、こういうUIにすべきだみたいな話です。

先に書いたように前の仕事では何となく他のサイトの見栄えをまねしているだけで、統一感はあったものの、目的意識はありません。

ただ、コンポーネントをきれいに配置しているだけで、上から考えるのではなく下から考えている気配が強いかったんだなぁと今になって感じています。

デザインの勉強

デザインの方法

周りのフロントエンドエンジニアは結構UIに意見を言うことが多かったのですが、自分は思いついたことを言えませんでした。なぜかというと、何が正しいのかがいまいちわかっていないので、説得ができなかったからです。

だから、基礎的なところから本を読み直しました。

読んだ本

ここら辺の本を読みました。

『ノンデザイナーズ・デザインブック』は構図の整列の仕方だったり、強調の仕方だったりを教えてくれます。デザインの初歩の初歩にはいい本でした。

フラットデザインで考える 新しいUIデザインのセオリー』はコンポーネントの目的だったり、思想を教えてくれる本で、ちょうどプログラマにとってはわかりやすかったです。

『インタフェースデザインの教科書』はユーザーはどういうふうにUIを見るかという心理学的な話がまとまっていて、抽象的ではありますが、UXって何?というところが少し感じられるようになりました。

ノンデザイナーズ・デザインブック [第4版]
Robin Williams
マイナビ出版 (2016-06-30)
売り上げランキング: 1,305

デザインの思想

問題意識

デザイナーの手法とか考え方がずいぶんわかってきたなぁという段階になりました。その折に、GoogleMaterial Designガイドラインを見るといいよと言われたので見てみました。

material.io

それで事例みたいなものを見ていたのですが、驚きました。

ナビゲーションの遷移の発想と美しさ、コンポーネントの造形、配色しかたのどれをとっても自分に作れるとは思えなかったからです。

下のようなUIの事例集の本を見ていても、やっぱり自分の頭からこうしたデザインが出てくるのは想像できません。

【新版】UI GRAPHICS 成功事例と思想から学ぶ、これからのインターフェイスデザインとUX
安藤剛 水野勝仁 萩原俊矢 ドミニク・チェン 菅俊一 鹿野護 有馬トモユキ 渡邊恵太 須齋佑紀/津﨑将氏
ビー・エヌ・エヌ新社 (2018-10-19)
売り上げランキング: 13,670

実世界のデザインは基本的なテクニックのはるか先にあるように感じられるのです。

それでデザインに関係しそうな領域の本を色々と読み流しました。

読んだ本

もっといい本があるだろと言われそうですが、自分はデザインとは何かという根本的なところが知りたくてこんな感じのところに手を出しました。

これ以外にも色々本を読んで、とにかくデザインとは?というところについて考えました。

システムの科学
システムの科学
posted with amazlet at 19.05.18
ハーバート・A. サイモン
パーソナルメディア
売り上げランキング: 16,379
欲望のオブジェ
欲望のオブジェ
posted with amazlet at 19.05.18
エイドリアン フォーティー
鹿島出版会
売り上げランキング: 492,016
デザインに哲学は必要か
古賀 徹 板東 孝明 伊原 久裕 山内 泰 下村 萌 シン・ヒーキョン 小林 昭世 池田 美奈子 藤崎 圭一郎
武蔵野美術大学出版局
売り上げランキング: 43,720

デザインとは何か

色々定義はありましたが、例えば「現在ある問題に対する最適な回答」といった定義が印象に残っています。

これに続く言葉は、問題を徹底的に観察して、新しい見方を探し続けること、というものでした。

配色について考えるなら、色を見た時に自分はどういう風に感じるのかを観察し、ユーザーを見るときはユーザーの言葉を聞くのではなく行動、環境を観察すること。

時間が変われば問題は変わり、その時自分はどう感じているのかを観察すること。

そして、それらに対する徹底的な洞察。

これを見た時に知識がないのが問題ではなくて、単に世界のUI、自分の行動、あらゆるものを観察すらしていない自分自身の態度が問題だったのではないかと思いました。

デザインは答えではなくそれを見る人、使う人への問いかけである、そういう言葉も見てとても腑に落ちたような感覚を覚えました。

フロントエンドとデザイン

コンポーネントで考える

何度か書いているようにエンジニアはコンポーネントに画面を分割して作り始めます。サイドにナビゲーションを置いて、こっちはメインで、こっちにはカードを置けばいいかというふうに。

デザイナーの人はそうではなくて、こう考えます。

ユーザーにどういう行動をしてほしいのか、そのためにはどのような感情の起伏をさせればいいのか、そのためにはどういう風にナビゲーションを設置すればいいのか。

その結果、ナビゲーションがいらない場合だったあるかもしれませんし、あるページ内のナビゲーションは他のページのナビゲーションとは違うかもしれない。

ユーザーは誰だろう。料理中だったら、タッチ数を減らしながら操作できないとだめだ、そもそもインターフェースは画面なのか? 音声のほうがよい?

こういう発想の違いは知識としては知っていましたが、最近ようやく共感できるようになってきました。

パーツの種類

Material Designを初めとするUIを眺めていて、色々なテキストボックスを見ました。

背景色が紫、読み込み中に罫線が点滅する、アイコンが中に入っているだけ、hoverで色が全く変わるもの……

こういうものを書き出してスケッチに集めてみると、数10種類はありましたが、自分の中では完全にBootstrapがテキストボックスの代表で、テキストボックスの可能性について何にも考えていないことに気づきました。

コンポーネントは再利用しておけばいいという考えがありましたが、本当にそれでいいのかと考えるようになりました。

生活とデザイン

デザインを勉強し始めて、生活もよりよくなるようになりました。

メモもKeepあたりに適当に箇条書きしていたのですが、スケッチブックを使って強調、配列、アイコン、その他もろもろを使うようになりました。

自分の頭の中をデザインとして整理することで、すごく色々なアイデアが出ますし、問題を分析することができるようになりました。配色の研究にもなります。

家の中もレイアウトや配置に慎重になり、自分の行動に対して一番短い経路にモノを置いたり、ずぼらながらも整理整頓ぐらいはするようになりました。

料理をするときもそうで、何が主役で何をサポート役にすえるかと考えることで、調味料のバランスなどをスムーズに考え付くようになりました。

レーニングも自分の感情の起伏だったり、意味に応じて練習を分類・整理することで自信をもっていいという練習メニューを作れるようになりました。

残念ながらファッションは興味がないのであんまりですが、どうしてこの組み合わせなのかを見ながら考えたりはします。

デザインは生活自体に対する挑戦であり、問いであると思います。

まとめ

デザインという思考を取り入れることでとても新しい世界が開けたようでとても楽しいです。

設計は見栄えでしょうとか、センスでしょう、あるいはもしかしてロジックでやっていけばうまく行くんじゃないかと適当なことを考えていた過去の自分を説教したい気持ちです。

これからもっと自分の思考、自分の考えを見つめ直して、もっと本質的な可能性を問うていくようなそんな生活・思考がして行けたらとてもすてきだなと思います。

デザインの領域はアートだったり、編集だったり、音楽だったり、色々な領域にとびとびで学ぶことも多いですが、その分楽しんで生活できる日が続くんだろうという期待があります。

フロントエンドエンジニアになってよかったなと思います。

禅プログラミング

きっかけ

最近の仕事は難しい仕事が増えてきました。

例えば、あまり触ったことのないプログラミング言語のコードを読んだり、新しい機能のレビューを任されたり、新しいプロジェクトの開発環境の整備を1から作るなどです。

全く知識がないというわけでないので、頭をひねったり、多少調べれば解くことができるのですが、QCDが安定しないのでさてどうしたものかなと考えていました。

前の仕事では1つ1つのステップを設定し対策案を実施し、うまくいったら次に行くを繰り返す方法を習いました。

仮定を立ててそれを実証することを繰り返していればいいよというのは科学的で正しいとは思うのですが、時間がかかりすぎるので、このやり方には限界がありそうでした。

そういう問題意識を抱えていたところ、たまたま禅の本を読んでいて「自分を観察(=瞑想)すると仕事が捗るよ」という内容を見つけました。

面白そうだなと思って何気なしにやってみると意外とうまくいって、問題に冷静に当たれるようになってきたのでそれについて紹介します。

実務でよくあること

横道に逸れる問題

何か技術的な調査をしているときに、このツールをNPMで入れたらいいんじゃないか、という話を見つけます。

思考停止でそれをいれると、エラーで動きません。原因を調べると、さらに他のパッケージがないとエラーが出て動かないとか、バージョンが上がったら不具合があるよという様々な原因が見つかります。

そういう指摘を検証してやっと動いた!と思ったら、当初の問題を解決するものではなかったりします。そもそもうまく動けばいいほうです。

こんな風に技術調査をしていると別の問題がどんどん起きて、最初の課題ではないところに時間をとられて、時間が溶けていたりします。

また、業務で使っているSlackでレビュー依頼や別のIssueが挙がっていて、そっちを見ていると思考が流されたり、割り込みが入ったりで、気づいたら何をしているかわからなくなります。

検索がやめられない問題

こちらも技術調査でとにかく不具合があって直さないといけないということがあります。原因はとりあえずライブラリにありそうというケースを考えます。

最近だとStack Overflowに出てくるような問題の解法はあまりなく、どちらかというとGitHubのIssueにあることが多いです。

しかし新しいバグを踏むと、Issueで議論中で結論が出ているような出ていないような状態で放置されていたり、人によって違うことを書いていたりします。

こういう時に検索すれば答えがでるかもと思って調べていると、永遠に答えが見つからず辞め時を失うことがあります。

コードを見ればわかるといえばわかりますが、どれぐらいそこにコストがかかるのかを考えるといい塩梅というものがあるはずです。

禅の正式な定義は知らないので何となくで言葉を使っています。マインドフルネス、瞑想、ヨーガとの違いはこの際、聞かないでください。この記事についてはすべて同じ意味で置き換えてもいいと思います。

シンプルに「自分の考えていること、自分のやっていること、自分の体の状態をすべて正確に観察するように努める」という意味でとらえてください。

具体的に言うと、自分がいまどういう感情なのか、自分が何に集中しているのか、その時体に変化はあるのかということに意識を置きます。

もう少し細かいことについてはこれから書いていきます。

やっていること

『いかにして問題をとくか』を考える

いかにして問題をとくか
G. ポリア
丸善
売り上げランキング: 17,871

はるか昔に買ったはいいのですが、こんなの当たり前じゃないかと思って眠っていた本です。

本の詳細は書きませんが、問題を解くためのフレームワークのようなものが書かれています。例えば、

  • 未知なものは何か?
  • 与件(データ)は何か?
  • 条件は何か?

などです。

今、技術調査をするときはこうしたことを先に大きく目につくところに書くようにします。「この関数が偽を返すことが証明できれば、不具合は必ずこのスタックトレース内にある」とか、そういう具合です。

レビューの時も反復作業系なら「抜け漏れがないことを証明する」、新機能なら「既存の機能に影響がないことを証明する」という観点をぶらさないようにしています(もちろん、意図は複数ありますが)。

この何を解いているのかということを基準に思考を観察していると、いつ思考が横道にそれたか、今どこまで調査が完了しているかが把握できるので、思考が散漫になることが減りました。

また、レビューでも自信を持って、問題がないということを言えるようになった風に思います。

他の優秀な方たちはどうしているのかはわかりませんが(脳内で整理できているのかな)、自分は紙に頼ることが今でも多いです。

感情を観察する

問題が解けずに2,3時間たつと、イライラし始めます。レビューで指摘されて感情的になることはありませんが、同時に修正が大量に来ると頭がかっとなることがあります。

できる限り客観的に対応しますし、外にも出しませんが、かといって仕事中に感情を消すことは少なくとも自分にはできそうにないです。

ただ、感情を観察するようになって、いつそれが出てくるのかがわかるようになってきました。

そうやってメタ的に見ていると、「あ、今頭に血が上ったな」「胸から上に重心が上がった気がする」という兆候がわかるようになってきます。

さらにそれを深めて「普段の状態はどんな状態だろう」「どこから血が上がったのかな」「この状態で思考するとどういう思考になるのか」という観察を進めていると、気が付いたら冷静になっています。

また、今自分は問題についてではなくて、相手によく思われることに注意を向けていたなということがわかると、自然に問題のほうに思考を戻せます。

つまり言い方を変えると感情を観察することで、問題と感情を整理つけてとらえることができるようになったと思います。

これはノートに書くよりも、適当にSlackで自分にDMを打つようにしています。そうやって外に書いていると何となく傾向が見えてきます。

Vimを使う

今はVSCodeVimバインドですが、Vimは禅にとっていいエディタです。というのも、自分が今何をしているのか、何をしたいのかを正しく認識しないと、操作できないからです。

Emacsでもなんでもいいですが、Vimが顕著な気はします。

選択肢はどれだけあるか、今使うべきキーは何か、設定を変えることで最短を更新できないかなどを考えて作業することで、より禅の世界に近づけるという風に思います。

この分野は自分が語るほど強くなくて、周囲の人は、キーボード、画面分割、エディタの改造、シェルの改造、ブラウザの拡張などをかなりやりこんでいます。

いいエンジニアはそもそも自分のやっていることを把握しているものなのかもしれません。

やってみた感想

何かを考えるとき必ず他の人はどうしているか、ベストプラクティスは何かを探る癖がついています。

それも前職の思考のトレースに近いものですが、そうではなくて自分の軸を作ってそれに従う場面も必要なはずです。そこの優先順位が低いなぁと自分の思考をたどりながら、思ったりします。

そして感情が表に出ているときはパフォーマンスが悪いです。

悲しいはそもそもあまり思わない質ですが、怒りであったり、恐れ、焦り、あるいは愉快さであっても、明瞭に問題を解くときには役に立っていません。

「仕事は 楽しいかね」と最近色々な人に聞かれるのですが、うまく働けているときは問題のこと以外に注意が向いていないのでよくわかりませんという答えになります。

そのための環境は提供できていますかという意図の設問だと思うのですが、そこに入る過程は自分の注意力の向け方が正しいかどうかなので、自分自身の問題だよなぁと感じてやはり回答が難しいです。

自分は満員電車でもあまり苦に思わず、電車の揺れ、人の動き、体にかかる力などを味わうのが最近は気に入っているので、やはり心の持ち方次第ですとしか言えないです。客観的にみて、満員電車の環境がいいとは思いませんし。

今後

いかにも悟りましたという感じで書いていますが、実際は相変わらずSlackに注意をとられたりしますし、自席で仕事をしていれば紙やメモで頭を整理できますが、会話や会議になるとちょっと難しいところがあってまだまだです。

そういう問題に対しても深く観察して整理することで挑める部分もあると思うので、もう少し禅プログラミングを頑張ってみたいなと思っています。

RailsDM2019の振り返り(2日目)

前書き

前日に続いて参加したので書きます。

聞いたもの

操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践

speakerdeck.com

論理削除や削除テーブルなど、操作履歴をどう残すかという議論でした。

最近はフロントエンドが中心でこういう議論を全然していないなと思いつつ、以前はここらへんのやつを大体試せる環境にあったので懐かしく聞いていました。

要求によりますねという当たり前のことしか言えませんが、バージョニングと更新サインで管理しているとテーブルの結合とかがとにかくしんどかった記憶があります。

プログラミングスクールを作ってみた

speakerdeck.com

前に教育担当をしていたので、技術的なところに関しては詰め込めば詰め込めるというのはわかっていました。

なので、カリキュラム内容は充実しているなぁと思いつつ、同時に納得感がありました。

そこから先のビジネス的に利益になりづらいみたいなところは聞いたことがなかったので参考になりました。

ユーザー層も主婦や引きこもりの方が多いということで、知りませんでした。

How framework and buildtool handle webpack?

speakerdeck.com

WebPackerやcreate-react-appなどがどうやってWebpackを扱っていて、どうやって拡張しているかみたいな話でした。

業務で出てくる技術ではありますが、比較して考えたことがなかったので勉強になりました。

ある程度ブラックボックスにしておいたほうが確かにアップデートの時に楽だなぁとは思いつつ、1度ejectしてあとは自己責任という態度はまさしくReactらしくいいなぁと。

Evolution of Enumerator

speakerdeck.com

RubyのEnumeratorを使ったことがなかったです。Enumerableあたりでなんとかできることが多くて、そこまで使い込んでなかったので。

なので聞いた後でもEnumeratorはすごい便利!とは思いませんでしたが、Rubyのループ処理能力の高さとその実装方法が興味深かったです。

Rubyがブロックの中でループを打ち切る能力があるところとか意識してなかったです。よく考えると結構頑張っているのに、推されたことがないので意識してなかったです。

この発表を聞いたことでシンプルに書けることがありそうなので良かったです。

巨大なモノリシック Rails アプリケーションのマイクロサービス化戦略

speakerdeck.com

話としてはシンプルで環境を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アプリケーション

youchan.org

OpalはRubyライクな記法で書けて、JavaScriptに変換できる言語らしいです。

詳しいことをあまり話していませんでしたが、Virtual DOM、Isomorphic、Web Socketあたりができるという話でした。

ここらへんに関しては、ClojureScript、Elmあたりも見てきているので、Virtual DOMやっぱりあるんだ、そっかぁぐらいの感覚になってきました。

IsomorphicやSSRについては確かに考えたことがなかったです。前に挙げた言語もできるのかどうか記憶にないので、そこまで調べてなかったですね。

見ていて何度もリロードしていて開発体験がよくなさそだったので、自分としては採用しない気配があります。勉強にはなりました。

Active Record Oracle enhanced adapterのこれまでとこれから

speakerdeck.com

Active Recordの詳しいところは知らないし、聞いてみようかなぐらいのモチベーションでした。

中身はRailsOracleの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新人研修のコードレビューコメントを分析してみました

speakerdeck.com

最近、レビューに時間をかけているので何かヒントを、と思い見に行きました。

分析の手法や見方は好きだったのですが、分類や答えが何となく科学的というよりは、自分たちにとって都合のいい方法でやっている気がしてあまりうまく共感できなかったです。

それ自体が悪いというよりは、そのまま自分たちに流用できない気配だったので、自分たちの組織でやり直してみるのがよさそうという気持ちです。

"雑" / Almost Microservices

speakerdeck.com

必要な設定は全部DBのテーブルに入れてしまえというのは前の仕事では当たり前だったので、すらすら入ってきました。

逆に今の仕事でこれもこれも、オンコードでいいんだと思うところが多くて、戸惑う気持ちがあります。RubyやJSはそんな文化を特に感じます。

テストの仕方や、ユーザーを絞ってリリースするという発想は面白かったです。難しさはありますが、覚えておきたいところです。

作って学ぶ RDBMS

speakerdeck.com

理解できた気もするし、全く理解できていない気もします。

オープンソースとしてのDBは見たいなぁと思い領域でありつつ、C系統だしなぁとか、数学的なアルゴリズムが全開だとどちらにせよわからないし。。と思いながら放置していました。

聞いているとそういう心配はなく、読めるだけの下知識はもらえました。

小さく真似して書いてみるというアプローチも含め、OSSから学ぶ学習法を聞けて良かったです。

Thrifty Rails - How to run a production app on a budget

メモリやパフォーマンスを計測して、自力で直すとお金で殴るよりはいいよねみたいな話でした。

今日は難しい話ばかり聞いていたのでシンプルで聞きやすかったです。

パフォーマンス計測、メモリ監視、全部Gemで行けるよみたいなところで、驚いたところはあります。

特にN + 1問題について、Gemでチェックできるよと聞いてそこまでできるんだという感想でした。そもそもできると思っていないので、検索することもなかったです。

毎日の開発に役立つRailsプラグインづくりの秘訣

speakerdeck.com

人が多くてびっくりしました。今日は人が少ないところばかりにいたので、このテーマでこんなに人が集まるんだというのが発見でした。

中身はRailsのコンソールでの操作が難しければ、WebをGUIにすればいいじゃないみたいなところでこれは盲点でした。

コンソールのWrapperを書くとしてもRailsは選びませんし、そもそもCUIで頑張るほうを選ぶのでその発想がでてこなかったです。

そういうわがままさと技術的な詰め方というところが何となく自分にない感覚が多かったです。

感想

OSSの開発者が普段なにを考えて、なぜ物を作って、どうやって技術を選定しているのかというところを知れたのがよかったです。

自分で作ってみたいという気持ちもありますし、使う側としても背景を知ることで理解や共感ができるようになったように思います。

周りにOSSを書いている人は少なく、本格的なものになるともっと少ないので、今日でだいぶ身近なものになりました。

今回はフロントエンド関係の話をあまり聞いていませんが、発想は活かせそうなので参加してよかったです(と書いたら同僚は納得してくれないだろうか)。

明日もおそらく参加しますが、がちがちのOSS系統は少なそう?なので、別の視野を広げられそうで楽しみです。