2015-06-28 満洲暴走 隠された構造〜大豆・満鉄・総力戦〜、角川新書、安富歩、2015 †
- これはオモシロイ。エアロバイクをこぎながら 90分/520kcal で読む
- 後世から見ると、日本の総力戦はチグハクで、喜劇的ですらある。しかし、その喜劇の結果は歴史的な悲劇
- 個々の軍人や官僚は優秀で、まじめに仕事をしていた
- しかし、グランドデザインを欠いており、戦争を止められなかったばかりではなく、結果として起きてしまった「侵略戦争」すらまともに遂行できなかった
- 結局は、その場その場で弥縫策を繰り返し、ターニングポイントでは常に最悪の選択を行った
- そして全てを失った
- 現代にも通じることだが、日本は原理・原則をもとに意志決定をしない
- 当時は、総力戦の時代。とすれば、どう総力戦を勝ち抜くかという方針か、どう総力戦を回避するかという方針、そのどちらかを選択し、その方針に従って政策を決めなければいけない。
- 石原莞爾の 世界最終戦論 は妄想と欺瞞に満ちているが、それはそれで原理原則。
- 一方、石橋湛山の 小日本主義 は戦後の繁栄で正しさが証明された。これも原理原則。
- ところが、結局どちらも採用されなかった。行われたのは、ずるすると中国で戦線を拡大して、国家経済が破綻。やけになって対米戦を初めて、日本中の都市はナパーム弾で焼かれて、広島・長崎は原爆で壊滅。
- 筆者がその原因としてあげているのは、「日本特有」の「立場」主義
- 本来意志決定をする立場にある人々は、現状を否定すると「立場」がなくなるので、現場の暴走を追認
- 総理大臣から、軍司令官、小さな守備隊の隊長まで構造は同じ
- 戦後、「当時あの『立場』にいたら、ああせざるを得なかっただろう。しかたがない」ということで、ほとんどの軍人は罪に問われなかった
- 一方で、そのつけを払わされた多くの人間が居る
- 満蒙開拓団は、ソ連国境に入植させられたが、敗色が濃厚になると見捨てられた。関東軍には彼らを守る意志がなかったばかりか、退去勧告すら軍の撤退後にだされた。結局、ソ連の捕虜となり、多くの人が日本に帰らなかった。最初からシベリアで強制労働をするために入植したようなもの。
- 日本人は、無人の荒野を開拓したのではなく、現地人を退去させた村に入植
- ゲリラ掃討作戦で、三つの村の住民をまるごと虐殺
- 筆者自身があとがきで書いているように、確かによくまとまっていない。(曰く「ちゃんとまとめるには後25年必要だが、今出版する必要がある」)
- 例えば「立場主義」って本当に日本人に固有のものなの？とか
- 満州国の経済構造が、資料を羅列したレベルとか
- でも、現代の日本が、1930年代と相似であることは十分伝わる。
- 誰も責任を取らず、だた不都合な現状を勇ましい言動で塗り隠しながら、破滅への道を黙々と歩んで行った工程が相似
- 原発は、十分な事故対策(保障)を策定した上で再稼働するか、発電方法としては諦めるしかない。しかし、再び「絶対安全」というファンタージーのもとで再稼働がされつつ有る。
- 安全保障法制にしても原理原則が示されないまま、アメリカの軍事行動との一体化がされようとしている。つーか、日米安全保障条約って、もろ満州国議定書(満州国の日本の属国としての立場を明文化したもの)の相似形なんですけど、なにが「日本を取り戻す」だよ
2015-06-20 LIPC 101-350 合格 †
- 下の通称あずき本(あずき色の参考書)と、ping-t で勉強。約一ヶ月
- 一週目 : あずき本読み込み (一日一章)
- 二週目 : ping-t 1周目（500 問の想定問題をすべて「銀レベル」(= 一回正解) にする)
- 三週目 : ping-t 2周目（すべて「金レベル」(= 連続二回正解) にする)
- 四週目 : ping-t 模擬試験
- LIPC Lv1 取得のためには、もう一つ 102-350 に合格する必要がある
- 101-350 試験対策で覚えたことはもう要らないので脳のワーキング・メモリーから削除した
- そのとき、間違えて iPhone の端末ロックパスワードも脳のワーキング・メモリーから消してしまったので、iPhone をリカバリするはめになった
- つい昨日まで、ほぼ無意識にロック解除してたのに、いざロックパスワードなんだったけと思いだそうとしても思い出せない。多分数字ではなく図形で覚えてたんで、図形を忘れたら手も足も出ない
- Macbook に USB ケーブルでつないで、[電源+ホームボタン] でリセット、再起動してリンゴマークが出たら電源ボタンを離す(ホームボタンはそのまま)、それでリカバリーモードになるので [復元] で、工場出荷時に戻す→バックアップからリカバリ
2015-06-20 Linux教科書 LPICレベル1 第5版、翔泳社、2012 †
2015-05-25 ゴルトベルク・ヴァリエーションズ、avex、清水靖晃&サキソフォネッツ、2015 †
- サックスとコントラバスによるコルドベルク変奏曲
- こりゃ凄いや。とにかく華やか
- NHKラジオのウィークエンド・サンシャイン ( http://www4.nhk.or.jp/sunshine/ ) で聴いて衝撃を受けた。早速 iTunes で購入。CD ショップではどこも品切れ
- グルードのコルドベルク変奏曲も大好き。緻密で狂気にも似た作り込み。精巧な大聖堂の模型、どこまで拡大してもすごい作り込みがしてある
- こちらのコルドベルク変奏曲はとにかく伸びやかで奥行きがある。
- 最近イヤホンを変えた。新しいイヤホンは、ちょっと低音強調し過ぎかなと思っていたけど、この曲にはたいへん合う
2015-05-16 ATH-CKS55XBT、Audio Technica、2014 †
- 今まで有線の SONY MDR-NC100D/W を使っていた。2012 年に機種選定をした時にも bluetooth ヘッドホンを検討したんだけど、バッテリーが 3 時間しか持たないので断念した。
- 先週、会議用に買った 1200 円のヘッドセットが良かったし、MDR-NC100D/W もヘタれてきたので、音楽用のヘッドホンも bluetooth にすることにした。
- 当初買おうと思っていたのは SONY MDR-NWBT20N
- しょうがないので、ノイズキャンセルは諦めて、ネックバンド式から選ぶことにする
- 見た目は、右のイヤホンと左のイヤホンがケーブルで結ばれているだけ
- ケーブルの中程が少し硬くなっていて首周りに載せる感じ。
- 首の後ろ辺りが少し太くなっていて、ここにバッテリーや通信チップが入っている
- JBL J46BT 良くね?
- ネックバンド部分は、ほぼ厚めのシリコンケーブル
- イヤホンの装着感も良い
- どうも、音量が小さいらしいので断念。バッテリー小さいからしょうがないね
- 屋外でランニングするときには良さそう
- というとことで、ATH-CKS55XBT / ATH-CKS77XBT のどちらかに落ち着く
| 55 | 77 |
| 通信方式 | Bluetooth 3.0 |
| ヘッドホン | 同じ |
| マイクロホン | 同じ |
| 充電 | miniUSB (満充電 3h) |
| 連続使用時間 | 最大 5h (待ち受け 200h) |
| 重量 | 30g |
| コーデック | SBC | SBC/aptX/AAC |
- コーデックってなんだよ?
→ Bluetooth で音声をやりとりするときの音声圧縮形式
| SBC | Bluetooth標準。遅延 200ms 〜 250ms |
| AAC | iOS で採用されている圧縮方式。(MPEG系) |
| aptX | Android (高級機) で採用されている圧縮方式。遅延 30ms (英国の放送機器由来) |
- マルチペアリング・マルチポイント
| マルチペアリング | 複数の音源機器とのペアリング情報を保持できる | ATH-CKS55XBT は 8台までの機器と"マルチペアリング"できる |
| マルチポイント | 複数の音源と同時に接続できる | ATH-CKS55XBT は "マルチポイント"できない。同時に接続できるのは 1 台のみ。 |
- 使用感
- 耳へのフィット感は抜群。屋外のランニングはどうかと思うけど、ジムで使う分には問題なし
- 音質も問題なし。自分には十分に満足いく
- SBCの欠点として言われている、無音部分のホワイトノイズがやや気になる。楽曲の中の無音部分がサーっというホワイトノイズになる。ここのみ上位機種の 77 にしときゃ良かったかなと思ったところ (上位機種で解消するのかは知らないけど)。あくまで、楽曲の中の無音の話で、音声データが流れていない時にはもちろん無音。まぁ細かいことは気にしない
- 遮音性もまぁ満足行く。地上線や普通の地下鉄の中で Podcast を聞く分には問題なし。(さすがに大江戸線 *1 では音量を上げたけど)
- iPhone とケーブルで繋がっていないの気持ちいいな。首が楽。iPhone も使いやすい
- ペアリングが切れると、iPhone のスピーカーから全力再生されるので注意 [何に?(笑)]
- Siri 対応 (◯長押し)
- 音声電話対応だけど、まだ日本では、ヘッドセットで電話しているとヤバいひとっぽくみられるのでやめとこ
- ヘッドセットのバッテリー残量が iPhone に表示される
- ノイズキャンセルやっぱり欲しいなぁ... このイヤホンを買い換えるであろう 3 年後に期待
【1週間使ってみて】
- 1週間わざと充電せずに使ってみた。金曜日の帰り途に電池切れの警告、でも帰宅までバッテリーが持った
- iPhone で Bluetooth を使ったテザリングとヘッドセットを同時利用すると、音が途切れる
- やっぱり、電車の中ではノイズキャンセル欲しいなぁ...しょうがないから作るかな、簡単にできそうなんだけど、誰も作っていないところを考えると難しいのかな？
ヘッドセットのマイクから周囲の音を拾う → FFT で周波数分解 → 各周波数成分の初期位相を π/2 ずらす → 逆変換 → イヤホンから音を出す
で行けそうなんだけど、あとはイヤホンによる減衰分を考慮して音圧を下げるとか、計算時間と bluetooth の遅延を考慮するとかすりゃよさそうなもんだ
2015-05-16 W前社長と偶然会う †
- 勤め先で大変お世話になった先々代の社長と偶然電車の中で会う
- ちょうど、電車の中でノリノリで「わからん」を聞いているところに、途中駅から社長が乗り込んできた、慌ててイヤホンを外して、どうもお久しぶりですと...
2015-05-16 磁性流体、CZFerro、2015 †
- Kickstarter で面白そうな企画を見つけたので、一口乗ってみた
- 忘れた頃に届いた
- いやぁ〜、面白くて何時間でも遊んでられるわ。磁石を近づけると逃げたり、逆に集まってきてトゲトゲになったり、分かれていた塊を近づけていくと小さなつながりが出来て、そこから磁性流体がすすっと流れだして、やがそれが大きな流れになって一つにまとまるとか。
2015-05-10 BSHSBE18WH (Bluetooth Headset)、BUffalo †
- http://buffalo.jp/product/multimedia/headset/bshsbe18/
- Skype for Business (Lync) の会議用に購入。1200円也
- あまり期待せずに、一番安いものを選択。とりあえずアナログ電話の音質で人間の声が通れば OK。
- と思ったら、これ凄いな。会議用には十分
- 音声はクリアに聞こえるして、イヤホン下部のマイクもちゃんと音を拾う
- 音ズレもほぼなし (映像の口元と、聞こえる音声に不自然なところはない。*2)
- 会議の後で試しに音楽を流してみたらそこそこちゃんと聞こえる。
- 待ち受け 160 時間。最大通話 6 時間。カタログスペックなんで、話半分としても十分
- 装着感も普通のイヤホンと同じ。特に重いと感じない (わずか 6 g)
- 何よりケーブルが無いのがいい。Bluetooth に慣れると、ケーブル付きのヘッドフォンは首に縄を付けられているようで気持ち悪い
- 一昔前の Bluetooth ヘッドホンといえば、やたらと電気を消費して、重くて、しかも音質がいまいちだったけど、2015 年では 1200円で満足行くものが買えるんだ
2015-05-10 プロジェクトマネージャーのためのプロセスデザイン入門、日経BP、芝本秀徳、2014 (まとめ中) †
プロジェクト †
- プロジェクト
- 独自性 やったことがないことを
- スコープ どういう手順で作り上げるか計画し
- 有期性 期限までに終わらせる
- 無理ゲー。QCD を満たしたプロジェクトは 3 割
- でも不確実性こそ価値の源泉。プロジェクトに不確実性があるからこそ、顧客は対価を払ってプロを雇っている
- 不確実性を乗りこなす → プロセス化
- 不確実性を小さくする
- 衝撃に備える
- 徐々に不確実性を小さくする
- 主要なプロセス
- プロジェクトマネジメントプロセス
- エンジニアリングプロセス
- 品質マネジメントプロセス
- プロジェクトマネジメントプロセス (括弧内はPMBOK5)
企む(立ち上げ)
→段取る (計画)
→やる (実行)
→視る (監視・コントロール)
→振り返る (終結)
- 企む
- 段取る
- どうやって実現するか
- 最初は粗く、「やる」「視る」を通じて詳細化、修正=段階的詳細化
- 視る
- プロジェクトと現実との齟齬を見続ける。定量的に見続けていないと変化に気づくことはできない
- +仕様変更管理、リスク追跡、管理
- 振り返り
- 今回うまくいった施策は、次回も同じようにやってみる
- 今回うまくいかなかった施策は、同じ轍を踏まないようにする
- プロジェクト成功の条件 → これを準備するのがプロジェクトリーダーのお仕事
- 経営層のコミットメントがある。プロジェクトリーダーは、どうするかを決める権限はあるけど、何をするかは提案しかできない
- ユーザ主導。「プロなんだから、いい感じにしておいて」=「(数ヶ月後)こんなシステム使えない」
- 目的と目標が明確
- 目的 抽象的で長期にわたるめあて 健康になる
- 目標 目指す地点、数値、数量 毎日3km走る
- コミュニケションコストを惜しまない
- ステークホルダー間の認識合わせもITプロジェクトの一部
- QCDが現実的
- プロセスが設計されている
企む †
- 企む
- プロジェクトに対するニーズを明確にする。「何のために、このプロジェクトはあるのか？
- 大まかなアウトプット。プロジェクトで作るもののおおまかな GUI、帳票、外部連携
- 成果物WBS レベル3程度まで詳細化
- 「MECE (Mutually Exclusive and Collectively Exhaustive)」 モレなく、ダブリなく
- 「100% ルール」 WBS の子要素を全て足すと親要素になるようにする
- 大まかなプロセス。Agile? Waterfall?
- 「企む」アプローチ。段階的詳細化
- 分かっているところまでやる
- 分かっていないところを明確化する
- 分かっていないところをどうするか決める
- ステークスホルダーを巻き込む
- ステークスホルダーも自分が何を欲しているか明確に理解していない
- ユーザーはモノできて、はじめて自分の欲しかったモノがわかる→要求のクリープ
- ユーザーの「こんなモノが欲しい」を鵜呑みにしない。要求は、ユーザーの中から探すモノではなく、一緒に開発するモノ 【顧客ヒアリングプロセス】
- 要求の優先順位を決める→そうしないと優先順位に関係なくやりやすいモノから手をつけはじめてしまう 【狩野モデル】
- 【顧客ヒアリングプロセス】
- 目的は何か？
- ヒアリングするのは何のために？
- ヒアリングはいつから始めるのか？
- 得られた結果は、どのように利用するのか？
- 誰に聞くのか？
- どんな立場、何人ぐらいの人に聞くのか？
- 何処でヒアリングを行うのか？
- 何を聞くのか？
- どんな情報を聴きたいのか？
- どんなふうに質問するのか？
- 誰が聞きに行くのか？
- 顧客に聞きに行く
- 情報を整理する
- スコープに組み込む
- 顧客は何に勝ちをおいているか？
- スコープに何を組み込むのか？
- 【狩野モデル】
- 要件の優先度
当たり前品質 > 一元的品質 > 魅力的品質
- 判定方法
| | 〜がなかったらどう思いますか？ |
| | 気に入る | 当然 | なんとも感じない | しかたない | 気に入らない |
| 〜があったらどうおもいますか？ | 気に入る | 懐疑的回答 | 魅力的 | 魅力的 | 魅力的 | 一元的 |
| 当然 | 〜は、ない方がいい | 無関心 | 無関心 | 無関心 | 当たり前 |
| なんとも感じない | 〜は、ない方がいい | 無関心 | 無関心 | 無関心 | 当たり前 |
| しかたない | 〜は、ない方がいい | 無関心 | 無関心 | 無関心 | 当たり前 |
| 気に入らない | 〜は、ない方がいい | 〜は、ない方がいい | 〜は、ない方がいい | 〜は、ない方がいい | 懐疑的回答 |
- フェーズ
- 構想フェーズ
- 計画フェーズ
- 実行フェーズ
- 集結フェーズ
- NASAでは
- Requirement Definition
- Requirement Analysis
- Preliminary Desing
- Detailed Desing
- Implimentation
- System Testing
- Acceptance Testing
- Maintenance & Operation
- フェーズごとに次のものを定義する
- プロセス
- ツール・手法
- 完了基準「フェーズゲート」「マイルストン」
- フェーズ内完結の原則 = 作業を次のフェーズに持ち込まない
- 完了基準 超 重要 → ステークホルダーマトリックスで整理する
| フェーズ1 | フェーズ2 | フェーズ3 | ... |
| 👤1 | P | A | C | ... |
| 👤2 | I | C | A | ... |
| 👤3 | ... | ... | ... | ... |
- Responsible 実行する人
- Accountable 責任のある人
- Consult 意見を求めるべき人
- Inform 情報共有をすべき人
- プロジェクトチャーター(プロジェクト憲章)を作ろう = すべての計画の拠り所。全員で共有、いつでも見えるようにする
- 使命
- 目的
- 目標
- チームメンバー
- チームリーダー
- スポンサー
- マイルストン
「段取る」プロセス †
- プロセス = 料理の「レシピ」
- リソースを加工して、リソースや価値を生み出す手順
- プロセスの連鎖 = システム
- 作業WBSの中でのプロセス
- Level1 ◯✗ソフトウェア開発プロジェクト
- Level2 フェース (計画、要件定義、設計、実装)
- Level3 プロセス (要求分析、要件開発)
- Level4 アクティビティ (要求ヒアリング、要求文書化、要求の仕様化、顧客承認)
- 組織の中でのプロセス
| 目的 | 戦略 | 事業方針 |
| 目標 | 作戦 | プロジェクト |
| 方法 | 戦術 | プロセス |
| 行動 | 人 | 実務 |
- プロセスに必要な要素
- システム思考
- プロセスはインプットからアウトプットを出力する関数 value = process(in1, in2, in3)
- 逆算思考
- ゴールに行き着くために、どういうプロセスにすべきかを考える
- プロセスフローダイアグラム（PFD)
- プロセス設計をしておくとイイ事
- プロジェクトを実行している時に、何が「正しい」(=目的を達成するための手段) かのとりあえずの基準がある
- 変化に適応できる
- 共通言語を確立できる
- → プロセスは、人間の創造性を卑しめるのではない。過去の成功や失敗の経験の上に、新たな試みを行う手段。「巨人の肩に乗る」「死人を働かせる」
- PFD (Process Flow Diagram)
- DFD のプロセス版
- 作り方
- 1.最終成果物のモノを列挙する
- 2.そのモノの構成要素を列挙する
- 3.それを作るために必要なインプットとプロセスを挙げる
- 4.モノとプロセスを線で結ぶ
- 5.プロセスの入力と出力を見て、足りないモノがあれば補って 3 へ戻る。すべての入出力の関係がイケそうなら PFD 完成。
- 例
「視る」プロセス †
- プロジェクト＝不確実 ⇒ 顧客は不確実性を乗りこなす技量に対価を払っている
- プロジェクトの不確実性を乗りこなす
- 不確実性そのものを小さくする → 前項「企む」「段取る」: プロセス化
- 衝撃に備える → 「視る」
- 徐々に不確実性を小さくする → 「視る」
- 進捗は管理できない
- すでに出ている結果は変えようがない
- 最初に建てた計画に対してどれだけ進んだかは無意味
- プロジェクトはそもそも不確実だから
- やったことがないことに取り組む
- 顧客もプロジェクトの初期段階では、どういう最終成果物がほしいかのイメージが曖昧
- 管理できるのはプロセスだけ
- 現在位置を把握
- 目的地を把握
- どうやって現在地から目的地にたどり着くかの見通し(=プロセス)をたてる
- 見通しは確率で行う
- 50% の確率で完了するコストで見積もる
- Buffer : 90%の確率で完了するコストとの差分を予備として積んでおく
- ここまではよくやっていること
- 従来型の見積もりと進捗管理
- タスクごとにバッファ積む
- タスクごとに完了期日を設定する
- 定期的に進捗を確認する = 予定されていたタスクが完了しているか確認する
- [問題] 学生症候群 : バッファを先食いしてしまう
- [問題] パーキンソンの法則 : バッファが残っていると(大局的に見て)余計な作業をしてしまう。過剰品質
- [問題] 学生症候群とパーキンソンの法則により、各タスクは最善でもそれぞれのバッファを食いつぶして完了する。予想外の事態により遅れが生じると対処できない。「遅れが伝搬する」
- [問題] 進捗確認ごとに、小さな計画のほころびが見つかり、再度計画を立てる必要がある。自分たちはダメチームだと思うようになりモチベーション低下。もはや計画は計画でなくなる
- 本書の提案する見積もりと進捗管理
- バッファはまとめる
- ある程度長い期間で期日を設定する (AgileのSprintとか)
- 各タスクには原則的に期日を儲けない。かかった (かかりつつある) 作業時間（コスト）で管理する。
- 進捗確認は、現時点でどれくらいバッファを消費したかで確認する。期間の四分の一時点で 1/2 のバッファを使ってしまっていたらなにか問題が起きている。
- [利点] 学生症候群 & パーキンソンの法則が起こりにくい
- [利点] プロジェクトの実体をより早期に詳細に監視できる (ある期日にタスクが完了したかではなく、個々のタスクに現時点でどれくらいコストがかかっていて、そのコストと見積コストとの関係を管理する)
- [利点] 理論上はバッファは半分で良い。見積もりコストは 50% の確率で完了するコストだから、半分のタスクは見積コスト内で完了するはず。
- 作業者に全部バッファを渡す
- 作業者に半分バッファを渡す。残り半分はないものとして計画する
- 作業者に半分バッファを渡し、残り半分はプロマネが(隠し)持つ
問題解決 †
- 解決できる問題 = 変化によって引き起こされたことによる問題
- 「あるべき姿」から何らかの変化によってギャップが発生した場合は解決できる
- ⇒ 変化の元になった要因を取り除く
- ⇒ 別の対処を行う
- 解決できない問題 = 一度もあるべき姿を満たしていない問題
- 設定された目標自体に問題が有る
- 目標を達成するための条件が揃っていない
- ⇒ 目標自体を見直す
- ⇒ 目標を満たすための条件を検証しなおす
[意思決定のプロセス]
- 問題把握
- STEP1 問題を5W1Hの視点で理解する
- What(何が起きているのか),Who(誰が起こしているのか),When(いつ起きたのか),Where(どこで起こるのか),Why(なぜ起きるのか),How(どのように起こっているのか)
- STEP2 最悪の事態を想定する
- STEP3 最悪の事態を回避する方法を考える
- STEP4 その方法によって新たな問題が生まれないかを考える
- STEP5 情報を伝達する。Open。全部共有する
- 問題が起きていることは責めない / 問題を隠したら激おこ
- 人間は責めない、チームで問題に対処する
- BAD : 💣😱 vs 😡😡😡
- GOOD : 💣 vs 😱😉😉😉
- 問題分析
- STEP1 あるべき姿を明確化する
- STEP2 「IS」「IS NOT」分析
| IS | IS NOT | 区分点 | 変化点 |
| What | 問題が起きているケース | 問題が起きていないケース | IS,IS NOTの違い | どんなことがきっかけで問題が起るようになったか |
| Who |
| When |
| Where |
| Why |
| How |
- STEP3 区分点と変化点を摘出して仮説を立てる
- STEP4 仮説を検証する
- 区分点と変化点は仮説に過ぎないので、対処の前によく検証する必要がある
- 通常は、複数の区分点・変化点による複合要因が原因となる。
- ⇒ STEP3で洗いだした区分点・変化点の順列組み合わせのどれが原因か検証する
- 決定分析
- STEP1 目的を明らかにする
- STEP2 満たすべき要素を定義する
- STEP3 複数案を評価する
| 絶対目標 | 案1 xx機能の実装を諦める | 判定 | | 案2 ... | 判定 |
| 〜が満たされている | システムとしては代替機能あり | 顧客調整 | | すべての機能を実装 | GO |
| コストは〜以内 | コストは10%改善 | GO | | コストは50%増し | NO GO |
| 期限は〜まで | 1ヶ月前倒しで納品可能 | GO | | 期限内で納品可能 | GO |
- リスク分析
- STEP1 リスクの識別
- チームメンバーによるブレインストーミング
- 経験豊富な有識者への相談
- 過去プロジェクトで顕在化したリスクのチェックリスト化 (メーリングリストや不具合票は宝の宝庫)
- STEP2 リスクの評価
| 影響度 | 1(影響なし) | 2(0-5%遅延) | 3(5-14%遅延) | 4(15-24%遅延) | 5(25-%遅延) |
| 発生確率 | 5(確実) | 7 | 9 | 11 | 13 | 15 |
| 4(高い) | 6 | 8 | 10 | 12 | 14 |
| 3(可能性あり) | 5 | 7 | 9 | 11 | 13 |
| 2(低い) | 4 | 6 | 8 | 10 | 12 |
| 1(無い) | 3 | 5 | 7 | 9 | 11 |
- STEP3 リスクの予防と発生時の対処
| プロセス/カテゴリ | リスク要因 | 発生確率 | 影響度 | リスク指数 | 予防措置 | (種別) | トリガーポイント | 発生時対策 |
| | | | | | | | |
| | | | | | | | |
- リスク指数順に、一覧表にしておく
- 予防措置の種別 : リスク回避、リスク転嫁(アウトソース)、リスク軽減
- トリガーポイント : 何を持ってリスクの発生と見なすかを事前に決めておく (「x月x日までに〜できない」など)
- 発生時対策 : 事前に対策を決めておく
振り返り †
- 振り返りの目的
- 教訓の把握
- 人を責めない
- 過敏にならない
- 誰も攻撃しない
- 事実を忘れない
- 本にはするな (箇条書きで要点のみ)
- 経験の資産化
- 継続的に行う
- 全員参加で決める
- プロセスの粒度を組織のレベルに合わせる
- 完成がないことを肝に銘じる
- プロジェクト完了時に振り返りをやるだけじゃなくて、プロジェクト中にちょくちょく KPT やろうぜ
- Problem プロセスの問題点を挙げる
- Try 問題に対する施策を考える
- Keep うまく行った Try は Keep する
- 月に数時間の KPT で、最終的に数百時間の節約になる
2015-05-10 トールキンの世界、晶文社、リン・カーター、1977 †
- 指輪物語の元ネタ解説本
- 北欧神話やケルト神話、イングランドの英雄譚などが、どのように指輪物語に盛り込まれているか
- 訳 荒俣宏
2015-05-10 スプーンと元素周期表「最も簡潔な人類史」への手引き、早川書房、サム・キーン、2011 †
2015-05-10 古着屋総兵衛影始末 1〜11、徳間文庫、佐伯泰英、2008 †
- 随分前に叔父さんからもらって仕舞ってあったものを一気読み
2015-05-10 ある小さなスズメの記録、文春文庫、クレア・キップス、1953 †
- 舞台は第二次世界大戦初期のロンドン。ロンドン郊外に住む引退した老女優のもとにケガをしたスズメが舞い込む
- 老女優は、怪我が治るまでとスズメの世話をするが、やがてそのスズメが二度と飛べないことがわかると、クラレンスと名づけて共に生きることにする
- クラレンスは、芸を覚えて、空襲に怯えるロンドン市民 -特に子どもたち- に勇気を与えることになる
2015-05-04 鎌倉行ってきた †
- 今回は北鎌倉、建長寺から散策スタート
- ずんずん奥に入って行くと、ちょっとした山登り。建長寺裏山の頂上付近にある半僧坊*3の社にたどりつく
- 半僧坊からハイキングコースにつながっている。後戻りも何なのでずんずん進む。尾根伝いの旧街道を整備したもの、結構ハード。なるほど鎌倉は要塞都市、陸路からの侵入は困難と納得させられる
- ようやく山道から鎌倉宮の近くにでたので、鶴ヶ岡八幡宮を抜けて由比ガ浜へ。昼餉は何処もいっぱいで食べそこねたのでサンドイッチを購入。この決断が何を意味するか、彼はまだ知らない
- 海岸でエビスビール片手に玉子サンドを食べていると、なんとリアル「鳶に
油揚げ 玉子サンド を攫われる」。愉快々々。見上げれば、たくさんの鳶が海風でホバリングしながらマヌケな人間を狙っている
- 江ノ島まで海岸をてくてく歩く。疲れたら江ノ電に乗ればいいやと気楽に歩いていたら江ノ島まで歩けた
2015-05-03 恵比寿で野暮用を済ませる †
2015-05-02 ジム †
2015-05-01 日本赤十字社のネパール地震救援機金に寄付 †
2015-05-01 充電 †
- 一年近く前から、ノドが詰まるような感じがしている。意を決して検査に行った
- 飲んだり食べたりするときには気にならない。何もしていない時に、ノドが詰まるというか、小さいボールを嚥下できないでいるような感覚がする。
- 耳鼻咽喉科で内視鏡検査をしてもらった → ノドに腫瘍などは無し。おそらく(ストレスで)唾液の量が少なくなって、ノドが詰まったような感覚がするのではないかという診断
- 一つストレスの元が無くなった
- ついでに耳の掃除をしてもらう、大きい耳垢がとれた
- 午後は皇居外堀通りの木陰でお昼寝。良い天気で、夕方まで、うつらうつらしながら音楽を聞く
- Erik Satie
- Glenn Gould
- Gershwin
- Jethro Tull
- 充電完了
- 諸々、もういいことにしよう
2015-04-27 ASK-1000、Ryobi †
2015-04-13 某君の結婚式 @ 築地 †
2015-04-12 JJUG CCC 2015 @ 新宿 †
K-1 基調講演1 : Java 20年史 by 河村 嘉之 （日本Javaユーザーグループ 副会長） †
K-2 基調講演2 : Java SE 8 と Raspberry Pi by Stephen Chin（オラクルコーポレーション） †
- Java 8 から ARM Linux に対応 → Raspberry Pi でも Java 8 が動く
- Raspberry Pi の開封から Java を動かすまでのデモ
- ライン追跡ロボット
- NFC (近距離無線通信) 端末
- 3D プリンタを使って、ハードウェアを作る
F-1 だれも教えてくれないJavaの世界。あと、ぼくが会社員になったわけ。 by きしだ なおき (Line) †
AB-2 Web開発における最新テスト手法 by tokuhirom (subtech) †
- 原則
- テストを手動で全部できれば何にも考えなくていい
- でも無理なので自動化する必要あり
- → どこまで自動化するか？ 手動でやるよりも自動でやったものがいいものを自動化する
- テストは契約
- 階層別のテストプラクティス
- Model のテスト
- Before Class で CREATE DATABASE
- After Class で DROP DATABASE
- DATABASE 名は {プロジェクト名}+乱数
- テスト用 DBMS (MySQL) は、開発端末 or 共有サーバ
- バージョン揃える必要あり (現時点では、絵文字対応のため最新版の MySQL 5.6 で揃っているけど、)
- 外部 API (REST) を使うテスト
- Jetty でテストサーバーを作る <Unit Test 内で立ち上げる>
- Jetty Servlet Tester、Mock Api とか Github で公開してるんで良かったら使ってね
- 外部 API アクセスモジュールを jmockit で mock に差し替えてテストするのは悪手。外部 API アクセスモジュール自体の単体テストは往々にして薄い。特にマルチスレッドのあたり。実際に HTTP の通信させるほうが後々よい
- Controller のテスト
- JUnit の Before Class とかでサービスを立ちあげておいて
- Apache HTTP Client で HTTP から叩く
- Browser のテスト
- HTTP Form のテストは人手でやる。コスト的に自動化は割にあわない
- Dummy Data について
- fixture を予め大量に作るのはメンテナンスがめんどくさい (Excel ぎらいの中二病エンジニア多し)
- テスト実行ごとに生成している
- JUnit4
- CI
- CIは、もはや開発の基本
- CI動いてないと、テストが壊れる
- 誰かがお膳立てをすれば使われる
- Server には Nexus からしか配備できないようにする
- Nexus には Jenkins からしか配備できないようにする
- Checkstyle と Findbugs のエラーは担当者にメールで無限に投げつける
AB-3 大規模な負荷でもドキドキしない為のJava EE by nagaseyasuhito (Gree) †
- 負荷テストのアンチパターン
- シングルスレッド (Shell から負荷試験とか)
- ユースケースとかけ離れたシナリオ
- 手動実行 (同時性の担保とか、集計とかどうすんのさ)
- 負荷テストの目的
- 高負荷時の不具合
- 最近アプリの下のレイヤも気にする必要あり。Web Socket を使っていると OS が too many files で止まるとか
- CPU スカスカなのにスループットが出ないとか。でかい Synchronized で事実上 1 サーバ 1 多重とかやらかす
- 他ユーザのレスポンスが返ってくる
- Dead Lock
- 負荷をかけるテスター側が性能の限界になっていないか要チェック
- Stress Test も CI に組み込め
- JMeter
- 分散実行に対応 (サーバ4台で、各サーバに仮想ユーザ1000人とか)
- Script Sampler
- Test Script Sampler (JMeterスクリプト)
- Selenium Web Driver Sampler (Web Driver コード)
- JUnit Request Sampler (JUnit コード)
- グリーでは、結合テスト用の Junit Request を多重で動かして負荷試験をしている
- JMeter Maven Plugin
- Jenkins Performace Plugin
- JMeter の出力内容を Jenkins から見ることができる
- 時系列 (アプリのバージョン/リビジョン) でパフォーマンスの推移を見ることができる
- 性能のボトルネックを探す
- リソースモニタリングをする (CPU,MEM,Network...)
- 時系列がミソ Zabbix とか
- JMX
- アプリ実行時に外部から Java VM の状況を取得できる
- JVM 標準 (スレッドやメモリー)
- アプリ独自のパラメータを JMX で取れるようにしておくと便利 (ユーザ数など)
- Zabbix からも JMX いけるらしい
- Mission Control
- JPAのスケールアウト
- まず JPA のキャッシュは切る。(サーバ側をクラスタ化すると不整合が起きる、DBMSのキャッシュに任せる)
- �� READ が頭打ちになったら [Master - Slave - Replication]
- 別に作りこむ必要なし
- MySQL Replication Driver (JDBC) を使う
- connection.setReadOnly?(true) を宣言すると、以降 Slave にアクセスに行く
- JPA から使う場合には、entityManager.unwrap() で connection を取り出して、setReadOnly?(true)
- �� WRITE も頭打ちになったら [Partitioning]
- まずは、DBMS のチューニング (キャッシュやメモリを増設したり、プロセス数を増やしたり)。それでもダメなら Partitioning
- Eclipselink Partitioning
- Entityに @HashPartitioning? をつける
- INSERT : 国コードや期間などで書き込み先の Database を振り分ける
- SELECT,UPDATE : WHERE 句に、振り分けのキーとなる項目があれば、参照先の Database を振り替ける
- WHERE 句に振り分けのキーとなる項目が無いとき → 全 Database を参照 (理論的には並列処理されるはず)
- �� 合わせ技
- 帰途、東新宿のジムに行く。（いつもは池袋支店に行っているが、どの支店に行ってもいい)
- 1km ほど泳いで、サウナと温泉。
2015-04-01 木花咲耶姫 †
- 門前の桜の老木、昨年の冬に末枝を剪定
- 残った枝にわずかばかりの花が咲く
Random
東京の環状地下鉄線。建設するときにもう大深度地下しか空いていなかったので、トンネル径が小さく、車両も小型。車内は非常にうるさい
Bluetooth の 音声圧縮 SBC は、規格上最大 250 msまでの遅延が許容される。1/4秒遅れるとさすがに人間にわかるけど、この製品ではほとんど気にならないレベルだった
後醍醐天皇の皇子、無文元選禅師の従者。神通力を得て天狗になった
Last-modified: 2015-06-29 (月) 01:39:44 (3216d)
Short-URL: http://hondou.homedns.org/pukiwiki/pukiwiki.php?cmd=s&k=9cf3d8c446
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
progress2.png 1595件
[詳細]
progress1.png 1620件
[詳細]
buffer.png 1806件
[詳細]
pfd2.png 1658件
[詳細]
pfd1.png 1619件
[詳細]
kano.png 1852件
[詳細]
czf02.jpg 1846件
[詳細]
czf01.png 1894件
[詳細]
bshsbe18wh.jpg 1786件
[詳細]
tolkein.jpeg 1477件
[詳細]
kamakura5.jpg 1689件
[詳細]
kamakura4.jpg 1423件
[詳細]
kamakura3.jpg 1677件
[詳細]
kamakura2.jpg 1677件
[詳細]
kamakura1.jpg 1701件
[詳細]
charge.jpg 1682件
[詳細]
JJUG2015Spring3.JPG 1788件
[詳細]
JJUG2015Spring2.JPG 1705件
[詳細]
JJUG2015Spring1.JPG 1692件
[詳細]
sakura.jpg 1407件
[詳細]
