人間を冗長化するという発想 - cloned.log
システムを設計する上で、冗長化というのは多くの人が当然のように考えている。重要なポイントは、複数の内の一つがダウンしても自動的にその他に割り振られることと、サービスの提供が継続（但しパフォーマンスが落ちる可能性はある）することだ。 冗長化が必要なのは人間も同じである。人間の場合も「担当者の自動変更」と「等価な行動」が重要だ。具体的に言えば、前者は病気でも退職でも理由に問わず欠員が出たときに、その人の担当分を引き継ぐべき担当者が決まっているかどうかという点で、後者はいなくなった人と同等のパフォーマンス（技術スキルであったり知識であったりマネジメント能力であったり）を発揮できるかどうかという点だ。このような人間冗長化が行われていない場合は、欠員が出た時点でほぼサービス停止状態（具体的にはスケジュールの遅延など）が発生する。 このようなことは当たり前のことなのだけど、人間冗長化をしていないのにサ
上司が部下を怒る法則 - cloned.log
最近、自分の周りで上司が部下を怒っていることが多い。聴くつもりがなくても耳に入ってしまい、なんだかいつも決まったパターンだなと感じるようになってきた。大体の順序は以下のような感じだ。 起 （問題点を探す） 承 （見つけた問題点を徹底的に叩く） 転 （見つけた問題点を別の問題の原因にする） 結 （見つけた問題点を最初から言いたかったと結ぶ） 解説しよう。1.は「ここはどうなってるの？」とか「○○の進捗は？」とかいった感じで状況確認を装って問題点をサーチする。ここで問題点が見つからなければ良いのだが、現実にはほぼ確実に見つけることができる。それは時間の制約、立場の制約、個人的意見の制約などから誰も非の打ちようがない行動をとることが不可能に近いからだ。ここでの問題点は非常に些細なことでも良い。（メールのCC忘れたとか、客先に傘忘れたとか） 次に2.だが、1.で見つかった問題点を「普通はこうする」
ほとんどの人が参加する会議はしてはいけない - cloned.log
そう思った。今日、自分自身が参加しない少数派の立場だった。要件の当てはまる人だけを選んでの会議なのだろうけれど、逆にそこまで厳密に情報の壁を立てる必要があるのだろうか。参加しない人間にとってみれば、「自分たちには教えたくない内容なのだ」と勘ぐりたくもなる。 ほとんどの人が会議の対象なら思い切って全員参加にしてしまおう。内容が当人に関係あるかどうかではない。コミュニティーから除者にしたという行為が大問題だからだ。参加した者は内容を知っているから、「大した内容ではない」とか「関係ない人が聞いても仕方がない」とか言えるが、参加していない者はその判断すらできない。 結局、主催者というのは参加者のことを考えることに精一杯で、被参加者のことなど頭の片隅にもないようだ。もし、そんなことはないと否定するなら、それは被参加者には聞いて欲しくない内容だったことを暗示することになるだろう。 被参加者となった気持
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
