  |
はてなキーワード: supervisorとは
コンサル業界に長くいるとコンサル用語に慣れてしまい、一般的に使いがちですが、そんなことないよねという気付きを与えるため、ピックアップしてみました。
目次
Up or Out
「available」の略語。プロジェクトにアサインされず、売上をあげていない状態を指します。短期間ならば、このタイミングで休暇を取れますので嬉しいのですが、長く続くと肩身が狭い状態です。
英語の意味「人手が空いている。時間がある。」と相違はないものの、短縮し日本語化したこの使い方はコンサル独特のものと言えます。
「Knowledge Transfer」の略。意味は、英語のまま「知識の伝達」ですが、英語化した上に短縮化するところがコンサルらしいと言えます。特にアクセンチュアで使われ、アクセンチュアの人間が他ファームに行くと通じないという事態が発生し、慌てます。
コンサル業界全体では、むしろ「ナレトラ（Knowledge Transferの略）」「スキトラ（Skill Transferの略）」のほうが通じます。
「output」。元々はコンピュータ用語で、コンピュータに対して「入力」することを「input」、コンピューターから「出力」することを「output」といいます。コンサルでは、自身が作成する資料を指します。
「コンサルはアウトプットが全てだから」とよく言われますが、まさにその通りです。アウトプットのみでコンサルとしての資質が判断されるといっても過言ではありません。パワポの作成が下手だと出来の悪いコンサルだと思われるので、パワポなんてお絵かきだなどと侮ることはできません。
「supervisor」の略。英語の意味は「監督・管理する者」です。日本ではサービス業の統括責任者、エリアマネージャとして使われることが多いですが、コンサル（というよりこれもアクセンチュア用語な気がします）では「上司」という意味で使います。
「cut-over」。新しいシステムの利用を開始することを指します。コンサル業界よりもIT業界でよく使われる単語ですが、英語での意味は「木を伐採する」ですので、海外では通じない和製英語です。同じ意味で使われる「サービスイン」も同様です。
では、どう表現すれば英語圏で通じるのかというと「GO-Live」が正解です。
「共同作業」といった意味があるものの、行艇的には「相乗効果」といった意味でつかわれることが大半です。「シナジー効果」と言うこともあり、M&Aや、経営の多角化を行う際に、それぞれが元々持っていた以上の価値を生み出す効果を指します。他にも、取り組み施策に対してこういった効果もあるという派生的なケースで使ったりもします。
某CMで「結果にコミットする」というキャッチフレーズを聞き、何となく知っている方も多いのではないでしょうか。
コンサルシーンにおいては「約束する」といった意味合いで、責任をもって職務を果たすという強い意志を表す際に使用されます。決意表明的な意味合いも強く、提案書でもこの表現を使ったりします。コンサルプロジェクトでも上司が部下に「コミットメントしていない」とか「コミットメントが全く足りない」と叱咤するシーンがよく見受けられます。自分事で動けないコンサルはこれを散々言われているものと思われますが、言われても「なんのこっちゃ？」と『分からない奴に何を言っても無駄』パターンに陥らされるのはあるあるかと思います。
ここまで、淡々と説明してきましたが、やはりコンサル用語の真髄（？）といえば、
Up or Out
「up or out」。直訳すると「昇進するか辞めるか」ですが、意味合い的には「昇進できないものは去れ」となります。他の業界では、出世とは関係なく定年まで地味にこつこつ長く続けることが大事と言われたりもしますが、コンサルは毎年結果を出してなんぼと言われます。
コンサルファームにも昔はあった文化で、戦略や一部ベンチャーにはこの考えは色濃く残っています。大手総合系ファームは、日本で経営する上では労働法は無視できないので、この考えは次第に薄れていっているような気がします。
そんな大事な言葉まで、わざわざ英語を使って表現するところもコンサルらしいと言えます。
ちょっと調べてみたところ、やはりそうだった。具体的には『タクティクスオウガ』(1995)のスタッフで『ファイナルファンタジータクティクス』(1997)にも参加しているのは、松野、皆川、吉田という中核スタッフ3人と、外部のサウンドスタッフである岩田、崎元だけだった。
私がFFTから感じていた「タクティクスオウガ感」は、お話、絵、音楽という表層的なものだったのか（もちろんスクウェアのスタッフもタクティクスオウガに“寄せて”作ってただろうけれど）。
件の中核3人以外の『タクティクスオウガ』スタッフは、その後ニンテンドー64で任天堂より発売された『オウガバトル64』(1999)に参加している。
クエストはそこからGBAで『タクティクスオウガ外伝 The Knight of Lodis』(2001)をリリースするのだが、そこに『タクティクスオウガ』のスタッフはほぼ残っていない。 ここに至ってクエスト閥とスクウェア閥で完全に道が分かれたように見えるが、実はここからまた一捻りある。
その後クエストはIPをスクウェアに売却するのだが、そのときにスタッフもスクウェアに移籍したようだ。その結果、『タクティクスオウガ』(1995)にも『FFタクティクス』(1997)にも未参加だった『タクティクスオウガ外伝』(2001)の若いスタッフの中から、スクウェアに移籍後『FFタクティクスアドバンス』(2003)に10人、『FF XII』(2006)に11人ものスタッフが名を連ねている。ていうか『FFタクティクスアドバンス』ってこれもう実質『タクティクスオウガ外伝』じゃん、というメンツで作られている。『タクティクスオウガ外伝』の村澤裕一ディレクターは現在もスクエニでデザイナーとして『FF XIV』の開発に関わっているようだ。そして、その『FF XIV』のアートディレクターは皆川裕史。タクティクスオウガの遺伝子はまだ息づいている。
海外ブログから原書の該当部分の引用だけ拾ってきたので考察は任せた
In the early days of airmail flying, the mail pilots came to believe that their crash rate was unacceptable, even for people accustomed to danger. Finally, a group of them convinced the U.S. Air Mail Service that postal supervisors at the airports were ordering them aloft in bad storms and poor visibility. The solution? Not a new regulation spelling out what weather was safe and unsafe, but rather this simple order: if an outgoing pilot desired, his supervisor had to join him in the cockpit to fly a circuit around the airport before the pilot went off on his mail run. Quickly the supervisors’ tolerance for bad weather dropped.
この話の続き
systemd-nspawnに移行した
以下詳細とか雑記
docker commitもdocker diffも使わないし、要らない
要らないだけならまだしも、aufs、overlayfs周りでトラブル可能性がありむしろ邪魔
イメージの差分管理はファイルシステムの層でやるのが素直でコンテナ管理にくっついてるのに違和感がある
Docker特有の機能をフルに使ってる奴ならまだしもコンテナ動かすだけなら何使っても変わらねーよｗ
Docker Hub からイメージダウンロードしてtarで解凍すりゃ良いだけじゃねーか
composeだって容易にコンバート可能だし、composeで何が起きるかわからない状態で本番運用とか口にしないで欲しい
実際systemd-nspawnの今でもベースはDocker Hubから拾ってきてるし、Docker使ってる奴との受け渡しも問題ない
やりかたは runc.io のGetting startedでも見れば？
Docker hubでよくわかんねーイメージ落とすときに、出所がクリアになるってメリットだけだなこんなん
取り急ぎansibleでセットアップは済ませてる
コンテナにしたからプロセス管理は違う方法でやります→supervisorで云々→めんどくさいだろ！
じゃあ1プロセス1コンテナにしてマイクロサービスにします→本当に便利それ？管理できる？
ログの管理は？logrotateは誰がやる？データボリュームはどこにする？みたいなアホみたいな検討し始めたときに俺は会議室を出た
「いや今はこれが主流で流行ってるから便利です」みたいな事言ってるバカが居て殴りたくなった
「毎週、毎週swarmが壊れたバージョンアップで再起動だのと余計な仕事増やしやがって、いつまでDocker社のβテストに付き合うつもりだクズども」
とは言えないので
「今の状況は前よりも運用負荷が高い状況みたいなので、systemd-nspawn等のシンプルなものに代替できないか検討してほしい」
と言ってなんとか説得
(結局半分以上は俺が対応したが)社内のクリティカルな部分のDockerは全部廃棄した
普通に起動して、普通に終了できる。コンテナの中なのにそれを意識しないくらい普通に起動する。
aufs,overlayfs等の差分管理しなければそれに付きまとう問題もない(overlayfsとか使うこともできる)
自動起動も設定もコマンドもコンテナ内だから〇〇しなきゃダメみたいなやつが無くなって、ものすごく安定してる
Dockerも--privilegedつけてinitからrunすればいいって？糞不安定だし、権限多すぎだろ？capabilitiesを適切に設定しろだって？
一生やってろバーカ
結局のところ本当にこれ便利になったんだっけ？って聞かれて理由を言える奴じゃないと何をやってもダメってことが分かった
これはDockerに限らず全部そうだと思う
QiitaとかにあるDockerでこんな素晴らしくなったよって記事の大半は本質を見失った馬鹿記事
楽になるどころか厄介事を＋１してるだけ
とりあえずこっちはDockerのゴタゴタに振り回されなくなって良かったよって話
そもそも便利なのかちゃんと考えてる？
「日々Dockerfileをメンテして開発環境がこんなに楽になります！」
「Dockerなので本番とも開発者同士でも同じになります！」
馬鹿じゃねーのかｗ？
Dockerfileメンテなんて手順書メンテとかシェルスクリプトメンテしてんのと大して変わらねーよｗ
そのDockerfileから作ったものが本番と同一だなんて保証はねーって気づけボケが
それと「同じDockerfileから作ったものだから環境差異はありません」なんて寝言まだ言ってるの？
yumもaptもリポジトリがセキュリティアップデートやらで変化する以上
いつも同じ結果になるわけじゃねーだろが、（バージョンロックする方法はあるけどめんどいだろ）
本番でもコンテナを使ってますってやつら以外無理してDocker使う必要ないんじゃねーか？
お前らが欲しいのは軽いVMであって細切れのコンテナじゃねーだろ？
initを潰して,supervisor入れてプロセス管理して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか？
流行りのコンテナぽくしたいならLXDやらsystemd-nspawnの方がよっぽど筋がいい
というわけでよく考えなおせ
続き書いた
