自作カット野菜で一汁一菜をさらに効率化する

もう長いこと味噌汁を食べて暮らしている。土井善晴氏の提唱する一汁一菜生活だ。簡単なので仕事に疲れた日でも作れる。味噌はそれだけで美味しいし具から出汁が出る。具の組み合わせによって細かく味が変わるため、飽きることもない。土井善晴氏のいうとおり、持続できるライフスタイルだった。

 

しかし、いくら味噌汁が楽とはいえ切り物が面倒だった。キャベツは手でちぎれば良いが、玉ねぎや茄子も食べたい。人参やカボチャをちぎるわけにはいかない。どうしても包丁がいる。まな板を出すのも面倒だし、何より刃物を扱うには注意力がいる。疲れた日にやることではない。一汁一菜の唯一の難点が野菜の加工なのだ*1

こうして行き着いたのがカット野菜だ。ただし、カットされた野菜を買ってくるのではなく、自分でカット野菜を作る。好きな具を選べるのが一汁一菜の醍醐味だからだ。

f:id:non_117:20200813191255j:plain

野菜は余裕のあるときにまとめて切り、タッパーかジップロックに入れて野菜室で保存する。意外にもこのカット野菜は五日くらいもってくれる*2。つくりおきの料理はすぐ味が落ちるのだが、生の野菜は美味しいままのようだ。とはいえ一週間以上持つかは怪しい。もし、柔らかくなったら使い切るか冷凍すると良いだろう。

野菜は大きめに切っておく。煮物は放置すれば火が通るので、食べやすい大きさなら何でもいい。それに、ある程度大きく切ったほうが保存性が良いだろう。

 

このカット野菜のおかげで自炊がずいぶん楽になった。帰ってきたら小鍋に肉と野菜、お湯を入れて煮込むだけだ*3。五分から十分鍋を放置し、部屋着に着替えたらもう食べられる。火を止めて泡立て器で味噌を溶いたら完成。三ステップくらいの手数で、出来立ての夕食にありつける。洗い物は鍋だけでいい。鍋だけ洗っておけば次の日の料理もどうにかなる。

 

味噌汁生活では好みの味噌を見つけるのが大事だ。我が家のお気に入りはひかり味噌のマル無だ。乳酸の味がしてとても美味しい。成城石井で見つけた。一汁一菜開祖の土井善晴氏は「おきなわのおみそ」を気に入っているようだ。私も気になっているのだが、まだ入手できていない。

www.hikarimiso.co.jp

人によって好みの味噌は違うだろうから、どうしても味噌探しが必要になる。とりあえず買ってみるしかない。しかし、試しに買った味噌が美味しくなかったらどうするのか。そんな時は別の味噌を混ぜたり醤油や酒、味醂を入れたら良い。顆粒だしを入れて旨味を補ってもいい。ベーコンを入れるのも手だ。土井善晴氏はよく味噌汁にベーコンや揚げ卵を入れている。味噌汁には油を入れるのもありなのだ。結果的に美味しくなったら何でもいい。

*1:肉はカットされたものを買ってくる。

*2:ただし水気を避けること。水がたくさんついていると流石に長持ちしない

*3:うちには電気ポットがある。いつでもお湯が出てくる。

2019年ふりかえり

同人誌を生産する生活

同人誌制作が生活の中心だった。妻が同人活動を始め、それに振り回された一年といえる。妻はもともと絵を描く人だったが、ある日突然漫画も描くようになった。配偶者とはいえ、ひとの趣味なので始めは放置していた。だが、どうも雲行きが怪しい。スケジュールが破綻していたのだ。新刊が落ちるかもしれない、そんな状況で2019年を迎えた。年末年始の休暇をすべて費やし、私はスケジュール管理とアシスタントをすることになった。妻は1日に4ページの作画をこなし、私がベタとトーンを塗る。正月も休むことなく作業をし、締切前日には当然のように徹夜をした。

 

同人誌を作るのは文化祭の準備と似ている。あらゆる手段を使って完成させ、イベントで頒布しないといけない。本を用意できたら対面販売の喜びが得られる。インターネットで得られるただの数字とは違って、目の前の人が本を買ってくれるのだ。狭いスペースに何時間もいるのは疲れるが、精神的にはそれを上回る満足感がある。イベントの熱気に浮かされた我々は、また次の参加申し込みをしてしまうのだった。

 

こうして生活は同人誌制作に支配された。妻は常にネームか作画をしているし、私は余暇の一部でレビューとスケジュール管理、アシスタントをしている。

 

同人誌を一冊作るには2ヶ月が必要だ。ページ数は30〜50くらい。1ヶ月かけて妻がネームを書き私がレビューをする。不自然な話の流れがあれば相談の上軌道修正をする。たいてい終盤が問題になる。自分が何を描いているのか理解するには時間がかかるからだ。なんとかネームを確定させたら残りの1ヶ月で作画を仕上げる。ネームの時点ではコマ割りと台詞しかないので、下書きとペン入れ、ベタ、トーン、仕上げをやる。

 

当然、生活に問題がでた。掃除や洗濯は自動化されていたが、食事が課題になった。調理に時間をかけたくない。だけど、食事の質は落としたくない。共働きな我々は、残業をしたら自炊が難しくなる。ホットクックも使っていたが、調理釜を洗う余裕がなければ運用できない。

 

答えは大量のつくりおきだった。日曜日の夜に、8リットルの寸胴鍋で調理をする。平日は小鍋に取り出して温める。炭水化物はマカロニや白米、パスタ、パンなど。レシピはポトフ、トマト煮、おでんに近い何か、カレー、ハヤシライスなど。野菜と肉を大量に入れて作るので、栄養は完璧になる。

 

飽きないのか?飽きるがそれは問題ではない。外食で移動や食事に時間をかけたり、コンビニごはんで栄養バランスに苦労するよりはましなのだ。もちろん飽きへの対策はある。例えばトマト煮であればマカロニと具だくさんのスープ、チーズを使って電子レンジで焼けばよい。土日が忙しい時はどうするのか?その週は諦める。次の週に挽回すればいい。

 

5日ぶんの食事となると、どうしても調理に時間がかかる。具材を切るのに時間がかかるし、調理の順序に気をつかうと*1、1時間から2時間はかかってしまう。とことん雑な調理をしたら30分でできるかもしれないが、どんな味になるかわからなくて試せてない。だが、2時間の投資で食生活が保証されるなら安いものである。

 

生活の安定性

同人誌生産でも、毎日少しずつ進めると効率がよかった。気まぐれに手を動かす作戦だと、ひとつのタスクが重くなって手をつけづらくなる。重いタスクのことを考えると、脳裏にこびりついてストレスになる。軽めの日課にするとストレスもなく成果が出るようになった。

 

この方針を端的に示すよい言葉がある。

昔、心理学の教授に「ひと鍬(くわ)だけ入れておこうね」ってアドバイスをもらったことがある。

https://anond.hatelabo.jp/20150714165131 *2

ひと鍬とはどのくらいか。漫画だったら一段ぶんの下書き、ペン入れ、ベタとか。読書なら1, 2ページでもよい。よっぽど気力が尽きていたなら、書きかけのページを眺めるだけ、既に読んだところを眺めるだけでいい。もし元気があれば、もっと進めてもいい。

 

毎日少しずつやっておくと、土日にたくさん進めなくてもよくなる。休みの日は仕事の疲れを癒やすのに使うものだ。毎日積み上げた成果があると、土日にだらけても心は軽くなっている。私は身体の言うことに任せて昼寝をするのが好きだ。

 

毎日一定の出力を出すには、生活の安定性が鍵になる。平日はできる限り19時に帰宅し、20時以降は自由にしておく。残業は避け、仕事が多いときは朝を早くする。飲み会もあまり行かない。酒の力を借りた会話は尊いし、楽しいのだが、生活リズムとの兼ね合いが難しい。できることなら16時に退社して飲み始めたい。

 

生活を安定させるには体調が大事だった。体調は睡眠運動食事、ぼーっとする時間に支配されている。特にぼーっとする時間が大事だ。この文章ではこれを無と呼んでおく。無をやる、無になるといった使い方をする。無はストレスを癒やす儀式で、副交感神経を高めるものだ。何もしなくても食後ぼーっとしていれば無になるのだが、ゲームや仕事を始めると無が消えてしまう。無の時間を削ると胃腸が荒れ、体調の悪化に繋がる。もちろん睡眠と運動も欠かせなくて、睡眠の質が運動に依存しているし、胃腸のお天気も運動で決まる。つまり、毎日運動をするしかない。

f:id:non_117:20191207120516p:plain

無をやるぴんくふわねことめんだこ: https://moko-oxygen.booth.pm/ グッズはこちら

 

働いて趣味をやりながら、運動もやるなんて無理なのでは……。私もそう思うし困っている……。鍼の先生によると、食べて1時間くらい経ってから、散歩すると良いらしい*3。とはいえ、時間が厳しい。食後の散歩はまだ習慣にできていない。仕方ないので週1のジムで運動の時間を確保している。

 

体調管理

原稿に肩を破壊された妻が鍼に通いだした。鍼は肩だけでなく体調にも効くらしい。面白そうだ、くらいの気持ちで鍼へ通ってみると、冷え性と胃腸の弱さを指摘された。これには心当たりがあった。冷えとだるさはここ数年の悩みだった。胃カメラを飲んで「ストレス性の問題ですね」で終わったこともあった。

 

鍼へ通うとすぐに効果が出た。初日の晩にはぼーっとして心地よい体調を体験できた。無の強度がすごいやつ。2週間ほど経つとだるさが消えていた。1カ月もすると冷え切っていた足が暖かくなってきた。血流がまともになり、むくみも目立たなくなった。数ヶ月前とは別人のようである。

 

ただし、治療は受け身でいればよいものでもない。鍼に通っても、猫背の習慣がある限り肩こりは治らないだろう。大事なのは、鍼をきっかけに身体の変化を感じとることだ。筋肉を柔らかくしてもらえると、忘れていた姿勢を体験できる。この感覚を観察して習慣を変えると効率的に健康を取り戻せると思う。

 

鍼の体験から身体の観察が大事に思えてきた。Fitbitを使っていても、いまいち数値と体調が結びつかない。睡眠スコアが高くても起き上がれないことはあるし、最高の目覚めをしたときはスコアを見る意味がない。そういえば、人工のセンサーに頼らなくても内臓や筋肉には大量の神経が通っている。腕でとれる情報なんてほんの一部だ。自分の感覚を磨いたほうがいいのではないか。では、感覚を磨くにはどうしたらいいのか。ぼーっとするついでに、体内へ目を向けるのが良い気がする*4

 

本業

人に合わせることを覚えた。今年はチームビルディングに挑戦し、人の割り当てが天から降ってくることを知った。(優秀な)マネージャーは、その場その場で最善を尽くして判断をする。それでもどこにどんな人が当たるのかは運で決まる。あるいは、そう考えたほうがよい。というのも、マネージャーといえども、そのとき手元にあるリソースから選ぶしかないからだ。複雑な社会で商売をやっていると、将来にわたって誰が余るか、どのプロジェクトの優先度が変わるか、なんて予知できるわけがない。その時々の局所最適をやっていくほかない。

 

人の行動はあまり変わらないこともわかってきた。ほとんどの人は自分で制御しきれない癖を持っている。なぜ癖があるのかもわからないし、気がついたらそうしてしまっている。カントも人は曲がりくねった木だと言っているし、そういうものなのだろう。なので、リーダーが柔軟に合わせるしかない。短期的には諦めて、数年後の変化に期待するようにした。不思議なことに、ちょっとダメだと思った行動も半年や数年経つと変わってたりする。

 

行動は自分で考えたときに変わるようだ。他人から指摘をされても、たいてい何も変わらない。これに気づいてからは他人に指摘をしないようになった*5。何か問題が起きたとしても、悪いのは環境や構造である。人間は環境に適応して行動するので、環境整備に気を配ったほうが生産的だ。

 

自分で考えるにはどうしたらいいのだろうか。「自分の考えを疑う習慣」が有効だが、メリットとは裏腹にあまり勧められない。自分を疑う習慣はストレスにつながってしんどいのだ。いったんこの癖がつくと、考えが暴走して休めなくなる。自分を休ませる習慣もセットで身につけないといけない。

 

具体的なフロントエンドの話。redux-sagaで大量のロジックを書いた結果、手足のように使いこなせるようになった。当初は苦手意識があったものの、blocking Effectとnon-blocking Effectの違いを理解したらスルスル書けるようになった。UIと通信が絡み合うときに便利だ。async, awaitより好みかもしれない。

 

reduxは嫌いだったのだが、react-reduxがhooks対応してからはどうでもよくなった。もうconnectは使わなくていい。ただ、管理画面をreact / reduxで綺麗に作れるのかは気になっている。シンプルなアプリケーションならObjectに状態を押し込んでも管理しきれるが、ある複雑さを超えるとOOP的なアプローチをとりたくなる。classとメソッドを使うとshallow compareとの相性が悪くなり、immerやimmutableも出てくる。そもそも複雑な仕様を回避すべき、という話もあるが、ビジネス上の要求によってはそれもできない。compareまわりの問題はreactそのものに関わるので、reactを使う限りはシンプルなObjectに寄せておくのが良いのかも。facebookは複雑なロジックをサーバーに逃がすgraphQL方面のアプローチをとっているが、これが現実的なのだろうか。

 

読書

毎日風呂で読書をしている。風呂蓋の上に本を置き、鉛筆と定規で線を引きながら読む。ジャンルは人文科学、新書、小説など。私の職業はソフトウェアエンジニアだが、家では技術書を読まないようにしている*6。リスク分散を意図していて、視野が狭くなるのを恐れているのだ。

 

今年は社会学だけでなく哲学にも時間を割いた。もともとレヴィナスの全体性と無限に興味があったのだが*7、彼の師であるハイデッガーの本を読み始めたら半年が溶けてしまった。

 

半年もハマったのは、人間がよく分析されていたからだ。私は十代の頃から人間は不思議だなあ、くらいの興味を持っていた。なんとなく情報学の進路を選んでしまったが、人間への興味は諦めきれないところがあった。そのため、情報学の中でも人間を扱うVR人工知能の研究室を選んでみた。だが、研究が全然面白くない。そこに興味はなかったのだ。やる気が出ないなか、しょぼい研究をして卒業し、労働をはじめた。そして数年後、たまたま見つけた社会学者のブログをきっかけに人文科学の読書が始まり、今年になってようやく哲学に行き着いたのだった。

 

ハイデッガーの本来の問いは存在論である。なのだが、議論を進めるさいに人間の分析が必要になる。この人間の分析があまりに現実的で見事だった。心酔した私は、ハイデッガーの書籍、講義録、書簡を読みあさった。3月から9月までハイデッガーを読み続け、一度は熱が抜けたのだが、また最近になって存在と時間の新訳を読んでいる。再読しても発見があり、より深い解釈ができそうなので、人生を通してあと数回は読むことになりそうだ。

 

哲学のほかには、文学、物語も読むようになった。哲学を初めて以降、人間を面白く感じるようになった*8。今はガルシア・マルケス百年の孤独を読んでいる。津原泰水も良かった。

 

現代の本は読まないのか?あまり読まない。社会学と哲学、経済学の知識があると、身のまわりや世の中の出来事を自分で解釈できる*9政治学もあるとよさそうだ。計算機の時代なので計算機科学も役に立つ。もちろん興味深い本もあるが、5年経って淘汰されたものを読むのでもじゅうぶん間に合う。枯れた知識を仕入れるのは、目の前の情報に振り回されるより効率がよい。なので、来年も哲学、文学を読むと思う。あとは政治学言語学をやるかもしれない。

 

おまけ: 今年よかったあれこれ

iPad Pro

アシスタント作業と日記に使う。液タブより描きやすい。風呂蓋キーボードも便利。

GRIII

散歩のお供。ポケットから取り出してシャッターを切るUXがシンプルでよい。とはいえ、iPhoneよりシンプルかというと微妙なところ。タッチパネルに触れただけで起動してほしい。

寸胴鍋

大量つくりおきの道具。

鉄鍋

メンテナンスが楽な製品を買った。炒め物が美味しくなる。揚げ物もできる。

電気ポット

お湯の水割りがいつでも作れる。お湯は自律神経の調整に便利。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

面白くて内容もよい本。システムの設計は依存関係の交通整理だと理解した。

珠玉のプログラミング

システム開発で大事なことが書かれていた。経験的に当たり前なことも、端的に言語化されてる点に価値がある。

SRE サイトリライアビリティエンジニアリング

前半だけ面白かった。章ごとの共著は品質にばらつきがでる。内容も練り上げられてない。

はじめてのUIデザイン

UI設計の入り口としてよい本。ユビキタス言語と絡めた議論ができそう。

データ指向アプリケーションデザイン

必修の教科書。マネージドサービスは裏が分散システムになっていることがある。仕組みの知識がないとパフォーマンスが出せない。

ピアニストならだれでも知っておきたい「からだ」のこと

ピアノの話かと思いきや、本質的な姿勢の仕組みが解説されている。脳は背骨で支える。

医師のつくった「頭のよさ」テスト

頭のよさとは、自分の認知特性を知って最適化することだと説く本。本質的に正しい。各認知特性の特徴が具体的に説明されている。自己だけでなく他者理解にも有用。

知的生産の技術

日記をはじめたきっかけ。50年前のライフハック本だが、今でも通じる。

モビリティーズ 移動の社会学

現代社会の解釈に重要な本。グローバル化、移動の歴史について。

存在と時間

人間がよくわかってわからなくなる。高田の新訳がおすすめ。

コミュニティ

現代のコミュニティは泥臭く政治闘争をする組織。なぜかゲーティッドコミュニティ批判に議論が流れた。

社会学の考え方

ジグムント・バウマン節の本質オンパレード。アイデンティティを獲得するために、市場でアイデンティティキットを買う、という一節が良かった。

書くことについて

スティーヴン・キングの哲学。物語の作り方が本質的に語られる。

ピアノ再開

10年ぶりくらい?に再開した。音が鳴っているだけで楽しい。

日記の習慣

文章の練習と日常の記録、または遺書の代わり。iPhone / iPad / macのメモアプリに書いている。非公開な日記は何を書いても自由で最高。

しなければならないをやめる

予定詰め込みストレス対策。休日に何もしなくてもおおよそ死なないぞ。*10

スカーフ

首元を暖めると全身がポカポカになる。屋内でも首に布を巻く。常に使うので綿製品がよい。

人および自分は必ず死ぬ

存在と時間の影響。これを常に意識している。交通安全と健康意識にも繋がった。

 

課題

姿勢

よい姿勢をとれるが長時間続かない。インナーマッスルや背筋が足りていないかも。身長を1cmあげる気持ちで体幹を伸ばすとよい。

胃腸

運動習慣と食事、無の時間に気をつけたい。胃腸がちゃんと動いていると疲れにくいような気もする。

料理

寸胴鍋料理のレシピを増やす。

*1:さしすせその概念、ソフリットで美味しくしたり。

*2:消えた記事だがtumblrに引用が出回っている。

*3:何も持たずに散歩をするのがよい。歩行の動きで内臓の位置がリセットされるとか。

*4:最近胃腸の動きがわかるようになりました。

*5:ただし、コードレビューは指摘をする業務なので別である。

*6:技術書は業務中に読む。

*7:タイトルがかっこいいから読みたい。まだ積んでる。

*8:同時に、人間がよくわからなくなっている。

*9:解釈しつつ同時にその解釈を疑い続けることに注意する。

*10:毎日少しずつやると矛盾するようだが、休日は少しだけ鍬を入れたらあとは寝ていてもいい、くらいの意図。

React Concurrent Mode雑感

 Concurrent Modeのドキュメントを読みました。useEffect によるFetch-on-render から、Suspense によるRender-as-You-Fetch への変化が本質にみえます。

before

function ProfilePage() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(u => setUser(u));
  }, []);

  if (user === null) {
    return <p>Loading profile...</p>;
  }
  return (
    <>
      <h1>{user.name}</h1>
      <ProfileTimeline />
    </>
  );
}

function ProfileTimeline() {
 // 省略
}

after

// This is not a Promise. It's a special object from our Suspense integration.
const resource = fetchProfileData();

function ProfilePage() {
  return (
    <Suspense fallback={<h1>Loading profile...</h1>}>
      <ProfileDetails />
      <Suspense fallback={<h1>Loading posts...</h1>}>
        <ProfileTimeline />
      </Suspense>
    </Suspense>
  );
}

function ProfileDetails() {
  // Try to read user info, although it might not have loaded yet
  const user = resource.user.read();
  return <h1>{user.name}</h1>;
}

function ProfileTimeline() {
  // Try to read posts, although they might not have loaded yet
  const posts = resource.posts.read();
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.text}</li>
      ))}
    </ul>
  );
}

*1

 いいですね。if (user === null) { が消えています。読みやすいですね。でも、ひとつ疑問があります。resource.user.read() これはなんなのか。
 Facebookの答えはRelayです。Relay is a JavaScript framework for building data-driven React applications powered by GraphQL だそうです。useLazyLoadQuery が重要なhookになります*2。とはいえ、Relayそのものを使えという話ではありません。サーバーとクライアントのお喋りをいい感じにやる君が必要なだけです。後ろにservice workerがいるのかもしれませんし、in-memoryでキャッシュしているかもしれません。もっと素朴に作るなら、Lazy Loadとキャッシュ機構抜きで、データのfetchと加工を隠蔽してくれれば大丈夫です。
 Suspense を使ってとりあえずrenderされるUIを作るには、賢めのデータとる君が必要になりそうです。自作をしても良いですし、Relayのようなフレームワークに乗っかってもよいです。最悪なのは、resource.user.read() の行でfetch し始めることです。UI定義の中でエラーハンドリング、データの変形をやり始めると、Presentation Domain Separation*3から遠ざかりますし、何より読みにくくなります。
 元はといえば、useEffectの時からそうでした*4。何でも非同期処理を書けるのでuseEffectは割れ窓にできます。componentDidMountの時代から可能だったと言えばそう。Facebookにいる人々のレベルが高いからかもしれませんし、React is a JavaScript library for building user interfaces の責務に忠実だから危険なほどの自由さがあるのかもしれません。Reactの各種APIはとても便利にできています。プログラマは柔軟にUIを構築できます。ですが、Reactでメンテナンスしやすいコードを書くには(そこそこ深く)考え続けなければなりません。自由とはそういうものですし、制約の少ないフレームワークにするのがReactのやり方なのでしょう。私は自由と考え事が多いものは好みですが、チームで開発すると苦労は増えます。

f:id:non_117:20191103204013j:plain
積み木をするめんだこ
*5
 Reactは着実に進化しており、ますます柔軟にUIを作れるようになっています。Presentation Domain SeparationとReactの自由さ、開発者のスケーラビリティすべて満たすのはたいへんそうだなと思ったのでした。

 イラスト、プログラミング、文章などは意図が何か? 観察はしたのか?この二つの問いでレビューできてしまう。できることなら問いかけないほうがよい。この二つは終わりがないので誰に投げても刺さってしまう。だが、あまりに質が低いとき、手癖でやっているときに問わざるをえない状況もある。目的が存在する業務ならば、目的とコストのほどよいバランスで両者の探求を打ち切ることはできるが、目的をはっきり認識できていない人にこれを投げると無限の地獄に放り込まれるので、特に注意して使いたい。

redux-sagaのall([fork])パターンは、即座にfinallyに突入してしまう

function* subtask() {
  try {
    yield all([
      takeEvery(action, hoge),
      fork(poyo)
    ])
  } finally {
    if (yield cancelled()) {
      // 後処理
    }
  }
}

subtaskがcancelされたときに後処理が実行されてほしい。ところが、この書き方だとただちにfinallyブロックが評価されます。cancelledはfalseを返すので、後処理はうまく行われません。

yield all([
  takeEvery(action, hoge),
  fork(poyo),
  take(dummyAction),
])

みたいなことをするとfinallyに突き抜けることはありませんでした。

なお、ちゃんとドキュメントに書かれていました。

redux-saga.js.org

There is another popular pattern when designing root saga: nesting fork effects in an all effect. By doing so, you can get an array of task descriptors, and the code after the all effect will be executed immediately because each fork effect is non-blocking and synchronously returning a task descriptor.

Note that though fork effects are nested in an all effect, they are always connected to the parent task through the underlying forkQueue. Uncaught errors from forked tasks bubble to the parent task and thus abort it (and all its child tasks) - they cannot be caught by the parent task.

よかったですね。allの中身が3, 4個くらいならばallを使わずに書くのがわかりやすいかもしれません。

redux-sagaはblocking Effectとnon-blocking Effectの区別が死ぬほど重要です。注意してやっていきましょう。

であること、できること、すること

であること、できること、すること

2019/07/31

 「であること」は、過去のその人の特徴を他者から判断したものになる。例えば日本人である、医者である、社長の息子である、東大生である。これらの特徴は生まれもった環境的特性や、本人の行動によって獲得された社会的地位などの特性がある。

 「できること」は、その人が今できることである。能力に近い特性。東大生であっても高校化学の内容を全く忘れていれば、東大生ではあるが、高校化学ができないことになる。「であること」を達成するのに必要な能力と、今できることは必ずしも一致しない。「できること」は、箸を持てる、浴衣を自分で着ることができる、微分方程式が解ける、というように「であること」と同様の様々な尺度が考えられる。

 「すること」は、将来の自分に対して行動を起こすことである。漫画を読めば同じ漫画を読んだ人と会話ができる。英単語を日々覚えていくと、英語を素早く原語のまま読むことができるようになる。

 これらを総合すると、「すること」が起点となって「できること」が増えて、それを他者に認められることで、「であること」が達成される構造が見える。「すること」と「できること」は、おおよそ個人の行動の範囲内で完結する。また、これらを厳密に区別することにはそれほど意味がない。そして、「であること」はただの結果である。まったくの他人に自分の業績を知らしめて第一印象を良くすることには役立つが、「であること」にしがみついて、しかし、今は何もできない人はたいてい信頼されない。それゆえ、結果の「であること」だけに拘泥するのは意味がない。

 そして、この構造は自信、自己肯定感の問題にもつながる。また、自由の問題にもつながる。「であること」が本質的には無意味であること、これを「であること」にこだわるひとはうっすらと理解している。理解しているが、認めてはいない。それゆえ、不安である。自信につながるのは「できること」である。そして、「できること」は直接的に積極的な意味での自由につながる。「すること」は、将来の自信と自由を培う基盤となる。

 ここで抗しがたい、「できること」を制約する基盤がある。自らの肉体である。老いは「できること」を否応なく減らしてゆく。病気も同様である。あるいは、先天的、後天的な不利益が肉体に降りかかっていることもある。残念なことに、これは生物としての特徴なので覆すことはできない。であるならば、身体に制約されない、できることを増やすのが将来的な自由の最大化につながるのだろうか。知識を使えること、考えられること、これらは肉体の衰えよりは長く保持できる能力であろう。知ることは重要な自由の基盤といえる。

 知ることをしなければ、知らないことを知ることができない。無知の知はそれ自体として重要な性質であるが、自分の無知の具合を知るために知識(経験も含む)が必要になる。知識を得ること、経験をすること、どちらも「すること」である。

 「すること」は何に対してでも可能なのだろうか? しばしば起こる悲劇は、自分の欲求を無視して、他者からの評価、「であること」を想定して、「できること」、「すること」を逆算する事例である。プログラミングに興味がないのにソフトウェアエンジニア「であること」を求める人、患者を癒やすことに興味がないのに医者「であること」を求める人、いくらでも事例はある。もちろん、知識を増やすことは無知を知ることにつながる。なので、興味がおこらない領域の知識を得ることは将来的な糧となる。だが、「すること」はある日少しだけやったら良いものではない。「できること」に繋げるには、「すること」を繰り返し何度も、大量にやっていく必要がある。毎日興味のないことをやるよりは、少しでも興味のある、本当に興味のあることをするのがよいだろう。たいてい、興味のないことをし続けるのは無理だと思われる。

 残念ながら、資本に恵まれない我々は労働をし続ける必要がある。対価の額はおおよそ椅子の種類で決まっている。ここに、興味がなくても「できること」を増やさざるをえない構造がある。我々にとって最適な行動は、「できること」を金銭に変換する効率を上げること、そして労働ではない時間を最大化して、他の「できること」を増やす方針だろうか。興味のある「できること」「すること」が対価を稼げる業と一致している人は幸運である。しかし、実は「できること」が何であるか、興味の対象であるか、は問題ではない可能性もある。「できること」は自信と自由につながるため、自信の基盤を得たあとでは「できること」が何でも良かったと思うのかもしれない。

ソフトウェア設計のための柔軟性とスケーラビリティを考える

ソフトウェア設計のための柔軟性とスケーラビリティを考える

2019/07/15

 

 ソフトウェア設計の目的とは何か。ソフトウェアをお金を儲けるための道具=システムとして作る場合、重要な目的は柔軟性とスケーラビリティである。

 変動し続ける社会環境や、競合によるお金儲けの環境変化に対応するために、柔軟性が必要になる。現実が変わったら収益源のソフトウェアも対応しなければならない。さもなくば、競合に対する優位性が減り売り上げの低下につながる。

 そして、スケーラビリティは自社の市場を広げるために求められる。ここで私が述べているスケーラビリティには二つの側面がある。

  1. ユーザー数が増えて、システムで使うリソースを増やせるようにすること
  2. 市場の拡大に伴って巨大化したソフトウェアの開発と運用が業務として無理なく回るようにすること

巨視的なスケーラビリティ

 システムがサーバーで動いている以上、システムを動かすために物理的なリソースを必要とする。ユーザー数が増えたらサーバーを増やさなければならない。簡単にサーバーを追加できるのならば話は簡単だが、下手な設計をしているとサーバーを増やしてもシステムがスケールしなくなる。

 ここで重要なのは、サーバーが増えても律速しにくい巨視的な設計である。巨視的な設計とは、データベース、アプリケーションサーバー、オブジェクトストレージ、ログ収集機構、メール配信、バッチ処理などの大きな単位でみた部品の結合関係を整理し、あらゆる部品で処理が詰まらないように作ること。

 この設計がなぜ難しいかというと、具体的な実装の細部を無視し、抽象化された部品として整理をしているからである。部品として抽象化するさいに、部品の知識が足りないとシステムはスケールしなくなる。システム全体へ影響を及ぼす重要な特徴を抽象化によって捨ててしまうからである。抽象化は情報を捨てる特徴を持つので、知識の欠如、観点の偏りが決定的なミスにつながる。

 システムをうまく抽象化できたとしても、スケーラビリティを求めるのは終わりがない。factorioisuconで体験できるように、システムを作ると必ずどこかで律速する。律速した場所をチューニングしても、また別のところが律速する。現実的にはどこかで妥協をする必要がある。

機能の複雑化と戦うスケーラビリティ

 二番目の問題。ソフトウェアが巨大化すると言っているが、なぜ巨大化するのか。ユーザーに見せるUIはユーザーの目的に対して一直線に問題を解決するものが理想だ。シンプルに作れるならばそれが一番よい。だが、たいてい複雑化して巨大化している。なぜなのか。

 ユーザーの目的が複数あるケース、これはどうしようもない。開発し始めた当初は大雑把に認識していた目的が実は人によってバリエーションに富んだ目的だった。タスク管理ですら、ユーザーの立場や業種、知識に応じて目的が違うはずである。これがタスク管理システムが乱立する理由である。ともかく、このように大きな領域で仕事を始めると見えていなかった目的が乱立することがある。この場合にはすべての目的を需要に応じた妥協をするとはいえ、リソースの許す限りすべての需要を満たしたくなる。

 それゆえ、画面は複雑化し機能は増え続ける。市場規模、ユーザー数が拡大すると、これは避けられない。何故なら、人間は自分の目的に完璧に合致していなくても、便利な道具があればそれを使うから。システムの意図した目的と人間の目的が完璧に合致するならば、システムに変更は入らないが、少し目的のずれた場合には変更の要求が発生する。最初は心地よく使えていても、日常的に繰り返し使うことによって、この目的のずれが体験の悪さとなって現れる。なので、ユーザーを増やさなければならない資本主義の仕組みに乗る以上は、ユーザーの目的が多様化することを避けられない。よって、システムは複雑化してしまう。

 本来ならば、機能が増えすぎたらそれを整理して圧縮するのが望ましい。機能ごとに利用頻度の統計をとるのもよいだろう。だが、似たような目的を複数の機能で実現しているシステムはあまりに複雑化しすぎている。ここで、機能を統合して減らす決断が必要になる。たいていの人は機能、コード、部品を増やすことは簡単にできる。だが、減らすのは難しい。増やすことによって発生する責任は軽いが、減らすことによる責任は重い。確固たる思想を持って、このシステムの本質的な目的は何なのかを見定めておく必要がある。

 また、管理画面の機能が増え続ける問題もある。ユーザー数が増えると、サポートやお金の管理、監査、データ収集などの管理画面を使う社内の人間のための機能が増える。これらは自動化されていることが望ましい。それが会社の利益率に直結するからだ。こちらもユーザー数が増えるにつれて機能が増えて複雑化する。規模が小さいうちはラフなデータを出力して、人間が加工をすればよいが、組織の拡大とともに規模が大きくなると、専用の自動化が必要となる。

 

 以上観たように、広い意味でのスケーラビリティを完璧に満たすのは難易度の高い設計が求められる。管理機能まで含めた全体を見渡す立場の人がいれば、まだましだが、機能ごとに担当者、チームが別れていると全体の調和を目指すのは難しくなる。こうしてコミュニケーション能力が求められる。人間のコミュニケーションが増えると、それもそれで組織のスケーラビリティを阻害する要因となる。これはまた別の話ができるだろう。

 

まとめ

  • お金儲けのためのシステムは、会社が存続し続けるために柔軟性とスケーラビリティを備えたシステムを作る
  • スケーラビリティは巨視的なスケーラビリティと機能の複雑化と戦うスケーラビリティがある
  • 巨視的なスケーラビリティは開発者にとってお馴染みのシステム構成の話で、抽象化の漏れが致命的になる
  • 機能の複雑化は市場の拡大によって確実に引き起こされる
  • システムを運用するための社内の組織、システムを運用するためのシステムが増える
  • 人間がシステムを作る以上、人間と人間のスケーラビリティも視野に入る

おまけ

 つまり、システムの設計とは何なのか、何をしているのか。これはお馴染み問題解決能力と同じもので、「目的と制約を明確に認識して、目的を満たす最小コストの方法を見つける」ことである。目的は法人の場合は法人の維持、つまり利益率の維持、よってお金儲けであり、制約はソフトウェア技術、ハードウェア、人間の能力、法律などである。

 規模の拡大は外部からの要請によって求められる。投資家や株主など。資本主義は投資対象が毎年成長することを求めるシステムなため。

 柔軟性とはスケーラビリティを満たすために必要な性質なのではないか、この疑問も出てくる。おそらく正しい。柔軟性はシステムの目的でありスケーラビリティのための手段でもある。これを考えるには柔軟性も詳しく分解していく必要がある。素描しておくと、

  1. 柔軟なところと変わらないところの区別
  2. 変わりやすさを見抜く未来予知の話
  3. 未来予知に必要な広い教養の話

あたりだろうか。