クリティカルチェーン(CCPM)を読んでみた（やってみた）
久しぶりの書評。いまさら次郎ですが１０年前の本、クリティカルチェーンを読んでみた。きっかけは自分の会社のプロジェクトで別のPMのひとから教えてもらい、一部導入（めっちゃ一部）してみて一定の成果があったので改めて勉強したいと思い、以下の原典からあたってみた。
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
- 作者: エリヤフゴールドラット,三本木亮
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2003/10/31
- メディア: 単行本（ソフトカバー）
- 購入: 12人 クリック: 142回
- この商品を含むブログ (119件) を見る
目次
- やったこと
- 読んでみて
- これからやること
やったこと
バッファ管理を変えてみた
これまでは、今までのPJの実績や個人の経験で細分化した各タスクの工数を見積もり→バッファを載せて管理見積もりをしていた
直近のPJでは、各タスクをバッファなしで見積もり、バッファをまとめて【PJ全体のバッファとした】
良かった事
もともと見積もりはぶれる事をメンバで合意しているから、一タスクの遅れに一喜一憂する事がなくなった！（即スケジュールやWBSを見なおす必要がなくなった）
おそらく納期まで工数はのびるの法則があるから、各タスクが早く終わっても前倒さない夏休み症候群がなくなるから
特定の手法などを使うと改善が行いやすい。失敗しても、成功しても振り返りがやりやすい。
読んでみて
- PJの遅延は機会損失につながることから、早く終わらせることは価値がある
- スケジュールを間に合わせる！という事にフォーカスするのは自社開発のサービスには相性がいい
- バッファは個々人によって見積もられる、さらにマネージャーに足される。こうやって作られる。
- クリティカルパス等のボトルネックに注力する（集中できる）
- 人間の心理をPJには加味できることがわかった
- ボトルネックとは制約条件の事。制約条件に如何にフォーカスするかが分かった
- 時間を金で買う。これは現在のビジネスでは必須の考え方だなと。サラリーマン思考に反省
- TOCの思考そのものをもっと学びたいなと思った
- 各バッファが食われるアラートに注目する
Hadoop/hiveのバックアップとデータ移行
なんだか最近Hadoop周りしか記事書いてない気もしますが、誰か見てるかもしれないという希望的観測のもと、Hadoop/hive の組み合わせという多分一般的な構成の手動でのアナログ的なバックアップ手法、及びデータ移行についてメモっときます。
手順
1. HDFS の /user/hive/warehouse/ をLinuxファイルシステムのファイルとして保存
hiveのデータはHDFS の /user/hive/warehouse/ に格納されてますのでこれをLinuxファイルシステム（ローカル）として抽出し、圧縮、またhiveのmetastoreも合わせてバックアップ
$ hadoop fs -get hdfs://{fromhadoop_host}/user/* ./
$ tar zcvf hive_warehouse.tar.gz hive/
※{fromhadoop_host}部分は移行元のIP or hostを指定します
2.hive metastore のデータをダンプ
データと合わせてhiveのメタストアをバックアップします。今回はhiveのmetatoreにmysqlを利用してるのでmysqldumpコマンドでバックアップします
$ mysqldump -u root -p hive > dump
3. 上記、２つをデータ移行先で復元する
1.2 で取得した、hiveのデータとmetastore(mysqldump)を移行先へ転送
$ scp hive_warehouse.tar.gz exsampleuser@{tohadoop_host}:
$ scp dump exsampleuser@{tohadoop_host}:
バックアップならここまでで終了ですが、別のクラスタへの移行・復元する場合。
metatoreをリストア
$ echo "drop database hive; create database hive;" | mysql -uroot -p
$ mysql -u root -p < dump.sql
hiveデータを解凍してリストア
※既存データを削除して行う
$ hdfs dfs -rm -r /user/hive/warehouse
$ tar -xzvf hive_warehouse.tar.gz
$ hdfs dfs -put hive/warehouse /user/hive/
※旧構文 hadoop dfs -rmr
嫁とひざまくらとビール
嫁に膝枕をしてもらっている。嫁はビールを飲んでいる。
しごとから帰り癒しの最高の形のひとつがみえました。
それぐらいがちょうどいいか。と思う。
良いじゃないか、たまにはコードを書かなくても、人間だもの
戦うサラリーマンの皆様にお勧めします．
至高の一品 -ウオッチバンドカレンダー-
引用：http://item.rakuten.co.jp/taisei-honpo/001/
このデジタル社会でも、結局卓上カレンダー。な人いますよね。私もそれです。
これなんで廃れたのか分からんぐらい秀逸なんですけど。。。
間違いなくスマートウォッチ越え。
AWS料金の割引について -リザーブドキャパシティ-
今さら次郎な感じはありますが、AWSでは一定使用量をコミットする事によって割引を受けられるリザーブドキャパシティという契約があります。こちらは契約内容（割引適応量）や割引金額は公表できませんが、そもそも知らんかった！という人のために概要をご紹介します。
なにができるの？
- 毎月一定量の利用（最低利用料金と読み替えても良いです）を約束するとお安くしまっせ
- 各サービス毎に契約（EC2,CloudFront,RedShift等・・・）
- １２カ月〜契約可能
予約容量とは、お客様に 12 か月またはそれ以上の月間最低使用レベルを約束していただくオプションで、その代わりに大幅な割引価格を提供するものです。予約容量契約は、単一の領域からの毎月のデータ転送量 10 TB が最低ラインです。約束していただく使用量が多ければ、追加の割引が適用されます。
引用：公式サイトより
最低料金をコミットなのでこちら、10TBを絶対使うではなく割引適応後の単価で10TB分の費用は絶対払います。という事を考えて、割引後の価格がお得か以下のように計算できます。
例）例えば、日本リージョンのCloudFrontの場合
10,000GB[10TB]×($0.201[GB単価] - 割引金額 ) > 現在の利用料金
なら、最低利用量（今回の場合10TB）に達していなくてもお得ということになりますし、契約は可能です。あくまでAWS側は10TB行かんくても、使ったとみなしまっせ！というスタンスですので絶対に10TB以上の利用量使ってないとダメ！という事ではありません。
いつ、どこで、どうやるの？
- 問い合わせフォームからまずはお問い合わせ
- 条件や見積もりを戴く
- 契約を締結する
いつから？
- 翌月の利用料金から割引適応
- 管理画面のBillから見える利用料金が割引適応金額で表示されます
（適応月の最終週あたりに更新されます * Amazonサポートの答え）
上記のように、一定量既に利用されている方は大幅に費用削減が可能です。
サービス毎に条件が違うので費用がかさんでいる部分のみでも適応の検討をお薦めします。
※とはいえ契約期間中は最低利用料金を支払うリスクはあるのでやはり、導入の判断は自己責任でお願い致します（何時サービス停止になるか分からないサービスでの適応は怖いですね）。
