kumamotone’s blog

iOS/Android アプリエンジニアです https://twitter.com/kumamo_tone

Scrapbox に書いた箇条書きを Markdown に変換する JavaScript

Scrapbox に書いたメモを Markdown に最低限変換するJavaScriptを書いた。

scrapbox.Page.lines.map(line => {
  if (line.section.start) {
    // セクションの開始行なら見出しとしてフォーマット
    return `## ${line.text}\n`;
  } else {
    // タブの数に基づいてインデントを調整
    return line.text.replace(
      /^\s+/, 
      match => ' '.repeat((match.length - 1) * 2) + '* '
    );
  }
}).join('\n'); // 変換した行を改行コードで結合

使い方

  1. (Chromeの場合) F12 で開発者メニューを開く
  2. Console に上記のスクリプトを入力して Enter
  3. 右クリックして Copy String Contents を選択

先行研究

shokai/Scrapboxからmarkdownに変換 の内容をベースに、箇条書きが深くなったときにうまく変換してくれなかったのでそこだけ書き足した。箇条書きのみのテキストなら変換できる。画像とかアイコンとか表とかそういうのがどうなるのかわからない。

Scrapbox はマジで愛されていて、いろんな実装が存在する。TypeScript や Rust で変換できる CLI を書いてくれている人とか、ブックマークレットを書いてくれてる人とか、UserScript という仕組みを使ってパーサーを書いてくれている人がいるので、それに乗っかってポップアップメニューでコピーできる仕組みを作ってくれたりしてる人とか……めちゃくちゃ良いんだけど……なんというかみんな根気があるな……という気持ちになってしまった……おじさんは、なんとなく何をやっているのかが酔っ払っていてもわかるぐらいのコード量で、コピペしてなんか出た!ぐらいのUXじゃないと安心して安定的に運用できる気がせず……まあ別にそれがイイという哲学でやらしてもらってるんで、別にええんですけど……

コミュニケーションの方法って(たぶん)色々あって良い

このページは mhidakaが建立した Advent Calendar 2023 Vol.1 の4日目です。

きみ誰

kumamo_toneは2016年あたりからiOS/Android/Flutterを軸に活動しているアプリエンジニアで、前職がmhidakaさんと同じメルペイでした。以前は勉強会の運営やカンファレンス運営などもやっていたので、その道の先輩でもあるmhidakaさんのことは色んな面で尊敬申し上げております。

近況報告

  • 引き続きスマホアプリエンジニアやってます
    • ずっとiOS ときどきAndroid という感じだったのですが、5月から株式会社YOUTRUSTというところでFlutterアプリ作ってます
  • 2023年は絵画教室などで練習をしたり、Slay the Spireにハマって全実績を解除したりしました
  • 歯の矯正を3年9ヶ月も前からやっているのですがまだ終わってません しかもまだ毎月すんごい痛い どうしてこんなことに…

最近思っていること

刺激の強いX(Twitter)に疲れてきていて(ChromeのExtensionで心がざわつく要素を消したりいっぱいミュートを設定したりしてなんとか使っています)、改めてブログっていいな〜と感じる機会が増えました。

自分は体も弱く内向的で、超ド近眼という出自から、10代の頃からコミュ障というレッテルを貼られることが多く、未だにコミュニケーションというもの全般に苦手意識を持っています。

一応、仕事上の短時間のコミュニケーションなら問題ないように振る舞えるケースも多く、大人になった今では、面と向かって問題を指摘されることは少なくなってきましたが(まあ大人だから言わないだけかもね)、人と長時間対面で過ごした後はしばらく何もできなくなるほど疲弊してしまうこともしばしばです(そもそも、会話というフォーマットが悪すぎるのではと ターン制コミュニケーション を読んでからは思うようにもなってきました)。色々思っていることがあっても喋るスピードで思考できないし、複数人いると自分のせいで会話のテンポを落とすような気がして発言できない……なんだこの悩み……中学生か?

そんな自分なので、せめてパソコンぐらいはうまく使いこなして交流できるようになりたいな〜最近はよく思っています。具体的には雑にXにpostする、ブログに考えていることや感想などを書く、Slackのtimesチャンネルとかを放置しない、Threadsとか、しずかなインターネットみたいな、新しい媒体が出てきたらできるだけ乗っかってみる、などなど…比較的元気がなかった去年とかと比べれば今年は顔を出せたかな、と思いつつ、2024年はもっと色々なところに情報を置きたい。どうせ自分のことなんて書いてもつまんないだろと思って、何も書かない、何も言わない癖がついてしまっているけど、そのせいでさらに語り下手になり、さらに話の技術が壊滅的になっていく、負のスパイラルを断ち切りたい……職場の人に「休日何やってます?」とか「普段何食べてます?」とか話題を振ってもらうたびに、おれの自己開示が足りないがゆえに、つまんねー会話をさせてしまっている……とめちゃくちゃ反省してます……自意識過剰か……昔はもっと気兼ねなくインターネットに色々書けていた気がするのだけど、なぜなのだろうか……これも自意識過剰なのかな……

というわけでこの文章に関してもその一環と思って書いているのですが、結局エディタを前にするとなんだかうまくまとまらず、日付ギリギリにうんうんうなっています たすけて〜^^;

CA.flutter #1 に参加しました

cyberagent.connpass.com

本日はサイバーエージェントさんのFlutterエンジニアによる勉強会、 CA.flutter #1 に参加しました!会場はサイバーエージェントさんのアベマタワーズでした。

オンラインでの配信もされていて、YouTube Live で配信内容が見れるようになっているのもとても良かったです!(巻き戻しもできたのでブログまとめたい勢としては聞き逃した部分を確認できるのでめちゃくちゃありがたい……!)

www.youtube.com

質問は sli.do でリアルタイムに受け付けられていたのもとても親切な設計だと感じました!質問もすべて読み上げられないほどめちゃくちゃ盛り上がっていました…!

app.sli.do

以下発表内容になります!

複雑な画面遷移を賢く管理する: AutoRouteGuardの活用法

発表者の ひろ(Hirokazu Tanaka) さんは、2023年新卒入社で、株式会社WinTicketでFlutterアプリ開発を行ってらっしゃるそうです。

auto_route は Flutter のナビゲーションパッケージのひとつで、2023年現在、 go_router に次いで人気のあるパッケージです。

Winticketでは、2021年3月にFlutter製アプリにリプレースした当初から auto_route を使用されてらっしゃるそうです。

auto_route の特徴的な機能として、 AutoRouteGuard があります。 AutoRouteGuard では、AutoRouteGuard クラスを継承したクラスを定義して、ルーティングのよくある複雑さを解消しています。

たとえば、公式の以下の例では、画面遷移時に、未ログイン時はナビゲーションを中断してログインページに遷移、ログインが成功した場合のみだけ本来行おうとした遷移を実行、失敗した場合は中止しています。

class AuthGuard extends AutoRouteGuard {                
  @override                
  void onNavigation(NavigationResolver resolver, StackRouter router) {                
    // ナビゲーションは、resolver.next() が true(ナビゲーションを続行)または false(ナビゲーションを中止)で呼び出されるまで一時停止される
    if (authenticated) {
      // 認証されている場合は、ナビゲーションを続行
      resolver.next(true);                
    } else {
      // 未認証の場合は、ログインページにリダイレクトする
      resolver.redirect(LoginRoute(onResult: (success) {                
        // success == true の場合、ナビゲーションを続行、
        // そうでない場合は中止する
        resolver.next(success);                
      }));                
    }                    
  }                
} 

たとえばWinticketではVIPユーザーと呼ばれるユーザーには、 /campaign/vip に遷移させるということをさせていることがあるようです。具体的には、以下のようにAutoRouteを定義しているそうです。

AutoRoute(
  path: '/campaign/vip',
  page: SecretVIPPage,
  guards: [
    IsLoginGuard,
    IsVerificationGuard,
    IsVIPGuard,
  ]
),

これによって、ログイン済み、本人確認済み、VIPユーザーの条件を満たす、という3つのガードを画面遷移に適用して、さらにVIPユーザーでない場合はそれ用のページに飛ばす、といった動作が実現できているようです(こういう形で組み合わせできるのはいいですね)。

また、WinTicketではフィーチャーフラグを使ったtrunk-basedなブランチ運用をされているようなのですが、フィーチャーフラグの状態を判定するのにも AutoRouteGuard を使われているそうです。

また、キーボードが閉じられるまで画面遷移を遅延させる AutoRouteGuard も定義されているようです(これも面白い)(閉じる判定 WidgetsBinding.instance.window.viewInsets.bottom == 0 でいいんだ…)。

個人的には、ナビゲーションには go_router か素のナビゲーションを使うことが多いのですが、go_router にも未ログイン時にログインページにリダイレクトさせるような機能(参考)があるようで、使ったことがなかったので気づける良いきっかけになりました!

質問コーナー

Q. go_router ではなく auto_router を選定したのはなぜ?

当時の判断らしい

How To Improve UI Quality And Performance

発表者の なるお(naruogram)さんは、2024年入社予定。サイバーエージェント24卒内定者の方で、Amebaマンガに所属。Flutter だけでなく、 iOSアプリの開発も行ってらっしゃるそうです。

UIの品質とは、「そのサービスがユーザーにとってどれだけ使いやすく、理解しやすく、効率的であるか」と定義されているようで、具体的には以下のチェックリストが考えられるとのことです。

なるおさんの所属する Amebaマンガ では、 UIの品質を Visual Regression Test を使って、改善しているそうです。テストツールは playbook-ui/playbook-flutter というサイバーエージェントの方が関わられてるツールと、 reg-suit を使っているそうです。

github.com

VRT では、以下のような点をチェックしているそうです。

  • 異なるデバイスでもUIが崩れないか→VRTテストにおいてテストする端末を増やす
  • 異なる状況でもUIが崩れないか→長い文字列や通信環境が悪くて画像が取得できなかったケースのStoryを用意する
  • 端末の文字サイズによってUIが崩れないか→ TextScaleFactor の値を設定し、複数パターンの文字サイズをテストする

また、 integration_test を使ってパフォーマンス計測を行う取り組みもやってらっしゃるそうです。

await binding.traceAction(
  () async {
    await tester.scrollUntilVisible(
      itemFinder,
      500.0,
      scrollable: listFinder,
    );
  },
  reportKey: 'scrolling_timeline',
);

計測するためには、Widget Test のコード上で、 IntegrationTestWidgetsFlutterBinding.ensureinitialized() で取得したインスタンスに対して traceAction() を使用し、引数に reportKey を文字列で指定します。

import 'package:flutter_driver/flutter_driver.dart' as driver;
import 'package:integration_test/integration_test_driver.dart';

Future<void> main() {
  return integrationDriver(
    responseDataCallback: (data) async {
      if (data != null) {
        final timeline = driver.Timeline.fromJson(
          data['scrolling_timeline'] as Map<String, dynamic>,
        );

        // タイムラインを、読みやすく理解しやすいタイムラインサマリーに変換
        final summary = driver.TimelineSummary.summarize(timeline);

        // その後、タイムライン全体をjson形式でディスクに書き込む
        // このファイルは、Chromeブラウザのトレーシングツールで開くことができる
        // トレーシングツールは chrome://tracingに移動して開く
        // オプションで、includeSummaryをtrueに設定することでサマリーもディスクに保存する
        await summary.writeTimelineToFile(
          'scrolling_timeline',
          pretty: true,
          includeSummary: true,
        );
      }
    },
  );
}

また、上記のテストドライバーを別ファイルに保存します。

もしテスト自体を integration_test/scrolling_test.dart、テストドライバーをtest_driver/perf_driver.dart というパスで保存していた場合、テストドライバーを指定して、以下のように実行するようです。

flutter drive \
  --driver=test_driver/perf_driver.dart \
  --target=integration_test/scrolling_test.dart \
  --profile

さらに、おそらく上記例の summarize のかわりに summaryJson というプロパティを使用すると、平均/最長フレームビルド時間、平均/最長フレーム描画時間、平均CPU使用率、平均メモリ使用率などをJSON形式で出力することができるようです。(これはやってみたい、、!)

懇親会で登壇者のなるおさんに質問させていただいたのですが、公式の下記の Performance profiling という記事が参考になりそうです。

docs.flutter.dev

個人的には、Flutter で VRT や PlayBook をガッツリ使った事例は貴重だと思うのでとても聞けてよかったです!また、 integration_test でプロファイリングするのはぜひやってみたい!

小売アプリのためのアクセシビリティ

発表者のKoki Masuyama(masssun)さんは、今年1月に中途入社されて、AI 事業本部アプリ運用カンパニーというところでモバイルアプリチームのリードエンジニアをされているそうです。

アプリ運用カンパニーは小売り企業の方々と協業して、アプリを中心としたデジタルでの購買体験の実現を行う事業部とのことでした。

アクセシビリティの重要性からはじまり、まずエンジニア主導で行える Flutter におけるアクセシビリティ対応としては、

  • スクリーンリーダー
  • 文字サイズ

の対応がありそうとのことでした。

スクリーンリーダー

Widget ツリーに、「このテキストは何であるか」「ボタンをタップすると何が起こるのか」などの情報を付与します。

たとえば具体的には、Semantics ウィジェットで囲んで label を設定するということができるようです。

ただ、AppBar, Text など標準Widgetの多くはそもそも Semantics でラップされているようなので、使っていれば対応が済んでいるとのことでした。

そのため、Flutterでは特別にアクセシビリティ対応を行わなくても、スクリーンリーダーが対応ができる範囲が広いようです。しかし、それを踏まえた上で、いくつかのTipsがあるようでした。

  • cached_network_image を使用している画像について、 Semantics で囲む (Image の場合は semanticsLabel という引数がある)
  • 複数のスタイルが適用されている Text は、別の Text として認識されてしまうが、まとめたい場合は MergeSemanticsRichText などを使う
  • アイコン付きのボタンについて、アイコン部分については読み上げさせたくないので、ExcludeSemantics ウィジェットでアイコン部分を囲む

文字サイズ

Text ウィジェットを使っていれば、フォントサイズはOSの設定に基づいてFlutterが自動的に計算してくれるので、これも特別な設定は必要なさそうとのことでした。

しかし、Layout overflow を起こさないような設計にする必要はあるとのことでした。そのための対応として、

  • SizedBox で width, height を固定にしない
  • ConstrainedBox で minWidth, minHeight を適切に設定
  • Column の children に設定されているWidgetは Wrap/Extended でラップすることで、画面端で改行されるようにする

などの工夫を行っているそうです。

個人的には、アクセシビリティはどうしても自分が当事者でないときに見落としがちな部分なので、Flutterでの具体的な事例や、気をつける観点などを知れる良い機会になったなと思いました!

おわりに

今回は CA.flutter の1回目の開催で、発表者の方々は新卒1年目、中途1年目、内定者の方ということでフレッシュな感じかと思いきや、かなり腕利きの方々という感じでとても勉強になりました!また、今所属しているYOUTRUSTでやっている勉強会(12/9(金)に第4回目をやります 今週 11/17(金) 13:00〜募集開始です)や、FlutterKaigi でお話した人とまた懇親会でお話できたりする機会になったのも嬉しかったです。また機会があれば参加したいです!

「プログラマー脳」を読んだ

www.amazon.co.jp

「プログラミング”力”を”鍛えて”、”優れた”プログラマーになりてぇ〜」というあるあるBIG煩悩に、筆者の個人的な経験や主観……ではなく、できるだけオープンになっている定量的な研究結果を引用して誠実に回答しようとした本だと思った。

優れたプログラマーとは?

この本で想定されている優れたプログラマーとは、以下のような人を指している。

  1. 人のプログラムを効率的に(短時間で)読むことができる
  2. バグの発見を効率的に(短時間で)行うことができる
  3. 良いコード(わかりやすく、保守性の高い)コードが書ける
  4. 大規模なシステムでも共同作業を行い、オンボーディングを行うことができる

地に足についたシゴデキ感があり、たしかに目指すべきはこれだよな〜と改めて思った。

この本では4章に渡って、以上のようなプログラマー像になるためのヒントやテクニック、それの根拠となる研究結果などを紹介されている。

認知負荷について

一冊を通じて語られていて、個人的にも意識していきたいなと思ったのは「認知負荷」についてだった。

人は見慣れないものを理解するのには時間が掛かるし、短期記憶に入っていないものは取り出すのには時間が掛かるし、日常的に慣れた操作以外を行うときは操作そのものに意識が持っていかれる。

認知負荷が高まると課題の解決に時間が掛かるが、逆に、できるだけ他人の認知負荷を高めさせないことが、チームメンバーとしては良い振る舞いだ、というメッセージを感じさせられた。

「メソッドを細かく分割するのは何故良いのか」「なんで変数名はあんまり省略すべきでないと言われているのか」みたいなところの答えにもなっていて、「焦ってとにかく一度に複数のことをやろうとするな」というのは前から感じていたことではあるが、この本によって思考が一歩前に進んだ気がする。

プログラミングに当てはめると

具体的には、以下のようなことが言われていた。

  • 短期記憶やワーキングメモリに蓄えれる情報はそんなに多くないため、メモなどの補助ツールなどを利用したり、練習などを経て、長期記憶や外部装置を充実させることにより、複雑な課題に取り組みやすくなる
  • 「関数やクラスを細かく分ける」「変数名は省略されていないものを使う」「一貫性をもたせる」などのプラクティスに従うことで、認知負荷がかからないコードを目指すと良い
  • 新人にオンボーディングするときは、新人がそもそも慣れない環境で色々慣れるべきことがあることを考慮して本当に小さいものや、慣れさせるためのタスク(リファクタリング)などから渡していくと良い

まとめ

多くのプログラマーが抱えているBIGペインに対して、できるだけ筆者の個人的な経験や主観を廃して向き合って体系的に整理された情報として、尊い書籍だなと思った。

speakerdeck.com

iOSDC Japan 2023 の shiz さんの発表資料は本書の一部が非常に良くまとまっていて、振り返るのにとても良かったのでここで紹介させていただきます。

2023年4月に、株式会社メルカリ(メルペイ)を退職しました。3年と4ヶ月ほど在籍させていただきました。

個人的な振り返りも兼ねて、簡単にどんな感じだったか書き残しておければと思います。

入社

2019年の11月に新卒で入社したヤフーを退社して、アプリ(iOS)のエンジニアとして同年12月に入社しました。

入社を決めたきっかけなどは、書き残してなかったというのもあり、もう記憶がおぼろげですが、以下のような感じだったと思います。

  • メルカリのバリューが、当時自分がありたいと思っていた像とかなり合っていると感じた
  • ペイメント事業に関わってみたいと思っていた
    • 当時WeChatとAlipayが使いたいという理由で2度中国に行くほどモバイル決済のオタクだったし、モバイル決済に可能性を感じていた
  • 勉強会などで会って印象が良かった人たちが多数在籍していた

この頃は我ながら気合が入っていて、オフィスから近いという理由で背伸びしてちょっと家賃14万の狭い1Kに引っ越し、堅実に実績や経験を貯めながら効率性を極めて、とにかくやるぞという気持ちに溢れていました。

COVID-19 の流行

ところが、2020年に入ってすぐCOVID-19が流行しはじめ、具体的な時期はうろ覚えなのですが、メルペイはかなり早い段階でフルリモートの環境に移行しました。

個人的には当時はリモートワークはうまく活用していければいいなと思っている派でした。実際、前職ヤフーのときは結構リモートワークの制度を使って家から仕事をしていたりもしました。しかし、いざ仕事をやっていくぞとなると、コミュニケーションの取りづらさや、仕事が終わった後も常に気が張り続けているのか睡眠などに影響が出てきたりして、色々な問題に直面しました。

また以前は、頻繁に技術勉強会に参加したり、技術カンファレンスの運営などにも関わっていて、それらに参加したり発表したりするためにいい仕事をするぞみたいなモチベーションがあったりとか、参加すること自体が良い息抜きになっていました。しかし、それらも(ある意味)なくなったことにより、ますます仕事との向き合い方というのがよくわからなくなっていました。

適応障害と休職

極めつけは、はじめて大きめのプロジェクトのTech Leadにアサインしてもらったタイミングでした。

アプリ開発者としてはあんまりもう技術力的なところを突き詰めてもしょうがないなと思っていた時期だったので、ありがたいアサインで、結構気合を入れて臨みました。

一方で、チャレンジングなことが多すぎる状態というのもあり、フルリモートでうまく周りのサポートを得ることも難しく、その頃の仕事に関しては一定評価してもらえたものの、ストレスからか体調不良が無視できなくなってきたため、適応障害ということで休職することになりました。

ここには詳細は書きづらいですが、前々から抱えていたプライベートな悩みも重なり、まあもう生きてくのは割に合わないなという感じにはなったりし、他にも数々のやらかしを経て、ふわっと言って復職後含めて結構良くない状態でした(今はほぼ寛解しました)。この時期にご迷惑をお掛けした方には改めてお詫び申し上げたいと思います。

自分は基本的に心配性で、キャリア的には綺麗な経歴だけが売りみたいなところがあったので、これらの部分については基本的にネットとかではぼやかし続けてきており、今回も書くかどうか迷ったのですが、どうせこの時期の話をする上では避けて通れないですし、できるだけ誤魔化さずにやっていこうと思うようになりました。

違和感に対する気付き

このあたりからフルリモートのやりづらさに加えて、

  • 提供しているサービスと、自分の価値観とのズレ
    • いわゆるリボ払いのようなものを提供していて、かなりの収益を上げていた*1
    • 世の中で言われている悪い側面だけでないことや、 evil になりすぎないように努力している人がいるのも感じたが、考えても違和感は残った *2
    • もっと決済や送金のUXに関わるプロジェクトにも参加できるのではないかと思っていたのだが、そうならなかった
  • この規模の組織で仕事をやっていくということ
    • 関わったプロダクトで、自分が作り上げたという気持ちになるのが難しかった
  • iOS のエンジニアとしてやっていくことに対しての疑問
    • ほとんどの仕事でネイティブのコードを書く必要性を感じられないジレンマ

などにも悩むようになりました。

転職

ある程度悩み尽くしたあたりで、転職サイトや Twitter DM などで何社かお話を聞く機会があり、最終的に YOUTRUST 経由でメッセージをいただいた会社に入社させてもらえることになりました。

決め手としては、

  • フルリモートではなく週3回の物理出社と週2回のリモートワークのハイブリッド型(2023年5月現在)
  • 規模が(主観的に見て)(現職ほどは)大きすぎない
  • Flutterというクロスプラットフォームフレームワークを使っている

あたりでした。関わってくれた人たちの雰囲気が良いと思ったというのもありました。

よかったこと

うまくいかなかったことも色々ありましたが、自分が関わった範囲では職場環境はかなりホワイトという感じで、給与水準も高く(と思います)、入社当時はアプリエンジニアには iMac Pro が支給されていたり、イベント運営や、採用会食する機会などもありましたが、そういうときにも全体的に羽振りが良いと感じました。

エンジニアに割り振られるタスクの量も自分が観測する範囲ではあまり多くなく、そのような余裕もあってか、困っていることがあったときにSlackに書くと、親身になって即レスしてくれるナイスな人も多かったです。カンファレンスでよく登壇しているとか本を書いてるとかデカいイベントの運営をやっているとか、自分がそうなりたいなと思っていた方向性で活躍している人もいたし、やっぱりお金や時間に余裕があるからか親切だと感じる人が多かった。

あと、人の悪口とかをしたり聞いたりするのが嫌なのですが、日本語が喋れないメンバーもいるチームでカタコトな英語でコミュニケーションしていたというのもあってか、そういうのとも比較的無縁でいられたというのも良かったです。

上達すると期待していた英語は、実感としては思ったより上達せず、会議はおろか日常会話ですらかなり怪しく、最後まで文章を書くときはDeepL Proを使い倒していました。というか振り返ると一時期は体調が悪すぎて日本語もうまく発話できてませんでした。ただ、退職時のマネージャーは入社時よりうまくなってるとも言ってくれていたので、もしかするとある程度うまくなっていたのかもしれません(DeepLに慣れて、見かけ上の文章力が上がっていた説あり)。

リモートワークについて

うまくいかなかったことの原因を、結構コロナ禍とフルリモートのせいにしてしまいましたが、世の中の状況や現時点の自分のライフスタイル(独身独居で孤立していた)などが現時点でたまたまうまく噛み合わなかっただけで、リモートワーク自体はとてもありがたい制度だと思います。

どこからでも仕事ができるということで広がる可能性はたくさんあると思いますし、都市圏の高い家賃を払い続けるのはアホくさいです。

というか本来、ステレオタイプな感覚で言ったら僕は内向的で、一人の時間が長くて、基本的に日がな一日パソコンに向かって作業しているわけなので、うまく使えば比較的相性がいいはずでもあるとも思います。

ただこのあたりは同じような性格やライフスタイルの人が体調を崩していたり、現在進行系で悩んだりしているのも見るので、現時点ではまだ自分の中で結論が出しづらいです。

おわりに

多くのWeb系の企業がリストラや採用ストップを掛けている中、安定した環境を離れて転職というのは不安な部分もあるのですが、次の職場にも楽しみな部分はたくさんあり、前向きにやっていきたいと思います!いつかそんなこともあったねって笑って話せるようになるといいな。

追記:会社や中にいる人に感謝こそすれ批判したい意図などはまったくないので、ブコメ等での、中にいる人が嫌な思いをする可能性のあるサービス等に対する批判はお控えくださると幸いです。

*1:このあたりは決算資料 で公開されているので、機密な情報ではないと思います

*2:当時自分の中でいい感じの納得ができていなかったという話であって、悪いと言いたいわけではないです。

エアロバイクを100日漕いでみた感想

エアロバイクを年始から100日連続で漕いでいた。ので良かったこと微妙だったことなど軽く振り返る。

良かったこと① アドレナリンの起点になる

何かやる気がない作業があったときに、とりあえずノートパソコンを台に置いてペダルを漕ぎ始めちゃうことで作業の取っ掛かりを作ることが意外とできることに気づいた。

やる気はやるから出てくるんや、みたいな話は何万回も聞いて飽き飽きしてるが結構本当の話っぽい。

良かったこと② 気分が良くなる

長期的な気分の落ち込みにどれほど効くかどうかについては色々な要因があるので実感できてないが、少なくとも即時的なストレス解消効果はあると思う。

ただ20分ぐらいだと全然駄目で、40分〜1時間、それも結構心拍数に関しては丁寧にキープしながら真面目に漕がないと汗もかかないしすっきりもしない、

微妙だったこと① 体感できる良さの割に時間が持っていかれる

とりあえず30分〜1時間漕いでから何かのアクションをするぞとなると、結構可処分時間が圧縮される。正直忙しい時期にどのくらい有酸素運動に割くメリットがあるかというと微妙な気持ちになる。

見たい映像とかを流しながらやると時間を持っていかれたという気持ちにはならないので、逆に普段はエアロバイク漕いでいるときしか動画見ちゃ駄目みたいな制限にしてもいいかもしれない。

微妙だったこと② 別に痩せはしない

ちょっと減量しようかなというモチベーションもあったのだが、これに関しては体感全然関係なかった。

実際有酸素運動で消費できるカロリーというのは本当に微々たるもので、1時間真剣に漕いで100kCalとか200kCalとからしい。

あと非アルコール性脂肪性肝炎になっていて、それが改善されることも期待してたのだが、定期検診で微減の傾向がありつつも、これがどのくらい効いているかはなかなか判断しづらい感じだった。

微妙だったこと③ デカくて邪魔

購入したFITBOXというエアロバイクはそこまで大きな機械ではないが、それでも東京都心クソ狭ハウスに置くとかなりの存在感がある。スペースに余裕がないので普通に邪魔。これは明確にデメリットなので置いて得られるメリットがどのくらいあるのかはちゃんと天秤にかけるべきだと思う。

その他雑多な振り返り

習慣化について

2週間ぐらい続けた後は、本当に習慣化したといっていい状態になっていて、自然と忘れずやるようになっていた。がTwitterに毎日投稿するのはタイムラインを圧迫するからあんまりよくないかな、と数日おきに投稿にしたりとかすると、あんまり見られてない感じがして漕ぎ方とかが適当になったりしていた。

本当はTwitterに書く以外で何かいい方法があるといいのだけど、とにかく毎日Twitterに投稿しながらやるというのは、習慣化に効くことがわかった。必要性の高いことで他にベターな方法が思いつかないときは使っていこうと思う。

ちょっとだけ漕ぐのはたぶんあんまり意味ない

本当にちょこっとだけ漕ぐのに関しては、部屋から一歩も出てない日なんかに関しては多少いいんじゃないかと思いつつ、目に見える効能としてはスッキリもしないし痩せもしないし何も現れない。ただ漕がない日があると一気に習慣化しづらくなると思うので、ここらへんはどうするか悩ましい。

100日使ったら故障した

100日使ったあたりで、ちょうどペダルを漕いだときにキュルキュル異音がする状態になった。

Googleで検索していると同様に返品交換してもらった人のブログが出てきたので、そこを参考にメールを送ったところ、結構迅速に対応してもらえた。

sakuchoman-blog.com

梱包用のダンボールは送ってもらえるし送料は負担してもらえるが、分解の仕方を調べるために説明書を探したり、そもそもかなりの重量感のあるものなので、梱包するのも結構大変だったので、なんでそういう状態になってしまったのかは分からずにちょっともやもやはしている。

アニメ見ながらはかなり良い

家のエアロバイクで革命的なのが中央スペースにiPad置いて、そのままiPadのスピーカーで映像が見れることだと思う。これがジムならイヤホンが必要だしわざわざ持っていくのも面倒くさい。

イヤホンしていても、当時見ていたアニメでいうと「機動戦士ガンダム 水星の魔女」とかはまだ良いとして、「ひぐらしのなく頃に卒」なんかはジムで見るのは結構はばかられる。「お兄ちゃんはおしまい! 」なんかは更に厳しかったと思う。

25分のを2話見てエンディングを流し切って終えると気分もいい。

Special Thanks

色々な方が反応してくれたり応援してくれたりしましたが、100日通してメッセージ送ってくれたりいいねつけたりしてくださった @koux2 さんにはマジで感謝です!!ありがとうございました。

まとめ・これから

とりあえず真面目に毎日Twitterに報告しながら取り組むとある程度習慣になることがわかってよかった。

健康効果がどのくらい出ているかはっきりと実感できるできていないが、ちょっとだけ健康になった気もする。

膝を壊したりしない限りはベッドでゴロゴロしているよりはたいてい有用な気がするので、しばらく気が向いたときベースで漕げるときは漕いで、体調等トラッキングしていければと思う。

ソースコードを書くなど単純な作業は外部に委託するなど

ソースコードを書くなど単純な作業は外部に委託するなど” という表現がちょい燃えしていた

この件がどうなのかは分からないが、こういうことを嫌な感じで耳にすることは全然よくあって、やはり作業者としては結構もんにょりした気持ちになる

「○○するだけ」って言って作業渡してくる人、全然○○するだけじゃないことの方が多い 普通に解決しても当然のように流される上に問題が起きると「○○するだけなのに何で進まないのか?」って感じを出してくるからどう転んでも本当に疲れる

最近コーディングに限らず、仕事って目に見えない創意工夫や善意によって成り立っていると感じる 発注者が本当にきめ細かく要件が定義できていて問題ないこともあるが、現実的には言ったとおりに機械的に作業したらうまくいかないことは多い

プレイヤーとして作業の工程の想像ができてしまう場合は特に言ってしまいがちだと思う 自分も過去に人にタスク渡すときに「○○をやるだけだと思います」みたいなこと言っちゃったことある気がするんだけどマジで気をつけようと思う