島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

なんとなく体調がおかしい時の対応

はじめに

年齢からくるものか、生活習慣からくるものかちょっとわからないですが、朝起きた時に本調子でないことがあります。頭や体が重かったりして、心と体が整っていない感じです。

そういう時に対応していることをメモしておきます。

睡眠不足なら寝る

とても簡単な理由の一つが睡眠不足だと思うのですが、これは大変簡単で「寝れば良い」一択で考えています。無理をせずに、寝ます。フルフレックスの弊社ならメンバーも不調なら寝てしまって調子良い時に仕事して欲しいです。

ただ寝るのが上手な人と下手な人がいると思うのですが、寝やすい環境づくりは必要なことがあります。

  • 食事をして満腹中枢を刺激する
  • 風呂に入って一度体を温める(その後少し涼しい部屋にいると眠気が襲ってきます。確か体がそういう仕組みなんだそうな)
  • 部屋の温度や湿度を快適にする

ちなみに予防としては「そもそも寝不足にならないようにする」なのですが話題が逸れるので今日は書きません。

漢方薬を飲む

以前メンバーに相談してみたらご家族が漢方に詳しいそうで聞いてみたところ、いくつか紹介いただきました。私は以下のあたりが合っている感じかなと思っています。もっと強力?っぽいものもあったようなんですが、そこまでじゃない感じでした。

  • 補中益気湯
  • 加味逍遙散

食事の前に服用して、食事後少しすると良い感じになることが多いです。

軽く体を動かす

これは休むのが難しい時や軽度の時には有効なのですが、単純に血流を上げてやるだけで調子上がることあるので、スクワットしたりするといきなり元気になったりします。大体コーヒー入れながらスクワットして待っているとなんか良い感じになります。

風呂に入る

寝ようと思って風呂に入ったら、逆にスッキリして問題が解消することがあります。やはり血流大事な気がします。

おしまいに

体調管理の引き出しを色々と持っていると、ダメな時に片っ端から試していけるので良いのでは?という感覚があります。どれやってもダメな時は結構シンドイんですけど。

ステップアップJavaScriptという中級になりたい人向けの書籍について。もしくは人生で初めて本を書いてみた話。

はじめに

2022年1月14日に「ステップアップJavaScript」という書籍が発売になりました。JavaScriptを学んでいく上で一度は困りそうなトピックの解説を入れつつ、動く仕組みを作りながら学ぶ本です。 是非チェックして欲しいです。

書籍の中身については弊社でも作成した書籍Webページに仕込みました。「はじめに」「目次」「実際に書籍の中で仕上げるデモ」を確認できます。

books.circlearound.co.jp

きっかけ

お問い合わせフォームから翔泳社さまに直接ご連絡いただきまして、当初は「先方が持っている企画内容でJavaScriptの書籍を書かないか?」というお話でした。大変ありがたいことであったものの「我々はその内容では書く気になれん」とワガママを言わせていただきました。私はこういうところ頑固なので、たとえ仕事をロストしても考え方を曲げたくないという面倒なところがあります。

現代のプログラミング学習において「全てを網羅するような辞書的な書籍」というものはあまり価値が高くないと考えています。それは全てインターネットにありますし、特にJavaScriptについて言えばMDNを見れば最新の正確な内容を確認することができます。

developer.mozilla.org

これをお伝えしたところで会話終了と思いきや

「それならどんな本なら書きたいんですか?」

と逆に問いかけられたので私たちで企画を練ることになり、一回目のオンラインMTGはお開きになりました。

私たちの考える中級とは?

宿題になったので、脳内にあるものを何かしらの形でアウトプットしてみる必要がありました。私と小笠原の二人で進める上でもゴールが明瞭でなければチグハグな内容になりますし、出版社側とも企画意図をしっかりと合わせたいと考えた為です。

小笠原との次のMTGの直前に私がMiroで描き殴ったのが以下の絵です。イメージとしては「私の前に面接で『中級』を名乗る人がいたらどういうスキルを持っている人を想像するだろうか」という切り口でした。

JavaScriptの中級者について考えてみた
JavaScriptの中級者について考えてみた

当初は水色と紫で色を入れた範囲を全部網羅したいと考えていました。SPAやオブジェクト指向のようなところも軽く網羅する予定で、かなり大きく出たものだと今では思います。これをまとめる中で「JavaScriptができる」と言っても実は複数の切り口がありそうだということに気づきました。本書の読み方でも示しましたが

  1. DOMの扱いやHTML5の呼び出しなどを学習する「ブラウザを使いこなす軸」
  2. JavaScript言語の特色や変遷を把握して言語を適切に使う「JavaScript言語の軸」
  3. クラスや関数を使いこなし、コードの堅牢性や再利用性を追求する「言語によらないコード感覚の軸」

というようなものです。実はさらにもう一つあり「仕事としてコードを書く際に必要な心構えや考え方」のような、弊社のトレーニングで伝えている"実際の開発現場でやれると良い振る舞いや考え方"についても強く打ち出したい、弊社がやるならそういう色を付けたいとも考えていました。書籍というものをよくわかっていない私としては、一旦これを共有してみてどういうリアクションが貰えるかから考えようとしていました。

書籍に求められる条件について

次の会合では、たたき台を提示したこともあってより具体的なことを意見交換できたのはとても良かったです。先方はより責任を持った方も含めた3名の方で対応してくださり「書籍を売る側はどのようなことを考えているのか」が私の脳内に写像できたことは、振り返ってとても重要だったと思っています。この会合で私が脳に刻んだの主に以下の3つです。

  • 長く読んでいただけるものになる方がありがたい(つまり流行りのライブラリを説明するだけの内容だと、すぐに時代遅れになってしまう)
  • あまりに上級な内容を入れようとすると買ってくれる人がかなり限定されるので、結果として売れなくなってしまうことがよくある
  • 私たち現場開発者、トレーナーが思う「中級」と書籍で言う「中級」には多少乖離がありそう(これは中級者として完成した人を指すのか、初級から中級になろうとするのかの差異かもしれません)

この辺りをポイントにできたので「何をやるべきか」がより明瞭になったと感じています。経験不足のため、当初自分が提示した内容が本としてどの程度のボリュームになるのかがイメージできていませんでした。今回の書籍を実際に手に取ると287ページとかなり分厚く、これ以上の内容を盛り込むのはどう考えても無理だったろうと感じています。上手に誘導していただいたのでしょう。

最終的に、当初の大柄すぎる内容よりも言語そのものの理解にフォーカスする方が結果が出せそうだと納得することができました。ただし、大抵の読者がブラウザ上のJavaScriptを利用している事実や、「世間では意外にDOMを理解していない人は多く、この内容は落とさない方が良い」という提示をいただき、当初は落としても良いかと考えた基本的なDOM操作の内容をおさらいする内容を入れています。

思い返して印象に残っていること

非同期処理での苦しみについて

本書は殆どの部分が「トレーニングを通じで口頭やホワイトボードなどで伝えたことのある」内容をキッチリ整えたものになっています。従って、新たに捻って生み出すよりも、過去の脳内から整理して出力し直す作業が多かったので、あまり止まらずに書き続けられました。

しかし本書で最も大事な内容の一つである非同期処理は、正直苦しみました。当初、歴史も含んだ形でアウトプットして失敗しました(これは結果的に付録になりました)。改めて歴史がどうのとかは置いておき「まず何を学べば理解が捗るか」を再考して書き直したものになっています。島田達朗さんが書いてくださった下記のレビューでも、非同期の概念のページを引用してくださり、本書の中でも印象に残る良い内容が書けたのだと思います。

note.com

async/await は大変直感的な記述で非同期を記述できる為、まずこれで「背景の深い理解は一度置いておいても、思った処理を書くことはできる」という状態にたどり着けます。その後でPromiseと対比することで理解を深めていってもらう流れにしました。歴史とは逆ですが、この方が「概念化した後、詳細を学ぶ」という順序で整理ができると考えたのです。

複数の非同期処理を順番に実行することはasync/awaitを活用できるなら書きやすいです。多くの方が次に悩むことの一つとして「同時に複数の非同期処理をスタートし、全て終わってから次の処理を行う」ということがありました。これについてはPromise.allを紹介することでフォローしています。個人的にはどちらかと言うとPromise.allの具体例をもっと書きたくなってしまうところでしたが、書籍の目標としてはasync/awaitで行う連続的な実行とPromiseの基本理解の方へフォーカスしています。

参照について2つの内容をミックスして誕生した流れ

実は当初はプリミティブ型とオブジェクト型の解説のみで一度区切っており、付録の中でメモリをイメージする内容を入れていました。一度書き上げてから見直した時に、参照の印象が薄く、書籍の目的に対して足りない気がしたことと、レビュアーの意見に「付録の方の内容が良かった」というものがあったりするなどして、付録から一気に移動してきた経緯があります。ここは結構な大工事をギリギリでしてしまいました。今から書くならもう少し表現を変えても良い気がしています。

この件の反省としては「販促の時にどういうポイントを打ち出すか」は最初に決めておくべきだったということでしょう。

それと、この話題は厳密性を上げようとすると無駄に難解になる上、処理系依存の話も多くなってしまうと思いますし、抽象化し過ぎると解像度が低すぎて伝えたいことが伝わらないはずなので「どういう脳内イメージを構築しておけばコードを書く上で勘違いしないか」に苦慮したところでもあります。あまりこれに取り組んでいる文章も見たことが無いので、意図が適切に伝わるか多少の不安もある中で書いた内容です。最終的には一定以上の内容にできたはずだと思っています。

本当はメモリの話から広げてパフォーマンスの話へ繋げたい意図もあったのですが、紙面の都合上果たせませんでした。「Array.join使う方がforで連結し続けるより速いよ、それはメモリの確保が...」みたいなことを入れたかったなぁ。

コンテンツ化に力を入れ始めた理由

もともと私はあまりコンテンツ重視の考え方をしていない方です。どちらかと言うと「困った時に適切なインターネット上の文章に到達できる」ことを重視しています。ですが、この数年の個人向けトレーニングでは、その方法では苦戦するシーンが結構出てきてしまいました。あまり正確性の高くない情報へのヒット率が高まってしまい「嘘とまではいかないけれども、適切ではない」とか「様々なシーンで利用される言葉が誤用されている」などの事が増えた為です。

そうなると「困ったことは検索して…」ということを学習して欲しいのに「検索でヒットした内容に従ったのに間違いばかりである」という誤った学習をしてしまいます。このことはかなり大きな課題だと考えています。

私の理想では「『何か作りたい』程度だったらインターネットの情報だけでいい感じにできるから、人に教わる必要などない」となって欲しいのです。そして「仕事にするくらいのレベルに達したかったり、熟練のスピードを上げたければ人に教われば良い」という状態が理想だと考えています。それにはある程度適切な情報に辿り着きやすい環境が必要です。弊社では Tech libというWebサイトを作成して、Youtubeチャンネルで話した「私たちが大はずしはしていないだろう」と思っている内容を取りまとめていますが、アクセスはまだまだ伸び悩んでいます。 techlib.circlearound.co.jp

このような動画も知識のコンテンツ化の方法としては優れていますが、書籍は出版社が私よりも多くの方へ届けてくれるので、宣伝があまりうまくない私にとってはとても良い手段の一つではないかと考えるようになりました。今後も色々と世に送り出せたら素晴らしいです。

おしまいに

あまりまとまらない話を書き殴ってしまいましたが、実績解除の記録として置いておくのも良いかと考えています。 もしステップアップJavaScriptに興味を持っていただけたら下記のWebページから是非内容を確認されて、マッチしそうなら是非お買い上げください。

books.circlearound.co.jp

f:id:ms2sato:20220204223138p:plain

オフィス引っ越しまでのあれやこれや

はじめに

公的には9/7付けでオフィスを引っ越したのだが、この情勢でしかもまともなオフィス引っ越しとしては初めてだったのでメモっておく。ちなみに次のオフィスは私の自宅と一緒になってSOHO的になるので、かなりの縮小方向。これを書いている9/9は残りの荷物が全て運び出されている日で、その作業を横目で見ながらこの文章を書いている。

前提

  • コロナ禍なので、皆で集まる作業はやらず、基本的に私が一人で進行
  • オフィス自体は5人くらいで利用のものなのでそれ程大規模ではない
  • 既に全員完全テレワーク達成しているので普段オフィスに来る人はいない
  • 私の自宅の引っ越しとオフィスの引っ越しは同時進行

一人でやると結構ハードだったというのが率直な感想。

物件探し

可能なら当時住んでいた物件に登記事務所だけ移そうと思ったのだが、それはオーナー都合で難しいということになり、新しい居場所を探すところからスタート。メンバーはフルリモートで今後はどこに住んでも問題なくなりそうだけれど、私自身は営業の都合や金融機関等周辺の事情も考えると新宿区からは離れない方が良さそうだと判断*1

  • 新宿区orその周辺程度の場所
  • 会社で契約でき、事務所の登記が可能
  • 仕事部屋or仕事スペースが生活空間以外に持てる物件であること

バーチャルオフィス等は金融機関の融資の都合上難しく、利用しないことに決めた。家の近くに超割安な物件を借りる手もあったが、そうなると大抵狭すぎるのとあまり綺麗でないということ、遊んでいる空間を作るだけになるのは浪費感があるのでやめた*2

登記可能物件はそもそも数が少ないので、少ない中で良さそうなのを見ていく形になった。幸運にも最初の頃に「最悪ここでもいい(ちょっと高いけど)」的な物件がヒットしていたので、安心して進めることができた。結果として想定の間取りや土地を実現できたと思う。大家さんも一緒に入っている物件でとても良い感じの老夫婦で楽しく暮らせそう(社交辞令かわからないけど大家さんは「コロナ明けてきたらお酒飲もうよ」と何度も誘ってくれている。誘惑に負けるかもしれない。お酒やめてるのに)。

移行プロセス

概ね以下のように進行。2つの引っ越しを同時にハンドルする形。

  1. 旧オフィス解約の手続き(2ヶ月前解約)
  2. 旧自宅解約の手続き
  3. 旧オフィス、旧自宅内の物品の整理や破棄
  4. 佐藤個人の新オフィスへの引っ越し
  5. 旧オフィスから必要なものを新オフィスへの送付
  6. 法務局へ変更登記
  7. 旧オフィスの廃棄する物品の撤去
  8. クレカの住所変更とかとにかくいろんなところの住所を片っ端から変える

代表取締役の住所の変更は引っ越しの日から2週間以内に変更登記するものなので、法務局への申請の手間を一回にすべく、個人の引っ越しとオフィスの引っ越しの日程を調整した。最終的にはオフィスの移転日をうまく調整すれば実現できたので大きな問題はなかったが、5〜7が同じ週に一度に発生したので最後の週が想定よりもアクセクしてしまった。

途中で「日中はオフィスの荷物の整理」「帰ったら自宅の荷物の整理」という期間があって、この期間は結構しんどかった。とは言え、近くオフィスを構える予定の人に必要なオフィス用品を譲渡できたのは良かったと思う。こちらの荷物も減るし、相手も無料でホワイトボードやモニター等が手に入ってWin-Win。

おしまいに

荷物の撤去も全て済み物理的なところは終わったので、手続き的なところを進めて全てが終了する。早く解放されたい。変更登記後14日経って履歴事項全部証明書が取れるようになれば、税理士の先生、社労士の先生の仕事も進み、金融機関への住所変更もできる。

大変ではあったけれども、物理オフィスを縮小するのは下記のエントリのように会社として必要なステップだったと考えているので、実現できて良かった。 circlearound.co.jp

全体を俯瞰してみると営業に繋がるパスの減少は否めないので、継続的なアクションとしてチャネルを増やしていくのはやらないといけないなと思っているところ。元々オフライン中心であったところを少しずつ変えようとしているので焦らずに積み重ねていきたい。

そんな未来予測ではありますが、これまでの繋がりから受託のお仕事もトレーニングのお仕事もいただいており、有り難い限りであります。声かけいただいたのに、手がいっぱいになっていることが多い*3ことも課題なので、この辺りも今後は解消していきたいです(きっと相性のいい業務委託の方などいらっしゃると良いんでしょうね)。

その他

これまで私の現場介入を減らすアクションを取ってきた結果(現在ほぼゼロになっている)、引っ越し期間も特に顧客プロジェクトへの影響なく進めることができ、各メンバーの成長には助けられた。今後は人数が増えていく傾向にあるのでこの状態を維持して進められると良いのだろう。自分としては営業や新メンバーの勧誘や育成、書籍を書くなどのコンテンツへ時間を充てて、IT技術者としては「困りごとの相談相手」「何かあった時に使いやすいバッファ」「生き字引き」のポジションになると思われる。

以下はモノが全部無くなってスッキリした旧オフィス。

f:id:ms2sato:20210910181115j:plain
旧オフィス1
f:id:ms2sato:20210910181152j:plain
旧オフィス2

*1:起業前からリモートワーカーだった私はフルリモートの構想はずいぶん昔から持っていて、その当時から自分が都心から離れるのは余程会社のステップが上がらないと難しいだろうと考えていた

*2:倉庫的な活用も無しではないが、倉庫に置きたいようなものがそもそも無かった

*3:新規の作り切りよりも、長期的なものを対応していくことが多いのでこの傾向強いんです

About MikroORM decorators

This entry is answer for @MikroOrm's Tweet.

Abstract

  • As a result Everything works fine.
  • But I do not know the cause, but works fine(Can not reproduce ... sorry).
  • MikroORM works very well!
  • Thanks for your advice!

Logs

Phase 1. Next.js with MikroORM works fine.

I researched MikroORM and Next.js. And found following repository which I refer to.

github.com

It works fine.

(I couldn't reach following entry, but same author's lecture. Nice entry!) medium.com

Phase 2. Configuration.PLATFORMS require all driver ( Can not reproduce)

I wrote any code and refactoring( I think that detail of this is important, but I could'nt find it ). I saw an error as require @mikro-orm/mariadb but not found. I used Postgresql, and already installed @mikro-orm/postgresql worked fine on Phase 1. I tried installing @mikro-orm/mariadb, but another driver required.

Error line is Configuration.PLATFORMS

Configuration.PLATFORMS = {
    mongo: { className: 'MongoDriver', module: () => require('@mikro-orm/mongodb') },
    mysql: { className: 'MySqlDriver', module: () => require('@mikro-orm/mysql') },
    mariadb: { className: 'MariaDbDriver', module: () => require('@mikro-orm/mariadb') },
    postgresql: { className: 'PostgreSqlDriver', module: () => require('@mikro-orm/postgresql') },
    sqlite: { className: 'SqliteDriver', module: () => require('@mikro-orm/sqlite') },
};

I could not solve this.

Phase 3. I realized "Error occured by entity's Decorator on build for client"

I tried creating interface for client(not importing MikroORM's Decorators), Errors not occured!

I thought that errors are solved by changing build config for client/server( Following Tweet )

Phase 4. Omit Decorators and Use EntitySchema helper

Well, MicroORM provide EntitySchema helper as another method of creating schema. https://mikro-orm.io/docs/defining-entities#entityschema-helper

I tried and It works fine. Finally, EntitySchema helper's entity is few dependency and more simple code!

Phase 5. @MicroOrm's advice

Thanks for your kindness. I tried My problem reproducing from my past commit. But no errors occured. It works very well(I'm confused it). Unfortunately, I could not provide good report for this problem.

So MikroORM's developer's experience is very good. Thanks for your great work!

My package.json(save my versions)

{
  "name": "myapp",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "test": "env TS_NODE_PROJECT=\"tsconfig.test.json\" mocha './test/**/*.spec.ts'",
    "test-single": "env TS_NODE_PROJECT=\"tsconfig.test.json\" mocha $@"
  },
  "dependencies": {
    "@babel/core": "^7.12.10",
    "@babel/plugin-proposal-class-properties": "^7.12.1",
    "@babel/plugin-proposal-decorators": "^7.12.12",
    "@material-ui/core": "^4.11.2",
    "@material-ui/icons": "^4.11.2",
    "@material-ui/lab": "^4.0.0-alpha.57",
    "@material-ui/pickers": "3.x.x",
    "@mikro-orm/core": "^4.3.4",
    "@mikro-orm/postgresql": "^4.3.4",
    "@mikro-orm/reflection": "^4.3.4",
    "babel-plugin-transform-typescript-metadata": "^0.3.1",
    "final-form": "^4.20.1",
    "firebase": "^8.1.1",
    "firebase-admin": "^9.4.2",
    "mui-rff": "^3.0.3",
    "next": "10.0.3",
    "react": "17.0.1",
    "react-dom": "17.0.1",
    "react-final-form": "^6.5.2",
    "react-query": "^3.5.11",
    "recoil": "^0.1.2",
    "utility-types": "^3.10.0",
    "yup": "^0.32.8"
  },
  "devDependencies": {
    "@firebase/rules-unit-testing": "^1.1.6",
    "@mikro-orm/cli": "^4.3.4",
    "@types/chai": "^4.2.14",
    "@types/mocha": "^8.2.0",
    "@types/node": "^14.14.10",
    "@types/react": "^17.0.0",
    "chai": "^4.2.0",
    "mocha": "^8.2.1",
    "ts-node": "^9.1.1",
    "typescript": "^4.1.2"
  },
  "mikro-orm": {
    "useTsNode": true,
    "tsConfigPath": "./tsconfig.orm.json",
    "configPaths": [
      "./db/mikro-orm.config.ts"
    ]
  }
}

WEB開発の基礎知識を集約すべく「Tech lib」というサイトを作ってます。または ContentfulとGatsby.JSとNetlify でサイト作ったらとっても良かった話

Tech lib
Tech lib 〜 WEBプログラミングの基礎をここに集約 〜

はじめに

techlib.circlearound.co.jp

Tech libという名前でWEB開発の基礎知識を集めたサイトを作ろうとしているので、お伝えしたいがためのエントリです。後半は弊社が技術的に新たに取り組んだポイントなどを記しました。前半の暑苦しい内容に興味ない方はザッとスクロールどうぞ!

動機や背景

「WEBにに存在する有益な情報に自分でたどり着く」というのはかなり大事なスキルで、その為にはプログラマーを育てたい弊社のスタンスとして「弊社であまり情報集約や学習用サービスの用意などはしない方が良い」と今まで考えていました。「学習が容易である」ということにこだわり過ぎて「補助輪がなければ歩めない人」を誕生させても仕方がないという理由からです*1

ただこの数年の実体験を振り返った時、私がIT技術を学んだ20年前よりも遥かに得られる情報が増えた反面、情報の確からしさの確認や情報への辿り着く事への難易度が大変上がってしまったと言わざるを得ません。

身近な結果として初学者の方に対する「xxを自分で調べて報告してね」という事へのリターンの正確性がかなり低下したと実感しています。

そこで「少なくとも弊社で考えるある程度の確からしさのある情報」が集まった場所を作っておき、それが最初の学習に貢献できれば素晴らしいと考えるに至り、Tech libというサイトの開発がスタートしました。

「正しく権威のあるもの」は海外の一次情報サイトやその翻訳であることは言うまでもありませんが、それをまだ読解できないような方に向けて「とんでもない大間違いということはないから、迷った時に参考にすると良い」という場所を目標にしています。

弊社の技術的な新しい取り組み

上記の動機のような考え方の変容からの新たなチャレンジ以外にも、弊社としていくつか技術的なチャレンジを行っています。

  1. SEO的な情報露出にあまり積極的でなかった弊社がかなり力を入れようと方針している点(露出できないと課題が解決しない為)
  2. Contentful / Gatsby / Netlify という JAMStackのベクトルでの開発を行った点(上記のSEO対策の為にも、サイト速度とセキュリティに力を入れたい内容の為)

1については今後結果は出ると思いますが、既に検索ワードの組み合わせによってはGoogle検索の20番台に出ているものがあるなど、開発した期間やコンテンツの貧弱さから考えるとこの先が楽しみな結果が出ています。

2については

  • 静的サイト&CDNによるレスポンス速度でSEO効果が高まること
  • システムのセキュリティやサーバー性能に気を使わなくて良いこと
  • JSが得意な人間が多い弊社としては最適なこと

という観点で選択しました。実際かなり弊社には合っていると思います。私が初期開発を行なって 小笠原(@IT_BOZU) にバトンタッチしましたが、機能改善も大変スピーディで良好です。コーポレートのWEBもWordpressから乗り換えたい程です。触りはじめの私の喜びの声は以下のあたりを辿ると確認できます。

当時のことを知り合いの開発者の方とのメッセージの中で以下のように共有しました。体験としてスムーズ過ぎて楽しかったです。

私はNetlifyはよく知ってる状態で、Gatsby & Contentfulは初めて状態からスタートしたんだけどローカルでとりあえずブログが動くのが10分程度、デプロイが1時間未満。調べながらでもこれくらいだったよ。

実際にそれなりに動くようにするまでにサイトデザイン以外に

  • ページネート
  • OGP画像の自動生成
  • タグ

などを組み込んでみました。結果からするとJS、Reactがわかる人だとかなり良い速度で開発できる気がします。上記のような箇所は一回体験すれば今後は横展開容易(基本テンプレート的にpackage.jsonと初期ページ実装を用意すれば良さそうだと考えています)なのでコスト感としてとても軽いです。運用面では、コンテンツ内容はContentfulで修正すると裏で勝手にデプロイされて暫くすると反映。デザインはGitHubにpushすると裏で勝手に〜。みたいな感じで基本的に普通のことすれば勝手にデプロイまでされて楽チンです。今はローカルでも本番データで確認しながらにしていて「本番データがないと雰囲気わからん」みたいなことは今のところありません*2

おしまいに

今はGoogleさんに好かれようとしているのでデザインが多少おざなりではありますが、今後改善されていきます。 まだ始まったばかりの試みではありますが、現在かなり積極的に取り組んでいるので応援いただけたらとっても嬉しいです。

長々書きましたが引き続きご贔屓に。よろしくお願いいたします。

*1:これはスキルの話なので、検索して辿り着くスキルを鍛えるべきと考えています。ここが育っていない事の方が大きな問題です

*2:コンテンツが増えると変わるかもですが、今はこれで十分

仕事の評価は「他者のコストを減らせたか」も加味するとわかりやすい

f:id:ms2sato:20200824011713j:plain

はじめに

なんとなくふわーっと浮かんできた内容をメモがてら書いときます。

プログラマーの仕事の評価はコードだけでは測れないと思っています

私たちの仕事はコードを書いてシステムを提供する事がメインです。なのでまずコードを書けなければ話になりません。もちろん素晴らしいコードの書き手は評価が上がるべきだと思っています。ただ、単純にそれだけじゃ無いよね、というのが私がよく思う事です。

  • 素晴らしいコードを書く能力があったとしても、安定して能力を発揮してくれなければそのケアが必要なので周囲の人のコストを食っていきます。
  • 素晴らしいコードを書く能力があったとしても、チームのメンバーとうまく連携できなければトータルで見ると高い成果を出せない場合があります。
  • 素晴らしいコードを書く能力があったとしても、責任感が無いと顧客からの評価が大変下がります。

仕事でのシステム開発は、楽しいことばかりでは無いです。地味な作業も多いですし、どうしても複雑になる仕様も苦しいです。個人で楽しんでコード書いている時の高揚感が得られないこともしばしばです。ただ、システムを作り出して誰かに使っていただき、お金を得るというのはそういうことなのかもしれません。そうして純粋に高揚する楽しい部分は、各プロジェクトの中の一部や、顧客に依存せずに会社が提供する時間の一部などに含まれるのだと思います。

コードを書ける・書けないだけを純粋に見た時に一定のラインを越えている人がいたとしても、先述したような周辺事情も鑑みると評価を高めにくいことがよくあります。特に私が相対するのが完成された実力者よりも、発展途上のこれからの人という事が多い為に確率としては高くなるでしょう。「いびつな状態」になってしまう事が多いのですね。

もう少し掘り下げ

仕事である以上、コストというものを考えながら物事が進みます。そして評価を上げるのは「他者のコストを減らせた時」が最もわかりやすいタイミングであると私は考えています。「新しい事ができるようになった」時も評価が上がるはずですが、これだけだとなかなか見えにくい時もあるなと感じる為です。

心を安定させる

気に入らないことや、ちょっとした不安や失敗にいちいち動揺してしまう人は、なかなか仕事を手放しで任せる事ができません。仮に手がかかっていないように見えたとしても、上長はそっと見守ったり心の隅に置いていたりします。もしかしたら定期的に意識して何か働きかけているかもしれません。この「他人が心を配ってくれている時間やコストを減らすこと」は、その人の評価を上げます。

チームプレイができるようになる

言動や立ち居振る舞いによって他人の成果を落としてしまうと、他者のコストを増やします。もしも「その人がいない方が他者の心が安定するので成果が出る」レベルにまで達してしまえば、一人で閉じた仕事しか任せられないので大変評価しにくい状態になります。適材適所でうまくはまる場所を考えるのもコストです。その人に合った仕事を用意するのもコストがかかるでしょう。

責任感を持つ

仕事の正確性を上げるのは責任感が問われる事が多い気がします。面倒なことでもやり遂げられる人には安心して仕事が任せられる為、「チェックをする」という上長のコストを減らします。また、他人のやっている仕事を奪って自己の責任を増やそうとする行動は、わかりやすい他者コストの減少なので評価しやすいです。

おしまいに

ちょっと雑に書いたエントリですが、私だとこういう感じで評価というものについて考えますよってことで。

リモートワーク安定稼働までの弊社の工夫

f:id:ms2sato:20200416171155j:plain

はじめに

https://circlearound.co.jp/2020/04/10/covid19/

こんな感じで、弊社は2月から完全テレワークにシフトして、皆がリモートで仕事するようになりました。 もともと週に何日かは気まぐれにリモートしていた(私が率先してやっていたので、皆必要に応じてやっています)ので、導入自体はスムーズでした。 とは言え何の課題もなくうまくいってしまったわけでは無いので、その流れや対策を記しておくと参考になるかなと思い、書いておきます。

前提

  • 弊社の場合一人暮らし男性が大半で、嫁子持ちもいたりします。
  • 少人数チームです。たまたま開発の業務委託メンバーがいない時期だったので、社員3名+私で4名チームです。
  • 弊社事業にはシステム開発とプログラミングトレーニングがありますが、主にシステム開発文脈で記します。

情報まとめ的な対応

とりあえず、個々人の知識を寄せ集めて対策して行くのが良いと思ったので、知識共有の場所を作りました。

「快適リモートワークのための工夫」という文書

以下のような内容をメンバーが自由に編集しています。新しい体験や思ったことがあれば書いて大丈夫な場所です。主に以下のような幹でまとめています。

  • 机椅子のような「設備系」の話
  • リフレッシュ方法や食生活についての「行動系」の話
  • そもそもの物事の考え方や受け止め方についての「マインド系」の話

あまり堅苦しく考えていないので「ドアの前に置いて帰ってくれる宅配業者リスト」とか、「交代浴的な風呂の入り方」から、気晴らしのエロ系の話(これ書いてるの私だけですけど)まであります。もしも女子メンバーが関わるようになったら適切な情報が適切な方の目に触れるように、人知れず綺麗に整理される予定です。

Slack上の #remote チャンネル

特にコンテンツにまとめるレベルでもなく、何となくお得な情報があるよ、とかは #remote チャンネルに緩く書いています。例えば「新しい設備でこれ買ってみた」とか「弁当を作ると色々良い」とかコミュニケーションします。雑に貼ると以下みたいなやりとりしたりしてます(会話が飛んでたのと、メンバーのアイコン出ないように切り取りました)。未だに私は運動が定着しません。オラもリングフィットしたいぞ!

f:id:ms2sato:20200416155919p:plain f:id:ms2sato:20200416155957p:plain f:id:ms2sato:20200416160127p:plain

それでも起こる個別の問題

私のように15年くらい前からカフェで仕事したり家で仕事したり、一年くらい家でコードばかり書いた経験のある人間は色々と慣れもあります。でもメンバーの殆どはそういうやり方に慣れていないので、ただ文書を共有するだけで解消できない問題も出ました。結果的に工夫を相談してそれをさらに文書に落としたりしています。

「家だと集中できない」

とりあえず筆頭がこれになるのでは無いかと思うので、まずはこれを。雑談交えて会話して解決していきました。

私がたまに皆と話す内容に「脳は実は簡単に騙される」というような話があります。その応用でもう少し具体的に落としました。「仕事はデスク、くつろぐのはベッド」などと分けるだけでわざわざ書斎を持たなくてもできたりするのです。

ノートPCを持っているなら移動できるので、これを手軽に行えますし「くつろぐときはスマホしか使わない」と決めたりするのも手段の一つでしょう。以下は「快適リモートワークのための工夫」からの抜粋です。

家だと基本的に集中できないのは、家が休む場所だと脳に刷り込まれているため

  • 場所を変えるや視覚的に休憩スペース/作業スペースを分けるようにするなど工夫の余地はある
  • これは前話したかもしれないけど、場所と行動を結びつけるのが大事。ちゃんとしたデスクの前は仕事モード、そうでなければベッドの上でくつろぎモードとかメリハリつけると良い。脳は簡単に騙せる。 最初のお前を騙せ、世界を騙せ

この件はそれぞれ実践している様子ですし、少し長期で見ないと効果がわからないかもしれませんね。半年後くらいから大変になってくるので、まだまだ楽な時期です。

「なんだか体調が優れない。原因がよくわからない。手足が冷たい。眠りが浅い。」

慣れない人が家に引き篭もっていると陥りがちなのが「病気でも何でもないんだけど体調が悪くなる」というものかと。睡眠時間がメチャメチャになったり、いつも頭がボーッとしたりします。自律神経がうまく調整できなくなっている為だと推察されるので、本当はサウナ&水風呂を勧めたかったりするのですがこのご時世だと難しい。

なので、以下のような家のお風呂でやる簡単交代浴を勧めました。実際やってもらって随分体調が安定したそうです。よかった。文書には他にも運動とか、朝日を浴びる、みたいなことが記されています。

  • 風呂
    • 交代浴のススメ
      1. 十分湯船であったまったる(温度を最初から熱めにしておくのが良いです。ぬるいと水で死にますw)
      2. 水or水に近い温度のシャワーを手足、胴回り、肩など末端から順番にあてます。この時辛かったら手足だけとかでも十分です。水を止めた時に体温が一気に戻って来すぎるならもう少し当てると良いです。
      3. 体の水分を切ります。小さなタオルで拭くか、体の表面を手刀でビシッとするだけでもかなり良いです。
      4. しばらく洗い場でのんびり過ごします。私の場合には湯船のヘリに腰掛けてボーッとしてます。この時寒さを感じないのがうまく行っている。寒いなら水をかけすぎ。寒すぎなら風邪引くので湯船に入りましょう。
      5. 体が段々平常時の温度に近づいて来たら湯船に入ります。
      6. 2-5を3セットくらいやる。
      7. 最後は水をササっとかけるくらいで上がります。かけすぎると風邪ひきますw
      8. すぐに水分をタオルで吸い取って、暖かい部屋でだらだらしてください。ベッドに倒れ込んで良いです。多分そのまま眠れるので注意してください。

会話したーーーい!!

「テキスト中心の会話ではニュアンスが伝わりにくい」

「テキストではコストがかかるので会話したい」

「世間の不安感を孤独に受け止めるのは辛い」

みたいな、根本が「とにかく会話したいんだけど、どうにかならないものだろうか」という話。これについてはzoom 繋ぎっぱなしの社内もくもく会をやった時に「zoomなどだとあまりに顔が大写しになったり、部屋が見えたり、他にも突発的に映っちゃいけないものとか無いか心配になって緊張する」という学びがありました。

ここはツールを工夫しないとダメかなと思い、私の理想の「繋ぎっぱなしテレカンツール」を作成することにしました。主に以下のようなことを実現しています。

  • メンバーの顔は基本的にぼやけている「あ、いるな」とわかる程度
  • 音声はかなり小さめで繋がっていて「近づく」「離れる」という機能で音量調節できる(オフィスでデスクに近づいて「ねぇ、ちょっと...」と話せる感じ)
  • 部屋の全員が小さい音で会話を共有しているので、遠くで誰かが相談している内容が横耳に入ってくる為、「あ、それってさー」と、割り込むことができる

https://voffice.netlify.app/?room=sandbox

のような、簡単なURLを共有することで同じ部屋に入れる仕様です。この入るまでの手軽さも大事で、朝誰かがSlackに「今日の部屋」を共有しておけばあとは皆が適宜入ってきます。特に義務はないので、独りで集中したければ繋がなくて良いですし、休みの日でも「誰かと話したいなー」と思えば勝手に部屋作って繋いで良い運用にしています。zoomほど有名じゃ無いので、room名を総当たりしてくるような輩も今の所いないです。

テレカンツールを繋ぎっぱなしにすると監視されると思う人が世の中にいる様子ですが、弊社はリモート始める以前から

「監視するのなんて面倒だから放っておくので成果出して欲しいし、なんでも困りごとがある時には私に自分から相談して欲しい」

という形でコンセンサスを取っています。なので相談があればvofficeに私がいれば近づいて話しかけてくれるし、そうでもなければ繋ぎっぱなしで遠くで自分の仕事してくれています。入ってきても特に挨拶も無くても良いかなとさえ思ってます(ここは人それぞれのポリシーに任せていますが)。

このツールができたおかげで、対面で話したいという意見は出なくなりました。むしろこれでずっとリモートでもいけるような実感を得てくれたようです。ここは思い切ってコストをかける判断をしてよかった。HTML/CSS/JSしか使っていない為、httpdさえあればすぐに使えます。GitHubでソース公開されているので興味あればどうぞ(AGPLです)。うまく動かなかったらPullRequestください。

github.com

おしまいに

こういう時だからなんでも我慢しろ我慢しろと言ってもお互いツライだけです。様々な方法で工夫して、ストレス減らしながら乗り切っていきましょう。