読書記録：『生産性』伊賀泰代
ちきりんの中の人として有名な伊賀氏の本。
タイトルがキャッチー。
印象に残ったのは、生産性を上げる方法は2つあり、
①固定のコストを削減する
②売上を増やす
ってとこ。
日系サラリーマン企業に勤めているからか、①ばかり意識して②を考えていなかった。
あとはマッキンゼー流○○。
テクニックの話で、しかも生産性とあんまり関係ないので飛ばした。
なんとなく、出版社の意向でタイトルが決まったのかなーと感じた。
よくわからない世界
今日はやりたいことがあって、いろいろ試したけどできなくて１日潰した。
情報をWebで探して試して、探して試しての繰り返しでしんどかった。
仕組みがわかっていれば、情報をフィルタリングしたり、やり方を工夫したりできるんだけど、今日は知らない世界だったからできなかった。
仕事をしていると、やらなきゃいけないことがあるけどよくわからないから知ってる人に聞いて、聞いたことを試して、できなかったら聞き直したり他の人に聞いたりしてやることがある。
自分が知っている仕事だと、自分で判断したり勘所がわかったりするので楽だ。
やっぱ、「なんとかしてどうにかする」やり方よりも、仕組みを理解してやる方が好きだな。
ユースケースドキュメントの形式をどこまで整えるか
形式は厳密に決めなくてよい。
ケースとして、以下の2つのどちらでもよい。緻密さは状況により調整する。
１．ミッションクリティカルな大規模システム。メンバーは取り決めに従った手続きにはコストを掛ける価値があると考えている。よって、
・ユースケースのテンプレートはより長く詳細なものになる
・曖昧さや誤解を減らすため皆が決められた形式で書かなければならない
・漏れているものはないか、曖昧な点がないか詳細に調べるため、ユースケースのレビューはより厳しいものになる
誤りに対する許容度が低く、ユースケースを書く場合の許容度（個人差）も低い。
２．３〜５人のチーム。作成するシステムは、最悪の障害が起きた場合でも便利さが失われる程度で、電話をかければ事足りる。メンバーはすべての形式的な手続きは時間や労力、お金の無駄だと考えている。よって、
・テンプレートは単純にする
・記述形式には様々なバリエーションを認める
・レビューの回数は少なく、許容度もゆるやかにする
記述の誤りや漏れは、プロジェクトのほかのメカニズム、おそらくチームメイトやユーザとの対話を通じて発見することになる。文書によるコミュニケーションに含まれる誤りに対して寛大になれるため、略式の書き方や人による違いを容認できる。
弁当化計画1
先週と今週の土日に白米で試し炊き。川崎は水がまずいのでミネラルウォーターを使おうか迷ったが、試しなので水道水で炊いた。特に味に違和感はなかった。久しぶりに炊きたての米を食べた。こっちでは弁当ばかりで、実家に帰ったときくらいしか食べないから。やはり米はうまい。
日曜に弁当用の炊き込みご飯を作った。なぜ炊き込みご飯かというと、①おかずを別に持っていく必要がない②炭水化物過多を防ぐため。
①、まだおかずを作って弁当にするほど慣れてない。冷食もアリだけど、冷食では元々の目的である「健康的な食事&できれば食費節約」を達成できない可能性が高い。ただし、最近の冷食はかなりクオリティが高いらしく、自分の冷食のイメージと乖離がある可能性も高いので知識のアップデートは必要。
②、案の定米を炊きだしてからは米ばかり食べている。米はほぼ糖分なので体脂肪率がやばい今は本来は取るべきではない。せめて少しでも糖分率を下げたいので、米に野菜や肉を混ぜてかさ増しできるまぜごはん系にした。
どのくらい減らせているかというと、米Onlyであれば5合炊ける炊飯器だが、ゴボウ、人参、鳥肉、ひじきを入れたところ米は3合までしか入らなかった。2合分の炭水化物を節約できる。今回は炊き加減がわからなかったため米3合としたが、水の量が多すぎてベチャベチャのおかゆ未遂であった。今後この炊き加減のコントロールができるようになれば、キノコやコンニャクなどを入れてさらに炭水化物の割合を減らすことが可能となる。
この炊き込みご飯を作るための材料費(米や炊飯器自体は含まない)は1000円弱。3〜4食分になるので弁当に比べればコスパは良い。今回は適当な材料に加えて調味料も買ったが、工夫すればさらに下げることも可能。
弁当箱はジップロックのタッパーを使用。レンジも使えて必要十分。
今後の課題はさらなるコストの削減と緑黄色野菜の不足を解消すること。
サロゲートキーは使わない方がいい
サロゲートキー(代理キー・人工キー)を振っとけば楽だけどあんまよくない。サロゲートキーは1レコード1キーでわかりやすい。取り出すときも一つのキーだけ合わせればいい。
場合(チューニング)によってはそれがいいときもあるのかもしれないけど、基本的に(特に概念レベルでは確実に)ナチュラルキーを主キーにした方がいい。
理由は「ナチュラルキーでないと、本来のデータモデルがわからなくなるから」。本来(業務上・仕様上)、どの属性にどのテーブルのレコードが依存していて、どの属性に従属性があって、というのが、サロゲートキーでは見えない。本来重複してはいけないデータの重複の危険性もある。キーが違うから属性一緒でも登録できちゃう。
データモデルを現すときには、必ずナチュラルキーを使うこと。そのあと、物理的に問題がある場合のみサロゲートキーを用いること。
DBエンジニアの世界では常識のようです…。
追記
データウェアハウス（大量のデータを長期で保管したい場合など）では、ナチュラルキーが変わる可能性がある場合に、サロゲートキーを追加して履歴管理を行うことは一般的らしい。
米を炊く計画
3年ぶりくらいに米を炊こうと思う。
理由は職場が変わって食生活が悪くなりそうだから。以前は職場のビルの1Fにスーパーが入っていたので、スーパーの弁当を買うことができた。スーパーの弁当も焼肉やアジフライやカツ丼みたいなのが多かったけど、鮮魚コーナーに寿司類があり、マグロ丼やいわしの握りなどが400〜500円で手に入るためよく食べていた。摂取する油を極力抑えるために魚、できれば美味しく栄養価も高い生を選んだ
今月から職場が変わり、スーパーを利用できなくなった。イオンがあるがやや遠く昼は面倒。弁当屋が来るが肉や揚げ物ばかり。肉と揚げ物が受けるのか、それともコストの問題か。あとはコンビニ。コンビニ弁当は大して美味くもないのに高い。米はテカテカ、肉はベタベタ、パスタには油が絡み申し訳程度の野菜はとても毎日買う気はしない(たまには買う)。
また先月から残業が減ったため、夕食の自炊のために冷蔵庫を購入した(三菱のMR-P17Y。静かでとても使い勝手がいい)こともあって、いよいよ弁当を自作することにした。食費の節約にもなるしちょうどいい。
とはいえ、生きとし生けるもの全ての基本である米を炊くための炊飯器がない。2〜3年前にダイエットの一環で炭水化物を減らした際に炊飯器を廃棄してしまったので。ボロいやつだったからどのみち持ってても買い直しは必須。
今後の計画
・炊飯器を買う。15k〜20k。
・使い捨ての弁当容器(レンジ可)を買う
・土日にまとめ炊きして、1食分ずつ弁当容器に入れて冷凍する
・平日はそれに適当なおかずを入れて持ってく。冷凍のまま。昼に職場のレンジで解凍
・最悪おかずだけイオンで買う。面倒だけど波に乗るまでのつもりで
・できれば朝ごはんも。毎朝コンビニおにぎりに200〜300円使うのをやめたい。朝食抜きはナシ。昼前に腹が減って集中力が落ちるから。
・米は実家に依頼済み。
以上
ドメインとは何か
ドメインはITのお話してると頻繁に出てくるけど、
いちばん分かりやすく言うとドメイン＝単位。
あるいは制約。(単位は制約の種類のようなイメージ)
例としてよく使われるのが日付だけど、これは「日」が単位。
だから、単位が同じであるデータ
（たとえば「製造年月日」や「賞味期限」）
のドメインは「日」（または「日付」や「年月日」）となる。
もうちょい詳しく言うとドメイン＝同じ制約で定義されるデータの概念。
同じ制約ってのはたとえば「日付」だったら、
・YYYYMMDDの8桁であり
・YYYYは1900以上の整数であり
・MMは1以上12以下の整数であり
・DDは1以上31以下の整数であること。
・ただし、MMが02のときDDは28以下でなければならない
・ただし、YYYY/4が0かつMMが2の時DDは29うんぬんかんぬん
みたいな。
一般的に日付っぽいデータってのはここらへんの制約に縛られてるけど、
それを明確に「日付」はこうである！ってのを定義するとそれがドメインになる。
ドメインを定義することである属性の集合をひとつのエンティティとして扱うことができる。抽象化されるので変更に強い。管理しやすい。
ってのは理想なんだけど、実際はそんなに綺麗にデータモデルを設計できるケースなんてほとんどないので形骸化してるところも多い。ドメイン=データインスタンスになっちゃってなかなか抽象化はできない。
