  |
はてなキーワード: Siとは
http://anond.hatelabo.jp/20160123131828
やれ技術が古い、テストをしないだのと叩かれまくっているけど、SIerって言っても色々だと言いたい。
俺が勤めている会社は、100人に満たない小さな会社だけど、ちょっとしたニッチな固有の技術を持っていて
それを売りにした製品を自社開発すると同時に、受託開発も引き受けている。
固有技術なので顧客には完全なブラックボックスということがあって、それが顧客との間で有利に働く。
当然論文も特許もあるけれど、それを理解できる客など殆ど居ないので商売としては相当な強気を通していて、
受託受注額も業界屈指だと思うけど、技術力の高さに関する評判の為に顧客も文句は言われないし、その結果として給料はいい。
平均年収は800万程度だったはず。残業はないわけではないけど、社員平均で月間40時間は切ってたはず。
同時に社内にも、うちは技術力を売りにしている、という自負があるので、現場の環境整備に関する要求も当然の様に行われる。
アジャイル開発が話題になれば、いち早くそれらを試す位の事はしてきたし、gitを始めとして話題になったものは積極的に使う事はいとわない。
JIRAなど有償のものなら、それを購入するのも躊躇いなく行う。
社内勉強会も活発で、いわゆる流行りの言語ついてとか、機械学習など流行っているものの専門書の輪講など様々に行っている。
例えば、論文を執筆して発表すれば、出した会議や学術誌のインパクトファクターなどで評価値が決まっていて、これは公開されている
エンジニアでも、コードのコミット行数、ビルドの失敗回数、バグを出した数、修正した数などが、ビルドサーバーで自動的に計測されており、
一方で、ここで下位扱いになっても、クビにはしない。ただ、相当期間の再学習期間を与えられ、様々にテストを課される事にはなる
まず、役職者には工学博士を持ってないとなれない。新入社員も当然ながら全員修士卒以上を要求しているが、学部卒も稀にとる
しかし、博士がないと出世は出来ないので、優秀であれば、どこかのタイミングで大学院に進学する事を求められる。
その間は、午前中のみ会議や、ちょっとした仕事をするために出社を要求されるけど、ほぼ一日を研究に割り当てる事を業務にする
テーマは殆どが自社製品に関するものなので、修了者全員が業界屈指の専門家として帰ってくる事も会社の強みにしているのもあり、
その間に給料が下がることはないし、海外留学する場合にも学費も何もかもが会社で負担してもらえる。
海外留学や海外との取引を行うために、英語学習も推奨されていて、某大手英会話学校の講師が会社にきてレッスンを行うなどするが
社員にはTOEFL80点を常に維持することが求めれられている。高額な受験費も会社もち。
一方で育休などの制度も充実していて、企業内保育所を作り保育士を1名雇っているので安心して出産を行えるなど、女性にも受けがいい。
ちなみに社内結婚も推奨されていて結婚時には50万円一律で支給されるとあって、何組かカップルがいる。
さらに、家賃の半分を会社が持つなど優秀な人材を一人も社外に出さない事に社長は余念がない。社内では人材コレクター呼ばわりされる所以だ
という具合に、SIといっても様々なので、ひとまとめにして貶されることに抵抗がある。
SIはやめておけというのはわかった。
じゃあ、どこならいいんだ？
何ならいいんだ？
要するに、どこに行っても何をしても、このご時世働くのは大変で、給料は上がらなくて、つらく苦しいのではなかろうか。
だったら、少しでも好きなこと、自分に向いていることをするのは悪くない。
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。
今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。
一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。
以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。
これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。
あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。
そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。
上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。
まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。
まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。
また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。
会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。
いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。
情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。
ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。
会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。
どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。
利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。
本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。
表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。
その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。
他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
一部の本当にトップクラスや理系は除いて当時はトップ校でも文系は壊滅的だった。
さて…、15年ほど経ちあの時と自分の周りを見てどう思うかの話だが。
自分の知り合いは当時雇用が旺盛だったITに行った人が多かった。ITはその後も躍進し続けて、現在でも人の足りたことがない業界という事で、その頃そういった企業（主にSIだったようなきがするが）に行った知り合い達はその後もそういった会社で長く働いている。充実しているかどうかは別として、忙しそうだ。
ここまではまぁ分かる。
ところが、ここからが本題で当時社名ブランドを優先させた（職種や中身ではなく）上位校の人達はその後どうなったか？
これが芳しくない。皆、当時ブランドがあった（社名が知られていた）企業に就職していったが、それらの企業も新卒維持にかなり無理していたのだろう。よほど堅実な所以外はかれらも皆、そこをいろいろあって（会社がなくなったり、買収されたり、リストラされたりなどなど）四散しているというのが現状だ。
もちろん安定的な企業を選んだ人はいまでもあまり変わっていないが。
さて、社内外に資料をメール送信する際に自己解凍形式で送信する文化がある。パスつきzipで固めてパスは別メールで送信する、という文化もある。
手法のいい悪いなんてどうでもいい。世の中は圧倒的にwindowsPCばかりなのだから自己解凍でもいいだろうし、メールサーバではじくのも当然だ。zipのパスワードなんてツールを使えば３分かからないとわかってるけれどもそれがまかりとおる。
ただ不思議なのは、この意図した結果は達成されていない方式がまかり通っているのに、たとえばドロップボックスなり、宅ファイル便なんぞでファイルを送るのは厳しき禁止されていることが不可解だ。
決定権を持ってる会議に参加している人（決定権が個人にある企業なんてみたことねーや）はとにかくプライドが高いので、知らないこと、わからないことにぶつかったときに、それを持ってきた奴を叩く。「俺にわからないものをもってくるな」というのをオトナ語に変換して怒ってくる。つまり、世の企業体のテクノロジ水準はそういう人たちがわかる程度のものに落ち着いていく。だから技術屋あがりの企業はやわらかいツールであっても使い始める。使ってから考える文化だから。スキルのない企業だと他人が使い終わったそれを導入する。自分に理解できるから。安いし。
フランスの漫画家ジョアン・スファール Joann Sfar は、シャルリー･エブドに2004年夏から2005年9月まで"Mon cahier d'éveil"(僕の情操教育ノート)という作品を連載していた。
その後、今年1月のシャルリー･エブド襲撃事件を受けて、ハフィントン・ポスト フランス版ブログに"Si Dieu existe" というイラストエッセイを発表。以下はその連載第2回、"Un concert pour Cabu"の日本語訳である。
イラスト部分は実際にハフィントン･ポスト フランス版でご覧いただきたい。
http://www.huffingtonpost.fr/joann-sfar/dessins-sfar-cabu-hommage_b_6658718.html
なお、ページ番号は連載第1回からの通し番号となっている。
これはお葬式じゃない。
13
カブっていう大した奴
いま君は泣いていないけど、それは君が砂漠みたいに乾いちまったからなんだ！」
14
それは本物のイスラム教じゃない。
みんなが正しい、そしてみんなが間違っている。
というのもイスラム教徒は信者をとりまとめる最高機関を持ってないからだ。イスラム教に教皇はいないんだ！
それゆえに独裁者達や過激派は、論破されることもなく、イスラム教を不当にも自分のものにすることができてしまう。
フランスでは、人道的なイスラム教徒を代表する人たちがテロリズムに対して抗議したけれど、その抗議の正当性は、世界的に認められたどれかのイスラム教の機関から来ているわけではなかった。
このところ僕は、「"イスラム教を改革する"必要があるんじゃないか」とみんなが口にするのを聞いている。
数え切れない程のイスラム教徒はいるけれど、彼らが信奉する戒律について、正当性があるのか無いのかを一刀両断で決めてしまえる「誰か」は存在しない。
15
「"バチカンII”ってアラビア語でどう言えばいいんだろう？」
目下のところ、僕は神経過敏になっている。
「もうしたよ」
16
僕たちがその姿を絵に描く権利があるにせよないにせよ、ムハンマドは剣を持ったただ一人の預言者だ。これは圧倒的大多数のムスリムの、寛大で平和な日々からとても隔たりがある。
逸脱した暴力は、この独特なイメージ、武器を持った神の使者のイメージの下に結集しようとしている。
そうだね、改革が必要だ。でも改革をもたらすのは誰だろう？フランスにはそのための充分な手立てがない。イスラム教を和らげるためにムスリムが声を上げるなら、その運動はペルシャ湾岸から起こらなければならないだろうし、そうすれば豊かなオイルマネーを活用できるに違いない。
もちろん、敵は原理主義者だ。そして今日、僕たちの言うことを聞いてもらうには、とてつもないイマジネーションと力強い声が必要だ。
僕はムスリムに心から敬意を表する。今日の暴力の第一の犠牲者はムスリムだ。そして、「コーランが推奨する聖戦は、何よりもまず心の中の悪魔と戦うことだと考えなければならない」と発言する勇気をムスリムは持っている。
それでも自己批判しろという声がムスリムには突きつけられている。
18
僕は、夜明けの光に照らされた雨の中のカブ夫婦の姿を思い出す。シャルリー･エブドの訴訟中のことだった。最後にカブへ挨拶したのは僕の映画の撮影の直前だった。僕たちはオデオンのそばのイタリアンレストランに居合わせたのだった。
僕が最後にヴォランスキと食事をしたのは半年前、サン･ジェルマンだった。
3週間前、僕はおばと会いにリュニベルシテ通りへ行ったのだけど、その時、サン･ペール通りの角で、20メートル離れたところにヴォランスキを見た。彼は僕を見ていなかった。僕は急いでいたので、彼を抱擁しには行かなかった。
19
カブを見る時はいつも連想的に、トレネの歌を聞かなければいけないぞ、と思ったものだ。僕はトレネのシャンソン全集を持っている。フレモー版だ。
「君はこんな時にも自分について話そうとしてるのか」って？
そうさ。ストレスを感じたワンコが自分のキンタマをなめて安心しようとするように、僕は自分のスタイルにしがみついて、昔の手帳に書いた話を自分に繰り返してみなければならない。そこに一つの意味を見つけるために。立っているために。僕はシャルリーをやめた。ハリケーン・カトリーナの日だ。ロマンチックで自己防衛的な理由だった。洪水に沈んだニューオーリンズ、それはもう僕にはひどすぎる出来事だった。
そして僕は私小説的なものやフィクションへ避難しようとして、時事ネタときっぱり別れようとしたが、やり損ねた。
ニューオーリンズの音楽が死んだカブのために演奏されている。それは僕の記憶を呼び起こす。僕は洪水の泥に埋まったファッツ･ドミノのピアノのことを考えている。
21
「シャンソンが好きなのかカブに聞いた。カブは答えた。トレネが好きなのだと。」
カブの友人達はブラッサンスの仲間達に似ている。ヒゲを生やし、肘に革をあてたコーデュロイを着ている。もちろん、彼らは涙で目を赤くしている。彼らは反レイシストの、反狩猟の、反闘牛の、古株の活動家だ。気のいい男子たちで、勇敢な女子たちだ。移民の為に、書類の無い入国者のために、そして誰もがこの国が立派だと感じられるように、彼らはずっと暴れ回っている。
今日、僕は、このとても優しくとても過激な人たちが、警察の活動のおかげで安心させられてしまっているのを見る。
22
マダム･カブは僕に語る。カブはなんでも引き受けて、絵でもポスターでも描いたし本も書いた。ある日彼が罪悪感を感じたのは、フライドポテトの移動販売のトラックの店先に絵を描く時間が無いことだったそうだ。
フレッド･マヌーキアンと楽団は続けてキャブ･キャロウェイの「ミニー・ザ・ムーチャー」を演奏する。
僕に起きる可能性のあること、僕を守ってくれるかもしれないことの中で一番美しいもの――
聴衆に挨拶するや、カブの兄弟がファンファーレを鳴らし、僕はマヌーキアンの楽団とファンファーレにサンドイッチみたいに挟まれているのに気付く。僕が描いているのは、オフィクレイドの音色が僕の真っ正面で鳴った時のエモーションだ。すまない、僕はずっと泣いている。オーケストラのおかげで泣き顔は隠れたから、僕は運が良かった。
P13. カブ Cabu(1938ｰ2015)、P18. ヴォランスキ Wolinski(1934-2015) いずれもシャルリー･エブド襲撃で殺害された漫画家。
シャルリー･エブドの漫画家達については鵜野孝紀氏のコラムが詳しい。http://books.shopro.co.jp/bdfile/2015/01/bd-19.html
P12.フレッド・マヌーキアン Frédéric Manoukian Big Band のリーダー。
P13.カブの兄弟 Michel Cabut氏。 https://youtu.be/ZX7rZCpl0x4?t=2m23s
P18.「僕の映画の撮影」 スファールの2本目の実写監督作"La Dame dans l'auto avec des lunettes et un fusil"と思われる。2015年夏公開。
P20.「手帳」 スファールはcarnet(手帳)というイラストエッセイのシリーズを刊行している。"Si Dieu existe"は11冊目の"carnet"となった。
P21. ジョルジュ・ブラッサンス Georges Brassens(1921-1981) フランスの歌手。https://youtu.be/84SMQ4Gyz5o
なお、このコンサートはテレビとラジオで放送され、ラジオ音源をFrance Interのサイトで聞くことができる。
http://www.franceinter.fr/emission-un-cabu-extraordinaire-soiree-speciale
フランス語圏の漫画を日本ではバンド・デシネ、略してBDとして紹介することが多いわけですが、そのBDの世界で、ジョアン･スファールは例外的なほど多作、かつアニメや実写映画の監督を務めるなど多才なことでも知られています。一般にBD作家は日本の漫画家と比べると寡作なのですが、スファールの場合は、ほとんど日本の漫画家かというくらいに多作なようです。
スファールの作品の中には宗教に対する風刺もあります。ただし作風は、おそらく一般にシャルリー･エブドの風刺漫画から想像されるようなものとは異なっています。たとえば長編『ラビの猫』(これは自ら劇場用アニメ版の監督もしています)では「猫はユダヤ教の宗教儀礼を受けてユダヤ人になれるのか？」という設定からストーリーが展開します。(さらに付け加えると『猫』ではユダヤ教ラビがイスラム教修行者とある出来事を通じて意気投合するシーンが描かれます。さらに終盤は共に旅する仲間となります)
とりあえず、シャルリー･エブドで作品を描いたことによってスファールを「シャルリー･エブドの漫画家」と考えると誤解に繋がることは言っておきたい。
「スファールという漫画家はシャルリー･エブドに作品を描いたこともある」というくらいの理解が適当かと思われます。
ただし、スファールは、シャルリー･エブド襲撃事件を受けていくつもの作品を発表しています。
たとえばフランス語版ハフィントン･ポストの『Si Dieu existe』という作品。
http://www.huffingtonpost.fr/joann-sfar/carnets-dessins-si-dieu-existe_b_6602154.html?1423152000
猫が言います。
"Si Dieu existe, il ne tue pas pour un dessin."
「神様はいるよね、でも神様は1枚の絵のために殺したりしないよね」
最後に、日本語訳のある2冊の本を紹介してこの増田を終えたいと思います。
http://www.amazon.co.jp/dp/4861139562/
プチバンピ―学校へ行く
■背景と問題点
SI業界におけるシステム開発のプロジェクトでは、ソフトウェアの品質が問題になることが多い。
問題点は、知識不足や経験不足な人間が大量に放り込まれたプロジェクトでは低品質なクソコード（※1）を大量生産してしまう事にある。
※1：クソコードとは、可読性の低さ、保守性の低さ、コーディング規約違反、テストが不十分、静的解析の指摘結果が多い、命名の悪さなどが該当するコードである。
■解決方法
真っ先に思いつく品質向上手段としては、レビュー、指導（教育）が考えられると思う。ただ、コストがかかり浸透するまでに時間がかかるのが欠点だ。
そこで、人間の感性に訴える「羞恥心」をうまく利用する方法はどうだろうか？
クソコードの基準を作り、基準に満たないソースコードをコミットした人物を徹底的に「晒す」ことで、
危機意識が高まり、クソコードをコミットする前に見直しする結果、品質が上がると考える。
「晒す」とは、クソコードをコミットした人物の所属会社名と所属プロジェクトと氏名を館内放送するなどプロジェクトメンバーが一目瞭然で分かる公知の事実にすることである。
月末にクソコードコミットワーストランキングを作成し、食堂、トイレ、休憩スペースなどの目に付くあらゆる場所に掲示することで危機意識が生まれるだろう。
人月単価交渉の際にも基準値に満たない数値が出ていることを示すことで、具体的な根拠を持った単価の切り下げ交渉も可能だろう。
朝会・夕会があるのであれば、クソコード作成者を読み上げて周知の事実とするべきだろう。
請け負った会社単位でのクソコードコミットワーストランキングも作成し、会社ぐるみでの取り組みも強化させることで品質が向上するだろう。
■まとめ
プロジェクトメンバの意識が「クソコードをコミットすると恥をかく」を徹底させ、
きちんとしたものを作らなければならないという意識を芽生えさせる事が一番重要である。
ソフトウェアは目に見えないものなので、品質が分かりにくいが、
物作りの現場だとクソな部品を渡されれば次の工程の人間が困るのは目に見えている。
物作りの現場では、誰が不良品を作ったか？を特定されて、詰められるのは当たり前だろう。
だが、ソフトウェアの現場では未だそれを見ない。そろそろやっても良いのではないか？
読者の皆様はいかが考えるだろうか？
SIerが欲しがるプログラマーなしでもシステムできちゃう製品あるでしょ。
分岐をアイコンのようなやつでつなげるとか、ものっすごく単純にしたドメイン固有言語をコピペするだけでシステム完成するやつ。
パソコンのﾉの字も知らないオッサンは、上流の設計をそのまますぐに設定をしてお客に売る。
人月がめっちゃ安くなるよ―！！っていうアイドルと付き合えちゃうくらいなレベルの妄想をもっているらしい。
でもね。
今まで見てきたけど全部燃えてたよ。
ガソリンがたんまり仕込まれている焼夷系の地雷なんだよあれは。
大体お客さんは安い安いとか言っときながら、SIでシステム買おうとしているから絶対に自分らの社内ルールに合わせた複雑な要望を持っている。
社内ルールをパッケージに合せることや、システムの設計と社内のルールを歩み寄らせるというのは理想だが根付いていない。
本来ならばシステム担当役員が企業全体のフローごと改革するような強い権限を持っていればいいが、システムを買う窓口になっているお客サンがわのSEは普通の平だし、ヘタしたら外部の人間だし、
だから企業ごとのカスタマイズが必要になるのだが、あのノンプログラマー大丈夫系製品はほっとんどかゆいところに手が届かない。
ノンプログラマー大丈夫ってことは、プログラミングでの抽象度の高い操作を極力無くしてほぼ設定段階で済ませようとしているのだとおもう。
そしてノンプログラマーでも大丈夫系製品なので本当にノンプログラマーで構成された上流たちが、お客の要望をきいて「できそうじゃね？」「販売元にきいてみっべ」「いざとなれば誰か外注すっか」みたいなノリでやりがち。
で、「仕方ないプログラマ様にきていただぐべ」とかなるんだけれども
プログラマ様も謎の製品について学習するコストもかかってしまって余計時間がかかってしまう。
はっきりいってピュアJavaで書いてくれたほうがわかりやすい。
この手の製品で本当に挙動が分からなくて、サポートに電話しても要領を得なくて、でも上からは「おら、やれよバカ」っていわれて
しかたないからClassをデコンパイルして読んで、できません…っていうこともできないから、結局別プロセスで動かす逐一データを変換するような物をつくらなくちゃならなくなった。
それ誰が面倒を見るの？
納期に迫られてしかたねーしかたねーでとりあえず作ったし、オレは外部の人間だからすぐ抜けちゃうけどさ
こんなことここ五年で4回くらいみた。
簡単にする仕組みは良いよ。
ブラックボックスだし小回り聞かないし、でも色々な要望がでてきて結局袋小路に追い詰められるんだよ。
使って良いのはプログラミング言語の上を覆うくらいのフレームワークまでだね。
あとね。
作っている途中で思い出す感じなんだよ、
そんな状態なのに機能が制限されている簡単ツールなんて使うなよ。
ねえねえ。
よく「会社員としてのエンジニアは給料安い」って声があがるけど、
派遣社員と同じで自分の単金が見えているから、そう思うんだと思う。
「単金60万円だけど、自分の給料は25万。35万もピンハネされてる！」って具合で。
有給や賞与、営業コスト・管理コスト、会社負担の社会保険料や研修費、業務が空いた時も給料が発生したり、
時には赤字のプロジェクトに採算度外視で人を入れざる負えないことがあったりすることも加味すれば、妥当だと思うけど。
個人事業主として60万円貰っている人は、人脈広げて営業やら確定申告やら自分でやっているし、
さらに必要とされる技術を自分で身につけなければあっという間に仕事がなくなるので、
それと比較しなければ「会社員としてのエンジニアは給料安い」とは言えないんじゃないかなぁ。
もちろん多重請負・偽装請負で、
お客さんから「あなたには100万払ってるんだから」と言われるのはまた別の話だけど。
時々まとめサイトを延々と眺めてしまう時期が到来する。延々と読んでいると鬼女関連のスレを扱うまとめ記事の自主規制（？）ぶりがすごく目に付く。
管理人の自主規制ではなくブログ側のNGワードが厳しいのかもしれないし、元スレでそういう表記なのかもしれないが。
主に性的あるいは暴力的な表現を含む単語と、そういう単語に使われがちな漢字そのものの使用を必死に……必ﾀﾋに避けている。
久々に見たら相変わらず、というかどんどん規制されていっている気がするので一例を書いておく。
「性」「犯」「殺」「殴」……ブログによって分かれるが「◎」「※」「×」などで置き換えられる。「せい」「はん」と平仮名表記したり、「殺」を「刹」に置き換えるパターンも。
頻出する「可能性」「個性的」「確信犯」「犯人」等も当然一斉置換されていて若干読みづらい。「※る」を文脈から「殴る」「蹴る」はたまた全く違う言葉なのか推測する必要がある。
「下着」「ブラ」……最近見てびっくりしたのがこれ。「しtaぎ」「ぶra」 NGワードだかなんだか知らないが、平仮名にしただけでは足りず一部ローマ字で表記。
「ラブラブ」が「ラぶraブ」のように表記される。読みづらい。他に「せいsi」等。一斉置換なので間にスペースが入っているとそのままに。
■その他
投稿者のIDに「SM」等が紛れていると伏字になったり、「えすえむ」になったり。
書いてみたらあまり思いつかなかったので、詳しい方が補完してくれることを願います。
またこれが管理人による自主規制なのか、ブログ側が厳しくてそうしないと記事投稿できない仕様なのかご存知の方がおられればご教授願いたいです。
本稿はTVアニメ『マイ・リトル・ポニー 〜トモダチは魔法〜』の二次創作作品「How Applejack Won the war」についての解説である。
～How Applejack Won the War～ 完成版 ‐ ニコニコ動画:GINZA
すでに動画up主による訳詞がついているため、これだけ観ても楽しめる。
しかし元動画作者の Sherclop Pones の特徴として「偏執的なまでに韻を踏む」の他に「やたらダブルミーニングを込めたがる」というのもあり、翻訳動画だけではカバーしきれない、あるいは観ててわかりにくいところが多々存在する。
以下ではそうしたスキマを解説していきたい。訳はだいたいオリジナルであるが、ところどころでリンク先動画主のGED氏の訳を大いに参考にさせてもらった。この場を借りて謝意を表したい。
一日目
開戦だ
さあ、ジョニーよ銃をとれ*
訓練所で射撃練習だ
三段目(Come on Johnny get your gun)の元ネタは当然反戦小説『ジョニーは戦場へ行った』（さらにその元ネタとなった軍歌『オーヴァー・ゼア』）。
四段目の「訓練所」は fruit camp 、新兵訓練所である Boot camp (昔流行ったアレ)とかけてある。
行進しよう
集結ポイントへ
お嬢様みたいにさ
エージェント・オレンジ？ まあ、待ちなって
三段目: i’m speaking fancy too. は第二シーズン六話「恐怖のキューティー・マーク」より。フランス語のキューティーマークが発現したアップルブルームに対してアップルジャックが言ったセリフ。日本語版放送時には「妹がザマス言葉になっちゃった！」と訳された。なぜこのセリフが引用されたかといえば、前段の歌詞 Rendez-vous が「集結地点」を表すフランス語だから。
四段目: Agent Orange? エージェント・オレンジはベトナム戦争時に、森林ゲリラに悩まされたアメリカ軍が木々を根こそぎ除去するためにばら撒いた悪名高き除草剤。含有されていた有害物質が後々までベトナムの人びとに深刻な影響を与えた。
二日目
仕事は多い
ラリティもがんばってる
地面を均して、納屋を建てる
五段目: Raze the field, raise this barn. - 第三シーズン八話「Apple Family Reunion」の劇中歌より。原曲の raise（建物を建てる）と、 raze（破壊する）をかけている。
ここまでは
楽勝だ
市民に死傷者は出たけれど
撃ちてしやまぬ
戦友の手を取りド-シ-ドと踊ろう
五段目: do-si-do とはスクウェアダンスやポルカの基本ステップ。元はフランス語。
新兵たちよ
良心の呵責などいらぬ
家族と結べ、戦債を売れ
条約を結べ、戦歌を歌え
一段目: Draft horse そのまま訳せば「徴募(Draft)された馬」だが、同時にアメリカのばん馬にあたるゴツいお馬さん(Draft horse)にもかかっている。
三段目: alpha, bravo, charley-horse アルファ、ブラボー、チャーリーは、軍隊で使用されるコールサイン。それに charley-horse すなわち「こむら返り」をかけている。
四段目、五段目: Family bonding, selling bonds, Signing treaties, singing songs 日本語訳動画うぷ主のGED氏は「一家団結、戦時公債、条約締結、軍歌斉唱」と訳している。名訳である。
上昇！
投下！
支援部隊がすぐ駆けつけるはずさ
五段目： 『マイ・リトル・ポニー』のオープニングにおいて、主人公のトワイライトは毎回気球に乗って登場する。
三日目
沖に出よう
静かな海でたったひとり
自分の罪に思い巡らす
寝てるなよ
終わってないよ
戦いのときだ、総員甲板へ
やつらの戦艦を沈めて
ジューシーに焼きあげろ
五段目: Burn them to a Honeycrisp ハニークリスプはりんごの品種。パリッとしたジューシーな食感が特徴。
降伏だと？
まだ殺りたんねえな
あのチキンどもを追い立てろ
やつらにくれてやる厩舎などない
捕虜は取るな、皆殺しだ！！
四日目
戦争に勝った
紅く甘美な勝利だね
三段目: Loyal to my apple corp 作曲者である Sherclop Pones の人気シリーズ動画「Friendship is Witchcraft」でアップルジャックとレインボーダッシュのエレメントが入れ替わってしまい、アップルジャックが「忠誠」のエレメントになってしまったことがあった。
戦の馬たちよ
誇りを高く持て
ドアに飾った勲章が
私の勝利を語ってくれる！
三段目: Freedom isn't Everfree: 『マイ・リトル・ポニー』本編に出てくる Everfree forest という地名が、アメリカの右翼が好きなフレーズ Freedom isn’t free. 「自由はタダじゃない」にかかっている。
