  |
はてなキーワード: 発注とは
気づけば中年のオッさんだ。
俺も経験を書いてみたいと思う。
「会社で無能扱いされたら自分の能力を悲観するより、会社に合ってない」
と考えたほうがいい。
ここからは、そういう考えに至った
この言葉が届いたら良いなと思っている。
たぶん、君が輝く職場はどっかにある。
15年前は超就職氷河期。
同時にブラック企業が大学新卒を食いつぶし始めた時代でもあった。
大学時代、何も考えていなかった俺は、
店を持って自立すべしという話は、
当然、考えるよりも手と体を動かす仕事。
終わらない仕込みの山と料理長の怒号。
風俗に通うが勃つこともできず、
嬢の胸で泣いて過ごす日々であった。
「お前のような奴は何をやっても続かない」
「根性のない奴は一生負け続ける」
２社目：WEB制作会社
１社目を辞めてから３年間、自宅療養になった。
手伝って欲しいと言われた。
話してて賢いと思ったからとの事だった。
取り扱ってる会社だった。
先輩と１つ案件を回し終わったら、
次からは一人で全部やらされる事になった。
この仕事を支えた。
求められれば面白くなり、みんなの期待に応えたくなってくる。
完全に身バレるので書けないが、
気づいたら社長の次に高給取りになっていた。
この職場では、明らかに俺は有能であった。
３社目：広告代理店
もっと大きい仕事、もっと社会にインパクトのある仕事がしたかった。
そこで待っていたのは、
繰り返される板挟みと調整。
「鬱病持ちとか人事なにやってたんだよ」とか
「部門結成以来のババを引いた」とか
妻子がいたので１社目の時のように長期休養は取れなかった。
地味なBtoBや自治体や役所のWEBコンサルを専門でやっている会社。
クライアントが定時なので、
常駐勤務ならは同じような勤務体系でいけるでしょう。
と、勧められての事だった。
実際、朝は9時に出社。18時には全員退社する職場だった。
前職や前々職で作った人脈やノウハウは、
代理店の使い方も慣れていた。
発注される側の苦悩を味わっていたので、
先回りしてキーパーソンに見せるなど根回しなどを行った。
時代感ともあっていたのか、
案件受注額は毎年倍倍と膨らみ、
本社の規模は３年で５倍以上に大きくなった。
この職場では、俺は再び有能になった。
５社目：個人事業主
好きなことだけをやっていける。
やりたくない仕事は受けないこともできる。
全然稼げてないし、
そこそこ貯金したので５年くらいは
収入なくても食っていける。
ここで結果をあげられるかどうかは解らないが
もう会社に振り回される事はないだろう。
もし、今「無能」と言われて苦しんでる人がいたら
色々と動いてみたら良いと思う。
無能と言われるような状況に身を置くのはやめたらいい。
おじさん、独り部署で20年近く少しだけ特殊な仕事してんのね。
若い頃は他部門の先輩に無茶で本来自分の範疇外の仕事を押し付けられて、
顎で使われて、そりゃ偉そうにされたもんだよ。
その人達は僕の都合や段取りなんかに聞く耳を持ってくれないんだよね。
おめーの都合なんか知らねーからとっととやれよ！もう夜の10時なんだけど。みたいな感じで。
そんなこんなで、無茶を聞いて頭を使って仕事の効率化をはかって必死こいて頑張った結果、
偉そうにしていた先輩達よりも立場上は偉くなれたのね。
そこに到るまでの間に精神を病んだり体を壊したりもしたけど。
今まで聞かされてきた要求が脳筋ならではの、「細かい事はどうでもいいから、俺の意を汲んで気合でやれ！」といった
内容だったから言うことを聞く必要は無いんだよね。そもそもその人達の部下じゃないし。
他人に物事を頼むときは相手がどういった立場であれ、発注元は細かい情報を正確に伝える責任が生じる訳で、
その責任を放棄して丸投げしてくるような人間の言うことなんて、こっちは知ったこっちゃないのよ。
すると不満が湧いてくるんだけど、それは僕に直接言ってくる訳じゃなくて、
もっと偉いひとから間接的に聞こえてくるのね。こんな風にあいつら不満を言ってるぞと。
細かい不満の内容を聞くと、立場が変わってから偉そうになっただの、
僕だけ使っているソフトで楽をしているだの、ソフトがあれば俺でもできるのにだの。
いや、君らエクセルすらまともに使えないじゃない。
だからね、おじさん、働き方改革を実行すべく、小学生の頃にN88-BASICしかやったことないのに、
仕事の合間にコツコツとプログラムとWEBの勉強をして社内にローカルサーバーを立ててシステムを組んだの。
WEBベースでアホでも理解できるUI、誰でも簡単に保守管理できるやつ。
おじさん、普段からエクセル方眼紙を社内・社外から送りつけられてて、
これがすごく便利で、自分が今まで投げられてきた仕事が誰でもワンアクションで
終わらせるようになったんだ。当然システムの出力に応じたパソコン外での
作業は生じてくる訳だけど、それは誰でもできることだから、テメーら自分でやってね。
凄く便利になってよかったね。ざまあみやがれ。
これで時間に余裕ができたので、本来の担当案件に集中して取り組むことができるし、
自分の退勤時間はほぼ定時になったし、有給もどんどん使ってやろうかと思うよ。
子育て期間に封印してた大好きなゲームを気の済むまで遊びたいんだ。
とりあえずSplatoon2とゼルダはやるし、ゲーミングPCをGTX1080で組んだから
STEAMで色々と買い漁るよ。
以前は求人雑誌に小さく載ってる程度だった気がするが、最近はあらゆる所で見かける。
クイズ番組のイラストが全ていらすとやだったり、ヨドバシで柱一面に大きないらすとやの絵が貼ってあったり。
こんな一流所でもイラスト発注出来ないくらい不景気なんだな…こういうイラストを描いてた人達はおまんまくいあげだろうな…と何となく見る度に悲しくなる。
少し前に Twitter か何かで「○○の×巻発売です。電子書籍でもいいけどできればお店で買ってください」みたいな書き込みを見かけた。
実際、紙のほうが作者的には嬉しいの？
最初の発売時はそのときの売れ次第で次の印刷数が決まるみたいの聞いたことはある。
印刷されて本屋に流通すれば、すでに印刷されてるから本屋で売れなくても編集社としての利益はでてるから。
そういうこともあってか、発売から１，2年経ったちょいマイナー漫画ってアニメイトとかでも売ってないことが多い。
もし売っていて自分が買っても、誰かから注文なければ次を発注したりはしないんだろう。
それだと自分が買っても買わなくても作者や編集社にはほぼ影響ないと思う。
電子書籍だと、人気ランキングが少しだけ上にいって作者が気付いて「おっ」っと思うかもしれないし、購入があってからお金が入るなら「まだ売れてるんだ」と思うこともありそう。（こういう業界詳しくないから売上関係なく月給とか1ページ辺りで金額決まってるのかもしれないけど）
そう考えると、新刊なら紙で、数年前のを買うなら電子書籍のほうがいいのかなって思ったんだけどどうなんだろう？？
それともうひとつ気になったんだけど、アンケートか感想かのはがきを書くのが一番の応援になるみたいのを聞いたことがある。
10年、20年前ならともかくいまどきはがき？？って疑問に思ったんだけど、漫画の業界でははがきにそんなに重要なの？
感想でもはがきよりは、Twitterとかブログに書いたほうが本人以外の人も見て買うキッカケになるかもしれないし。
ブログのアフィリエイトだって買ってくれるキッカケになるんだし、はがきよりも喜ばれそうだけど、どうなんだろう。
と、書いてみて思ったけど、マンガ家の人やその関係者が増田なんかみてると考えづらいし、自称詳しい人のブコメくらいしか期待できないな。
文字数制限に引っかかって下のほうが切れたので、こちらに追記します。
システム P の Web 側をひとりで開発している私がここまで信頼されていないのには、以下のような理由があります。
Git で機能単位でフィーチャーを切って(注: その機能のためだけにソースコードを枝分かれさせて他の機能に影響が出ないようにすること)開発を行い、私が機能を実装してコミット(提出)すると、X さんと Y さんがテストをして、不具合が出たら Redmine に登録して私がフィードバックを受け、私が修正し、それをまた X さんと Y さんがテストをして……という流れで開発をしています。
この X さんと Y さんによるテストを、なぜか「受入試験」と呼びます。ふつう、受入試験と言えば、開発元で最終テストまで済ませたものを発注元に納品した時に発注元が行うテストのことです。
実は、XYZ の 3 氏は、システム P の契約の上では「A 社の契約社員」ということらしいのです。私の所属は B 社なので、他社(下請け)が作ったものを自社で試験することになり、「受入試験」という工程になるとの由。
システム開発の理屈など分からない A 社の上層部から見ると、受入試験でたくさん不具合が出ている、何だ B 社は品質が悪いじゃないか、ということになります。品質を高めるためにテストを入念にすればするほど報告される不具合の数が増え、なおさら「品質が悪い」と言われてしまいます。
そして、複数のフィーチャーをマージ(結合)したソースコードの試験は、私にはできません(させてもらえません)。一般に言う単体試験も結合試験も、この現場ではみな「受入試験」です。
A 社の上層部だけでなく、プロジェクトマネージャーの V さん、プロジェクトリーダーの Z さんもこの仕組みがおかしいことを理解しておらず、「増田さんはバグが多い、信用できない」と本気で思っています。そりゃあポカミスは多いですがね……。
それ、たぶん私です。多くの方から意見をいただきたく、増田デビューしました。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
前職を退職する時、社長に掛け合って自分で自分の送別会の幹事をやらせてもらった。
→超円満退職だったし、いっぺんにいろんな方へ次のご報告もしたかった。
→８０人は余裕で入るし、勉強会とかでよく使ってたので、
PA機材とかの設営とかも混乱がないため。
食べてもらって感想をもらいたいという狙い。
そこは今度一緒に働くシェフにお願いした。
・司会は元同僚と受付の女の子にお願い
場が温まると思った。
結構な数になった。引き継ぎする人と仲良くなってもらったり、
昔の案件でご無沙汰になってる方に営業チームと引き合わせたりする。
あと、俺の新しいビジネスの紹介も兼ねて。
→同じチームの直属の上司や、ずっと一緒にやってきたクライアントに
送別メッセージをお願いした。自分の送別会用といったら驚いていたが
快諾してくれた。あと言ってないのにチームメンバーが
○結果
・パートナークライアント含め、かなりの方に来てもらえたのだが、
延べで100人以上になってしまい、ちょっと会場がぎゅうぎゅうになってしまった。
・プレゼンが効いたのか、パートナーさんの会社から独立後、最初の大口の発注をもらった。
・料理は総じて好評だったのでシェフも自信がついたよう。アンケート取らせてもらったら、色々と意見をもらえた。
・会自体は司会が素晴らしかったので盛り上がった。笑いあり涙ありな感じにしたかったのでよかった。
・最初は自分だけで動く予定で考えていたのだが、最終的には同じチームのメンバー始め何人も手伝ってくれた。（感謝）
事が面倒くさいし事こういう事書くと漫画家とか出版社を肩持ちたがる人が湧くので嫌なんですけどね。
後、長文になるとそれだけでケチ付ける人とか居るんですが、別に私の事はどーでも良いんで拡散でもしてやってやって下さい。
あ・・・あと全員がって話では無く私の場合は一人の作家とまぁ小学館の某webでの作家に対してしか向けてないので。
現在アシスタントのメインの募集法って ganmo http://ganmo.j-comi.jp/とjac http://www2.plala.or.jp/JAC/が有るんですけどね。
ここで募集したりするのは何の問題も無いんですが、ここに平然と「小学館編集部」として登録してくるわけですよ
問題無いだろう?って思うでしょ?それが問題だらけなんですよ。
まずコレ彼らは「下請け契約」として発注しているつもりですが時間拘束と命令飛ばしてくるんですよね。
まぁ当然登録はしてないですよね。わざわざその辺は調べました。
あと、アシスタントやっている人間で「アシスタントは下請けでしょう?雇用?ばかじゃねーの?」って人がいましたが
雇用かどうかを決めるのは使用者が決めるのでは無く「労働実態」と「労働者性」なんですよね。
漫画家や編集がどれだけ「下請けで雇いました」って言っても労働者性認められると労働なのよね。
と・・・言うか漫画業界って権利とかって騒ぐ割に出版社は漫画家に漫画家はアシスタントにって感じで使い捨てな感じで
まともな契約書すら書かない事が横行している訳でねみんなおかしい訳。
あ…編集部が代理で募集するの悪いのは在宅同士でアシをすると下手すると契約書すら送ってこない訳で相手の住所すら分からん訳よ?
で馬鹿編集部って作家を守るんだみたいな事言いだして不払い有るクセに作家の居場所吐かない訳。
あとちなみにだけど小学館はその作家に対して裁判起こすからって事で裁判所からの調査嘱託で聞かれても吐かない訳?
と言うかね契約書送ってこないって私は意匠権別に譲渡してないから人の現行勝手に盗んで印刷して利益得ているって不当利益なわけ
https://news.nifty.com/article/item/neta/12111-34639/
●籠池氏が明らかにしたメールの内容
籠池氏が明らかにしたメールには、森友問題の背後の闇を知るうえで実に興味深い内容が含まれている。月刊誌「紙の爆弾」（７月号）で筆者が報告したその内容を、下記に引用・転載する。
２０１７年５月１６日に、民進党が開催したヒアリングで明らかにしたメールは、森友学園の校舎建設事業の設計にかかわったキアラ建築研究機関の杉本氏と、近畿財務局との交渉の窓口に立っていた酒井弁護士、校舎建設工事を担った藤原工業など内部でのやり取りと、近畿財務局や大阪航空局とのやり取りのメール（２０１６年４月～）であり、驚くべき内容が書かれていた。
同年３月１１日の森友学園側からの、深部にごみが存在するという報告や、録音テープで話題になった財務省本省での籠池夫婦と田村嘉啓室長との面談を受けて、深部のごみの量と撤去費用の算定に関連したメールである。ここではすでに３月でのやり取りを受けて、深部にごみがあるものとして、近畿財務局が算定式をつくるため問い合わせを行っていた。１６年４月１日に近畿財務局管財部の池田氏から下記のようなメールが出され、「提示を依頼する書類」が請求されている。
（財）「瑞穂の国記念小学院開校に向けご協力ありがとうございます。（略）５月末を目途に土地の評価額算定を実施し、（略）土地の売買契約を締結すべく作業を進めています」「つきましては、現在地表に野積みされている廃棄物の撤去、今後の建築基礎の掘り方を行い発生する土砂の撤去費、地中に埋設されている廃棄物層（略）等を適正に反映させ、価格提示行いたいと考えているところです」
この中で「提供を依頼する書類」が添付され、ボーリングデータ、柱状図、掘削図などの提供が、要求されていた。これに対して、キアラ設計（キ）と酒井弁護士（酒）の間でのやりとりが以下の通り新資料には記されている。
（キ）「要求資料を作成するうちに、気になることがあり・・・・添付に計画地のボーリング調査資料を付けております。…これで行くと・・・約３m以深には廃棄物がないことを証明しています。・・・」（４/８）
（酒）「柱状図がないことは不自然でしょうか？・・実際にどうこうではなく机上の計算でも構わないというのが、近畿財務局の考え方なのではないかと思います」(４/９)
（キ）「やはり仰るように、言われてから提出する形をとるべきかと考えます。」（４/９）。
（酒）「柱状図の提出は、やめましょうか・・・あいまいな形では億単位の交渉はできません」(４/１０)
(キ)「今回工事に係わるボーリング調査に関する資料は、抹消しました。」（４/１０）
以上のように、近畿財務局側が深部のごみの存在について、深部での地層の様子を示す柱状図の提出などを求めている。これに対して、その柱状図を提出すれば、深部にはごみがないことが示されていて、深部にごみがあるとする主張と矛盾することになり、大幅な値引きが期待できなくなるとして、キアラ側と酒井弁護士がメールをやりとりし、ボーリング調査の結果の柱状図を提出しないことにしたことがわかる。そして森友の籠池氏は発注事業者だが、キアラと酒井弁護士との間でこのようなやり取りをしていたのを最近気が付いたという。
このメールでもっとも重要な点は、ごみがあったと報告していた森友学園側が、そのごみはなかったという調査資料を持っていたことである。そして近畿財務局は、現場の実態を調査もせず、この森友学園側の事業者の主張のまま、ごみがあったとしていた点である。そして柱状図等が提出されていないにもかかわらず、２回目のごみの撤去に関連して、深部に約２万トンのごみがあるという算定式を偽装し、その撤去料として１トン当たり約４．２万円かかるとして８億円を算定したのである。
筆者らは、これまでの調査・分析によって、２万トンを計算した算定式に矛盾点が多いと指摘してきたが、その指摘に符合し、算定式の出鱈目さを裏付けるメールである。
今回の新資料でわかったことは、近畿財務局は本件用地の地層図や柱状図の提出を森友側に要求しながら、その地層図や柱状図を所有し、深部にはごみがないことを把握していたということである。森友側に資料請求しても出してこないと予測しながら、あえて請求し、深部にはごみがないことを、契約時には近畿財務局や国は知らなかったことにしたのである。そのことが今回の新資料で掴むことができたといえる。
「森友告発プロジェクト」（藤田高景共同代表）などの市民８人は５月２２日、撤去料が８億円相当とされる２万トンのごみがないにもかかわらず、あるかのように偽装し、９億円相当の国有地を１億円に値下げし、国家財政に損失を与えたとして、背任行為で当時の近畿財務局局長と財務省の担当責任者、武内良樹、迫田英典２名ほかを背任罪で東京地検特捜部直告係に告発した。告発状はもうひとつ提出され、自民党候補者の応援に入った安倍首相夫人の昭恵氏付公務員秘書が選挙に帯同した件の公務員法違反も告発した（註３）。
【再掲】■アマゾンの「バックオーダー発注」廃止は、正味戦争の宣戦布告である
https://anond.hatelabo.jp/20170601214849
ここまでに集まってきた情報を集約し、どう対応するのが出版社にとって得策なのかを考えたい。前回同様、「僕と契約してe託出版社になってよ」と囁く声に揺れている人に向けてこれを書く。出版社が死に絶えた先に本の未来があると信じる人は、そう行動すればいい。私はそれに賛同しないし、その人たちのために論考を書く気もない。
５月から出版社に向けて五月雨式にアマゾンから「説明会」の案内が送られている。内容はここ数年繰り返されてきたのと同じ取次流通への悪口雑言と、「このままでは貴社の流通が危ない！ さあe託契約を！ ６月中なら特別条件で！」というものだ。
目新しい情報といえば、日販の在庫率が出版社の規模によって違う、つまり、「あなたたち中小は差別されていますよ」という煽りだ。しかし、先般日経新聞に出ていたアマゾン負担による集荷構想は、小規模出版社には適用されないという。なんのことはない。アマゾンだって差別をやっているのだ。説明会の案内が来ない出版社には特別条件も提示されないし、説明会に参加することも許されない。質問しても答えも来ない。
日販はここに至っても、対応についてなんら説明を始めていない（大手にはしているのかもしれないが）。この沈黙は組織としての老朽化を実感させる。なので筆者としては、ことさらに日販を擁護するつもりもない。ただ、説明会でのアマゾンの弁によれば、今春にヤマト運輸と期を一にして、日販も条件改定の交渉を切り出したとのことだ。アマゾンから執拗に「在庫の拡充」を求められ、その原資を求めたのだろう。本件において日販は、愚鈍ではあるが邪悪ではない。むしろ、これまで一般書店そっちのけで利益の低いアマゾンを優遇してきた不正な状況を改善しようとしたと言える。
業界紙『新文化』５月25日号記事「アマゾンジャパン、「日販バックオーダー発注」停止の真意／バイスプレジデント・村井良二氏、事業企画本部長・種茂正彦氏に聞く」でも、日販に在庫要望を繰り返したことは明言されている。
この記事で可笑しいのは、アマゾンが40万点やら200万点やらのアイテムについて「精度の高い需要予測を持っていて、その数量の在庫を持つよう日販に求めたが、応じてもらっていない」と不満を述べているところだ。この主張こそが、アマゾンが求めているものが読者の利益でも流通の速度や確実さでもないことを裏付けている。
それだけ確度の高い予想をもっているのであれば、現在の在庫を３～４倍増し、６～８週間の需要予測分を仕入れて在庫すればいい。調達日数は８-10日くらいなのだから、需要のスパイクもほとんどがそこで吸収でき、欠品率は80％以上向上するだろう。アマゾンは「ロングテール」を誇っているのだから、たとえ予測が大きく外れても、100週間くらいのうちにはあらかた消化できる。もちろん経費はかかる。しかし駅前やロードサイドの一等地に店舗を構える書店にくらべれば、はるかにコストもリスクも低い。しかし、その在庫経費を日販に求めようとする。お門違いとしか言いようがない。
だから、前回に言ったとおり、アマゾンが求めているのは経費の負担であり、流通の改善などではない。これは正味戦争なのだ。（前回のエントリで「正味戦争」という言葉を知らない業界人が多いことを思い知らされた。61年の雑誌戦争、69年のブック戦争を総称して正味戦争と呼ぶ。書店による一斉販売拒否などの実力行使を含む激しい闘争であったが、当事者間で情報が共有されオープンな話し合いがもたれただけ、今回の戦争より公正であった。）
さて、戦争の状況を概説したい。アマゾンが提示している中小出版社への「特別条件」は65％である。個別交渉で時限ながら68％を獲得した社もあり、前述のとおりオープンな条件ではない。アマゾンは各方面で為される「条件切り下げ」の指摘を気にかけているようで、「全アイテムの登録・週５日の出荷回答・２か所（+１か所になる場合あり）への納品」の３条件が遵守されるかぎり、この条件を「変えるつもりはない」と語っている。
しかし、条件が遵守されているかの判断権はアマゾンが握っているし、「変えるつもりはない」というトークを明文条項に盛り込んで契約できた社はない。なによりe託契約は「完全なる合意」を条項に謳っており、個別の覚書や担当者との口約束等は意味をなさないとされている。
これらの条件を「６月末日までですよ」と決断に期限をかけ、「もうこの条件は出ませんよ。いますぐ契約を！」とテレビショッピングのようにプレゼンしているのがアマゾンの説明会である。まともなBtoB商売のセンスではない。
これは商売の正味の話だ。だから、検討する人は正味の損得を計算するのが最初にやることだ。しかし、この件についてあちこちから相談を持ちかけられるが、自分で計算をしている人があまりに少ない。
週５回２～３か所に宅配便で出荷する経費は、送料・梱包手数料・資材費を計算するとかなり大きな割合を占める。60％掛に切り下げられたときに、実正味がいくらになるのか。それはアマゾンでのカゴ落ち失注を防ぐ（e託で防げるとも限らないが）ことで割にあうのか。宅配便の追加納品先が突然鳥栖に切り替えられても大丈夫か。冷静に計算してみることが必要だろう。
アマゾンでの失注は、100％が失われる売り上げではない。そのうち、切実な需要の分は、他の身銭を切って在庫をもっていたり、迅速な調達に努力していたりする書店にまわるのだ。アマゾンが在庫と調達に不熱心な書店である事実が広まれば、その率はますます高まるだろう。
当方ではエクセルの計算シートでそれらの要素を試算し、パラメータが変わるごとの得失がわかるようにした。より汎用性の高いものに改善でき次第、近日中に本項への追加として公開することにしたい。大して複雑な計算ではないが、自力での計算方法に自信がもてない方は、それまで決断を待ってはどうだろうか。
なお、匿名性の高いspreadsheetの公開方法を募集中である。
本記事のライセンスについて「CC BY 4.0」を宣言します。転載・再配布・翻案自由とします。また、はてなによって本記事がまた消去された場合は元記事の掲示が無意味になりますが、その場合もどなたかが再掲載してくださることを希望します。
あったあった。
材料って、突然「今すぐ持ってこい」って仕入先に言ったらすぐ持ってきてくれるわけじゃないんだよな。
「いつものメーカーの〇〇は日頃からそんなに市中在庫がありません。数を揃えるなら他社の△△とかをかき集めたら何とかなるかもしれませんけど、高いですよアレ」みたいな感じで、多量に仕入れようとしたらなぜか価格が上がる。
以前より少量だけ作っていた、価格的に厳しい得意先向け廉価モデルを増産して市場に投入しようということになり中国に発注出した。でもあいつら欲の皮が突っ張ってるから、日本の品薄を知ってて値上げしてくるのな。しかも急がせたら急がせるだけ不良率が上昇する。
発送するときはするときで、運送会社から「3.6立米以上はチャーター料金を頂戴します」などと言われて渋々承諾したものの「すみません、空いてるトラックが見つかりませんでした」と追い打ちを食らうとか。
入社3年目までwebアプリを開発する部署に所属していたのだけど、
今度担当するシステムの中核はcobol？という言語で構成されているらしい。
といっても今度の部署は、下流工程をソフトハウスさんに投げてしまうので、
これからの主な仕事は、発注元の「業務フロー変えたいからシステムもこんな感じに変えてくれ〜」
みたいな要件を聞いて、それをソフトハウスさんに伝えて開発してもらう、
いわば橋渡し役みたいなものになる。
全く異なる毛色の部署からの異動だし、なんとか手探り手探り手探りで４月から業務をしてみたけど、
この、発注元とソフトハウスさんの橋渡し役って、何の利益を生み出してるのかよくわからなくなってきた。
この橋渡し役は、「システムのことわからない発注元の要望を、システム仕様に翻訳する」という役割があるらしい。
だけど、このシステムの発注元はちゃんと要望をシステムチックに出してくれるんだよね。
先日受けた、エラー時のチェック仕様変えたいですっていう要望についても、
要件書の記載がそのままif文作れるような文章になっているので、
僕はそれを受け取って、いくつか申請書を作って、あとはソフトハウスさんに要件を伝えるだけ。
というのも、COBOLとかメインフレームとか、まだ圧倒的に知識不足の為、
ソフトハウスさんが作ってくれた成果物、実施してくれたテストの証跡を検証できないんです。(ごめんなさい。)
テスト証跡ではなく、「テスト結果の報告」をチェックして、それをもとにいくつかのチェックリスト作って提出して、
その結果がなんだがよくわからないうちにシステムに反映されていた。
この仕様変更について僕がやったことといえば、
·いくつかの申請書をつくる
·ソフトハウスさんのテスト結果報告に対して「確認しました。対応ありがとうございました。」と返信する。
·いくつかのチェックリストをつくる
くらいだ。
エクセルとメーラーしか触ってないのに、いろんなことがトントン進んでいくのが不思議だし、
こんな業務にもちゃんとお給料が発生するのがいちばん不思議だ。
·······。
もっと月日が経って、色んな仕事任せてもらえるようになったら、また振り返ろうと思う。
悩み
···「内部のロジックなんて読めなくてもなんとかなるよ」なんて言われるし、
ひとつひとつを深くこなす、みたいなのがイレギュラー、という空気を感じるけど
まだその空気に慣れてない。
