Runner in the High

技術のことをかくこころみ

ITエンジニアの副業あれこれ

いろいろやってみた知見が溜まったのでまとめ。

開発

時間給で労働を売る古き良きスタイルの副業。副業として機能開発とかバグ修正とかやったりする。

自分はUIがいい感じだったからという理由でOffersを使って副業を探した。

offers.jp

注意点として、日中まともに会社員やっている人だと、稼働時間が自ずと平日夜か土日だけになってしまう。これが厳しいところとして、副業先のチームの開発プロセスには載ることが基本できないため、非同期作業みたいな形になる&開発スピードが求められるコアな機能開発みたいなアイテムには入りづらくなる。

あと純粋にモチベーション的に平日夜とか仕事したくないときもある。でも副業でアサインされてると仕事しないといけない。場合によってはチームの開発作業の進捗妨害をすることにもなったりする。

独立して作業可能なアイテムを貰えるプロジェクトか、例外的に日中もコミュニケーションできる人の場合にはそこそこワークする副業だと思われる。しかし、ひとりで作業を進められない系の人(未経験とか)は確実にやらないほうがいいと思う。

メンタリング

自分はMENTAを使った。

menta.work

注意点として、MENTAはとんでもない低価格でメンターリングプランを提供するユーザーによって価格崩壊が起こっているので、ちゃんと金を稼ぎたければある程度の価格帯(30k-50k)でのメンタリングプランを提供する必要がある。もちろん高ければ高いほどコンバージョンしにくいが、ちゃんとした価格でまともな(?)メンタリングを受けたい層もマイノリティーではあるが存在しているので、そこを取りに行くのがよい。

私見だが、メンタリングにちゃんと金を払える人間のほうがコーチャブル*1でメンタリングに素直だと思うし、安くすることには安くする以上のリスクもある。

執筆(Webメディア)

エンジニアHubみたいなメディアで執筆をする仕事。

izumisy.work

基本的に1記事いくら、みたいな単価計算になる。すごく儲かるということはない。

最も重要な点としてメディアで執筆をお願いされるような記事というのは「自分が得意な分野」が対象になるということ。

自分が得意な分野ということは、記事を書くことは単なるアウトプットであって、自分の勉強になるかというと... そんなことはない。つまり、知っていることを書いているだけなので学びはほとんどない(編集の人が校正してくれるので文章を書く練習にはなるかもしれないが)。

技術書籍を執筆している人たちも同じようなことを言う。自分が知っていることをただ書くだけなので、自分の学びにはならない。それが許容できるなら執筆の仕事をやってみるといい。どちらかと言えば、金をかせぐというよりも自分のブランディングのため、というほうがモチベーションの向き筋としては正しいかもしれない。

技術顧問業(アドバイザー)

Twitterだとか知り合いのツテをたどって、自分の得意な領域でアドバイザー的なやつをやる。

自分はブロックチェーン技術に関する会社でElmのアドバイザーをやらせてもらっていた。

アドバイザー的な立ち位置であるからには「〇〇なときはどうするべきか」「この言語ではどうすることが最善か」などを知識や経験で持っていることが求められる。自分の場合は現職でElmをかなりの規模で使っているため、そのような知見を広められたらいいなという気持ちでやっていた。

また、顧問業は純粋にコードを書くのとはバリューの出し方が異なる。

開発のゴールはプロダクトを作ることだが、アドバイザーは実際に自分の手を動かすことは少ない。逆に、より大局的で大きなインパクトを生むことが期待される。例えばレビュー方針や設計方針など、チーム全体の生産性を向上させるためにはどうするべきか?を知識や経験を元に考えたりアドバイスしたりするなど。

コードを書いて機能開発をしたりバグ修正をしたりするというのは比較的わかりやすい価値提供であるが、顧問業となると単価もそれ相応に高くかつ設計やチーム全体のイシュー解決がメインの業務になるため、事業ドメイン理解も求められる。設計なんかはドメイン理解があって初めて正しさが分かるもので、ただ「デザインパタンやらフレームワークや言語が得意/詳しい」というだけで根本的な解決ができるかというとかなり怪しい。

自分が顧問業をやらせて頂いていたプロダクトは本業とは全く異なるドメイン領域のものだったため、この部分の理解が浅いことで設計のアドバイスが難しく感じることもあった。顧問業をやるにあたってドメイン理解は技術に関する知識以上に武器になる。

「技術顧問とはどうあるべきか?」みたいな話は元メルカリCTOのsotarokさんの記事もほぼ必読だと思う。

note.com

ブログ

自分の場合にはAmazonアフィリエイトリンクを記事中に貼っている。

例えば以下みたいな記事。

izumisy.work

エンジニアブログはうまく記事を書けば、はてぶでバズったりだとかTwitterで拡散されたりするので、その瞬間風速で金を稼ぐ。やり過ぎると「このブログはアフィ目的のやつだ」と気づかれる。自分も会社の後輩にこのブログがアフィ目的なやつだと思われている(実際そうだが)。

一番ラクだが、上で紹介した副業の中でダントツで一番金にならない。せいぜい毎月500円くらい。一度だけ例外的にはてブでバズってアクセスが跳ねたときは6000円くらい稼いだ。基本的に手間がかからないことが魅力。逆に言えばそれだけ。

なお、はてなブログはProプランになってもGoogleアドセンスの審査が通らないのでやれていない。これは、はてなブログ側の問題とのことで結局Pro契約の2万円をドブに捨てることになった。はてなさんどうにかしてくださいマジで。

副業するべきか、どの副業がいいのか

個人的な体感として、一番簡単で金にならないのがブログ、一番難しくて金になるのが技術顧問業という印象。そういう意味では、やはり副業で開発かメンタリングをやるのが無難なのかもしれない。

会社にもよるが、本業でちゃんと給料もらえているor上がる可能性があるのであれば副業なんてする必要がない。むしろ本業でバリューを発揮して給与上げるほうが長期的には得なことが多い。副業には稼ぎすぎると確定申告とかしないといけなかったり、コンテキストスイッチなどの面倒臭さがある。副業で本業へのやる気が削がれるのは最悪だと思う。

一時期は不動産投資とかも考えていたこともあったが、知れば知るほど小さな会社経営並の難易度だと感じてやめた。サブリース業者に任せたりするのも、なんだか不動産業者という情報強者の言いなりになってしまう不安がある。

izumisy.work

2020年末Rustlang環境構築

以下をやるだけ

# インストール&初期セットアップ
$ brew install rustup rust-analyzer
$ rustup-init
$ rustup update

# プロジェクト作成
$ mkdir your_own_rust_project
$ cd your_own_rust_project
$ cargo init --vcs git --bin

# rust-analyzerを使わないならrlsと関連コンポーネントをインストールする
$ rustup component add rls rust-analysis rust-src 

Rustの環境を構築するには brew install rust ではなく rustup のほうをインストールするのが正解っぽい。インストール後に rustup-init で初期化するとコンパイルに必要なrustcとかもインストールされる。

rust-analyzerはrlsに代わるRust用の言語サーバー。どうやらこっちのほうがナウいっぽい。Githubからクローンしてきてビルドしたりとか自分でバイナリ配置したりしなくてもHomebrewでインストールするのが一番はやい。

vim-lsp-settingsがrust-analyzerに対応しているので、上記ふたつをインストールし終わったら :LspInstallServer するだけでバキバキに補完を効かせてRustのコードが書ける。最高。

ElmでサードパーティーなUI系モジュールを使う際にはTEAを前提にしたインターフェースでラップする

Elm Packagesで公開されているモジュールの中にはTEAでいうところのviewやmodelしか提供されていないものがあったりする。

これがコレクション系モジュールだとか関数単位での機能提供が目的のモジュールであればまだ問題ないが、UIを提供するタイプのモジュール(日付選択のカレンダー、トースト、など)だと話が変わってくる*1

モジュールによっては「仕様上今はupdate関数を提供する必要がないだけ」の可能性もあり、バージョンアップによって独自のMsg型とそれをハンドリングするupdate関数が将来的に現れる場合がある。こうなると利用している箇所すべてにupdate関数のハンドリング処理を追加する必要がでるなど、サードパーティーのバージョンアップによる修正作業が生まれる。

このようなケースを回避するために、UI系のサードパーティー・モジュールは必ず自前のモジュールにラップすることが望ましい。まずこれだけでサードパーティーによる影響範囲を1モジュールにカプセル化できる。

さらに、ラップするモジュールはあらかじめTEAの構成要素となる関数(model, update, view)をモジュールのインターフェースとして提供しておく。こうすることで、仮にupdate関数などを提供していないサードパーティー・モジュールから、提供しているモジュールに乗り換えたりしても、ラッパー・モジュールが変更を吸収することができるため、アプリケーションの大部分は影響を受けない。

仮に現時点で部分的に移譲する実装がサードパーティー・モジュールから提供されてない状態であっても、コードコメントにプレイスホルダーであると書いておけばいい。

module MyWidget exposing (Model, Msg, update, view)

import ThirdPartyWidget

{- 
    ThirdPartyWidgetのラッパー・モジュール

    今時点の実装ではModelとviewのみ内部実装をThirdPartyへ移譲している
    今後ThirdPartyを差し替えたりバージョンアップの際にTEAなモジュールになった場合には
    update関数とMsg型の実装をサードパーティー・モジュールの実装へ移譲する
-}


type Model =
    Model ThirdPartyWidget.Model


type Msg =
    NoOp


update : Model -> Msg -> ( Model, Cmd msg)
update model _ =
  ( model, Cmd.none )


view : Model -> Html msg
view (Model value) =
    ThirdPartyWidget.view value

Elmの素晴らしい点は、どんなに複雑なUIであっても必ずTEAのパターンに帰結するという点。

つまり、TEAから外れるモジュールは原則存在しえない。だからこそ、最も柔軟なインターフェースとしてTEAを構成するモジュールの形にしておけば、最終的にどんな変更が入ったとしても理論上はラッパー・モジュール内部で変更を吸収できる。

サードパーティー・モジュールをラップするという考え方

なお、サードパーティーなモジュールをラップするという考え方は特段Elmに限った話ではない。

dry-rbシリーズ*2の作者も「常に自分でコントロール可能なインターフェースにだけ依存させろ」と言っているし、安定依存の原則を考えたらアプリケーション開発では当然の話だと言える。どこか一カ所でしか使わないならまだしも、複数個所で使うようなサードパーティーの機能は必ず自前のモジュールとしてラップしておくことが望ましい。

izumisy.work

*1:カレンダーだとかドロップダウンセレクタなどのUI系モジュールはユーザーからのクリックや入力のようなElmランタイムを経由するライフサイクルが絡むことが多いため、機能が増えるとupdate関数が出現するケースがある

*2:Rubyアプリケーションにモナドやバリデーション基盤などを導入するためのユーティリティ系gem https://dry-rb.org/

マネジメントする立場になって思うこと

今年の夏頃から会社で4-5人チームのリーダーをやっている。

新卒で入社したころはまさか自分がリーダー的存在になるなんて思っても見なかったが、やってみるとこれはこれでおもしろい。来年になる頃には自分がなんでこの選択をしたのか忘れてしまいそうな気がするので、ここに書き残しておく。

やってみようと思った理由

正直なところ、学生時代から「やっぱエンジニアはコード書いてナンボ」みたいな気持ちでいて、当初はリーダーだとかそういうものには微塵も興味がなかった。Twitterとかを見ていても「マネジメント層になるとコードが書けなくなる」みたいな話もちらほら目にしたり、そういうものを見ると尚更「そんなんやるもんじゃねーな...」と思っていた。

しかし、実際チームでマネジメントをしている人をみている限りでは、マネジメントをしているからコードが書けないだとかそんなことはないどころか、ビジネス的な視点とエンジニアリングの視点がいい具合に混ざり合って、大局的に物事が見えているようにも見えた。そのような事実を目にすると、少しづつ自分の中で「自分が目指すキャリアというのはこれなんじゃないか?」という気持ちが高まってきた。

加えて、社外の人々の話を聞くところでは、国内のベンチャー(メガベンチャー、ミドルベンチャークラス)ではどの企業においてもプロジェクトをマネジメントする層が絶対的に足りていないという話を非常によく聞いた。眉唾ではあるが、聞くところによればいまのベンチャー界隈におけるマネジメント層は年齢的に20代後半から30代前半であることが多く、この世代はサブプライムローン危機による就職の難しさやライブドア・ショックでIT企業に対する良くない印象がついた時期でもあったため、そもそもソフトウェア産業に携わる人間の絶対数が窪んでいるのではないかという話である(要出典)

なるほど、そういうことであればなおさらマネジメントをやったほうがいい。人がやりたがらないことをやることで自分の価値が上がる。そんな理由でマネジメント・キャリアに進んでみることにした。

マネジメントをするエンジニア

マネジメントをするようになったとはいえ普通にコードは書くし、いまだに機能開発のコーディング作業が1日の大半を占める。この部分は以前とあまり変わらないところだと思う。逆に、自分の中で大きく変化があったのは、自分のチーム以外の状況を今まで以上に意識するタイミングが増えたことか。

自分の開発しているプロダクトでは自分のチーム以外にもいくつかのチームが存在している。ビジネスサイドのロードマップだったり開発進捗は毎日変化するため、常に状況を鑑みて他チームのリーダーを話し合いチームリソースの配分であったりリスケジュールを行うことになる。この種の意思決定をするには、チームの開発進捗だけではなく他チームとのリソース調整を考えたり、ビジネスサイドの動きをみつつスケジュールを考え直したり、これはかつてのように1プレイヤーとしてただコードを書くだけでではあまり意識できないところだと感じた。

逆に言えば、一度こういう視点を身につけると今度はメンバとして働く上でも強い。仮に自分がリーダーではないとしても、リーダー的な視点を持って意見や提案をできる。これはやってみないと分からないところだと思う。

マネジメントのおもしろさ

今の会社だからというのもあるかもしれないが、やはりマネジメントは「自分でコントロールしている感」がすごくあり、これはめちゃくちゃにおもしろい。もちろんその分責任も大きいが、自分の意思決定がビジネスにインパクトを与えるというのはまた一味違ったおもしろさがある。

マネジメントというと様々な重圧がありそうな雰囲気もあるが、個人的にはいまが一番多くの人に頼れているようなそんな気がしている。チームのメンバ、ほかチームのリーダー、上長、などなど、1メンバとしてチームで開発をしているとき以上に自分が関わるネットワークが大きくなり繋がるノードが増えたような、そんな感じ。

組織パターン

組織パターン

B2Bなソフトウェア開発における必読書3選

B2Bなソフトウェアの開発において業務知識なしにシステム設計をすることはほぼ不可能に近い。

これまで、業務支援系のシステム開発SIer企業たちのお家芸であったが、近年ではWeb系のベンチャー企業やスタートアップであってもこれまでSIerが担っていたようなドメイン領域で戦うことが増えている。

「会計処理」「流通管理」「在庫管理」「人事管理」あたりのドメインにまつわるシステム設計は、B2Bをやっていればいつか必ず遭遇することになる。その際にドメインに関する知識を一切持たずにまともなシステム設計をすることはたいていの場合難しい。

Web系であれなんであれ、B2Bなソフトウェアエンジニアは自分たちが取り組むドメインに関する知識を持ってシステム設計に臨む必要がある。これはデザインパターンや設計手法"以前"の話だ。

ITエンジニアのための「業務知識」がわかる本

財務会計」「販売管理」「物流・在庫管理」など、様々な企業活動の業務知識を集約した一冊。これを読むだけで、ざっくり世の中の企業が日ごろから行っている業務ドメインの活動やそれに関連する法律などを知ることができる。また、各業務ドメインを扱うエンタープライズ系システムにおいてどのような機能が必要とされるか、なども例として紹介されており非常に参考になる。

どちらかといえばこの本は業務のライフサイクルやそれに絡むプロセス、用語などを網羅した本になっている。なので、この本を読んだ上で更に自分が深めたいドメインに特化した書籍に向かうのがよい。その手掛かりをこの本は十分に提供してくれる。

データモデル大全

「データモデル大全」は上の本で学ぶような業務知識をどのようにしてデータモデルに落とし込むべきかが学べる良書。特にエンタープライズ系システムが扱うドメインをテーマとして積極的にカバーしており、具体的には「受注と出荷」「サービスと契約」「在庫」などが含まれる。

ソフトウェアエンジニアである我々は、業務知識を実際のソフトウェアに落としこむにあたってデータモデリングを必ずすることになる。データベース・ミドルウェアを使わないソフトウェアはほとんどないと言っても差し支えない。とくに、在庫管理のデータモデル設計の考え方はECサイトや在庫管理システムを作ることがなくても間違いなく学びになる。

これまでのDB設計で「残り〇〇」のようなデータをDB上の1カラムにステートソーシングで表現してきた人は間違いなく設計の観点がレベルアップするだろう。

システム設計のセオリー

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

システム設計のセオリー --ユーザー要求を正しく実装へつなぐ

  • 作者:赤 俊哉
  • 発売日: 2016/02/26
  • メディア: 単行本(ソフトカバー)

「システム設計のセオリー」はいわゆる「エンタープライズ系システム」の開発における開発プロセスにおいて、それぞれのプロセスの目的や手法、注意点などを説明している。大規模なソフトウェアの開発プロセスにおいて「どのような観点で仕様を決めるべきか」「どのようなフォーマットで仕様をドキュメントに残すべきか」などを大局的に学べる一冊。*1

アジャイル開発の登場によって、特に新興のWeb系企業でウォーターフォール開発が「時代遅れ」かのように言われがちだが、それがウォーターフォール開発を無視してよい理由にはならない。

どんなソフトウェアの開発にも必ず「要求分析」「要求定義」「外部設計」「内部設計」などのフローが暗黙的に存在しており、それぞれの役割を知って初めて自分たちの開発に特化したプロセスの取捨選択ができる。深く考えずに「ドキュメントは大事じゃないから残さなくていい」「テストはなんとなく画面を触っとけばOKだろう」などの意識でいる人ほど、改めてウォーターフォールに立ち返るべきだ。

izumisy.work

*1:この本に関してはB2Bに限ったはなしではないが、いわゆる基幹系システムの開発という文脈で取り上げてみた。

GPD PocketからOneMix3 Proに乗り換えた

かつてIndiegogoでバックしたGPD Pocket初代をときたま外出のとき持ち歩いたりしていたが、とうとうOneMix3 Proに乗り換えた。

性能も使いやすさも段違いになった。

izumisy.work

今の世の中のUMPC全体のトレンドが7型から8型台へ移りつつあり、OneMix 3シリーズに限らずMAG1やGPD Pocket P2 Maxなどもまた8インチモデル。

これはすごく理に適っているなと個人的には感じていて、なにより7型は正直キーボードがめちゃくちゃきつい。 GPD Pocketを買った最初のころは、見た目が好みというだけでキーボード入力を頑張っていたが、手の小さい自分ですらやはり7型だとタイプミスがかなり頻繁に起こる。

7インチは見た目こそ小さくてかわいいが、実際に使うとなるとキーボード入力の難しさがめちゃくちゃネックになってくる。

f:id:IzumiSy:20200919211958j:plain
左がGPD Pocketで右がOneMix3 Pro

しかしOneMix3 Proのような8インチ台に突入してくると圧倒的にキーピッチに余裕がでる。 OneMix3 Pro特有の部分で言うならばやはりスペースキーだけが若干遠くアクセスしずらいという点はあるものの、それ以外でキーボードに対する不自由さはほとんどない。 このキーボード配列は確実にUMPCを日ごろから触る人が設計している。

Windows10からはWSLも使えるので、Ubuntuデュアルブートにしなくても開発環境が整うのもうれしいところ。 Web開発をするにはやはりMac/Linuxじゃないと、という思い込みがあったが、近年のWSLの進歩を見るとWindowsだけでほぼ開発を完結させられそうな未来が見える。

ちなみにモバイルディスプレイはJapanNextの10inchのやつがコンパクト&超軽量でおすすめ。

isucon10に出て予選敗退した

iguchi1124hayashikunとisucon10に出た。一番伸びたスコアは1300くらい。

f:id:IzumiSy:20200913175854p:plain

やったこと

覚えていることベースでやったことを書いてみる。

自分が覚えているのは基本アプリケーションサイドの変更ばっかり。

マシン構成の変更

hayashikunとiguchi1124がAP2台+DB1台の構成に変更した。

index張り

使われてそうなとこにいくつか張った

create index char_stock on isuumo.chair (stock);
create index estate_latitude_longitude on isuumo.estate (latitude, longitude);
create index estate_height_width on isuumo.estate (door_height, door_width);
create index estate_rent on isuumo.estate (rent);

nginxでクライアントキャッシュ

hayashikunが椅子と物件の詳細情報をクライアントサイドキャッシュするようにした。効果は不明。

よく考えたら椅子は在庫数みたいなデータがあるのでキャッシュさせたらまずそうだがスコアには影響はなかった。

なぞって検索の処理をAPサーバでやらせる

ポリゴンの内外判定系をSQLでN+1してやっているということがわかったのでpolyclip-goというライブラリを使ってST系関数の呼び出し部分をアプリケーションサイドに寄せた。

スコアは10くらい伸びた気がする。

LowPriced系のオンメモリキャッシュ

APサーバで結果をキャッシュするようにした。これはめちゃくちゃ効いて400くらい伸びた。

DBのアプリケーションの最大コネクション数を変更

10→50にしてみた。効果があったのかは不明。

botリクエストの排除

UAを見てbotだったら503返すようにするあれ。効果は不明。

ランキング処理

任意の椅子にあう部屋を取得するエンドポイントで使われているSQLがorを5つ使っているのでそのぶぶんのorをひとつに。

椅子の縦横奥行きのうち最長辺を除いた二辺でドアの縦横幅と比較すればorをひとつにできた。

   var estates []Estate
    w := chair.Width
    h := chair.Height
    d := chair.Depth

    // 短い短辺ふたつをとりだす
    lengths := []int64{w, h, d}
    sort.Slice(lengths, func(i, j int) bool { return lengths[i] < lengths[j] })
    len1 := lengths[0]
    len2 := lengths[1]

    query = `
        select *
        from estate
        where (door_width > ? and door_height > ?)
            or (door_width > ? and door_height > ?)
        ORDER BY popularity DESC, id ASC
        LIMIT ?
    `
    err = db.Select(&estates, query, len1, len2, len2, len1, Limit)

featureテーブル

これはやろうとしてできなかった。

LIKEを発行してchairとestateのfeaturesカラムを舐めているクエリがいくつかあったので、それに目星をつけてchairとestate用のfeatureテーブルを別で用意してみることに。これがうまくいけば検索クエリが改善するので購入ボリュームが底上げされると思っていた。

しかし、実際にはLIKEを発行するようなクエリは全体でみるとほんの数パーくらいしか占めておらず、改善する意味はほとんどがほとんどないということが終わってから分かる。また、意味がない割にfeatureテーブルを作ろうとするとめちゃくちゃ難しく、後半はここで時間をかなり使ってしまった。

思ったこと

用意されているDBテーブルがふたつだけ、そしてアプリケーション実装コードも短く、いままで以上にシンプルな構成のアプリケーション、という感じだった。

ベンチを動かしてみると一番負荷が集中するのは結局DBで、いかにキャッシュを効かせてDBへのアクセスを減らすか、いかにDB設計を考えて負荷を分割するか、という部分がポイントだったのかなという印象。しかし我々のチームはDBの分割などの戦略までは到達できなかったので、上位のチームがどのようなDB構成の戦略をとっていたのかが気になる。

また、今回のアプリケーションisuumoの特徴として

  • レコードの入稿がCSVを用いたバルクで行われる&頻度少なめ
  • 物件テーブルには更新がない(ユーザーの行動も資料請求で終わる)
  • 検索クエリが極めて複雑

など、実際のsuumoのようなプロダクトにものすごく近い状況が再現されており、おそらくベンチマーカーの挙動も 検索→商品詳細閲覧→資料請求or購入 という流れをたどるように作られていたように思える。つまり、パーチェスファネルのようにまずは検索部分のボリュームを稼がないとスコアに直接響く資料請求や購入につながらない、という感じ。

なので、早い段階で検索より先の部分(商品詳細とか購入とか)を改善しても、結局検索部分で詰まってトラフィックが増えないため結局スコアが伸びなかったのは極めて自然に思える。実際、トップページの商品表示で使われているLowPriced系APIをキャッシュした結果スコアがかなり伸びたりもしたので、アプリケーションの仕様からユーザーストーリー的な部分を把握して改善優先度を決定する、というのがISUCONで最も必要な考え方なんだろうなと感じた。

前回だか前々回だかのisucariでは「購入されやすい椅子」や「購入が多いユーザー」などのように、ベンチによるユーザーごとに特性を再現するギミックが仕込まれていたので今回も購買傾向を分析したりしたいと考えていたが、購入者の情報がUA程度でしか識別できないなどの理由がありやらできなかった。が、もしかしたらそこにもヒントがあったかもしれない。

isuconのアプリケーションチューニングにおいて優先度を決定するには、やはりまずアプリケーションの仕様や傾向を把握することから始めないといけない。gistの資料を読んだり、ログをとったり実装を読んだり。これは仕事でソフトウェア開発をするうえでも同じだし、こういう部分を無視してスコアが稼げないように問題設計がされているのはすごくおもしろい。

「チェアdeスクっと」は名前はダサいが気軽にスタンディングデスクを導入できる最強の製品

いわゆるコロナ禍で自分も在宅ワークを余儀なくされているが、やはりなんといっても座りっぱなしで問題になるのは腰。腰がイカれてくる。

Fitbitで歩数を見ても腰が壊れるのは自明で、自分はかなり通勤経路が長めの人間だったということもありこれまでは余裕で10k歩ほどあるけていたものが、ここ最近では歩いてもせいぜい5k程度にしかならない。歩かないとどうなるかというと、それは下半身のとくにハムストリングスが十分に伸びなくなるため腰痛に悩まされる。下半身を動かさない人間はだれでもみな腰痛に苦しむことになる。

これは座っていることがほとんどの原因なので、これを解決するために自分も据え置き型のスタンディングデスクの導入を検討していた。しかし、いかんせん値段が高い上に置くと机のほとんどのスペースをとられてしまう。昇降デスクも部屋狭いので置く場所がない。

というわけで見つけたのが「チェアdeスクっと」という製品。名前がめちゃくちゃダサい。

この製品はハイバックチェアの背もたれの部分に取り付けることで椅子をスタンディングデスクにできるというもの。

これなら机の上に据え置きにする必要もないし、昇降デスクを買う必要もない。

f:id:IzumiSy:20200905173502j:plain
天板の雰囲気

天板の大きさ的にはMacbook Proの15inchを置いてまあまあいっぱいという程度。

背もたれには以下のようにして固定されている。

f:id:IzumiSy:20200905173434j:plain
背もたれ部分に引っ掛けて固定されている

天板は角度を変えられるようになっている。

自分は若干傾斜があるのが好きなので、以下のような設置角にしている。

f:id:IzumiSy:20200905173446j:plain
横から見た雰囲気

固定の仕組みがかなりよくできているので、相当重いものを置かない限り落ちることはない。とはいえ、当たり前だがアームを付けたりディスプレイを置いたりするのは止めたほうがいい。

一つ気になるのは、椅子の背もたれが動くものだとタイピングをしている最中にすこしグラグラすること。しかし、このあたりは使う分には慣れる。

所感

この製品は極めて日本的だと思う。誰かの記事でも読んだが、そもそも日本は部屋が狭い。そういう部屋に住んでいる人たちのための製品だ。

現状、スタンディングデスクを導入するには机の上に据え置くタイプか別に昇降デスクを購入するしかほとんど選択肢がない。しかし、チェアdeスクっとであれば不要なときはどこかにしまっておけばいい。必要なときだけ場所を取らずにスタンディングデスクにできる。

いい製品だと思う。

なお、余談だが正座をやるようにしたらそこそこ腰痛が改善した。

スタンディングデスク+正座を組み合わせれば腰痛フリーになれるだろうか...

「朝30秒の正座」で腰痛が治る

「朝30秒の正座」で腰痛が治る