  |
はてなキーワード: デプロイとは
「よろしい、ならば戦争だ」
デコイ（英語: decoy、Military dummy、囮とも）は、敵を欺瞞して本物の目標と誤認させる目的で展開する装備の総称。
Matt Cutts氏が指摘するように、順位を下げるために付けたリンクが、期待とは正反対に順位を上げる手助けをしてしまうこともあり得なくはありませんね。
リンクされているサイトではなく、リンク元のサイトがスパムかどうか判断していることをGoogleのゲイリー・イリェーシュ氏がMarketing Land のポッドキャストで明らかにしています。
この説明にもネガティブSEOの具体例をあげて解説していることから、ペンギンアップデートがネガティブSEO対策に力を入れていることがうかがえます。
目的は「はてな次郎」の文字列を自分で管理して、インターネット上に増やすこと。
セルフプロデュースでセルフブランディングするのがポジティブSEOの王道です。
現在、「はてな次郎」をGoogle検索したら1万件ヒットする場合、セルフブランディングした情報が3万件ヒットするぐらいを目指してください。
「はてな次郎」に関する誤情報が、検索結果の10ページ以下に沈めばとりあえず成功です。
「はてな次郎」という文字列をインターネット上で増殖させる作業を、手動ではなく自動で行うことも可能です。
（例）有名人を応援するファンサイトを作り、各ページのタイトルやヘッダーに「はてな次郎」の文字列を入れる。
このような方法で、100万ページ程度のWebサイトは自動的に作れます。
元データや加工方法を変えて、さらにWebサイトを作れば「はてな次郎」の文字列をインターネット上に1億個以上投下することも可能です。
アメリカ大統領選挙でロシアが情報操作を行っていたと言われている「ロシアゲート事件」を参考にして、SNSにデコイをばらまくことも可能です。
やりたい放題のGoogleをブッ飛ばすには、プログラミングが有効です。
頑張ってください。
元記事の仮名が変更されたので本記事の仮名も変更しました。（はてな次郎）
補足：
http://anond.hatelabo.jp/20170209075944
・Rails/PHP7で開発してる
PHP5.3。フレームワークすら導入していない。
Win10シングルディスプレイ。デザイナーはPSDデータとかで容量を圧迫するに決まってるのに、低容量のSSDを使用している。逆にプログラマーはそんなに容量使わないのに大容量のHDDを使用している。頭悪い。
VirtualBoxで全部手動ですが何か。ドキュメントもないので全員環境がバラバラですが何か。
huh...?
サ ブ バ ー ジ ョ ン
口約束なら...
テスト工程を削ってる。受入テストすらも。テストせずにぶっつけ本番リリース。画面みたら即わかるnon objectエラーでさえも気にしない。言われるまで直さない
みんな忙しいバリア貼ってるので...
・Excel方眼紙使ってない
wordやで。
・アジャイル開発だ
ウォーターフォールすら理解してない。とりあえず空いてる人全員ぶっこんどけの人海戦術。
・裁量労働制だ
実質的な定時は22時やで
ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ
今年の1月からチマチマ作っていたアンテナサイトのジェネレータを公開しました。
お好みのRSSを登録するだけであなただけのアンテナサイトの完成です。
Google Analyticsのコードを使ってアクセス解析もできます。
ダッシュボードにて、アクセスランキング、逆アクセスランキングなんかも見ることができます。
今後はアクセスに応じて調整するような機能などを追加していく予定です。
ぜひ使って感想ください！
フリーで仕事をして5年目。仕事が途切れたので案件探さないとなと思い、先週から知り合いとご飯したりして案件探してる。普段の仕事はほとんどが知り合い経由での紹介。
さっき、ふと、クラウドソーシング各社ではじめて真剣に案件探してみた。
海外の知り合いはクラウドソーシングで案件とってるといっていたし、聞いたら単価も高かったので、そういう世界なのかと思ってたら、日本の案件はひどかった。
探し方が悪いだけなのかもしれないけど、まともな単価の案件は見つからなかった。
常駐型で20万〜40万/月とか、サーバたててデプロイして手順書つくって5000円〜1万円とかが存在する。
こんなんだと日払いで引越しのバイトでもやってたほうが圧倒的に儲かる。
そしてなにより怖いと思ったのはそれに応募してる人がいること。
フリーランスになったら最低でも60万/月は維持しないとフリーになった意味ないし人生詰むと思ってるんだけど（ボーナスもないし、案件とぎれることもあるし、国民年金にしか加入してないし、病気になったら終わるし）、こんな貯金もできないような単価で働く人がいるのかと思うと心が痛い。
こんな単価で受けるのは、未来の働き方なんかではない。
クラウドでのマッチングはいいことだと思うし、地方にいても働ける時代がやってくるべきだと思ってる。
でも、今のクラウドソーシングは、営業ができない人と、安く買い叩きたい会社をマッチングするプラットフォームでしかない。
そこそこの企業の特にWeb系で渡り歩いた経験から、真実を書こう。
はっきり言う、ほとんどのプログラマと自称する人間の 9 割はコーダーである。
言われたものを作る事はできるが、それ以外何も出来ないと言って過言ではなく、何もしない。
そんな驚きの生体をここに晒していく。
標準化と呼ばれるプロセスで、プログラマが環境の設計、組み合わせ、開発プラットフォームのセットアップ、開発環境の構築手順作成、開発手順の作成、必要な技術の考察を行う。
なぜそうなったのかは知らないが、一般的にそうなっている。
その環境に浸っているせいか、彼らはゼロベースでものを作ることが出来ない。
彼らにできるのは HelloWorld をコマンドプロンプトで表示するプログラム程度の事しか出来ない。
複数ソースの連結、ライブラリの読み込み、サーバへのデプロイ、どれも手動で出来ないのだ。
逆にそれ以外のこと、コードの読みやすさや、クローン率の低減、メソッドコメントの記載などの保守に関わることをしない。
それは彼らにとって「必要ない無駄な作業」としか考えないのだ。
早く仕上げるためなら、似たような動いてる箇所から、よく読みもせずにコピペを行う。
そして彼らは、作るより運用する期間の方が遥かに長くて、その間に修正で地獄を見るという簡単な論理に気づかない。
…何度味わっても気づかない。
たとえするとしても、業務時間中に業務で使ってる技術をピンポイントで学習するだけだ。
だが、プログラマと呼ばれる人間の母数に比べれば微々たるものだ。
彼らは言う「土日にまで仕事してられるか」「勉強会行ってるの？馬鹿か？」
あえて言おう、馬鹿は彼らだ。
Web で仕事をするならIDE（統合開発環境、エディタやコンパイル、テストやデバッグ実行などを画面から行えるツール）はほとんど必須（エディタで済ませる事も出来なくはない）が、彼らは状況に応じたセットアップができない。
たとえば「Maven（プロジェクト管理ツール）、checkstyle（コーディング規約チェック）、editorconfig（改行、インデント、文字コード設定）」が入っていたとする。
するとEclipseなどを使うとして
マニュアルやチュートリアルを用意しないと、道具の使用もままならない。
テストをなるべく機械にやらせようということの利点が理解できない。
そのために、何十回もコンパイル、デプロイ、アクセス、ログインの手順を何度も繰り返す。
関連する他の修正を行うたびに繰り返す…。
そしてやっと動くとひと仕事終えたと満足感に浸る。
ラリー・ウォールというとある有名な人物（Perl開発者にしてC言語ハッカー）がいる。
これは、自分の作るものは完璧なのだ、だから完璧であるように出来る限りのことをするという美徳である。
彼らは金のために嫌々動くだけのものを作るのだ、動きさえすれば報酬は変わらない、よって当然完璧かどうかなどどうでもいい。
同じ金でより良いものを作るのではない、要件だけ満たせばよいのだ。
変なプライドを持つコーダーは、それで運良く成功すると、自分の知識は正しい、自分の技術は十分なのだと考えている。
こういう人間は、プライドの無いコーダーよりたちが悪く、うまくいかないと他人か環境のせいにする。
そして調べず周囲を苛立たせるのだ。
土日に自ら勉強会に行くプログラマや、それこそ 50 人以下などという会社であればこうした事はあまりない（んじゃないかと思う。）彼らは自分でなんでもやらないといけないからだ。
だが、大企業に飼われる子飼いの企業、派遣（そもそも人手のみを求められる企業）、100人以上の企業では、役割分担に伴いこうした状況が多々発生する。
だが役10年、エンジニアを見てきた結果は変わらない。現実問題こうなのだ、こんな人間が大多数なのだ。
人の多い企業ほど考えたほうがいい、それでより良いものが生まれるのかと。
必要とされる技術だけを叩き込んで金にしたいと言うのは分からなくないが、基本姿勢や思想はどうなんだと。
経営者よマネージャーよ、あなた方の言う「最適化」とは現場が日々考え行っている最適化か？人員最適化だけを行って、生産性が伸び悩んでいないか？
そのあたりは考えた方がいい。
「ファイルまたはアセンブリ 'Microsoft.Web.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'、またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。 」
http://stackoverflow.com/questions/4742894/mvc3-deployment-dependency-problems
IIS を実行させているサーバの GAC に Microsoft.Web.Infrastructure.dll のアセンブリキャッシュが存在しないようです。
プロジェクト参照設定にある Microsoft.Web.Infrastructure のプロパティを開いて「ローカルコピー」を True に設定して、発行（デプロイ）しましょう。
その中でこんな部署に配属になったら自分のエンジニア人生が終わってしまう（テクニカルロックイン及び生涯収入的に）ので、会社を辞めるか別部署への再配属願いを出す。規模的には部署が 10 人以下ぐらいで。
この辺に当てはまるものがある部署はもうそれはエンジニア部署じゃなく、ただの SIer 上がりの口だけで何にもできない人間達だから近づかないほうが幸せだと思っている。
読んでもらえるかどうかわからないが，一応IDコールしてみる。＞ id:NOV1975氏
この記事，
という点において，「ウォーターフォールとアジャイルはどう違うのか」という問題が混然一体となって語られてて，ちょっとわかりにくい気がした。
そこで，この3つの論点について，自分なりの理解でアジャイルとウォーターフォールの違い（あるいは違わないこと）を書いてみる。
まず，OJTとOffJT(研修，勉強会等)の組み合わせで育てる，というレベルの話では，ウォーターフォールもアジャイルもあまり違いはない。
また，スキルの広げ方についても，ウォーターフォールとアジャイルであまり違いはないと思う。NOV1975氏は，
プログラミングって世界はわりと想像できるんですよね。もうちょっと大きいアーキテクチャの話とか、業務要件の落としこみの部分とかをどういうプロセスで身につけて成長していくんだろうか。
と書いているが，アジャイルでも，最初は既存のものの改修から始めてもらって，新機能の追加（ここで要件落としこみが入る），新プロダクトの設計（ここでアーキテクチャの話が入る），みたいに，徐々に範囲を広げていく感じだと思う。
ただアジャイルのチームでは，最初の「既存のものの改修」の段階から，運用の稼働を減らすことを意識し，テストやデプロイの自動化をしてもらうことになるはず。運用を意識する，という点では，運用系の機能追加（例：監視機能の強化）もやってもらうことになる。これをどこに入れるかは悩ましいけど，比較的初期段階で経験することが多いのでは。
手法レベルでは，アジャイルで特徴的なのは，OJTの手法としてwonodas氏の言うところのレビューやペア・プログラミングを重視している点ではないかと思う。このへんはwwolf氏のあげた「アプレンティスシップ・パターン」にもあるのではないかと思うが，職人と弟子の関係で，日頃の行動の中である種「背中を見せる」感じで（教えるというより）学ばせる感じになると思う。
これは（NOV1975氏自身が書いている通り）ウォーターフォールもアジャイルも変わらないと思う。顧客に提示する価格の中に教育も含まれることになる。
ここで重要なのは，アジャイルの場合教育は顧客にとっても価値が大きい点だと思う。なぜならアジャイルのチームは，システムを開発するだけでなく，運用も行うのが基本。運用の中で継続的に改造や機能追加を行うことで，顧客にとってのシステムの価値を高めていくのがアジャイルの真の意義。そういう活動を続けるために，教育に投資することは顧客にとっても価値があるはず。
話はそれるが，ここで少し面白いなと思ったのは，「属人性」の話。アジャイルのチームでは「属人性」を避ける文化があると思う。だがそれはチーム内の話であって，外から見ると同じチームに開発と運用を依頼することは，チームとしては「替え」がききにくくなる気がする。そのあたりを現状どう解決しているのかはちょっと興味がある。
これはもう，向いてない人はチームから出て行ってもらうのがお互いのため，というのがアジャイルのやり方だと思う。というかそもそもそういう人をできるだけ入れない。なぜならチームの文化が壊れるから。
正直，そういう人でもウォーターフォールだと活きる道がある，というNOV1975氏の考えには納得できないが，なんとか活かしたいという心情は理解できる。なので少し考えてみたけど，人手の作業が最後まで残りそうな QA (Quality Assurance) やマニュアル作成あたりに行ってもらうしかないのではないだろうか。個人的には，向いてない人が向いてない業界にいるのは本人のためにもならないとは思うけれど。
http://anond.hatelabo.jp/20160629082647
な～んかこういう話聞いてるとあまりに世界が違いすぎて胡散臭くなるんだよなぁ。
まず、上場企業なんか近寄ることもないからIRなんか出てないし
公開されてるコードなんてねぇよ。
GitHubなんてまず使ってねぇし、そもそもセキュリティ的にそういうの使えねぇし。
SVNどころかCVS使ってるとこも普通にあったよ。※しかも1年前とか。
デプロイも基本どこ行っても手動だしね。
やってることが良い悪いは置いといて違いすぎて全く参考にならないんだよね。
いままで3回転職したけど、うまく行ったこともあるし行かなかったこともある。いままではわりと気軽に転職先を決めてしまっていたのだけど、そろそろ慎重に行かないと後がないなという危機感を覚えたので、とりあえず今までのことを振り返って気をつけるポイントを書いてみようと思う。
これまで何をしてきたか、これから何をするつもりなのか、会社の強みは何なのか、今後考えられるリスクをどう捉えているのか。上場企業ならばIRという形で外向けに情報を発信しているので、それを読むのはかなり大事。
で、具体的に書いてなくてよくわからないところが絶対あるはずなので、それを面談で聞く。ピンと来なかったらその会社は駄目だ。
公開されているコードがなければリスクは跳ね上がる。もちろん公開していないすばらしい技術というのはあるのだけど、会社の評価という点では使えない。
GitHubに会社のアカウントがあれば分かりやすいが、それ以外でもがんばって探そう。OpenJDK, Ruby, LLVMなど大きなOSSプロジェクトのコミッタがいればちゃんとコミットをいくつか読もう。GitHubも個人リポジトリはなくても別のリポジトリにコミットしているかもしれない。
社長はエンジニアを信頼しているか。CTOがいる場合は、CTOと社長に信頼関係があるか。
技術は手段に過ぎない、ビジネスへのビジョンが大事。確かにその通り。ただしそれは、経営陣の技術者に対する信頼があればの話。
技術を目的にするな。確かにその通り。しかしいまどきSVNを使い続けていたりデプロイを手動でやっているのはさすがにヤバイ。ついでにOSSを利用することへの意見も聞いとけ。
もしそういうダメな状況を変えるために自分を雇うのだということであれば、上層部がそういう技術的なアップデートをどのくらい必要だと考えているかを聞くこと。社長が「エンジニアを君とあと何人か雇って、一年それに全力を注いでいいからバージョン管理やインフラなどの下回りを一新したい、既存の社員にも納得してもらう」というのであればいいかもしれない。権力のある人がそういう強い決意をもってないと改革は難しい。
この話は技術者ならば誰から聞いてもいい。もし面談の過程で技術者がでてこなければ、その会社は諦めよう。
ここでいうデザインは「サービス設計」のことね。デザイナー出身のマネージャーがいれば、その人と面談してデザインをどうやってしているかの具体的な流れを聞けると最高。あるいは、エンジニア・デザイナ・企画の三者がどうデザインに関わるかを聞くのでもいいかもしれない。
企画、デザイン、プロトタイピング、開発、リリース、改善、このサイクルを具体的に聞こう。直近の成功例と失敗例を聞けると最高にいい。
これは現役の技術者から聞こう。実際に自分が体験することになる日常になるのだから。
外注管理することになったらとにかく最悪だ。そうでなくても、君がもし生粋のエンジニアなら、外注にはなるべく関わらないほうが幸せだろうと思う。
以上。
"見出しでエンジニアと書いているのにプログラマの事しか書かれていない。それもソフトハウスへの転職。" という指摘をうけたのでタイトルだけ変えた。
昨今の宗教戦争アホくさい
でかいプロジェクトで、一度WFで始めたから仕様変更もできないし、完成するころには古臭いものになってる
WF最悪
みたいに定義して、細かくデプロイできるアジャイル最高、いやっほっー
みたいな論調あるけど
デプロイしたってことは、その時点で一度完成してるわけよね（実際に利用できなきゃ、通常デプロイって言わん）
WFでこれが出来ないとされているのは、「そのように定義されたから」で、それから外れると「アジャイル的に現場で改善された」とか、アジャイルに都合よく解釈されるわけ
んで、アジャイルでやっていく負の側面
等の部分については、完璧な人員が完璧な仕事をするか、柔軟な利用者が物凄く協力的か、そんな設定になっていて、「ない」ことになってる
「形として公開する」ことの怖さを、物凄く軽く扱ってる
基本しゃべってるのは、コンサルタントとかのいかにもな人らで、もうポジショントーク丸出しなんだけど（彼らは自分の提案で何かを変えなければならない人たちだからね）
前回、JSP？を軽く勉強したから今回は、フレームワークを導入した。
前回の教訓もあって、プロジェクトをimportしたあとプロジェクトのファセットから動的Webモジュールとして設定。
HTTPステータス 404 - /sa%dstruts%dtutorial/と文字化けっぽいエラー。
困った。。。
プロジェクトのファセットの隣にランタイムってやつを発見。Tomcatにチェックを入れてみたら
HTTPステータス 404 - /sa-dstruts-dtutorial/
文字化けが直った。
あとは、デプロイメントの記述子の設定を確認。ウェルカムページのweb.xmlが見当たらない…
プロジェクトの中にあるはずだけど、仕方ないから参照してるページにコピペ。
Javaってのは難しい言語だ。なんで環境設定こんな複雑なんだろう
プログラミング歴３ヶ月
Tomcat8では、managerページ開くのに
roles="manager-gui"の追加をしないといけない。
＞<user username="tomcat" password="" roles="manager-gui"/>
２．JavaのプロジェクトだけじゃWarをデプロイメントできない。
Jsp入門のページからプロジェクトを丸ごと持ってきた。しかしそれだけじゃデプロイメント出来ないらしい。
Eclipse→プロジェクトのプロパティ→プロジェクトのファセット→動的Webモジュールにチェックを入れないといけない。
デプロイメントに成功したのでプロジェクトのURIにアクセスしてみた。
[HTTPのGETメソッドは、このURLではサポートされていません。]
doGetというメソッドが無いとダメらしい。仕方ないのでそれっぽいのをコピって貼り付けてきた。
しかし先程のエラーは無くなったが、今度はJspファイルが無いらしい。
WEB-INF/直下に置いたのにindex.jspに遷移しない。
とりあえずわかったこと。Jspは難しく奥が深い。
※読みにくい、長い（そのため最後が切れてる）という指摘もいただいたので手直しします。
※長いのは元のnobiのが冗長なんですが、いらんところをバッサリきると、意図的とかも言われかねず。
----
長く書けるとこもないし、パブリックは増田にするということで、
-----
引用三行略
----------------------------------------
平日業務日の大事な時間、つつもいつも記者会見に遅刻してやってくるジャーナリストに奪われる、
他の報道関係者やアテンドする人の貴重な時間を連日削り取ってるのが貴方です。そんなあなたの大事な土曜日の時間を凌駕するほど、
----------------------------------------
お察しかもしれませんが、この投稿が共有されている人は「矢作晃」とある程度、交流がある方々です。※個人名落としました
【１．どう接するべきか（林案）】
子供を育てたことがある人ならわかると思いますが、ダダをこねる赤ん坊にいい顔をしてしまうと、子供のダダはひどくなるばかりです。おそらく最良の方法は無視する、あるいはちゃんと向き合って接する場合には「気をそらす」だと思います。
心をわずらっている彼が、最近、再び暴れているという知らせを何人かから受けて、彼のツイートやらFacebookの投稿、そこでのコメントのやりとりなどを観察しました（ブロックしているけれど、ブラウザのプライベートモードを使うとパブリックな投稿は読めるようです。まあ、そりゃ当然か...）。
自分の不幸のアピールは彼の天賦の才能なので、それを見て「かわいそう」、「何か言ってあげなきゃ」と思う同情心の気持ちはわかります。
でも、彼のことをこれから先、一生面倒をみる覚悟がないなら、そして本当に彼を思いやるなら、そこで突き放すことも大事だと思います。
人間は誰しも「人に認められたい」願望があります。彼は特にそれが強いと思います。
さらに自己肯定力はやたらと強いので、誰かがちょっとでも同調をしてしまうと「やはり、俺は正しいんだ」と、この24時間ほどの爆発を生んでしまうというのが私の見立てです。
----------
彼の見立てですから何も言うことはありません。このリストは、今の事件で彼が味方に付けたい、付けようとしているだけのリストです。自己顕示欲ねぇ、何かにつけて審査員とかやってる貴方は、いつもスペシャルアドバイザーとか、特別審査員とか、一般ではなく何か特別な枠におさまり(言い換えれば、その内容の責任を一切とらない安全なポジションを確保しながら、自己顕示欲をだしてますね。
----------
同情のコメントがなくても、おそらく愚痴ツイートは続いていたでしょう。
でも、ここまで増長することはなかったと思います。
「それでも彼のことが心配だ。何かしたい」という人はいるでしょう。
そういう人への私のオススメは、他の関連のない話題に彼を誘導することです
彼が好きなアニメやマンガが好きで、そこいら辺の話が得意な人は、その話で盛り上がるのもいいでしょう。
----------
かれにとっての、アニメや漫画へのスタンスが垣間見れる記述です。ただ、こういう人に限って、何も知らない、何もできないくせに、Cool Japanとか言い出しやすいのが特徴です。
村上隆だいすきですね。個人の意見としては、村上隆はその骨頂で、これまで日本のオタク文化に貢献してきた無名クリエイターをパクリ、商業主義に貶めるというのが私の認識です。
アートとは事腹痛い。そんなこ言うなら、村上隆のアートって、90年代は美少女変形戦闘機の突端に、女性器をリアルに写実的に描写してたのはご存じですよね。
----------
（この記事の末尾に参考になりそうなうつ病対策のページのリンクを貼っておきました）
「彼の原稿が好き」と本心で思っているのなら、それを書くことについて、私がとやかく言う権利はありません。
ただ、彼のことを本当に思うなら、もう少し経ってから、過去形で「好きだった」と書いた方がいいのではないかと思います。
【２．なぜ「過去形」なのか？】
彼が言っている通り、彼のIT関係の執筆の仕事は終わりだと思っています。
ただ、今終わったのではなく、とっくの昔に終わっていたと、私は見ています。
私は彼とは付き合いが古く、同情心や心配さからMacPeopleに彼の連載を提案していたこともありました。「とりあえずお試しで」と特集記事を振った結果、彼は逃亡し、音信不通になり、結局、連絡こずで、私とその編集者で全部を丸かぶりして死ぬ思いをしたこともあります。
その後も、何度か彼に仕事を与えようと、面白い製品発表の声かけを彼にも回したり、自分で企画した重要なイベントに彼を呼んだこともあれば、面白いネタを持っている広報会社の人を紹介したこともそれこそ何度もあります。ムーンライトウェーブの望月さんなどもその一人ですよね。
望月さんなどは本当に彼によくしてくれていると思います。でも、おそらく、彼が呼ばれたイベントを記事にしたことはほとんどないと思います（と、ここは私もまったく人のことは言えないのですが…苦笑）
編集者などにつなごうと呼んだパーティーも隅で昔からの知り合いと話をするばかりで（性格的に無理か、と途中から諦めました）。
ここで聞きたいのですが、そもそも、この中で、誰か彼がここ１〜2年で書いた記事を読んだ人、いらっしゃいますか？
もしかしたら、よく検索すればインプレスかどこかで見つかるのかもしれませんが、彼の最近のPublicへの露出で私が知っているのは有名な彼のツイッターと、あとは Kohichi Aoki と 松尾 公也さんのPodcastくらいです（他に本当にあるのでしょうか？）
------
矢作は終わったそうです。原稿も書いていません？●矢作の反論。および解説
原稿は2015年も、2014年も2016年も書いてます。あなたが見に来ないだけです。当たり前ですよ、ブロックしてるんですもん。仮に俺が「書きましたー言っても」知らないんですよね。
「そんな中、今回、彼が（これまでなんで招待されていたのか不明だけれど、記事は書いていたんだろうか？）」 への証拠と回答です。これだけでも、名誉毀損は成立します。
http://pc.watch.impress.co.jp/ba…/event/index_c105s3385.html
http://pc.watch.impress.co.jp/ba…/event/index_c105s2964.html
http://pc.watch.impress.co.jp/ba…/event/index_c105s2626.html
http://pc.watch.impress.co.jp/backno/event/index2012.html
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
http://pc.watch.impress.co.jp/…/feature/20150613_706743.html
http://pc.watch.impress.co.jp/…/kaimono/20150613_706753.html
7月になってからは、WWDCで発表されたEl Capitanにフォーカスして、El Capitanカウントダウンとして、15週間ぐらい毎月記事を書いてきた。
http://pc.watch.impress.co.jp/…/elcapi…/20150821_717281.html
わずかばかりですがWWDCを切り口に、2015年にわずかばかりばかり書いてるのに、ここ１,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ジャーナリスト業だか、ライター業はとっくに終わっていたんじゃないでしょうか（彼が認めたくないだけで）。
そこにまんまとアップルさんが、まるでアップルのせいで廃業したかのように見せたと愚痴る口実を与えてしまったのが今回の事件の全貌だと思います。
----
よっぽど私が邪魔なことが、言葉の端はしから●矢作の反論、そして解説
私がベルリンで、某氏をなぐったのは事実ですよ。この件について事実の否定はしません。中傷文のなかで、俺が誰かを殴った(とか書いてますが）事情も知らずに勝手な１事象で書くのはやめてほしい。背景には過去2年近くに及ぶ陰湿な無視行為が存在していたので、我慢の限界を超えただけの話。今回も同じですよ、積年にわたる恩着せがましさと、nobiの影での中傷（非中傷文）。ちなみに警察沙汰と言いますが、殴ったこと自体については警察は一切無関係です。ホテル入り口で、でてきたらもう一発食らわすつもりで待っていたら、ホテルから一歩敷地より出てほしいと言われましたが、敷地ギリギリでとどまり、押し問答になったので、私からドイツ警察を読んでもらい。警察のクルマに載せられる形で排除されました。現地でも調書は一枚。後日、調書を取った旨、敷地内に許可無く立ち入ったが不問、という紙ペラ一枚が国際郵便で届きました。あ、被害を受けたその人に同情してみせても無駄ですよ、その人、nobiが嫌いですwwwww
干されたという件も明確にしておきます。これはPC部門の決定なのでそれに従いました。
しかし、2016にはK-tai Watchで記事を書かせて頂き、まあこのままでは流れるでしょうが、2016のWWDCもPC Watchへと寄稿を打診し、その編集部から了承は得ています
もう一点、「もしかしたら、週刊アスキーが、獲物のいない猟場、食料のない餌場に、ノラ猫の餌をまいているのかもしれません（が最近、読んでないのでわかりません）。」
このセンテンスは、今、アスキーで原稿を書いている仕事をしている人に対する侮辱です。
-----
インプレスに干されてからなのかは、彼の記事は検索しても出てこないくらいに発見が難しいです。ツイッターでもフォロワーは、そこらの大学生以下くらいですよね。 マスメディアならぬ、ナノメディアに近いのですが、地上波のテレビでも取れない席が自分に与えられなかったと言って彼は愚痴ります。
それくらいに存在感のない記事、読者も求めていない記事、編集者もお情けで仕事を与えて手間が増えただけでもしかしたら迷惑かもしれない記事。
それでも「かわいそうだから何か仕事を与えなきゃ」という不健全な負の連鎖、いつまでもつづけられるわけがないですよね？
そもそも、あの見苦しいツイートの主の記事を載せるなんてメディアのブランド戦略としてもどうなんでしょう。
彼がこの先も「ITジャーナリズムの最先端をつっ走って」まだまだこれからかなり遠い先までどんどん走り続けられると本気で信じている人は、ここにいらっしゃいますか？
このあと、書きますが、彼は自己肯定力だけは強いので、走らせる距離が長いほど、崖の高いところにまで登っていきます。
今、ここで彼に同情して、もっと先にいけるよ的な声をかけてもっと高いところから堕ちさせるのは、本当に彼にとって良いことでしょうか？
だから、無責任に彼に自信を与えるのはやめてほしいと、私は思っています。
自分の人生の大事な時間を彼のために割くのは、時間と脳の無駄遣いなので、私は今回の件を本当に最後にしたいです。
------
さっき、ご指定のインプレスの Watch Headlineから、矢作でエゴサーチしたら1570ありました。
くり返し検索してもでてこないのは、貴方の検索能力が低く、あるいは見たくないモノに対して盲目になっているだけです。
前述の通り、2016年、2015年の記事も存在します。WWWDCまでに向けては、これまでもさまざまな仕込みも進行させていました。
自分の目が腐っている。ネットに書いてることも読めないという、根本的な勘違いを枕にしたうえで、お情けで仕事を与えて手間を増やすとか、侮辱も甚だしいです。
見苦しいツイートの部分はそのとおりだと思います。自覚しています。
編集者の手をわずらわすと言いますが、納品後からの作業においては、日本語の起承転結や、そもそも日本語を理解してない貴方の原稿より、
私の記事の方がデプロイされるまでに格段に必要とする時間は短いです。まあ、自覚ないんでしょうけど。
----
【３．自己肯定力】
ここがくどくて長いので、もう原典をあたってください。
-----
鬱とそれにともなう心身の不都合については、心療内科の主治医にかかっており、決められた日時に診察、カウンセリングを行って、日常的な生活が少しでも出来るよう、不眠を減らすよう、ストレスをためないようアドバイスをうけ、ずっと付き合っています。言うまでもなく、時間はかかりますが、長い将来には服薬やカウンセリングの必要のない生活へと戻りたいと思います。
---
1年の間、プログラマとして働いていたが、続けていくことが無理だと思い、さようならする話。
プログラマになる前は、コーヒー屋で働いていた。しかし、色々とあり辞め、職業訓練校に通ってプログラミング(php)を学び、60人ほどのソフトウェア開発会社に就職した。
会社に入ると、まずC#の研修があった。研修と言っても、C#で内製ツールを独りで作るという研修だった。この研修中に「あれ、オレ、プログラム書けねー」と思ったりしたが、研修は終えることができたし、社内の人にも「なかなか良く出来ている」と言ってもらえ、大丈夫だろうと思っていた。
研修が終わり、C#の社内で実際に使われているツールに、機能をいくつか追加する仕事を振られた。前任者にどんな設計になっているのか大雑把に聞き、なんとなくイメージができ、コードを読み始めたのだが、これが全く意味不明で、何のために有るかがわからないクラスが大量にあった。名詞の王国だと思った。前任者に、何故このクラスは、この単位で分割されているのか聞くと、「単一責任の原則だよ」とか「hogeパターン使うと、後から機能追加しやすいじゃん」というような回答をもらった。納得は出来なかったが、プルリクも承認されて、このツールがデプロイされていたので、社内的にも、このコードは、クソコードと言われる物では無いはずだと思ったので、自分もプログラムを書き続けていれば、こんな感じの設計に慣れてくるんだろうと思った。モヤモヤは残っていたものの、仕事はしなければいけないので、前任者のコードに習うように、クラスを追加したりして、機能を追加した。プルリクを出すと、設計には何も言われずに、タイポや、テストコードを注意されただけだった。指摘された点を修正すると承認された。振られた仕事は完遂した。が、結局最後まで、モヤモヤは消えなかった。むしろ、モヤモヤモヤモヤになった。
次に振られた仕事は、内製ツールを設計から自分で行い作成する仕事だった。言語はGoだった。Goで書いてと言われた時は、以前からの自分のモヤモヤはオブジェクト指向のせいで、モヤモヤしているんじゃないかとも思っていたので、喜んで！という感じであった。が、Goを触ってみると、結局、Goも継承の無いオブジェクト指向言語やないかと思った。Goの標準ライブラリのinterface名もHogerみたいな感じに接尾辞に-erを持ってくることが慣習らしく、この命名だと、interfaceを満たす構造体自身が-erになるので、正にオブジェクトだなぁと思った。巷での「Goはオブジェクト指向ではない」というのに期待していたのだが、自分にとっては、とてもオブジェクトしていました。
Goに対する印象は良くなくなったが、ツールの設計をしないといけなかったので、Goの構造体をC#のクラスに見立て、前回の前任者のコードのように、単一責任も持つ構造体に(無駄に)分けて、プログラムを書いて、プルリクを出した。自分でクソなコードだと思いながら。だけれどもレビューでは、「errorのチェック忘れ」「標準ライブラリにこの機能ある」「こんな風に書ける」といった感じだった。こんなコードで良いんかよと思ったが、良いらしい。ワケワカメだった。
ここらで、プログラムを書く仕事は、無理だと悟った。現実世界は、自分が自然だと思う方法と違う方法で、プログラミングをすることを強要してくる。
ちなみに、仕事ではC#とGoを書いていましたが、オブジェクト指向と仲良くなるためにSqueak(Smalltalk)で、オレオレ言語を作ってみたりもしましたが、何が嬉しくて、オブジェクト同士のメッセージパッシングでプログラムを作るのかわかりませんでした。
Clojureは、気持ち良くプログラムを書いていても、Javaが顔を出すところでフラストレーションが溜まってしまって、つらくなりました。
Common Lispは、自分が触った言語の中でも、秀でて良いと思いました。プログラマを辞めても、プログラム書く必要に迫られたらCommon Lispで書こうと思うくらいにです。Land of Lispが楽しいです。あと、CLOSの総称関数の考え方が大好きです。
最後に、この投稿は、一種の決別の表明です。いつまでも、自分に向いていなかったことに、時間を掛けてしまっている自分との決別です。
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にまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
普段は自社サービスでRailsエンジニアやっていて、コードを書いていることが多いのだけどたまにミドルウェアも設定ファイルをいじっている。
今に至るまでに、プライベートでRailsアプリを書いてVPSを借りてcapistranoでデプロイする、というのを3サイトほど行ってRailsはもういいかなって感じがしてる。AWS童貞なのだけど高くて個人では手が出せません。
js、coffee終了な匂いするしちょっと近くに寄りたくない気分。
Linuxサーバについてはもっと知見を深めたいとは思っていて、とりあえず今は http://www.usupi.org/sysad/backno.html を順番に読んでなるほどって感じ。これを読み終わったら何がいいのか。
