「営業部門」を含む日記 RSS

はてなキーワード: 営業部門とは

2017-09-20

女性管理職をやっかむ、ズレているオジサン


女の先輩がマネージャーになった

今日女性の先輩がマネージャー職になることが通達された。

社会営業部門では初めてのことだ。

僕はまだぺーぺーだから

出世争いに加わるのは先の話だけど

うちの会社も、やっと古くさい昭和の皮を1枚脱いだのだと喜ばしかった。


先輩は任された係で新しい取組をどんどん仕掛けて実績をあげていた。

他の部門との連携でもうまく調整していた。

彼女が抜擢された役職は、それまで他のマネージャー兼務していたか

ポストのものも長らく空いていたんだと思う。

実力と環境とがいいタイミングで重なった人事だと感じた。


それでも、前世から抜け出せない、ひねくれた見方をするオジサンがいた。

「〇〇さんは産休で休んでたのに、なんでこんなに早くマネージャーになれるんだろう。俺もあの部門に行きたいよ」


先輩は確かに産休・育休を取得していたけれど、

それはもう大分前のことで、ここ数年は出産前と同じようにフルタイムで勤務していた。

「俺の方が彼女より実績をあげている」とか「もっと会社に貢献している適任者がいる」とか

先輩の実績を見て人事に文句をつけるならまだしも、

産休で休んでいたことは先輩が出世することを否定する理由にはならない。

しろ産休で休んでいた間のGAPを乗り越え

家に子どもを抱えながら、

より効率よく、なるべく残業せずに成果をあげていたことは

先輩が有能であることの証明だと思う。

文句をつけたオジサンは、仕事人間だけれど

所謂セ・パ両リーグ制覇((セクハラパワハラ両方すること))の人。

僕も、オジサンの心無い発言を受けた同期の女の子に泣きつかれたことがある。

どんなにその人自身が実績をあげていても、

会社という組織の中で

わざわざ目下の人を踏みにじって余計な軋轢を生む人は

採用コスト教育コストを積み増す生産性の低い人だと思う。


限られた時間で成果をあげていた先輩が、他人気持ちが思いやれないオジサンより先に出世したことはとても良いことだ。


僕が子ども妊娠することはないけれど、

まれてきた子ども身体が弱くて、時間お金がたくさんかかるかもしれないし

いつ実家の親が倒れるか、いつ自分自身病気になるかもわからない。

ライフステージの変化があっても、

限られた時間で大きな成果を上げられる人になりたいし

置かれた立場で最大限の力を発揮する人を評価する会社でいてほしいと思った。

2017-06-14

経理仕事が合わなかった

営業部門採用されたはずが、経理部門に配属された。請求書の処理や物品の購入など購買に近い業務が主でそんなにスキル必要ということではなかったけれども、計算が苦手で大雑把な自分には地獄新卒からの4年間でした。

理由は主に業務内容のやりがいのなさと、計算を好む同僚たちと馬が合わなかったことです。

毎日数字ばかり打ち込む同じ作業やりがいを感じることができませんでした。基本的ミスなく作業することが前提の経理業務100%正しくやりきっても、感謝されることも評価されることもない。

しかミスが一つ起こるとかなりの大事になる。他人ミスに気づかないこと自体自分ミスになる。

褒められることはなく、謝り続ける、自分が悪いのか分からないまま怒られ続ける毎日

この環境でどうやってモチベーションを保つのか、真剣に悩んで先輩に相談した。

数字が合った瞬間って気持ち良くない?」と言われた。ごめんなさい、全く理解できなかった。数字はもう見たくないと日々落ち込むだけでした。

ここから下は弊社の先輩が変わっている、という話で全ての経理や購買の人がそうではないと分かっている。

自分ミスはしっかりピックアップされるが、ミスが起きないように新たな施策を実行するのは許されなかった。

当時その部署では複雑な計算電卓手書きで行っていた。大雑把な自分は、計算の途中どこかで数字が合わなくなる。エクセル計算式打ち込んで、数字を入れれば最終金額が出るような簡単なシートを作った。

先輩に「ズルしないでください」と言われ、目が回った。

何かを変える、ということに部署の人たちは猛烈な拒否反応を示すことが多々あった。それゆえ、書類フォーマットも何年も変わらず、他部署取引先に対して異常に面倒な手続きを頼まなければいけないことが多かった。その度に嫌みを言われたり、逆上されたりということが何度もあった。自分だって変えたいわ…と思いながらひたすら頭を下げるしかなかった。

残業は30時間程度だったので、身体問題なかったけれどこのままファーストキャリアを摩り下ろすのってどうなんだろうと悩みに悩み、胃に穴が空いたところで、異動希望が通らなければ退職しようと考えていると上司に打ち明けた。

救いだったのは上司積極的人生に介入こそしないけれど、訴えをきちんと汲んでくれる人だったこと。

ちょうどストレスチェックに引っかかり、産業医が後押ししてくださったこともあり、紆余曲折ありましたが今は営業職です。

自分の工夫によって結果が変わり、評価につながるのが本当に楽しい

経理仕事を通じて分かったのは、当たり前だけれど人には向き不向きがあるということです。

不向きな面でしか勝負できなければ、達成感がある仕事をするのは難しいし、周りから評価も低くなる。

羽生結弦フィギュア勝負すべきだし、五郎丸ラグビー勝負するべきです。

自分の得意分野で戦えないとき努力で苦手分野を乗り越えるのももちろん素晴らしいけれど、土俵を変えた方がいい結果が出ることもあると思いました。

経理仕事好きな人には毎回否定されるけれど、不向きな人には特に難しい業務だと思う。

仕事が難しいのではなくて、モチベーションを保って取り組むのが致命的に難しくて辛かった。

合わないと思ったら、何らかのアクションを取った方がいいと個人的には思います

どんな経験も糧になると信じて自分なりに頑張ったけれど、

営業部門でまあまあ成績が出せるようになって振り返って見て、やっぱり無駄時間だったなと思うので。

2017-06-01

anond:20170516051010

ブコメの内容は相変わらずひどいけど、今回の原文を読んで理解した上でトヨタ擁護する奴がいるなんて驚き。

クレームを言われたトヨタお客様センター担当者達が、話題を逸らす為にわざわざ見当違いな事をコメントしてるんじゃないかとさえ思える。

もしくは、話題逸らしの為にトヨタ社員営業部門担当者が、トヨタ本社の指示で書いてたりしてなw

2016-08-20

ソフトウェア見積って

明らかに見積おかしいケース、KO時点で見積もりが過少であることを伝えてもPMが聞き入れてくれない。

(見積もってるのはPM)

必要作業と、時間を伝えても「ないものはどうしようもない」といわれる。

営業部門等で、値引き交渉などいろいろあったのだとは思うが…

見積が過少(失敗)しているケースに対してPM責任を取ってくれない、

下流工程責任にしているように思う。

PMの上に相談したら、「見積おかしいのは是正していくので気にしなくてよい」と言ってもらえたが

PMの出す見積改善されているように見えない。

毎回、赤字を見込んで下流工程主導で対策会議を行うのが苦痛

2016-06-26

自分に足りないものばかり見つけて喜んでいるバカなお前らへ

本屋とかネットとか見てると

成功するためのHOW TO みたいなのって人気じゃん

TOEIC高得点仕事が出来る人になる、断捨離 整理整頓とか。

そういう成功HOW TO を見て喜んでる人って、

自分には○○が足りない、だから今俺は不幸なんだ」

っていう発想だよね。

自分自分を不幸だって思い込んじゃってるよね。

そんなんじゃ死ぬまでお前は不幸だよ。って思う。

一生不幸メシ食ってろって、

いったん自分を認めてあげた方がいいよ。マジで

給料は安いけど会社に勤めて毎日仕事がある。十分幸せじゃん。

嫌になる気持ちはわかるけど。

信頼して仕事を与えてもらえるってすごいことよ。

仕事がない?でもとりあえずはメシ食って生きていけてるんでしょ?

いきなり誰かに殺される訳もなく、生きていけるんでしょ?

良いじゃん。

重度の鬱?死にたい

でもネット開いて今この文章自分意思で読んでるんでしょ?

とりあえずは生きてるんでしょ?十分じゃん。良いよ。

好きなだけネット見ようよ。自由じゃん。幸せだよ。

自分に足りないものばかり見つけて

「あー○○ができるようになったら俺は幸せになるー」

ってバカじゃないの

まずはお前の今いる状況を肯定して幸せになれよ。超簡単

そこから何をやるかを、何を目指すかを考えろよ。

あと、何を目指すかを考えるとき

○それをやったら何が得られるか(具体的に)

○そのためにはどれくらいの時間がかかりそうか

○それをやる時間はあるか

○本当にそれを達成する必要があるか

○それを達成して得られるものより良いもの他の方法で得られないか

○それを達成した人は本当に幸せそうか

○本当にそれをやる必要があるのか

をしっかり考えた方が良い。

もちろん進めていく上で思ったより時間がかかったり、失敗したりすると思う。

そしたらもう一度↑のことをもう一度あらためて考えて今後の方針を決める。

例えば「TOEIC900点を取りたい」って思うとする

○それをやったら何が得られるか(具体的に)

→今の会社海外営業部門に異動できるかも

○そのためにはどれくらいの時間がかかりそうか

→1年くらいの期間で平日は1時間土日はみっちり勉強必要かも

○本当にそれを達成する必要があるか

→平日と土日潰して勉強するくらいだったら、遊びたい気もする

→そもそも海外営業部門って中途採用ばっかりだし、TOEIC出来たところで無理かも

○それを達成して得られるもの他の方法で得られないか

→まずは、異動先を自分で押し通せるくらい社内で認められる方が先

→そのためには今の自分の実績を上げる方が先かも。

○それを達成した人は本当に幸せそうか

→そもそも海外営業部門ってパッと見のエリート感はあるけどすごく忙しそうだし、

 専門部隊になるから部門への異動もないし、そこから出世も聞いたことがない。

○本当にそれをやる必要があるのか

→単純に出世ルートをたどりたいなら今の国内営業で実績を上げた方が良いかも。

→やっぱりTOEIC高得点時間をかけるくらいだったらその時間で今の与えられた仕事を十分頑張った方がいいか

みたいな。

まとめ

自分幸せを認めろ

○それを本当にやる必要があるのか考えろ

○頑張れ

以上

2016-05-15

コンサルタントITジャーナリスト林信行問題について

※読みにくい、長い(そのため最後が切れてる)という指摘もいただいたので手直しします。

※長いのは元のnobiのが冗長なんですが、いらんところをバッサリきると、意図的とかも言われかねず。

※長いのは勘弁して貰って、多少は読みやすくしてみます

----

長く書けるとこもないし、パブリック増田にするということで、

ライター「矢作晃」問題について の反論について、

-----

引用三行略

----------------------------------------

イントロ●矢作の反論、および解説

平日業務日の大事な時間、つつもいつも記者会見遅刻してやってくるジャーナリストに奪われる、

他の報道関係者アテンドする人の貴重な時間を連日削り取ってるのが貴方です。そんなあなた大事土曜日時間凌駕するほど、

無駄時間過去何十年も繰り返されたことをご自覚下さい。

----------------------------------------

お察しかもしれませんが、この投稿が共有されている人は「矢作晃」とある程度、交流がある方々です。※個人名落としました

【1.どう接するべきか(林案)】

子供を育てたことがある人ならわかると思いますが、ダダをこねる赤ん坊にいい顔をしてしまうと、子供ダダはひどくなるばかりです。おそらく最良の方法無視する、あるいはちゃんと向き合って接する場合には「気をそらす」だと思います

心をわずらっている彼が、最近、再び暴れているという知らせを何人かから受けて、彼のツイートやらFacebook投稿、そこでのコメントのやりとりなどを観察しました(ブロックしているけれど、ブラウザプライベートモードを使うとパブリック投稿は読めるようです。まあ、そりゃ当然か...)。

自分の不幸のアピールは彼の天賦の才能なので、それを見て「かわいそう」、「何か言ってあげなきゃ」と思う同情心の気持ちはわかります

でも、彼のことをこれから先、一生面倒をみる覚悟がないなら、そして本当に彼を思いやるなら、そこで突き放すことも大事だと思います

人間は誰しも「人に認められたい」願望があります。彼は特にそれが強いと思います

さら自己肯定力はやたらと強いので、誰かがちょっとでも同調をしてしまうと「やはり、俺は正しいんだ」と、この24時間ほどの爆発を生んでしまうというのが私の見立てです。

----------

同情について●矢作の反論、および解説

彼の見立てですから何も言うことはありません。このリストは、今の事件で彼が味方に付けたい、付けようとしているだけのリストです。自己顕示欲ねぇ、何かにつけて審査員とかやってる貴方は、いつもスペシャルアドバイザーとか、特別審査員とか、一般ではなく何か特別な枠におさまり(言い換えれば、その内容の責任を一切とらない安全ポジションを確保しながら、自己顕示欲をだしてますね。

----------

同情のコメントがなくても、おそらく愚痴ツイートは続いていたでしょう。

でも、ここまで増長することはなかったと思います

「それでも彼のことが心配だ。何かしたい」という人はいるでしょう。

そういう人への私のオススメは、他の関連のない話題に彼を誘導することです

赤ちゃんあやし方と一緒です)

彼が好きなアニメマンガが好きで、そこいら辺の話が得意な人は、その話で盛り上がるのもいいでしょう。

----------

大人あやし方だそうです●矢作の反論。および解説

かれにとっての、アニメ漫画へのスタンス垣間見れる記述です。ただ、こういう人に限って、何も知らない、何もできないくせに、Cool Japanとか言い出しやすいのが特徴です。

村上隆だいすきですね。個人の意見としては、村上隆はその骨頂で、これまで日本のオタク文化に貢献してきた無名クリエイターパクリ商業主義に貶めるというのが私の認識です。

アートとは事腹痛い。そんなこ言うなら、村上隆アートって、90年代美少女変形戦闘機の突端に、女性器をリアル写実的描写してたのはご存じですよね。

----------

(この記事の末尾に参考になりそうなうつ病対策のページのリンクを貼っておきました)

「彼の原稿が好き」と本心で思っているのなら、それを書くことについて、私がとやかく言う権利はありません。

 ただ、彼のことを本当に思うなら、もう少し経ってから過去形で「好きだった」と書いた方がいいのではないかと思います

【2.なぜ「過去形」なのか?】

彼が言っている通り、彼のIT関係の執筆の仕事は終わりだと思っています

ただ、今終わったのではなく、とっくの昔に終わっていたと、私は見ています

 私は彼とは付き合いが古く、同情心や心配からMacPeopleに彼の連載を提案していたこともありました。「とりあえずお試しで」と特集記事を振った結果、彼は逃亡し、音信不通になり、結局、連絡こずで、私とその編集者で全部を丸かぶりして死ぬ思いをしたこともあります

 その後も、何度か彼に仕事を与えようと、面白い製品発表の声かけを彼にも回したり、自分企画した重要なイベントに彼を呼んだこともあれば、面白いネタを持っている広報会社の人を紹介したこともそれこそ何度もありますムーンライトウェーブの望月さんなどもその一人ですよね。

 望月さんなどは本当に彼によくしてくれていると思います。でも、おそらく、彼が呼ばれたイベント記事にしたことはほとんどないと思います(と、ここは私もまったく人のことは言えないのですが…苦笑)

 編集者などにつなごうと呼んだパーティーも隅で昔からの知り合いと話をするばかりで(性格的に無理か、と途中から諦めました)。

 ここで聞きたいのですが、そもそも、この中で、誰か彼がここ1〜2年で書いた記事を読んだ人、いらっしゃいますか?

 もしかしたら、よく検索すればインプレスかどこかで見つかるのかもしれませんが、彼の最近のPublicへの露出で私が知っているのは有名な彼のツイッターと、あとは Kohichi Aoki と 松尾 公也さんのPodcastくらいです(他に本当にあるのでしょうか?)

------

矢作は終わったそうです。原稿も書いていません?●矢作の反論。および解説

原稿2015年も、2014年2016年も書いてますあなたが見に来ないだけです。当たり前ですよ、ブロックしてるんですもん。仮に俺が「書きましたー言っても」知らないんですよね。

「そんな中、今回、彼が(これまでなんで招待されていたのか不明だけれど、記事は書いていたんだろうか?)」 への証拠と回答です。これだけでも、名誉毀損は成立します。

WWDC 2015 リンク集

http://pc.watch.impress.co.jp/ba…/event/index_c105s3385.html

WWDC 2014レポートリンク集

http://pc.watch.impress.co.jp/ba…/event/index_c105s2964.html

WWDC 2013レポートリンク集

http://pc.watch.impress.co.jp/ba…/event/index_c105s2626.html

WWDC 2012 リンク集

http://pc.watch.impress.co.jp/backno/event/index2012.html

WWDC 2011レポートリンク集

http://pc.watch.impress.co.jp/backno/event/index2012.html

その後のフォロー記事とかは抜いて、リンク集を5年ほど。リンク集なので、他の筆者さんの記事もはいっていますけど。

これでも、記事書いてないと思いましたか? 中身がポエムじゃないから、見る気も起きないとか行っわず、逃げずにご回答ください。

http://anond.hatelabo.jp/20160514155637

この件についてはもうひとつ

林信行WWDCにおいてもオレの記事をほとんど読んだことがないというか、存在さら知らないくせにdisってるんだよね。オレの記事リンク掲載済み。

オレは例えポエムだと思っても、同業者の書いたITMediaなりASCIなりも読んでます。だからAttitudeとか咄嗟Twitterギャグで使えるんです。

書いてないと言われた記事2015年WWDCオーバービューもここにあるし、

http://pc.watch.impress.co.jp/…/…/event/20150609_705991.html

その後、イギリスでのApple Pay開始の方を受けて、

http://pc.watch.impress.co.jp/…/feature/20150613_706743.html

http://pc.watch.impress.co.jp/…/kaimono/20150613_706753.html

この2本の分析、および実践記事をまとめた。

7月になってからは、WWDCで発表されたEl Capitanにフォーカスして、El Capitanカウントダウンとして、15週間ぐらい毎月記事を書いてきた。

http://pc.watch.impress.co.jp/…/elcapi…/20150821_717281.html

わずかばかりですがWWDCを切り口に、2015年わずかばかりばかり書いてるのに、ここ1,2年全く書いてないとか、どの口に言われたんだろう。

ここまで事実を曲げて書いた中傷文の責任、またいつものへらへらニヤニヤ笑いでごまかすとはさせません。

人名を出すのは酷いですね。望月さんには大変にお世話になりました(なってます)。でも、記事書いてますよ。Parrotのドローン、Netatom Weather Station。あと、自分で書けないときロボット要素が強いときは、媒体の人に案内を振ってますし、メールにも返信をしています。あと、営業部門広告企画提案したいと言うことで、あなたみたいに恩義を着せる「お膳立て」は、しませんが、各種情報や日本での立ち位置なんかも説明してます。足りませんか? イヤ全然足らない、だとしたらそれは望月さんが私に直接不満を述べることでしょう。そのそも俺の記事見てないってあなたが、なんで、書いてないって決めつけるの? ぱぱ、もうリンクも貼り飽きたよ……。

http://pc.watch.impress.co.jp/docs/news/event/20140107_629705.html

http://pc.watch.impress.co.jp/docs/news/20120522_534410.html

スフィロは残念ながら最初はPC Watch向きではないと提案ボツになり、その後石井さんのロボット枠でフォローされてます

-----

 彼は同情心集めが得意で、昔から付き合いがあるインプレス系の方々のスネをかじり続けているのは知っていますインプレスの方々が、他の若い方々にあげられたはずのチャンスの一部を彼に与え続けていたことも。それによって彼は自分が「まだまだライターとしてやっていける」という誤解を長く持ち続けてきてしまったこともわかっています(が、その担当が誰だかわからないし、おそらく友達になっていないので、この投稿シェアできずに残念です。ご存知の方、ぜひ、この投稿コピペしてシェアしてください)。

------

そんな若い芽がいらっしゃるとは知りませんでした●矢作の反論、そして解説

多の若い方々にあげられたはずのチャンスの一部を彼に与え続けていたことも。この部分があれば、

インプレス社内でシェアしていただき結果として仕事を奪ってしまった若い方々について、お詫びと倍賞をいたします。具体名をお知らせ下さい。

そこまで知ってんのに担当名前は覚えてないんですね。さすが、三歩歩けば忘れらる人です。

-----

 しかし、そのインプレスも、昨年、彼が海外で暴力沙汰を起こしてからは彼のことを干している、と人に聞きました(被害に遭われた方は散々でしたね)。

 つまり、彼はもうほとんど仕事をしていないんじゃないかと思っています

 もしかしたら、週刊アスキーが、獲物のいない猟場、食料のない餌場に、ノラ猫の餌をまいているのかもしれません(が最近、読んでないのでわかりません)。

 実は彼のITジャーナリスト業だか、ライター業はとっくに終わっていたんじゃないでしょうか(彼が認めたくないだけで)。

 そこにまんまとアップルさんが、まるでアップルのせいで廃業したかのように見せたと愚痴る口実を与えてしまったのが今回の事件の全貌だと思います

----

よっぽど私が邪魔なことが、言葉の端はしから●矢作の反論、そして解説

私がベルリンで、某氏をなぐったのは事実ですよ。この件について事実の否定はしません。中傷文のなかで、俺が誰かを殴った(とか書いてますが)事情も知らずに勝手な1事象で書くのはやめてほしい。背景には過去2年近くに及ぶ陰湿無視行為が存在していたので、我慢の限界を超えただけの話。今回も同じですよ、積年にわたる恩着せがましさと、nobiの影での中傷(非中傷文)。ちなみに警察沙汰と言いますが、殴ったこと自体については警察は一切無関係です。ホテル入り口で、でてきたらもう一発食らわすつもりで待っていたら、ホテルから一歩敷地より出てほしいと言われましたが、敷地ギリギリでとどまり、押し問答になったので、私からドイツ警察を読んでもらい。警察クルマに載せられる形で排除されました。現地でも調書は一枚。後日、調書を取った旨、敷地内に許可無く立ち入ったが不問、という紙ペラ一枚が国際郵便で届きました。あ、被害を受けたその人に同情してみせても無駄ですよ、その人、nobiが嫌いですwwwww

干されたという件も明確にしておきます。これはPC部門の決定なのでそれに従いました。

しかし、2016にはK-tai Watchで記事を書かせて頂き、まあこのままでは流れるでしょうが、2016のWWDCPC Watchへと寄稿を打診し、その編集部から了承は得ています

もう一点、「もしかしたら、週刊アスキーが、獲物のいない猟場、食料のない餌場に、ノラ猫の餌をまいているのかもしれません(が最近、読んでないのでわかりません)。」

このセンテンスは、今、アスキー原稿を書いている仕事をしている人に対する侮辱です。

-----

 インプレスに干されてからなのかは、彼の記事検索しても出てこないくらいに発見が難しいです。ツイッターでもフォロワーは、そこらの大学生以下くらいですよね。 マスメディアならぬ、ナノメディアに近いのですが、地上波テレビでも取れない席が自分に与えられなかったと言って彼は愚痴ります

 それくらいに存在感のない記事、読者も求めていない記事編集者もお情けで仕事を与えて手間が増えただけでもしかしたら迷惑かもしれない記事

 それでも「かわいそうだから何か仕事を与えなきゃ」という不健全な負の連鎖いつまでもつづけられるわけがないですよね?

 特に今はどこのメディア不況だと聞きます

 そもそも、あの見苦しいツイートの主の記事を載せるなんてメディアブランド戦略としてもどうなんでしょう。

彼がこの先も「ITジャーナリズム最先端をつっ走って」まだまだこれからかなり遠い先までどんどん走り続けられると本気で信じている人は、ここにいらっしゃいますか?

 このあと、書きますが、彼は自己肯定力だけは強いので、走らせる距離が長いほど、崖の高いところにまで登っていきます

 今、ここで彼に同情して、もっと先にいけるよ的な声をかけてもっと高いところから堕ちさせるのは、本当に彼にとって良いことでしょうか?

 だから無責任に彼に自信を与えるのはやめてほしいと、私は思っています

 自分人生大事な時間を彼のために割くのは、時間と脳の無駄遣いなので、私は今回の件を本当に最後にしたいです。

------

えー、検索して下さい●矢作の反論、そして解説

さっき、ご指定のインプレスの Watch Headlineから、矢作でエゴサーチしたら1570ありました。

くり返し検索してもでてこないのは、貴方の検索能力が低く、あるいは見たくないモノに対して盲目になっているだけです。

前述の通り、2016年2015年記事存在します。WWWDCまでに向けては、これまでもさまざまな仕込みも進行させていました。

自分の目が腐っている。ネットに書いてることも読めないという、根本的な勘違いを枕にしたうえで、お情けで仕事を与えて手間を増やすとか、侮辱も甚だしいです。

見苦しいツイートの部分はそのとおりだと思います自覚しています

編集者の手をわずらわすと言いますが、納品後から作業においては、日本語起承転結や、そもそも日本語理解してない貴方の原稿より、

私の記事の方がデプロイされるまでに格段に必要とする時間は短いです。まあ、自覚ないんでしょうけど。

----

【3.自己肯定力

ここがくどくて長いので、もう原典をあたってください。

-----

●矢作の反論説明

鬱とそれにともなう心身の不都合については、心療内科主治医にかかっており、決められた日時に診察、カウンセリングを行って、日常的な生活が少しでも出来るよう、不眠を減らすよう、ストレスをためないようアドバイスをうけ、ずっと付き合っています。言うまでもなく、時間はかかりますが、長い将来には服薬やカウンセリング必要のない生活へと戻りたいと思います

2016-04-26

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2015-12-18

緊デジについて圧力を受けたので増田に書きます

とある特定会社については触れるな、責任を問う様な記事を書くなと言われましたが

関係者緘口令が敷かれ証拠の揉み消しが行われているため、増田にてリークします。

既報にて触れられた箇所は冗長になるため削除しています

2013年3月に終了した事業2015年11月時点で配信されない、配信についての期限も切られないのはさすがに民間からすればおかしいのですが、「それではいつ配信されるのか」などの疑問すら封殺して圧力を掛けるのはやり過ぎでは無いでしょうか。

内部資料を入手した上で記事にしているという証拠のため、手元の一部資料を上げておきます

https://drive.google.com/file/d/0B2eVxJtFskpeNUZURkVjSGZCRms/view?usp=sharing

------------------------------------------------------

◇緊デジとは何か

コンテンツ急電子化事業の略

東北振興と電子書籍市場活性化目的とし、書籍電子化を国の補助にて行う総額20億円の事業

JPOが事業受託し、パブリッシングリンク社が製作委託業務請負う。また出版デジタル機構が(補助金とは別に)製作費を立て替える形で、中小出版社でも費用無しで書籍電子化が行えるスキームが組まれた。配信も出版デジタル機構が担っている。

事業期間は2012年4月〜2013年3月

実際は2012年4月の出版デジタル機構設立に伴う"ご祝儀"として組まれ事業

略称

JPO:日本出版インフラセンター

PL社:パブリッシングリンク

機構出版デジタル機構

産革:産業革新機構

経産省傘下の半官半民ファンド

B社:ビットウェイ社

2013年10月機構合併した電子書籍取次最大手凸版印刷より買収した。

Y社:機構取引のある大田区電子書籍制作会社イニシャルのみ記載

…緊デジにおいて検品修正ファイル製作の一部を担当

M社:取次他社。

T社:凸版印刷子会社イニシャルのみ記載

◇なぜ未配信が発生したのか

予算消化ありきの事業

(既報ではあるが)とにかく期限内に規定金額を使い切ること、製作点数を満たすことを優先し、権利処理、製作体制の構築が後回しになったため。

電子化に伴う諸々の権利処理がなされていない状態にも係わらず、見切り発車で電子書籍製作がなされた。仕様も期間中に二転三転し、電子書籍製作を請け負った東北会社は二重三重作業を強いられた。

前述した通り緊デジ事業元請けとなったのはJPOだが、事業スキーム自体出版デジタル機構ありきで組まれもの。また、緊デジは機構営業部門出版社に対して営業を掛けており、説明会機構内にて行われていた。JPOとパブリッシングリンク社の出張所も機構内(神保町にあるビル内)に併設されていた。

電子書籍書店への配信部分を担うため、出版デジタル機構では会計監査院の指摘を受ける前から未配信書籍の存在を把握していたが、メンツ問題を恐れて出資母体の産革及び経産省への説明はされていなかった。会計検査院の内々の指摘に対しては、担当部長社員が職を辞したので分からない、との説明がされていた。

◇カラ納品で締め日に間に合うように見せかけの納品

事業は終了すれども納品はされていなかった

何故このようなことになったのか。書籍タイトル募集が不調に終わった後、なんでも良いから申請してくれとの駆け込み募集がなされ、製作、納品、配信と一連の作業が玉突き式に遅れたことに起因する。

すべての工程問題だったのだが、明確な隠蔽が行われたのは納品工程からである2013年3月の緊デジ事業締め日に間に合わせるべく、制作会社未完成ファイルを納品させる"見せかけ上のファイル納品"が行われた。中にはまったく同じファイルタイトルだけ変えて納品させる例まであった。このカラ納品はネット上の制作会社関係者ブログによっても示唆されている。

これはJPO、PL社、機構の三者による合意の元に行われ、カラ納品をもって産業革新機構および経産省には緊デジ事業完了したとして報告がされていた。

もちろん実際には納品されていないため、緊デジ締め日以降に発生した実作業によって費用が発生し、決算日をまたいだ予算上の付け替えが発生している。

この納品データ収納したハードディスク現品存在しているため、監査を行いファイル日時とファイルの中身を確認するだけで不正行為が判明する。

また、東北電子書籍製作会社取材するとカラ納品の指示メール、録音まで保存している会社複数存在している。

電子書籍ファイルフォーマットの多重製作

無駄になったフォーマット製作金額はなお不明

緊デジ当初はdotbook、XMDFファイルフォーマット製作がされていた。このうちePubで作り直し配信した電子書籍や、複数フォーマット製作を行うが片方のフォーマットしか配信しなかった電子書籍一定存在する。

これらの方針転換は緊デジ期間中にePub事実上の標準としての地位を固めたことも一因として挙げられる。ネット上の関係者記事からも作り直しや方針転換のため、納品・配信がなされず製作費用が丸々無駄となったものが多数存在することが示唆されている。

どれほどの金額無駄になったフォーマットに使われたのか、事業税金を原資としている以上、説明をすべきである

検品体制は万全だったのか

・極めて疑わしい検品体制

緊デジで納品された電子書籍ファイルについて、当初は神保町出版デジタル機構内に併設されているPL社の出張所にて検品がされていた。(異常が見つかったファイル修正も内々に行われていた)

極めてセンシティブな噂があるため、その後に起こった出来事事実だけ記す。ファイル納品数の大幅な増加に伴い、当時M社より機構へと出向していたH氏(元M社執行役員部長)の強い働きかけによって、B社と懇意である電子書籍制作会社Y社に、検品残りePubについて検品ならびに修正委託された。

その際に○千万金額が"検品修正委託"名目で支払われる。(その後H氏はB社と合併した出版デジタル機構運用部門長として採用されるに至る)

問題は3点。検品修正がなされているにも関わらず"正常に表示できない"と返答されているファイルがある点、検品について恣意的特定の1社が選定された疑いがある点、検品費用についての監査が不十分であるである

1点目

検品修正がされたのではなかったのか?

緊デジで製作されたePub電子書籍ファイル(※)は大部分がY社へ検品委託されており、実際に金銭も動いている。であるにも関わらず会計検査院の指摘に対して"正常に表示できない"と返答がされている。はたして、検品修正は適正にされていたのか。どのような作業が行われていたのか。どのようなやり取りがなされたのか。

ePub以外のdotbook、XMDFフォーマットについては制作中止や配信停止がなされた。別項参照

2点目

製作水準に達しない企業検品を請け負う

まず前提となる情報として、緊デジ事業電子書籍製作にあたって制作会社公募がなされた。その上で各制作会社試験を課し、水準に満たない制作会社足切りを行った上で発注が行われた。

そして、Y社はその"制作"会社選定時の試験足切りに合った企業である

足切りにあった企業が緊デジ事業製作されたファイル修正検品委託されているのである製作水準に達しない企業が"検品"と修正を行うに足るのかの説明が求められる。

関係者への取材によると"検品"にあたっては検品水準の維持を目的としてY社ただ1社を選んだとの返答だったが、なぜ製作時と同じように公開試験を行い、複数から選定しなかったのか。透明性のあるプロセスにて選ばれていないため、懇意にしている企業恣意的に選んだ疑惑があると複数制作会社からは指摘されている。

3点目

監査不十分な諸経費分担

出版デジタル機構内に併設された出張所にて検品が行われていた際の費用は、PL社と機構折半されていた。だが、検品をY社に委託した際にはその費用はほぼ機構のみの負担となっている。

機構大口出資母体には産革がおり、産革の資金の9割以上が税金で賄われている。前述したように、緊デジ締め日以降に納品されたファイル存在しており、それらの作業費は緊デジの事業費には乗っていない。

少しややこしくなったので状況を整理すると、緊デジはその事業費外に「締日以降の作業費」「検品修正費」という形で費用負担が発生しているのだ。

緊デジは東北復興予算によって賄われた事業だが、出版デジタル機構負担した作業費用も含めると税金が二重(場合によっては緊デジ事業費、期間外作業費、検品修正費の三重)に乗った事業ということである

これは緊デジ事業だけの配信調査監査では不十分であることを意味する。出版デジタル機構負担分の金銭の流れも含めた監査必要である

◇現執行体制責任はないか?

出版デジタル機構2014年6月に新社長就任、新役員体制に移行している。

そして、緊デジは2013年3月に建前上終了している事業である。緊デジ未配信は過去問題であり現執行部の責任は無い、と現在各所での“言い訳”がなされている。

しかしながら、入手した社内資料では新役員体制への移行時2014年6月時点でもまだ未納品電子書籍が大量に存在していると指摘されている。しかも、あろうことか副社長を排している大手出版社小学館による大量の未納品まで存在していた。

(より正確には直接申請と代行申請という違いがある。しかしながら納品がされていなかった事実は変わらないため詳細はここでは省略する)

内部関係者より証拠資料付きで告発されたこの件を受け、産業革新機構出版デジタル機構への投資を不適格として引き上げるべく、引受株式の一部処分を決定したとの情報もある。

※産革の株式処分2015年9月1日発表

http://www.incj.co.jp/PDF/1441072277.03.pdf

(会計検査院の緊デジ未配信指摘は2015年10月2日)

大手出版社特別扱い、他社マニュアル剽窃著作権法違反をする官製企業存在意義

大手出版社優遇し、中小出版社冷遇

機構には緊デジ以外にも問題が指摘されている。取次としての資質が問われているのだ。

ここでは既存出版取次の詳しい説明は省くが、分かりやすく述べると大手・老舗出版社既得権側として極めて有利な仕組みになっている。料率(出版社取り分)が多くなっており、仮払金と呼ばれる見込み売上金も有利な率で受け取れる。新規出版社は料率で不利、仮払金も率が悪いどころか受け取れないところもある。

では税金が投入されている電子書籍取次はどうなっているのか。こちらも大手・老舗出版社が有利な仕組みとなっており、一部は取次料なしでの扱いもなされている。取次料なしとは、つまり大手出版社によってタダで使われているのだ。

税金によって賄われた以上は最低限の公益性中立性は担保すべきであり、大手・老舗出版社が有利になるのはおかしいと前述の新規中小出版社からは指摘されている。

民間企業取引先の重要性に応じて条件に傾斜を付けるのはやむを得ない。だが公器としての存在を期待され出資を受けた以上、中小出版社と同一の条件にするのが筋だという論である電子書籍取次は出版取次と違い金融機関としての機能存在しないため、この主張には一定説得力がある。

この主張には対して、そんなことをすれば同業の取次他社との競争に勝てないと機構出資者反論もみられた。むろん、公益性担保競争力は一部トレードオフ関係にある。だが、現状は競争力の向上と称し得ない。実態大手出版社に対して国の税金が投入されているのとほぼ同等であり、補助金に近い。

書店に対しても同じことが起こっている。外資を含む一部書店に最恵待遇として有利な料率・条件が結ばれており、事実上の言いなりになっているのだ。

これら重視すべき対象機構内では戦略出版社戦略書店と呼ばれ、それ以外はゴミ出版社ゴミ書店呼称されている。

税金に群がるのは大手出版社だけではない。「凸版印刷赤字子会社(※注 ビットウェイ社)を買収した。ではうちに何をしてくれるのか」との大日本印刷の指摘に対して、共通書誌情報システム大日本印刷関連会社である日本ユニシスへと発注するなどの便宜が図られている。

果たして、このような結果を出版業界は望んでいたのだろうか。出版業界の終わりの始まりに思えてならない。

同業他社マニュアル剽窃などやりたい放題

さらには、同業の取次他社が用いるマニュアル剽窃まで指摘されている。前述した取次大手M社から部長待遇転職したH氏の手により、M社資料である電子書籍入稿マニュアル出版デジタル機構内にて回覧され、出版デジタル機構の同マニュアル作成時に流用されたという指摘だ。

これは社長副社長本部長の認識の元に行われており、社内及び業界内の武勇伝として語られている。もちろんM社の守秘義務違反行為にあたる。競争相手マニュアル剽窃する、それによって競争力を高めようとするのは民間でも眉をひそめられる行為だが、税金で作られた企業がやるとなれば民業圧迫との誹りは免れない。

事故多発、著作権法違反が行われるなどのずさんな企業統治

他にも被災地馬鹿にした発言がなされていた、値段・発売日違い事故の多発、著作権法違反による著者からの抗議、Y社及びT社に対する下請法違反派遣法に抵触する行為などのコンプライアンス違反散見されるという、複数証拠証言もある。

一部は既に然るべき機関通報がなされているため、これらの件については調査がなされることを期待したい。万が一ではあるが調査がされない、圧力を受ける等があれば証拠付きで今回のような形式でリークする。

出版に携わる人間として、どうしても許せなかったのは緊デジに関する一連の騒動が終わったこととして隠蔽されようとしていることだ。緊デジには正の面もあり、書籍電子化が加速したのも東北にある程度の金額が回ったのもまた事実だ。だが、負の面も大き過ぎる。それらは現在進行形証拠が消され、関係者箝口令が敷かれようとしている。大手出版社印刷会社が総出で無かったことにしようとしている。

あえて聞きたいのだが、自浄作用を発揮できない出版業界に、果たしてどれほどの価値があると読者は考えるだろうか。

------------------------------------------------------

取材にあたり】

上記、一部をあえて伏せる、疑問形にした箇所が存在します。

手元に資料及び証言存在していますが、記事内にて提示することでそれに沿った形で資料の書き換え、口裏わせがされるのを防ぐためです。ご容赦ください。

緊デジと出版デジタル機構についての調査、踏み込んだ監査がなされることを期待しつつ、復興予算という名目で行われた事業である以上は、国民や読者が納得する形の結論が出ることを強く望みます

2015-12-15

http://anond.hatelabo.jp/20151214200027

自腹の時もあれば、会社が出してくれる時もある。

でも、たいていが営業部門バカ騒ぎして上司をワッショイしてるだけだからつまんなくていかない。

それと、酒を酌み交わしたらみんな仲良し教の連中がうざい。

お酒が苦手な人にとって見たら、酔っ払いなんて幼稚園児以下のサルの集まり

2015-11-01

ツイッター中毒から抜け出したい

この4年間ほど、ツイッター中毒になっていたが、どうもメンタルに悪影響しか与えないことが判明し、暫く離れようかと思っている。

ツイート数は黒歴史消去を含めて5万ツイートくらいか。完全に中毒である

辞めようと思ったきっかけは、たまたま同業者と親しくなり、リアルで会ったことだ。私はその人自身は決して嫌いではない。はっきり言ってしまうと、今まで出会ったことのない優しさと包容力のある人で、かなり好きなタイプに入ると思う。リアルで会う前までは、頻繁にやりとりする人の1人だったが、やはりオフで会うと全く違う。毎日ツイートが気になるようになってしまった。

私は現在会社に中途で入った後、グループ再編でグループ内の別会社に移り、業界も変わってしまった。カルチャーも商習慣も全く違う業界で慣れることに苦労した。そんな矢先、ツイッター移転先の同業者で、非常に優秀そうな人を見つけた。それが上述の人である。そこまでは良かった。そこから先が問題だ。

移転先の業界は、巨大企業グループがいくつかあり、残りは地方拠点会社が数多く存在する。所謂斜陽産業であるが、待遇世間イメージから巨大企業グループ学生に人気がある。しかし、実態はかなりブラックな要素の方が多い。それはドラマなどにも取り上げられた。

ツイッターで知り合った同業者自身はあの業界で若手管理職になるくらいだから営業部門ではかなり優秀である。前向きなツイートが多く、視野も広い。それがその人の魅力でもあるせいか、同業者を中心にフォロワーもそこそこいる。私はその人を直接知る前まで、その人と頻繁にやりとりしている同業者存在をあまり意識していなかったが、その人のツイート意識した途端、同業他社フォロワーツイート意識して目にするようになった。馴染まない業界、息苦しい業界で、自分はどのように振る舞えばいいのか。折しも、その時、私は業務繁忙による過労と、上司パワハラで苦しんでいた時期だった。通院しながら抗鬱剤毎日飲む日々が何ヶ月か続いた。同業者で似たような経験の持ち主も多いと言われている。必然的に、メンタルの病んでいる同業他社フォロワーを密かに目にするようになった。

しかし、それが罠だった。

同業他社人達ツイートは、毎日が異常と思える程、会社上司に対する悪態や、業界特有の異様な商習慣に対する恨み節のような内容ばかりであった。加えて、自分価値観信条と全く相容れないツイートも多く、私のメンタル悪化させる原因となってしまった。同時に、移転先の業界に対する悪いイメージが一層強化されてしまい、勤務先もあたかもそういう会社じゃないのかと投影してしまうほど、ネガティブツイートだらけで、不愉快まりなかった。

もちろん、直接やりとりしている人とは価値観シェアできることもあったし、それなりに良い影響力はあった。特に、私が夏に1ヶ月休職し、ピンチだった時に助けられたりもした。それはとても感謝している。

それでも、トータルでメンタルへの悪影響度合いが強くなってきたので、やはり離れることにした。その人は、メンタルがタフなのか、同業他社フォロワー断末魔のような叫びに対して、常に寛容であった。どんなネガティブツイートに対しても、受け止めて励ますような優しさがあった。特に地方拠点の営業職の人達に対して。


メンタルへの悪影響について、具体的には述べられないのだが、上述の通り、価値観の噛み合わない人達連鎖的に、或いは間接的に繋がってしまい、どうにも不愉快になることが増えた。特に仕事に対する取り組み姿勢で目に余る不愉快つぶやきが入ってしまったことが一番大きい。


私は秋にピンチを何とか乗り越えた。同業他社地方拠点人達は、相変わらずメンタルが病んだままで、毎日毎日断末魔のような愚痴を1日何十ツイートも連投している。

上司死ね

・この仕事も営業も本当に大嫌いで消えてなくなって欲しい

言い訳だけは上手になった自分しか自慢できないことが悲しい

・あと5時間月曜日という地獄がやってくる

・この糞商品目にするだけで、商品開発者をぶっ殺したくなる

まぁ、所謂社畜」のおたけびなんだけど、私が決定的に彼等に対してぶち切れたのは、移転前の会社商品全般を完全否定して異様にdisっていることだった。さすがにこれだけは許せなかった。確かに私から見ても、明らかに糞商品の方が多いと思っている。それでもだ。私はこの商品を取り囲む市場というものが好きであり、好きだからこそやれたという経緯がある。それを頭ごなしに否定しかしない同業他社人達ツイート毎日毎日目にすると、いい加減、うんざりしてきた。

それでも、私が知り合ったその人は、彼等に対して優しかった。何故なら、その人自身もまた、私が以前いた業界存在に対して、否定的見解の持ち主だからだ。完全否定はしていないものの、やはり、あまり良く思っていない。こんな私でも、仕事一筋で一応やってきた。それを婉曲的に否定されるのは、やはり辛い。


取り敢えず異動先の仕事邁進すること、組織再編の渦中で自分を見失わないこと、ネガティブなことは目に入れないことが一番重要だと思う。

今までありがとう、Yさん。

2015-07-08

営業部門

俺たちは数字を追っかけて必死仕事してるんだ!

俺たちが客のことを一番知ってるんだ!

俺たちが売り上げを出してるからお前ら飯食えてるんだぞ!

なんなんこれ・・・

なんで、営業ってあんなに威張り散らすの?

売れないことのイライラとか鬱憤を社内の弱い立場の人にぶつけて発散するのやめてほしいよ

2015-05-22

転職日記(2015/05/22)

http://anond.hatelabo.jp/20150417085235

の続き。

出来事

2015年4月(3週目)

ここで最終出勤日。

定時近くなってから関係部署、主に営業部門の人にあいさつに行く。

外出やらで不在の人も多かったが、その場にいた人には一人ひとり声をかける。

昔一緒に仕事した(その後異動した)営業の人にも声をかける。久々に話せて良かった。

そのあと自部署へ。課長にはあいさつしたが、部長とそれ以上の人には何となくあいさつに行かなかった。

行けばいいんだろうけど。どうにも不器用だ。

部署を回る。自部署の人でも、俺の退職を知らない人がいて驚いた。

そりゃ自分から周知してたわけじゃないが、周知の事実だと思ってた。

退職会社タブー視してるから伏せているんだろう。

現場には混乱を招くと思うんだけどなぁ。上司会社面子か?アホらしい。

弊社では退職時に「退職のご挨拶メールを出す文化がある。

俺の場合は、(上と矛盾するようで恐縮だが)紋切り型あいさつに意味はないと思ってたので出さなかった。

結果的に、昔の上司や、遠方のオフィスの同僚、会社の同期入社の皆には連絡せずに退職することになった。

から考えると周知の意味で出しておいても良かったかなと思う。

退職事務手続きを終えてオフィスを出る。

特に大きい感慨はなかった。ひと段落したーとは思った。

同僚が昔、「前の会社を辞めてオフィスを出たとき空気が、これまでで一番美味かった。」という言葉を残したが、

自分の身になってみると、そこまでではなかったので、この会社はそれなりに好きだったんだろう。

転職先の入社まで少し日があるので、この日をもって、晴れて無職になった。

次は準備だ。

続く

2015-02-12

編集者仕事

編集者って何の仕事をする人なんだ。

http://anond.hatelabo.jp/20150211201344

編集者」とひと口に言ってもいろいろなタイプがいて、雑誌社で記者をやっている人が編集者を名乗っていることもあるし、雑誌編集部編集長デスク使い走りしかやってない人や、編集プロダクション所属で実質はDTPオペレータという人もいる。書籍編集者でも、作家様が執筆するような文芸担当実用担当ではずいぶん仕事内容が違うし、漫画写真集辞書みたいな特殊ジャンルもある。さら会社や個人によって仕事のやり方が違ったりするので、「編集者仕事」を一概に定義するのは難しい。

ただ、あえて定義すれば「本や雑誌を作ること」で、ある程度抽象化した形でなら大まかな流れは紹介できるんじゃないかと思ったのでまとめてみた。以下は原則として版元所属実用書系の書籍編集者仕事を想定。文芸漫画世界はよう知らん。

企画

企画は「思い付きを口走ること」でも「まだ世の中に存在しない何か」を探すことでもありません。満たされていない需要を探し出して、それを満たす商品製作を計画することです。そのために常日頃から情報を集めつつ、有望なアイディアを見つけたら市場調査、著者候補をはじめとした関係者へのコンタクト概要記述、目次案作成、仮タイトル考案、収支シミュレーション作成プロモーション概要計画作成などを行ないます。版元所属書籍編集者にとっては、企画が一番重要仕事です。

企画会議

版元所属書籍編集者なら、定期的に開催される「企画会議」で企画をプレゼンして経営陣や営業部門を説得して企画を進める了承を得ます。企画会議にかける前に編集部内で行なう編集会議にかけ、編集長の了承を得る必要があることもあります書籍編集者独立性が高いので不要のこともある)。企画を企画会議より先に進めるには、企画した編集者過去の実績や根回しも結構重要だったりします。

原稿制作

本来は著者の仕事です。「てにをは」はもちろん、取材権利処理も含めて原稿完成の全責任を負うのは著者です。本来は。しかし、実用書系の著者に商品にできるレベル文章を書ける人はほぼいません。原稿は少なくとも再構成場合によっては全面的リライトしなければならないことがほとんどです。これを自身で行なうか、外部のライターなどに発注するかは編集者によります。刊行点数のノルマに余裕があり、著者が書けなければ企画をボツにするという編集者もいます。また、長年ブログを書いているなどと言って妙な自信を持っていてリライトなどに対して「一字一句変えるな!」などと言い出す著者もたまにいますが、こういう著者を説得(というか説教)するのも編集者仕事です。言うまでもありませんが、たかだか2,000文字のブログ記事と、200ページ超の書籍のための文章はまったくの別物です。

組版

原稿がある程度そろったら、紙面の形に組版します。版元所属書籍編集者場合は、ほとんどの場合外部の編集プロダクション発注します(単純な縦組みの文芸書などでは印刷所に依頼することもあるようです)。これらに関する価格交渉なども、編集者重要仕事ひとつです。

校正

校正紙(組版された紙面)を目視確認する作業です。校正紙を著者に送り、内容を確認してもらう「著者校正」もここで行ないます修正の量にもよりますが、2~3回繰り返すのが一般的です。

装丁

装丁カバーデザインなど)についても、外部のデザイナー発注するのが一般的です。とはいえ丸投げで済むわけではなく、書籍の内容や競合の状況によってデザイン方向性を考え、それにそったデザインのできるデザイナーを探し、デザイナー方向性を伝えるための資料を集め、文字原稿についてはすべて編集者側で用意した上で、デザイナー複数回のやり取りをします。

印刷発注

組版装丁の目処が立ち、ページ数も大体決まったあたりで印刷所に見積もりを依頼します。見積もりの額によっては、デザイナー装丁仕様変更を依頼することもあります。特色、UV、箔押し、型押しの使用は慎重に。必要場合はここで印刷所に束見本(つかみほん)の作成を依頼することもあります

部決会議

ページ数が決まりカバーデザインもほぼ完成したら、いわゆる「部決会議」(部数決定会議)にて部数、価格、発売日などが決定されます営業部門などから要望によって、タイトルカバーデザインの変更を要請されることもあります過去の実績や知名度によっては著者や編集者の無理が通ることもありえますが、これらの最終決定権は原則として資金的リスクを負う経営者にあります意見が通らなかった場合には、過去の不甲斐ない自分を恨みましょう。

入稿作業

部数や価格が決定したら、印刷所へのデータ入稿作業を行ないます。売上スリップバーコードデータ作成するのもこのタイミングです。印刷からプルーフや色校正が出てくるので確認します。ここでの確認漏れはそのまま印刷事故につながるので、売上スリップバーコード、奥付などの最終確認複数部署による回覧で行ないます

契約・清算

入稿作業が終わると見本が出てくるのまで間に少し時間ができるので、著者との契約作業を進めておきます契約書は出版社ごとに統一されているのが一般的で、タイトルや著者名、部数、価格などを書き込んで著者に送り、記名捺印したものを返送してもらいます。刷り印税がある場合には、支払伝票の起票などもこの段階で行ないます編集プロダクションデザイナーへの支払い手続きもこのタイミングで。

見本

入稿作業後しばらくすると見本が届くので、まずは修正原本となる数冊を除いてから、著者をはじめとした関係者に数冊ずつ発送します。社内外へ見本を持参しつつ、挨拶をして回ることもあります。続いて雑誌社や有名ブロガーなどへの献本を行ない、書評を依頼したりもします。書籍編集者の通常の業務としては、これでひと段落いたことになります

販促活動

書籍編集者が行なう通常の販促活動としては、いわゆる献本のほかにも、書店に配布する注文書の原稿作成などがありますしかし、書店営業や広告に関しては原則として営業部門主体となって行なうことになっていて、編集部側が勝手に進めることはできないのが一般的です。結果として書籍編集者が行なう販促活動は、営業部門サポートや、著者によるイベントサポートなどが中心となります

増刷対応、改訂企画

実は世の中には間違いのない書籍というのはほとんどなく、それほど厚くない書籍の中にも複数の間違いが含まれていたりします。これを自分で見つけたり、著者や読者から報告を受けたときに記録しておき、増刷といったタイミング修正するのも書籍編集者仕事です。増刷時には、著者への報告や見本の発送、刷り印税なら支払伝票の起票といった作業もありますさらに、刊行から時間が経ち、内容の更新をする必要がありそうな場合には、増刷の代わりに改訂版の刊行を企画することもあります

まとめ

以上です。改めて書き出してみると思っていた以上にやることが多かったと感じたのですがいかがでしょうか?また、原稿制作重要であっても一部でしかなく、原稿さえあれば書籍が出るというわけではないということもおわかりいただけたかと思います一般的実用書の編集者は、この流れを同時並行して年間5~10点程度進めることになります編集者が何の仕事をする人かという疑問解決の参考になれば幸いです。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん