  |
昨年、一念発起して100kgの大台から70kgまで、30kgの減量に成功した。
やたらと知見を共有したがるのはエンジニアの美点の一つだが、私もその例にならい、ここにダイエット中に学んだことを共有しようと筆を執っている。
ダイエットとはそもそも、日常の食事のことを指し、それが転じて食習慣の適正化を意味するようになった。
減量の本質もそこにある。
人は食べたものからできている。食習慣を適正化すれば、自然と健康的になる。
30kgもの減量に成功した最大の要因は、自分がエンジニアであったことだと思う。
そもそもプログラミングとは、入力されたデータに対して任意の出力データを得るために加工する、その計算方法を設計し、実装することを指す。
料理もまた同じで、食材という入力に対して、調理を実施し、料理という出力を得る。
そのため、体重と食習慣の適正化というプロジェクトに対して、プロジェクトのマネジメント手法が応用可能なのだ。
メモリ4GBのオンボロPC抱えてパイプ椅子で開発すすめても、ろくに進捗しないのと同じだ。
ただし、闇雲に金をかければよいというものでもない。投資すべきものというのは、だいたい決まっている。
どれも無くても減量自体は可能なものばかりだが、あったほうが効率が良い。
そもそも減量はモチベーション管理のゲームなので、自動化、簡易化できるところはやったほうがいい。
金を払って健康を買っていると考えればよい。
まったくアーキテクチャを考えず、行き当たりばったりでファイルごとに違う設計のプロジェクトは悲惨な結果を招く。
最初にこのアーキテクチャで行くと決め、ひとまずはそれを続けることが大事だ。
減量で言えば、ローファットでいくかローカーボでいくかということだ。
日によって低脂質でいったり低糖質でいったりするのは全く良くない。
自分は低脂質でいくことにした。そのほうが筋肉量の減少を抑えられるし、コレステロール値の改善にも効果的だからだ。
金融系プロジェクトにありがちな細かすぎるコード規約は有害無益で時間と金の無駄だが、余りにフリーダムなのも混乱のもとである。
減量でいえば、目標カロリー量とPFCバランスだ。ここがいい加減だと、到底うまくいかない。
カロリー量はハリス・ベネディクト方程式から出される基礎代謝の1.5倍とかに設定すればよいだろう
そのうえで、低脂質ならP:30%, F:20%, C:50%のように割り振ろう。
たとえば1600kcal目標なら、P: 480kcal = 120g, F: 320kcal = 35g, C: 800kcal = 200g、といった感じだ。
この規約を守るためにも、あすげん/カロミルがあれば、計算が楽だったというわけだ。
プログラミングでは、実行時に行うと重すぎる計算はビルド時など事前に行ったりすることがある。
初代スーパーマリオブラザーズのジャンプは、1フレームごとに重力係数をかけて計算しているわけではなく、加速度がハードコードされている。
ブロック崩しでさえ物理演算するような現代においても、似たようなことをすることはある。
ダイエットで言えば、時間的余裕のあるタイミングで、できることをしておけということになる。
キャベツを千切りにしたり、きゅうりやトマトを切ったり、オートミールに材料混ぜておくことは事前にできることなのだ。
夜寝る前などにやっておき、明日の調理工数を最低限にしておくことが大事だ。
処理したものはジップロックコンテナにでも入れて、冷蔵庫にしまっておこう。
よく食べる鶏むね肉や牛もも肉なんかもキロ単位で大量買いして、1食量ごとに切り分け、ジップロックバッグに入れて冷凍庫に入れておこう。
適切なキャッシュがもたらす実行速度の向上効果は非常に大きい。
これは料理についても言える。
毎食ごとに献立を考え、材料を揃え、包丁で切ったり、コンロで焼いたり…などの調理を行うのは非常に非効率である。
いわば冷蔵庫はメモリキャッシュであり、冷凍庫はディスクキャッシュのようなものである。
よく1人分作るのも3人分作るのも変わらないよ〜などと言うが、同じ理屈で1食分作るのも、3食分作るのも、手間としてはたいして変わらない。
すでに広く使われ、実績のあるライブラリがあるのに、なぜ一から作らなければならないのか。
これはダイエットについても言える。
安価で大量に手に入るカット野菜などは、買ってしまえばいいのだ。
たとえばきんぴらごぼう。作ると面倒なきんぴらごぼうだけど、その面倒さの9割はごぼうを千切りするところにある。
千切りして水にさらし終わったら、きんぴらごぼうの調理工程の9割は終わっている。
しかもこの部分は、工数が量に依存しているため、大量作成の恩恵を受けづらい部分だ。O(n)である。
一方でカットごぼうを大量買いすれば、あとは炒めるだけなので量に依存せず、大量作成が容易になる。O(1)にすることができる。
他にも、オイコスヨーグルトとか、サラダチキンとか、Baseブレッドなどの外部サービスを使うのも良い。
プロジェクトの初期段階、リードエンジニアが重要なクラス群とサンプルとなるクラスをいくつか作った後は、それをひらすらに横展開していくことになる。
この段階では天才エンジニアなど必要なく、コピペマンでじゅうぶんになる。むしろ下手に独自の考えを持たず従順に開発してくれるぶん、そのほうが良いことさえある。
ダイエットについても同じことが言える。
なぜ毎食毎食、独自の健康メニューを考え出さないといけないのか。食事の都度、栄養成分を計算し、調整しなければならないのか。
あすけんで一度100点をとったらあとは、ひたすらそれをこすり続ければいいだろう。
朝
蒸しかぼちゃ
昼
ふかしたさつまいも
蒸しかぼちゃ
夜
りんご（皮ごと）
蒸しかぼちゃ
毎食似たようなものを食べていることがわかるだろう。
これは日単位でも同じで、別の日は牛もも肉が刺し身になったり、さつまいもが蕎麦になったりはするが、その程度の差だ。
どうしても違うものが食べたくなったら、そのときに改めて計算すれば良いのだ。
そうすれば手持ちのカードが増えていく。
インシデントが発生したとき、必要なのはリカバリーであって、そんな時に人を責めても何の役にも立たない。時間の無駄だし、士気も下がるだけだ
こうしたとき、自分を責めても仕方がない。自分をクビにはできないし、ダイエットは長期戦なのだ。
ある日に食べすぎたからと言って、次の日にその分を減らすと、必要な糖質や脂質が不足して代謝が落ちてしまったり、だるさが抜けなくなったりするため、そういう方向でのリカバリーはやめよう。
しっかりと痩せる食事スタイルが確立しているなら、それを続ければ良いだけだ。
どうせ1食程度ではそんなに太ることはできない。
計測は減量期間中だけでなく、むしろ減量終了後にこそ必要になる。
そもそも、減量前の食事が減量前の体重を作り上げてきたのだから、減量前の食事に戻せば、体重も戻るのは当然のこと。
もとの体重に戻りたくないなら、新たな食習慣を作り上げる必要がある。
プロダクトリリース後、つまり減量後の運用フェーズにうつったら、減量飯でもデブ飯でもない、心にも体にも良い食習慣へと移っていこう。
急激なUI変更がユーザーの反発を招くように、急激な食事変更は体重の反発（リバウンド）を招く。
そこで、オートミールだったところを玄米ごはんにするとか、ささみだったところを蒸し鶏にするとか、ちょっとずつ維持するためのご飯へと変えていき、どのくらいの量なら大丈夫なのかを見つつ、ソフトランディングしていこう。
40
