==================================
これは、
linux-2.6.20/Documentation/ManagementStyle の和訳
です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日 ： 2007/2/21
原著作者: Unknown
翻訳者 ： Noriyuki Taniuchi < n-taniuchi at ay dot jp dot nec dot com >
校正者 ： Seiji Kaneko さん < skaneko at a2 dot mbn dot or dot jp >
          Masanori Kobayashi さん < zap03216 at nifty dot ne dot jp >
==================================


                Linux kernel management style
                Linux カーネルマネージメントスタイル

This is a short document describing the preferred (or made up, depending
on who you ask) management style for the linux kernel.  It's meant to
mirror the CodingStyle document to some degree, and mainly written to
avoid answering (*) the same (or similar) questions over and over again.

これは Linux カーネルのための、好ましい（人によっては私が勝手に作った物
だと言うかもしれません）マネージメントスタイルについて書かれた短い文書
です。CodingStyle ドキュメントと同様に、主に同じ（もしくは似たような）
質問に何度も繰り返し答えなくても良いようにする(*)目的で書かれたものです。


Management style is very personal and much harder to quantify than
simple coding style rules, so this document may or may not have anything
to do with reality.  It started as a lark, but that doesn't mean that it
might not actually be true. You'll have to decide for yourself.

マネージメントスタイルは人それぞれですので、単純なコーディングスタイル
ルールに比べて、はるかに定量化が難しいものです。ですから、この文書が現
実に則しているかどうかは分かりません。冗談のつもりで書き始めたものです
が、この文書が実際には正しくないかもしれないというわけではありません。
自分自身で判断してください。


Btw, when talking about "kernel manager", it's all about the technical
lead persons, not the people who do traditional management inside
companies.  If you sign purchase orders or you have any clue about the
budget of your group, you're almost certainly not a kernel manager.
These suggestions may or may not apply to you.

ところで、「カーネルマネージャ」と言ったとき、それは企業で伝統的な管理
業務をする人のことではなく、高度な技術を持った人たちのことを指します。
もしあなたが注文書にサインをしたり、グループの予算について何か知ってい
るのなら、ほぼ確実にカーネルマネージャではありません。これらの話はあな
たに当てはまるかもしれないし、そうではないかもしれません。


First off, I'd suggest buying "Seven Habits of Highly Successful
People", and NOT read it.  Burn it, it's a great symbolic gesture.

まず、「Seven Habits of Highly Successful People」（日本語翻訳書「7つ
の習慣- 成功には原則があった!」）を買うことをお薦めしますが、決してそ
れを読んではいけません。燃やしてください。それは重要で象徴的な意思表
示です。


(*) This document does so not so much by answering the question, but by
making it painfully obvious to the questioner that we don't have a clue
to what the answer is.

(*) この文書は、質問に答えるのではなく、答えが何なのかを私たちが全く知
らないということをはっきりさせることで、何度も回答しなくて済むようにし
ようというものです。


Anyway, here goes:

とにかく、先に進みましょう。


                Chapter 1: Decisions
		１章：決断

Everybody thinks managers make decisions, and that decision-making is
important.  The bigger and more painful the decision, the bigger the
manager must be to make it.  That's very deep and obvious, but it's not
actually true.

「マネージャが決断をする、そして決断することは重要なことだ」と誰もが考
えます。重大で苦渋に満ちたものであるほどに、その決断をするマネージャは
優れていなければなりません。これは明白なことだと深く信じられていますが、
実際には正しくありません。


The name of the game is to _avoid_ having to make a decision.  In
particular, if somebody tells you "choose (a) or (b), we really need you
to decide on this", you're in trouble as a manager.  The people you
manage had better know the details better than you, so if they come to
you for a technical decision, you're screwed.  You're clearly not
competent to make that decision for them.

肝心なことは、決断しなければならなくなることを「避ける」ことです。特に、
「(a)か(b)を選んでください、本当にあなたに決めてもらう必要があるんです」
と誰かが言った場合、あなたはマネージャとして困難な状況にいることになり
ます。あなたの部下たちはあなた自身よりも詳細を良く知っているのでしょう
から、もし彼らが技術的な決断をしてもらうためにあなたのところに来たのな
ら、まずい状況にいるのです。あなたは明らかに、彼らの代わりに決断をする
適任者ではないのです。


(Corollary:if the people you manage don't know the details better than
you, you're also screwed, although for a totally different reason.
Namely that you are in the wrong job, and that _they_ should be managing
your brilliance instead).

（推論： もしあなたの部下たちがあなたより詳細をよく分かっていない場合で
も、まったく別の理由ですが、やはりまずい状況にいることになります。すな
わち、あなたは間違った仕事をしているのであって、代わりに彼らの方があな
たの優れた才能を管理しているべきなのです。）


So the name of the game is to _avoid_ decisions, at least the big and
painful ones.  Making small and non-consequential decisions is fine, and
makes you look like you know what you're doing, so what a kernel manager
needs to do is to turn the big and painful ones into small things where
nobody really cares.

したがって、決断することを「避ける」、少なくとも重大で苦渋に満ちたもの
を「避ける」、ということが肝心なのです。些細な、あまり重大でない決断を
するのは構いませんし、自分がしている事がよく分かっているように見せてく
れます。ですから、カーネルマネージャがしなければならないことは、重大で
苦渋に満ちた決断を誰もあまり気にしない些細なものに変えることなのです。


It helps to realize that the key difference between a big decision and a
small one is whether you can fix your decision afterwards.  Any decision
can be made small by just always making sure that if you were wrong (and
you _will_ be wrong), you can always undo the damage later by
backtracking.  Suddenly, you get to be doubly managerial for making
_two_ inconsequential decisions - the wrong one _and_ the right one.

「重大な決断」と「些細な決断」の主な違いは、決断したことを後で修正でき
るかどうかだと理解しておくとよいでしょう。間違っていた場合に（そして後
で間違いになるような場合も）、いつでも撤回してダメージを取り消せるよう
にしておけば、どんな決断でも些細なものにすることができます。そうすると
すぐに、あなたは二つの食い違った決断（間違ったものと正しいもの）をする
という理由で、二倍管理者ぽくなります。


And people will even see that as true leadership (*cough* bullshit
*cough*).

そうすれば、まわりの人々はそれを真のリーダーシップだとさえ思うでしょう。
(ウソ）


Thus the key to avoiding big decisions becomes to just avoiding to do
things that can't be undone.  Don't get ushered into a corner from which
you cannot escape.  A cornered rat may be dangerous - a cornered manager
is just pitiful.

したがって、重大な決断を避けるために重要なことは、「取り消せないことを
しないだけ」ということになります。避けられないコーナーに追い込まれては
いけません。追い詰められたネズミは危険かもしれませんが、追い詰められた
マネージャは惨めなだけです。


It turns out that since nobody would be stupid enough to ever really let
a kernel manager have huge fiscal responsibility _anyway_, it's usually
fairly easy to backtrack.  Since you're not going to be able to waste
huge amounts of money that you might not be able to repay, the only
thing you can backtrack on is a technical decision, and there
back-tracking is very easy: just tell everybody that you were an
incompetent nincompoop, say you're sorry, and undo all the worthless
work you had people work on for the last year.  Suddenly the decision
you made a year ago wasn't a big decision after all, since it could be
easily undone.

カーネルマネージャに巨大な会計責任を実際に負わせようとするほどバカな人
はどうせいないでしょうから、通常は撤回することは十分簡単だということに
なります。返せないほどに巨額のお金を浪費できるわけではないので、撤回で
きる唯一のものは、技術的な決断だけです。そして、これらの決断を撤回する
のは非常に簡単です。つまり、あなたが無能なバカだったと皆に言って謝まり、
あなたが去年皆にやらせた価値のない仕事をすべて無かった事にするだけです。
簡単に取り消す事ができたので、突如としてあなたが一年前にした決断はどっ
ちみち重大な決断では無かったのだということになります。


It turns out that some people have trouble with this approach, for two
reasons:
 - admitting you were an idiot is harder than it looks.  We all like to
   maintain appearances, and coming out in public to say that you were
   wrong is sometimes very hard indeed.
 - having somebody tell you that what you worked on for the last year
   wasn't worthwhile after all can be hard on the poor lowly engineers
   too, and while the actual _work_ was easy enough to undo by just
   deleting it, you may have irrevocably lost the trust of that
   engineer.  And remember: "irrevocable" was what we tried to avoid in
   the first place, and your decision ended up being a big one after
   all.

二つの理由から、人によってはこのアプローチが難しいことがわかります。
 - 自分がバカだと認めることは、見かけより難しいことです。私たちは皆、
   面目を保ちたいので、人前で「間違っていました」と言うのは本当に辛
   い場合があります。

 - 「お前らが去年やった仕事は結局価値が無かったんだよ」と言われること
   は、かわいそうな部下のエンジニアたちにとっても非常に辛いものになり
   得ます。そして実際の成果物を削除するだけで簡単に無かったことにでき
   ますが、あなたはそのエンジニアの信頼を取り返しがつかないぐらいに失っ
   てしまうかもしれません。覚えておいてください。「取り返しがつかない」
   は、そもそも私たちが避けようとしていたもので、あなたの決断は結局は
   重大なものだったということです。


Happily, both of these reasons can be mitigated effectively by just
admitting up-front that you don't have a friggin' clue, and telling
people ahead of the fact that your decision is purely preliminary, and
might be the wrong thing.  You should always reserve the right to change
your mind, and make people very _aware_ of that.  And it's much easier
to admit that you are stupid when you haven't _yet_ done the really
stupid thing.

幸いな事に、手掛かりを持っていないことを正直に認めて、あなたの決断が全
くの暫定的なもので、間違っているかもしれないということを先に言っておけ
ば、これらの理由はどちらも効果的に軽減することができます。考えを変える
権利を常に留保しておいて、そのことを皆にしっかりと承知させておくべきで
す。そして、本当にバカな事をする前であれば、自分がバカだと認めることは
ずっと気楽なものになります。


Then, when it really does turn out to be stupid, people just roll their
eyes and say "Oops, he did it again".

そうすると、本当にバカなことをやってしまった時でも、まわりの人々は目を
グルっと回して「あ〜ぁ、またやりやがった」と言うだけです。


This preemptive admission of incompetence might also make the people who
actually do the work also think twice about whether it's worth doing or
not.  After all, if _they_ aren't certain whether it's a good idea, you
sure as hell shouldn't encourage them by promising them that what they
work on will be included.  Make them at least think twice before they
embark on a big endeavor.

この「無能であることをあらかじめ認識させておくこと」は、実際に作業をす
る人たちに、やる価値があるかどうかをもう一度考えさせることにもなるでしょ
う。結局、良いアイディアであるかどうかを「彼ら」の方が確信していないな
ら、成果物が（カーネルに）取り込まれることを約束して希望を持たせては絶
対にいけません。彼らが大作業に取り掛かる前に、少なくとももう一度彼らに
考えさせてください。


Remember: they'd better know more about the details than you do, and
they usually already think they have the answer to everything.  The best
thing you can do as a manager is not to instill confidence, but rather a
healthy dose of critical thinking on what they do.

覚えておいてください。彼らはあなたよりも詳細を知っていた方がいいし、自
分たちが全てのものに対する答えを持っていると通常は既に考えています。あ
なたがマネージャとしてできる最良の事は、開発者たちがやっていることに対
して自信を持たせることではなく、適度に批判的に考えさせることなのです。


Btw, another way to avoid a decision is to plaintively just whine "can't
we just do both?" and look pitiful.  Trust me, it works.  If it's not
clear which approach is better, they'll eventually figure it out.  The
answer may end up being that both teams get so frustrated by the
situation that they just give up.

ところで、決断を避けるもう一つの方法は、悲しげに「両方できないのかなぁ」
と泣き言を言って、哀れみを誘うことです。信じてください。うまくいきます。
どちらのアプローチが良いのかあなたが分かっていなくても、彼らの方がいず
れ見つけ出すでしょう。その状況にいらいらして両チームが諦めるというのが
答えになるのかもしれません。


That may sound like a failure, but it's usually a sign that there was
something wrong with both projects, and the reason the people involved
couldn't decide was that they were both wrong.  You end up coming up
smelling like roses, and you avoided yet another decision that you could
have screwed up on.

これは失敗のように聞こえるかもしれません。しかし、通常それは、両方のプ
ロジェクトとも何かまずい点があるという兆候ですし、プロジェクトのメンバー
たちが決断できないのは両方が間違っているからです。結局はバラの香りがす
るような良い結果に落ち着き、失敗したかもしれないもう一つの決断を避けて
いたのです。


                Chapter 2: People
		2章：人々

Most people are idiots, and being a manager means you'll have to deal
with it, and perhaps more importantly, that _they_ have to deal with
_you_.

ほとんどの人はバカです。そして、マネージャであるということは、あなたが
その事実を受け入れなければならないということです。そしておそらくさらに
重要なことは、彼らの方もあなたを受け入れなければならないということです。


It turns out that while it's easy to undo technical mistakes, it's not
as easy to undo personality disorders.  You just have to live with
theirs - and yours.

技術的な過ちは簡単に取り消せますが、壊れた人間関係を取り消すことは簡単
ではありません。あなたは彼らの過ち（そしてあなたの過ち）をただ受け入れ
なくてはなりません。


However, in order to prepare yourself as a kernel manager, it's best to
remember not to burn any bridges, bomb any innocent villagers, or
alienate too many kernel developers. It turns out that alienating people
is fairly easy, and un-alienating them is hard. Thus "alienating"
immediately falls under the heading of "not reversible", and becomes a
no-no according to Chapter 1.

しかしながら、カーネルマネージャとしてうまくやるために、あまり多くのカ
ーネル開発者と絶交したり、無実の罪をきせたり、疎遠にしたりしないように
した方が良いでしょう。疎遠になるのはとても簡単ですが、逆は難しいのです。
したがって「疎遠になる」と、すぐに「取り返しがつかない」ことになってし
まい、Chapter 1 によるところのやってはいけない事になります。


There's just a few simple rules here:
 (1) don't call people d*ckheads (at least not in public)
 (2) learn how to apologize when you forgot rule (1)

簡単なルールがたった二つだけあります。
 (1) 人々を「d*chheads」と呼ばないでください（すくなくとも人前では）。
 (2) ルール(1)を忘れていたときの謝まり方を覚えてください。


The problem with #1 is that it's very easy to do, since you can say
"you're a d*ckhead" in millions of different ways (*), sometimes without
even realizing it, and almost always with a white-hot conviction that
you are right.

#1 の問題は、何100万通りの言い方で(*) 「お前は d*chhead だ」と言えてし
まうので、ついやってしまいがちだということです。気づかずに言っているこ
ともありますし、大抵の場合は自分が正しいという確固たる信念をもって言っ
ています。


And the more convinced you are that you are right (and let's face it,
you can call just about _anybody_ a d*ckhead, and you often _will_ be
right), the harder it ends up being to apologize afterwards.

そして、あなたが自分が正しいと確信しているほど、後で謝まるのが難しくな
ってしまいます。（現実を認めましょう。あなたは誰にでも d*chhead と呼ん
でいる可能性があるし、大抵はあなたが正しいのでしょう。）


To solve this problem, you really only have two options:
 - get really good at apologies
 - spread the "love" out so evenly that nobody really ends up feeling
   like they get unfairly targeted.  Make it inventive enough, and they
   might even be amused.

この問題を解決するための選択肢は、実際二つしかありません。
 - 謝まるのが本当にうまくなること。
 - 不公平にならないように均等に「愛情」をふりまくこと。十分独創的にやっ
   てください。そうすれば彼らは面白がったりすらするでしょう。


The option of being unfailingly polite really doesn't exist. Nobody will
trust somebody who is so clearly hiding his true character.

常に礼儀正しくするという選択肢はありません。明らかに本心を隠している人
なんて誰も信じないでしょう。


(*) Paul Simon sang "Fifty Ways to Lose Your Lover", because quite
frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't
scan nearly as well.  But I'm sure he thought about it.

(*) Paul Simon は、「恋人を失う方法は50通りある」と歌いました。率直に
言って、「開発者におまえは D*ckhead だと言う方法は100万通りある」とは
あまり似てないかもしれませんが、彼はそれと同じ主旨のことを考えていたの
だと思います。


		Chapter 3: People II - the Good Kind
		3章： 人々 II - 優秀な人たち

While it turns out that most people are idiots, the corollary to that is
sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot that you are.

ほとんどの人がバカなわけですが、それはつまり悲しいことにあなたもその一
人だということです。私たちは皆、自分が平均的な人よりもマシだという認識
に安住していられます（現実を認めましょう、自分が平均か平均より下だと信
じている人などいないのです）。しかしその一方で、自分が周りの人たちの中
で格別に頭が切れる部類に入るわけではなく、あなたよりはバカでない人がい
るだろうということも認めるべきです。


Some people react badly to smart people.  Others take advantage of them.

賢い人たちに対してひどい反応をする人もいますが、彼らを利用する人たちも
います。


Make sure that you, as a kernel maintainer, are in the second group.
Suck up to them, because they are the people who will make your job
easier. In particular, they'll be able to make your decisions for you,
which is what the game is all about.

あなたはカーネルメンテナとして、二番目のグループにいることを確かめてく
ださい。賢い人たちはあなたの仕事を簡単にしてくれるので、彼らのご機嫌を
取ってください。特に、彼らがあなたの代わりに決断してくれるだろうという
ことが重要です。


So when you find somebody smarter than you are, just coast along.  Your
management responsibilities largely become ones of saying "Sounds like a
good idea - go wild", or "That sounds good, but what about xxx?".  The
second version in particular is a great way to either learn something
new about "xxx" or seem _extra_ managerial by pointing out something the
smarter person hadn't thought about.  In either case, you win.

したがって、誰かがあなたより賢いと気付いたなら、あとは一緒にうまくやっ
ていくだけです。あなたの管理責任は主に「いい考えのようだね、それで行こ
う」、または「いいみたいだね、でも xxx についてはどう？」と言うだけに
なります。特に二つ目のバージョンは、「xxx」について新しいことを学んだ
り、より賢い人が考えていなかった事を指摘したことで、ものすごく管理者ら
しく見えるという点で素晴らしい方法です。いずれにせよ、あなたは成功する
のです。


One thing to look out for is to realize that greatness in one area does
not necessarily translate to other areas.  So you might prod people in
specific directions, but let's face it, they might be good at what they
do, and suck at everything else.  The good news is that people tend to
naturally gravitate back to what they are good at, so it's not like you
are doing something irreversible when you _do_ prod them in some
direction, just don't push too hard.

注意しなければいけないのは、ある分野では偉大であっても、別な分野では必
ずしも通用するわけではないことを認識することです。あなたが人々に別な仕
事をやらせようとする場合、彼らは今やっている仕事については得意かもしれ
ないが他は全て最低かもしれないという現実を認めましょう。朗報なのは、人
々は自分が得意なものに自然に引き戻されるので、あなたが別な仕事をやらせ
ようとしても、取り返しがつかないことをしているというわけではなさそうだ
ということです。ただ、あまり無理強いはしないでください。



		Chapter 4: Placing blame
		4章：非難の矛先を変える

Things will go wrong, and people want somebody to blame. Tag, you're it.

物事がうまくいかないと、人々は誰かを非難したくなります。あなたがその誰
かです。


It's not actually that hard to accept the blame, especially if people
kind of realize that it wasn't _all_ your fault.  Which brings us to the
best way of taking the blame: do it for another guy. You'll feel good
for taking the fall, he'll feel good about not getting blamed, and the
guy who lost his whole 36GB porn-collection because of your incompetence
will grudgingly admit that you at least didn't try to weasel out of it.

非難を受け入れることはそんなに難しいことではありません。周りの人々が「
必ずしも全てがあなたの責任というわけではなかったのだ」と理解してくれる
ような人たちなら特にそうです。そういう場合は一番うまい方法で非難を受け
ることができます。つまり、他人への非難を引き受けるということです。（マ
ネージャである）あなたは他人への非難を引き受けることで役割を果たした気
分になり、（ミスをした）彼は非難を受けずに済んでホッとし、あなたの無能
のせいで 36GB のポルノコレクションをまるごと失った人は、少なくともあな
たが言い逃れをしなかったことを一応認めるでしょう。


Then make the developer who really screwed up (if you can find him) know
_in_private_ that he screwed up.  Not just so he can avoid it in the
future, but so that he knows he owes you one.  And, perhaps even more
importantly, he's also likely the person who can fix it.  Because, let's
face it, it sure ain't you.

それから、（もし見つけることができたら）実際に台無しにしてしまった開発
者にそのことを「こっそりと」教えてあげてください。今後はそんなことが無
いようにというだけではなく、彼があなたに借りを作ったことを知らしめるた
めです。そして多分さらに重要なことは、それを修正できるのもまた、恐らく
その開発者だということです。なぜなら、現実を考えれば（修正できる人が）
あなたではないのは確かなのです。


Taking the blame is also why you get to be manager in the first place.
It's part of what makes people trust you, and allow you the potential
glory, because you're the one who gets to say "I screwed up".  And if
you've followed the previous rules, you'll be pretty good at saying that
by now.

そもそも非難を引き受けるからこそ、一人前のマネージャになれるのです。あ
なたが「私が台無しにしました」とちゃんと言える人であれば、非難を引き
受けることによって信頼され、陰ながら称賛されます。そしてもし、あなたが
これまでに出てきたルールに従っているなら、そろそろそれを言うのがとても
うまくなっていることでしょう。


		Chapter 5: Things to avoid
		5章：避けるべき事

There's one thing people hate even more than being called "d*ckhead",
and that is being called a "d*ckhead" in a sanctimonious voice.  The
first you can apologize for, the second one you won't really get the
chance.  They likely will no longer be listening even if you otherwise
do a good job.

人々が「d*chhead」と呼ばれるよりもっと嫌がることがあります。それは、聖
人ぶった声で「d*ckhead」と呼ばれることです。最初のものに対しては謝まる
ことができますが、二つ目についてはその機会は本当に得られないでしょう。
たとえあなたが他で良い仕事をしていても、たぶん彼らはもはや聞いていない
でしょうね。


We all think we're better than anybody else, which means that when
somebody else puts on airs, it _really_ rubs us the wrong way.  You may
be morally and intellectually superior to everybody around you, but
don't try to make it too obvious unless you really _intend_ to irritate
somebody (*).

私たちは皆、自分が他の誰よりも優れていると考えています。それはつまり、
お高くとまっている人がいると、ものすごく神経を逆撫でするということです。
道徳的にも知的にも、あなたは周りの誰よりも優れているのかもしれませんが、
誰かを本当に苛立たせたい(*) というのでなければ、あまりおおっぴらにその
事を言おうとしてはいけません。


Similarly, don't be too polite or subtle about things. Politeness easily
ends up going overboard and hiding the problem, and as they say, "On the
internet, nobody can hear you being subtle". Use a big blunt object to
hammer the point in, because you can't really depend on people getting
your point otherwise.

同様に、丁寧すぎたり遠回しになりすぎてもいけません。丁寧になりすぎて問
題を見えにくくすることになりがちです。曰く、「インターネットでは、婉曲
な言い方なんて誰も聞いてはくれません」ということです。ポイントを強調す
るために、無愛想にやってください。なぜなら、あなたが言いたいことをちゃ
んと分かっていないような人を当てになんてできないからです。


Some humor can help pad both the bluntness and the moralizing.  Going
overboard to the point of being ridiculous can drive a point home
without making it painful to the recipient, who just thinks you're being
silly.  It can thus help get through the personal mental block we all
have about criticism.

無愛想だったり道徳的だったりする合間にユーモアを入れるとよいでしょう。
思い切りふざければ、聞く人を嫌な気分にさせずに要点を理解させられます。
その人はあなたがバカだと考えるでしょうけど。このようにユーモアは、批評
されるときの抵抗感を和らげることができます。


(*) Hint: internet newsgroups that are not directly related to your work
are great ways to take out your frustrations at other people. Write
insulting posts with a sneer just to get into a good flame every once in
a while, and you'll feel cleansed. Just don't crap too close to home.

(*) ヒント：　仕事に直接関係していないインターネットのニュースグループ
は、他の人にあなたのフラストレーションをぶちまけるための素晴らしい方法
です。時々、軽蔑を込めた侮辱的な投稿を書いて、フレームにしたりすれば、
すっきりするでしょう。ただあまり身近なところでバカなことをしないことで
す。


		Chapter 6: Why me?
		6章： 何故わたしが？

Since your main responsibility seems to be to take the blame for other
peoples mistakes, and make it painfully obvious to everybody else that
you're incompetent, the obvious question becomes one of why do it in the
first place?

あなたの主な責任は、他人の過ちに対する非難を引き受けて、自分が無能だと
いうことを痛々しく公言することのようです。だとすると、そもそも何故そう
するのかという自明な疑問がわきます。


First off, while you may or may not get screaming teenage girls (or
boys, let's not be judgmental or sexist here) knocking on your dressing
room door, you _will_ get an immense feeling of personal accomplishment
for being "in charge".  Never mind the fact that you're really leading
by trying to keep up with everybody else and running after them as fast
as you can.  Everybody will still think you're the person in charge.

まず、ドレッシングルームのドアを叩いて泣き叫んでいるティーンエイジの子
供の面倒をみていれば、「責任を負っている」ことを身に沁みて感じるでしょ
う。皆に遅れないようにして、できる限り速く彼らの後ろを走ることによって、
実際にはあなたが先導しているという事実を気にしないでください。あなたが
責任者だと皆いつも考えてます。

It's a great job if you can hack it.
