  |
はてなキーワード: システム開発とは
SMAP解散という衝撃のニュース。だが、多くの人は今年の初めに流れたニュースを思い出して、ある疑問を抱いているのではないだろうか？
SMAP解散を回避するため、木村拓哉がタイムリープを繰り返している――いくつもの動かしがたい証拠とともに提示された、木村拓哉が時空を超えているという説。木村は今も解散を止めるため、タイムリープを重ねているのではないか？ SMAPは結局解散を避けられるのではないか？
結論から言おう。木村拓哉はもうタイムリープを行うわけにはいかない。我々の時空の物理法則は、彼が自在に時を駆け巡ることを許していない。彼の幾たびものタイムリープは、すでに我々の時空間に大きなゆがみをもたらしている。いくつもの並行宇宙が混じり合う事態が、すでに起きている。
そのことを指し示す記事を、いくつか適当にピックアップしてみた。
1.は、我々とは異なる世界線で書かれた記事であろう。数多のトラブルと問題が山積みだと噂されるみずほ銀行のシステム開発。それが予定通りに進んでいる――これが異次元でなくて何であろうか。
2.も同様。これは文字通り、鳥越氏が大健闘した世界の記事である。記事には得票順位が明示されていないが、もしかしたら鳥越氏が増田氏を制して次点に食い込んだ世界かもしれない。共産党がつねづね主張しているように、彼らの認知が歪んでいるのではない――彼らを取り巻く世界が歪んでいるのだ。
3.もかなり衝撃的な記事である。ここに紹介されている写真を見てほしい。被写体をとりまく空間が奇妙な歪曲を起こしていることがうかがえる。我々の宇宙そのものが危機に瀕しているのだ。
4.の記事が暗示する事態は深刻だ。我々のなじみ深いキャラクターが、若干異なるデザインと設定のものになっている。そんな異世界の住人が、この世界に迷い込んでいることを示している。
こうした事実を踏まえて、SMAP解散に関する木村拓哉のコメントをもう一度読み返してみよう。
「正直なところ本当に無念です」
……これは他のメンバーを責める言葉と解釈されて、木村が非難される一因となっているが、もちろんそのような心情によるものではない。幾たびもタイムリープを重ねながらSMAP解散を阻止できなかった、そして図らずもこの宇宙に危機をもたらしてしまった、自身の無力さを吐露しているのだ。
WEBシステム開発してるんだけど、ローカル環境にホスト名登録して、手打ちでアクセスする。
site.hoge.local
みたいな感じ。
だけど、Windows の Chrome はそれを検索しちゃうんだよな。
にアクセスしてほしい
site.hoge.local/
みたいに末尾に / をつけることで http://site.hoge.local にアクセスしてくれるんだけど、
例えば自分がいま開発している画面にアクセスしたいときも同じ感じになるので面倒くさい
site.hoge.local/feature
だとダメ
site.hoge.local/feature/
にする。
全部仕事だった。この３日の間に遅れているスケジュールを回復させようと毎日１６時間労働だった。
ＩＴ屋、ＳＩ屋に勤めて１０年近くがすぎた。慣れてしまってはいけないのだが、もうあきらめてしまった。職場から見えるビルの建築現場は日、月と休みだった。毎日日没後には誰も働いていない。私の仕事とは、会議のない日没後が本番だ。
２０万人月案件のひくまでもない。この惨状が常に続いているのは、どこでも発生しているのは、法規制がまったくされていないからだ。不動産屋なら受付に免状がかけられているように、納涼も知識もない人間が大勢アサインされている。２０万人月というのは、相応の能力を持った人間がよってたかってやっと達成できる作業量なのだが、単純に２０万人月あつめれば完成するように思われていないだろうか。オラクル、エムセス、レッドハット、シスコ、ほかいろいろ。企業の発行している認定失格ではなくて、法が定めた資格がないのが問題なのだ。座っているから死なないと思われていないだろうか。
http://www.itmedia.co.jp/smartjapan/articles/1606/13/news026.html
http://www.itmedia.co.jp/smartjapan/articles/1605/23/news085.html
http://www.itmedia.co.jp/smartjapan/articles/1606/20/news086.html
http://www.itmedia.co.jp/smartjapan/articles/1606/27/news086.html
web系エンジニアはSIerのやっている大規模システム開発について、上から目線でドヤ顔しながら意見しないほうがいいよ。
とくに若くてweb開発しかしたことない人ね。注意したほうがいいよ。
web系企業でつくるアプリってSIerの作る大規模システムと比較すると単純すぎるのよ。
web系のアプリってドメイン(システム化対象領域)が単純だから、まず複雑なデータフローが発生しない。サブシステム分割も考えなくていい。
それに誰もが理解しやすいドメインだから、だれでも各工程のレビューで問題点を指摘できる。
でもドメインが相当専門的に勉強しなきゃいけないような領域では、ただ世渡りがうまいだけの人や、流行技術に群がるファンボーイでは問題を発見することも把握することもできないでしょ。
web系を開発するのと同じような態度でいたら、実装する機能の意味を理解できないかもしれないよ。
web系はドメインが単純だから、変にビジネス志向だったり、流行技術志向だったり、SE職を軽んじてたり、総合テストといいながら個別に画面をポチポチさわるだけだったりする。
だけどエンプラ系はもちっと難しいのよ。
エンプラ系開発プロジェクトは大抵クソだけど、クソを取り除いたらチンカスしか残らない気もするけど、そこんところは認めてやってよね。
そもそもみずほ銀行の前身は、第一勧業銀行・富士銀行・日本興業銀行の合併あたりから始まってるわけです。
合併はしたもののこいつらは仲が良くなくて、社内でどこの銀行出身がリーダーとるかで血みどろの社内政治闘争が繰り広げられてます。それを反映して、社内の電算システムも、キメラ合体させ田つぎはぎのを使ってます。どの派閥も譲らなかったせいです。当然、死ぬほど古いプログラムを切り貼りして継ぎ合わせて使ってるので、もう誰も全体像はつかめないし改造するのも難しい状況ですし、触らぬ神に祟りなしみたいな状態でした。
記憶している人もいるかと思いますが、東日本大震災直後の2011年3月にみずほ銀行の子の電算システムは大規模な障害を起こしてます。8000億円規模の決済遅延を起こして、預金者に不便をかけました。当然金融庁の調査とかも入ってるんですが、その結果として「組織の上層部が派閥闘争しすぎで、仲悪すぎて、現場も混乱してひどい騒ぎです、いい加減にせえよ」といわれます（勧告というのを受けちゃいました）。金融庁にここまで言われるなんてよっぽどです。ゴイスー。
当然みずほ銀行は、この勧告に対して対応する責任があるわけでして、いくつかの対応策を発表したわけですが、その対応策のひとつが「サーバシステム全面刷新」でした。それぞれの出身銀行が持ち寄った古く非効率な電算システムを捨てて、新しいみずほ銀行としてみんなで仲良く効率的で顧客に安心感を与えるちゃんとしたシステムを作るぞー！ だから今回の不祥事はごめんなさいしてね。そういう発表でした。カシコイ！
まあ、しかし、今まで派閥闘争してたひとは１ｍｍも反省してないので、新しいシステム開発などできるわけもないのでした。そもそも、業務の要件をまともに定義できる人もいないのです。というのも、いくつもの派閥が自分たちに都合のいいような仕様を押し付けようとするからです。というか、もはや都合がいいとか悪いではなく、敵対派閥が進めようとした作業の妨害をしたり、仕様変更したりするのが、社内での出世ゲームになっていたのでした。コワイネ。
4000億円かかってしまったのは、結局作業が長引いたからです。2011年から5年もやっていたわけですからそれも仕方ないのです。もっと早めに見切りをつければ傷口は小さくできたでしょうし、経済的合理性だけでいうのならばそれが正しいのでしょうが、前述したように金融庁勧告にたいする責任として始まったプロジェクトですので「できませんでした」じゃすまないわけです。再発防止の努力してないという話になるわけでして、その批判をかわすために今まで無駄予算をダバダバ垂れ流してました。まあ、ぶっちゃけ、銀行は去年まで過去最高益とかでしたんで、4000億垂れ流したとしても、別に経営者の報酬減ったり、行員の給料減ったりしないです（預金者の利子とかは減りますが）。つまり何の問題もありません。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
「ダメなアルゴリズムで書かれたコードは、いくらでも捨てて書き直せる。しかしデータ構造に問題があった場合、プログラム全体の書き直しに発展してしまう」
この話と微妙にカブるようでカブっていないが、言い方だけ真似たものとして
「クソな下請けはいくらでも代わりを探せる。しかし元請けの回し方がダメだったら全員でデスマ確定」
という話もある。これまた開発経験者ならよくご存知だろう。
すなわち、最低でも年収500以上は確実に貰っているであろう、エリート様揃いのITゼネコンの中にも、一握りの、まさに一軍というべきデキる人達と、そうじゃない人達がいると。
そして一軍と二軍以下では、マネージメントにおいて天国と地獄くらいの差が出るのだから恐ろしい。
というかなんでそれだけの年収に見合う学歴がある人達なのに、デキる人が一軍扱いされるほど少数なんだよ、意味わかんねえ。
学歴というのは、努力の仕方、効率の見極め方についての上手い下手の最も分かりやすい数値だと個人的には思っている。
そうなれば当然高学歴は、システム開発という極めつけの頭脳労働で、そのパフォーマンスを遺憾なく発揮し、協力会社含めて皆をハッピーにするのだろう…そう、一軍ならね。って、全員じゃねーのかよ！
具体的にはこうだ。
良い方から説明すると、一軍のマネージメントは要件定義から寸分の隙もない。
顧客の経営戦略に基づいた要望を良く理解し、仕様に取り込んでいることは勿論、システム間通信のような、後でとんでもない話が発覚して色々揉めそうな部分も、既にこの段階において顧客の協力を取り付け、キッチリまとめていたりする。
とにかく裏で細かく調査していたことが見て取れて、仕事したんだね～という感じである。
それから設計に取り掛かるのだが、やはり要件定義の段階で「どうしても見えない部分」はあって、下請け以下が作業の過程で洗い出した結果、それが時にはリスケを招く事故になることがある。
しかし一軍の人らは、本来最後の手段であるリスケにも比較的前向きで、それについての顧客説明もしっかりしているのだろう、大して揉めること無く妥当な落とし所にたどり着くのだ。
また、下請けのグループ(≒サブシステム単位)に必ず1人以上プロパーを配置し、現場感の吸い上げと「同じ釜の飯を食ってる」感の醸成にも抜かりない。
それもあって、現場でよくありがちな「あの人ら(元請け)何も分かってない」という陰口は最小限になる。
強引にまとめるなら、リスクが常に頭にあって、かつその取り方について常に考えを巡らしている。「かもしれない」運転をしつつ、逃げ腰にならない姿勢は見事である。
そして、二軍以下は上述の一軍の振る舞いが全くできない。本当に全部できていないのだ。
要件定義は客の要望を汲み取る所から既に漏れ漏れ、当然後ろの工程で揉めそうな部分は一切見ていない。
設計の大元、ひいてはシステムの大元になる部分がこれだけ不完全だと、その時点でデスマ化・炎上は約束されたようなものである。
その後に起こる事態は、もはやここに詳しく書くまでもない。
穴だらけの要件定義を、場当たり的に客に相談しながら埋めていく作業が設計のお仕事になり、それが相次ぐ仕様変更を呼ぶ。
結果どこまでExcelやソースコードをいじっても作業量が減らない、いやむしろ増える。しかも成果物が増えてくる各フェーズの終わりが近づくほど、「横展開」という名目で作業量が爆発的に増大するのだから始末が悪い。
各成果物を直しきれず「修正漏れ」という事故を仕込むことも頻発し、それに伴い品質も凄まじい勢いで低下する。
それでもケツは絶対に動かない。それどころか人員の追加すら出来ない元請けもいる。お前ら見積もりドンブリ過ぎだろ。
現場では脱落者が日常的に出る。でも下請けチームにプロパーが1人もおらず、そうした危機的な現場感が上に届かない。それも合わさって「あの人ら何も分かってない」という愚痴が漏れ聞こえるようになるのだ。
こんな体たらくじゃテストに漕ぎ着けるなんて夢のまた夢だし、仮にどうにか辿り着いても、何がどう動けばいいの？ってレベルでグダグダだったり。
いやもう、マジで元請けの人らは何やってんの？という感じ。優秀な人が何十人もいるのに機能していないとか、なんでそんなことになるんだか。
http://news.yahoo.co.jp/feature/188
この記事のブクマで「さっさと辞めなよ」というブコメが付き、その通りだとは思うけれど…
私はWebシステム開発会社で、多い残業、強いストレスによる通院と体調を悪化させていました。
周囲に相談すると「早く辞めたほうがいいよ」とよくアドバイスされました。
しかしながら、今から思えばこのタイミングでの退職は失敗でした、なぜ失敗と思うのか。
休養が欲しいなら休職という手段が手軽です。当時の私も考えましたが、とにかく環境を変えたいと退職を決意しました
しかしこの休職しないという選択肢は、職歴の短さ・準備期間の不足による履歴書の空白期間の増加という悪影響を及ぼしました。
現在転職しましたが、労働時間こそ前職より少ないものの、ピリピリとした雰囲気の悪い会社に務めることになりました。
以前の労働期間中、メンタルクリニックに通院しており、うつという診断が下されました。
現在も処方された薬を飲みながら生活しているのですが、前職を辞めてからの就職活動中に
なにか役立つことがあるかもしれないと、ネットで見つけたメンタルヘルスの支援イベントに参加しました
そこでは私のような「うつ」は戦闘力5のゴミ程度なもので、医師からキッチリ診断書を貰い入院するのが基本
お金や就労の面から見て、手帳はそれほど役立つものではないよと言われましたが、やはりそれがあると無いとでは大違いでしょう。
区役所に相談に行った際も私のような、診断は受けているが自力で通院できて一応働ける人は全くの蚊帳の外でした。
建物が地震で半壊したときには誰も見ていないうちに全壊にしておけ、というのは社会人にも当てはまりそうです。
今働いていて、生活保護よりは多いお金を貰えていますし、働けているので障害年金の受給も絶望的と言われました。
退職から一年が経過し、新しい職場（WEBベンチャー企業）での仕事に慣れたこと、
また、富士通の同期入社の友人から頻繁に転職の相談を受けるようになったこともあり、本エントリを執筆する。
はじめに、筆者の退職理由を簡単に述べると、富士通という会社に未来を感じなかったことと、やりたい仕事はできないだろうと判断したためである。
参考までに、筆者は公共機関向けのシステム開発部門に所属していた。
担当していた業務は様々で、小規模なシステム開発や、子会社・下請企業の管理であった。
富士通には、人材キャリアフレームワークという社員評価制度があり、現場には、入社何年目はこのレベルの仕事、といった暗黙の了解がある。
本人の能力や意欲とは全く無関係に、入社後の経過年数で、仕事の裁量の幅が大きく制限される。
このことはいわば、学習指導要領ならぬ、業務指導要領があるようなものだ。
このような枠組みや暗黙の了解が存在すること自体が問題なのではなく、その枠組から逸脱した人材を想定しない・評価しないことが問題なのである。
筆者がお世話になった優秀な先輩方は、この業務指導要領の要件を満たして手に余った人、
いわば天井にぶつかった人から先に、より大きな仕事がしたいという理由で辞めていった。
筆者もその一人である。
既存産業の大きな成長が望めなく、社員個々の多様性が重要視される昨今の経済情勢において、
高度成長期における横並び思想をもとの作られたやり方が未だに社内を謳歌しているのは時代錯誤というほかない。
富士通への提言として、これからの時代は、年齢も在籍年数も関係ない人材評価制度を作っていくべきである。
そして重要なのは、会社の既存事業でいかに利益を上げたかについての評価ウェイトを下げ、
いかに新しい発想で新しい事業を提案したか・実現したかという評価項目を設立するべきである。
なお、富士通には社内ベンチャー制度があるが、これはうまくいかない可能性が高い。
なぜなら、社内ベンチャーを承認するのは旧式の人材の典型例である高齢な経営層であるからだ。
いままで数十の社内ベンチャーの審査結果を見てきたが、彼ら経営層に事業の将来性を判断する能力はないと痛感した。
また、他の理由としては、富士通の既存事業と衝突すると社内ベンチャーが潰されるということがある。
将来性のない既存事業を残して、将来を託すべき社内ベンチャーを潰すという企業風土なのだ。
富士通という会社には多数の既得権益集団がいる。そして、社内のルールは彼らが決して不利にならないように作られている。
なぜなら、ルールを作る権限は、先頭を走る集団、1980年代に大成功を収めた既得権益層がガッチリ握っているからだ。
いわば、前を走る人を抜かしてはいけないレースのようなものだ。
このような出来レースで若手社員のモチベーションが続くはずはないことは明らかだ。
筆者は、決して年功序列主義を批判したいのではない。
既得権益層が年功序列を悪用して、部下の手柄を自分の手柄にし、部下の失敗を部下に押し付けている実態に対する批判である。
ノブレスオブリージュ、権利を有するものには義務がある、という思想がある。
富士通の既得権益集団には会社の技術力や社員を率先することで、企業としての地位を向上させていく義務がある。
実態は、社内の後進に抜かされることを恐れるあまり、後進の他社に抜かされている。
ちなみに、この既得権益集団に有利なルールが生み出した現状については、
同じく富士通OBである城繁幸氏の著書「若者はなぜ３年で辞めるのか？」（光文社新書）が詳しい。
経営学において「ヴィジョナリーカンパニー」という名著がある。
この本によると、会社が永続的に成長・発展していくためには企業理念（ビジョン）を社員ひとりひとりが持つことが必要不可欠であると指摘している。
富士通の企業理念は、変革に挑戦し続ける姿勢や、よりよいICT社会づくりに貢献することを掲げている。
しかし、富士通という会社の現状として、このヴィジョンを失っている社員、とくに管理職がとても多い。
30代を過ぎて会社に定住することを決めた社員に変革に挑戦しようという熱意ある人物はひとりもいなかった、
そういう人々にとってICTで社会づくりなどどうでもいいのだ。
ただ顧客の要求を聞いて、それを子会社や下請けに作らせて予算や利益を達成することにしか興味がない管理職が大半であった。
元GEのCEOであるジャック・ウェルチ氏は、たとえ成果を出していようと企業ビジョンを共有しないものはクビにしろと自著で語っている。
このポリシーを導入したら、富士通の管理職の80%はクビになるであろう。そのくらいに富士通の管理職は夢や熱意のない人物ばかりであった。
そのような人材が将来的に会社を破壊する、というウェルチ氏の指摘の正当性を、富士通という会社の惨状が示しているのは皮肉という他ない。
富士通への提言として、ウェルチ氏のやり方を実行すればよいのだ。
成果によって管理職のクビを決めるのではなく、ヴィジョンを共有できているかでクビを決めるのだ。
このやり方を実行すると既得権益を握って離さない経営層や管理職が一掃される。
既得権益にしがみつくだけの人物こそ、ヴィジョンを持たない人物である割合がとても多かったことを付け加えておく。
経営コンサルタントの大前研一氏は、日本の生産性がアメリカの半分しかなく、もはや発展途上国にすら負けていると指摘している。
その原因について、日本では業務標準化が全く進んでいないためであると述べている。
自分の住む自治体と異なる自治体のマイナンバーのITシステムを比較してみてほしい。
ここで、自治体が異なればITシステムも異なることに気づくはずである。
はたして自治体ごとに個別のマイナンバーシステムを作る必要があるのだろうか？
答えはもちろんノーである。全国どこでも一律の業務であるべきであり、同じITシステムを導入するべきである。
自治体ごとに業務フローが異なるために、別のITシステムを使用した時に業務がこなせないという事態が発生する。
そのため各自治体が個別にITシステムをITベンダーに発注することになる。
そこでITベンダーは各自治体ごとに個別のITシステムを作ることになる。
ITベンダー側からすると一度作ったことがあるものをカスタマイズして、業務の順番を入れ替えたり、扱うデータを多少変更するだけで済む。
それなのに膨大な金額を請求するわけだ、ITベンダーとしてはボロ儲けである。
（なお、主要ITベンダー決算書を見ていただくとわかるが、ITベンダーの利益率が高いわけではない）
特に自治体のITシステムは国民の税金で作られているわけである。
各自治体は、このような現状を放置していて、国民に申し訳ないと思わないのであろうか？
このことは、決してITベンダーにのみ責任があるわけではない。
総務省が陣頭指揮をとって各自治体の業務標準化・統一化を進めなくてはいけないのに、それが全くなされていないのは監督官庁としての責任放棄である。
このように業務標準化が全く進んでいない現状は自治体に限らず、民間企業においても同様である。
会計パッケージにおいて、世界のデファクトスタンダードになりつつあるSAP導入に失敗する事例を数多く見てきた。
失敗する理由は、個々の企業の業務に合わせてSAPをカスタマイズしており、そのカスタマイズでは対応できない業務フローが存在するからである。
問題なのは、そのような業務フローは、決して必然的な業務ではなく、過去の慣習から存在しているだけであることがとても多い。
ここにおいて、ITシステムが業務に合わせるのではなく、ITシステムに合わせて業務の方を変えていかなくてはいけないのだ。
このことは、サービス・流通業の顧客からSAPのカスタマイズで無理難題があがってくることが特に多いことと無関係ではないであろう。
富士通は、既存顧客の業務標準化およびデファクト・スタンダードとなるITシステムの開発の陣頭指揮をとる役割を果たすべきだが、その望みは期待できない。
なぜなら関係が深い企業において、業務が効率化すると大量の社内失業者を出すことになるからだ。
そのような"顧客との良い関係"を崩すようなことはやらない会社である。
日本という国のあるべき姿を長期的に考えた際に必然的なことであるにもかかわらずである。
富士通の企業理念である、よりよい社会づくりに貢献するとは、まさにこの業務標準化を推し進めることなのではないのか。
富士通には外国籍の社員が相当数在籍している。しかし、彼らに求められる日本人への"帰化圧力"がとても強い。
同期入社の中国籍の友人は、対外発表会のために完璧な日本語の発音の練習をさせられていた。
完璧な日本語の発音は日本人に任せるべきで、中国に精通しているというメリットを活かせる部署に配置転換するべきである。
なお、残った外国籍社員をみると、小学生から日本にいるなど、生まれたのが海外というだけのほぼ日本人だったりする。
外国籍社員の離職率が高いことに対して、本部長が提示した対策が、
長く働きたい会社とはどのような会社か、というテーマで外国籍社員を集めランチタイムにディスカッションさせるというものだった。
この席で「無能な人が本部長にならない会社で長く働きたい」という大喜利でもすればいいのだろうか。
富士通はグローバル企業を表明しているが、このような組織で海外進出などできるはずもない。
なぜならば富士通の利益構造では、海外において利益を上げられないからだ。
このカラクリの解説は大前研一氏が詳解されているので、参考にしていただきたい。※1
６．富士通の良いところ
ここまで富士通に対する批判と改善の提言を述べてきたが、富士通の良いところについても触れておきたい。
まず、個々の社員の仕事力や組織力といった点では、他の大企業と比較して遜色ない。ただし、富士通の主要グループ企業に限るが。
数十を超える大企業および中小企業と仕事をしたが、やはり大企業は個々の社員のレベルが高く、組織力も高い傾向にある。
顧客として他社と仕事を進めていくうえで、大企業の方が優秀な担当者に遭遇することが多く、仕事がとても進みやすかった。
この理由について、大企業の社員育成能力が高いことはもちろん、社内チェック体制が整っているからではないかと思う。
社内で質の悪いものは弾いており、社外に出さないようにしているのだろう。
また、富士通は顧客主義がきちんと徹底されている会社であると感じた。
筆者と富士通の顧客主義が異なっていた点はあるものの、顧客起点に立つという考え方は大事なことである。
柔らかい人が多く、職場の雰囲気はとても良かった。お世話になった直属の上司や先輩方は、優しく丁寧なご指導をいただいたことに感謝している。
７．おわりに
最後に、立花隆氏の著書「東大生はバカになったか」（文春文庫）から名文を引用したい。※2
「いま、この辞めたい気持ちを逃したら、この会社に骨を埋めて、あそこにいる連中と同じになってしまうと思った。」
結局、筆者の退職理由は、偉そうな顔をしているがロクなビジョンも打ち出せない富士通の上層部のような人間になりたくなかったからである。
富士通という会社に必要なのは、優秀な若手の育成などではなく、無用な老害の排除である。
筆者には、富士通という会社は、沈みゆく泥船にしか思えなかった。
※1「産業突然死」の時代の人生論、第44回 談合をなくす二つの妙案－"便利なゼネコン"はいじめの温床
http://www.nikkeibp.co.jp/sj/2/column/a/46/
（この記事のゼネコンをITゼネコン（ITベンダー）に置き換えていただきたい。）
※2 引用にあたり、語尾を改めた。
補足１．城繁幸氏の著書「内側から見た富士通」（光文社）についてのコメント
この本は富士通が先んじて導入した成果主義が、名ばかりで社員のやる気を奪う結果に終わったという実態を告発した本である。
この本について、いくつか述べたい。
まず、本題である、成果主義が経営層のご都合で導入されて、社員のモチベーションを奪うという最悪の結果に終わったという指摘はまさにその通りである。
また、この本が出版されてから10年以上経つが、実態は改善されていないし、する気もないのだろう。
（そもそも経営者のご都合成果主義の導入を失敗だと気づく能力が欠如しているのかも知れない）
管理職の仕事は、部下の成果を評価することではなく、予算内におさまるように部下の評価を調整することであった。
なお、成果主義の導入を評価している現場社員は誰もいなかった。
（成果主義を批判する幹部社員はいなかった。おそらく批判すると何らかのペナルティがあるのではないかと邪推している。）
補足２．転職について
筆者の転職について、考慮したことをいくつか述べる。
まず、次の会社・仕事の選び方および交渉の進め方については、山崎元氏の著書「会社は二年で辞めていい」（幻冬舎新書）を大いに参考にした。
転職は考えていなくとも、今の時代を働く考え方、人材価値のセルフマネジメントなどは一読の価値がある。
富士通という大手を辞めたはいいが、次の会社で苦労している人が多いという意見についてコメントしたい。
筆者に言わせれば、それは転職のツメが甘いのだ。
現職のどこに不満を持っていて、そのうち、どこが改善の余地があり、妥協するべきであり、次の職で改善を期待するのか、についての思慮が浅い。
社会のルールをわかっていないで転職したとしか思えないケースもある。
そもそも富士通という会社に勤めているにもかかわらずITゼネコンの生態系を理解していない社員がとても多い。
下請け企業にいけばもっとやりがいのある仕事ができる、などという浅い考えで転職する人はいる。
ITゼネコンの下請けを生業とする会社の社長は、中間管理職と何一つ違いはない。
上の指示（元請けの発注）を受けて下に伝達するだけであって、自身で新しい事業を生み出す能力のない企業である。
新しい会社は、自社で新しい事業を生み出す能力があり、きちんと利益を上げている。
転職において改善したかったこと、専門的な業務ができること、自分のアイディアを事業に活かすことができること、それらがすべて達成できた。
午後Ⅱ 問題
問１ システム開発プロジェクトにおける要員のマネジメントについて
http://anond.hatelabo.jp/20160413023627
http://nzmoyasystem.hatenablog.com/entry/who_loves_SI
設問ア あなたが携わったシステムインテグレーション業界における特徴、プロジェクト組織体制、要因に期待する能力について800字以内で述べよ。
設問イ 設問アで述べた業務の中に、要因に期待した能力が十分に発揮されていないと認識した事態、立案した対応策とその工夫、及び対応策の実施状況について、800字以上1,600字以内で具体的に述べよ。
設問ウ 設問イで述べた事態について、あなたはどのように評価しているか。今後改善したい点とともに600字以上1,200字以内で述べよ。
イベントやパーティに行った時、何に興味を示すかは人それぞれだろう。
「どんな人が来ているかな」「どんな食べ物が出るかな」などなど。
自分の場合、そういう場所だと、演出のライトにフォーカスしてしまう。
ライトの点滅を眺めながら、それがどんなパターンで動いているか見極めようとし、分かったら「ああ、なるほど」と勝手に喜んだり。
つまり、世の中のあらゆる物事について、ルールや法則性と言われるようなパターンを見出す形で理解しようとするのだ。
世界をパターン化というアプローチによって抽象的に捉えようとすると言い換えれば聞こえはいいが、自分で作った思い込みに囚われやすい性格とも言える。
そんな自分にとって、プログラミングなんて簡単な仕事の部類に入る。
コンピュータは人間と違って全く融通が効かないし、指示命令書であるプログラムはコンピュータが行間を読まないことを前提に書かないと動かないし、何よりコンピュータの側が操作する人間の気持ちを汲んでくれることは絶対にない。
こう書くと極めて面倒なシロモノに思うかもしれないが、実はコンピュータに通じる共通パターンみたいなものがあって、それさえ分かってしまえば、あとはポイントを押さえ大いに効率よくやることが可能なのだ。
とはいえ流石に家に帰ってまでプログラムを組みたいほどではないが、それでも仕事にしたのは人生の選択として自分をほめてやりたい。
もちろんシステム開発に占めるプログラミングの割合は低い方なのだが、客が本当に欲しいものと、実装が楽になる方法の両方を常に勘案するという手法で仕事を進めているので、今のところ大事故はやらかしていない。
また、「マニュアルを読んでその通りにする」のもこれまた得意。
そこに来てプログラミングの土台となるミドルウェアは「とりあえずこうすれば動くよ、そんな難しくないからやってみ？」みたいなスタートアップのための情報が必ずあるので、これまた「動かなくてギブアップ」という経験は皆無。
一方で、同じITであっても、アプライアンスやストレージの管理がメインとなる、運用の仕事は全く苦手だったり。
メーカー・機種ごとに色々違っていて標準的な手法があまりないところに、それぞれ細かいところまで見ていかないといけないこともあって、自分お得意のパターン化があまり通用しないので、その時点で攻略する情熱や興味をを失ってしまうというか。
人間はパターン化がほとんど通用しない相手の最たるもので、そんなパターン化とか考える暇があるなら、もっと目の前にいる相手のことをきちんと観察しろよって話である。
しかし脳がパターン思考に最適化してしまったせいか、相手ありきの現物合わせが全くできないのだ。
「どういう言い方や持って行き方だと、最もスムーズに意思を伝えられるか」は「相手が何を思ってその言動になっているか」という想像力の問題になるが、その想像力が自分には少しも備わっていない。
なのでマニュアルなんて読んでも時間の無駄だし、多分そういう分野はマニュアルというよりレッスンor稽古or練習がモノを言う世界なので、マニュアルそのものがナンセンスという可能性が高い。
じゃあ練習すればって？誰を練習相手に？という取っ掛かりで詰んでいたり。
そもそも「パターン化できない」時点で「うわめんどくせー」と感じてしまう時点で、これ以上のコミュ力の成長は望めないだろう。
でも、もしこういうことが上手くできたら人生更に楽しいだろうなーとも思うので、なんとも悔しい。
お陰で、自分はこのままだとリーダーや営業職をこなせる可能性はゼロだし、多分それは機会損失でもある。まあ無理にやって周囲に迷惑かけるよりはマシだけど。
これは余談だが、それもあってか、フィクションの世界で目にする「人好き系リーダー」は、自分が最も好みのキャラだったりする。無い物ねだりの変形だろう。
でも入社する時に確か3年後、5年後に
3年後にはPLも経験できるようになりたいと言ったし
5年後はマネジメントもしたいと言った。
SESで現場に派遣されている立場だからPLの経験を積めるかどうかは現場次第。
結局ひとつ前の現場も今も一人現場で一人プロジェクトだったしこれから増員という話も難しい。
オレオレコードになりがちでやっぱりメンターは欲しかったなぁ。。。
何よりこれならフリーでいいんじゃねって薄暗い考えが常によぎる。
仕事は前述の通りで先行き暗い（会社としてもずっとPG/PT要員でいいと思っていそう）
人間関係は入れ替わり激しすぎて仲が良かった同僚・先輩はもうおらず。
3年働いたほうがいいって話はよく聞くけど
ちょうどお声もかけて頂いてるので行ってみようと思う。
辞める時はなんて言おうかな。
上の理由真面目に言ってもいいけど
大半のケースにおいて、
決められたタクト（時間間隔）で、決められた作業をすることが要求される。
そして、それ以外のことはしてはいけない。粛々と、与えられた作業をこなす。
ごく少数の管理者の下に、とてもたくさんの人がそういう作業をしている。
じゃあその管理者は何をしているかと言うと、やっぱりルーチンワークだ。
ルーチンの複雑さが違うだけで、99％以上の人がルーチンワークをしている。
製造管理だったり販売管理だったり会計だったり給与だったり色々ある。
それでも、作っている内容が異なるだけで、プロセスは同じだ。
繰り返す。私は何度でも繰り返す。
といってもユーロなんかは随分前からマイナスだから今更だけど。でもマイナス金利政策が急に騒がれ始めて、ウチの会社が煽り食らってる。きっとオレの所にもすぐに爆弾降ってくるから今から憂鬱。何故なら銀行のシステム開発やってるから。自分の立場は融資機能のしがないSE。なので、預金はわからないけど、預金側もマイナス金利は未実装っぽい。マジ日銀余計な事してくれたな。オイ。
・各貸出案件の約定レート（基準レート＋上乗せレート－優遇レート）は０％～２０％で設定可能。
・各レートはunsignedな項目で定義されている場合が多い。ぶっちゃけ符号無しの9(2)v9(5)とかそんなヤツ。
・今更符号付に変更できないから、各DBのFILLER潰して符号付定義するんだろうか。
・当然、レート項目を参照するプログラムは全部作り直しが必要で死亡確定
・当然、利息計算処理や利息積数の積み上げ、利回り計算処理なんかも全部作り直しが必要で死亡確定
・当然、客宛てのＤＭも符号印字出来ないだろうから、符号出せるよう全て作り直しが必要で死亡確定
・きっと決算処理も直さないとまずい。マイナス金利分の利息は税金もマイナスで返ってくるんか？？
今は自分が酔ってるだけでこんだけしか書けないけど、ホントはもっと悲惨な事になるに違いない。
まさかホントにマイナス金利貸出とかやらないよね？約款どうなってるの？いくらLIBOR連動貸出でもマイナス金利とかおかしくね？？
http://anond.hatelabo.jp/20150618025040
読んだ。
まったく別業種（出版系）から１年半前にキャリアチェンジして、システム運用業務に１年ほど従事した。
人当たりは良い方だったのと、口先だけごまかして虚勢を張り続けた結果、無能なくせに半年ほど前に１０名ほどの新規開発チームのチームリーダなった。
チームメンバーは僕よりもずっと若くてスキルもキャリアも抜群にある人ばかり。。
無能なくせにカッコつけたがる癖が邪魔をしてチームメンバーに相談もできない。
リーダになったことをきっかけに所属部署も変わり上司も今までとは違う人になった。
その上司には恐ろしくて相談もできない。ていうか、この上司が怖い。怖い。怖くて仕方ない。ダメな奴の烙印を押されて排除された人を沢山見てきた。
（いくつか凡ミスをしたので、既にできない奴の烙印は押されている気がするけど。。）
休日返上でこんな時間まで仕事をしても、本当に仕事が全く進んでない。。。
ついに、チームメンバーに自分は全然できない奴なので助けてくださいとメッセージを送った。
引き受けて抱え込んだ挙句、こんなことを言うのだから呆れられるだろうな。。
自分の心がとても弱いが故に背伸びしてカッコつけてきたけど。。
もう無理だ。これ以上は迷惑をかけられない。そして、隠せない。
僕は、一体何をやってるんだろう。。
最近、いつもため息ばかりついてる気がする。
誰に何の仕事が向いているなんてわからないが、確かに好きなことをする、と言うのは精神衛生上すごく良い。そして給料も良ければなお良い。
でもどの仕事にどういう人が向いているのかはある程度あると思う。そういう視点で探してみたら何か見つかるかもしれない。
同じようにSI業界に居た人間として、ちょっとSI(主に元請け)に向いている人を話してみようと思う。
私はもうすぐ40になろうかと言う人生を送っていて、底辺SI、ウェブ系、元請けSIを経て今はソシャゲの会社に居る。待遇・内容共に今は満足できている。
元増田の内容には概ね同意。技術者でありたい思う人には「SIはやめておけ」と言いたい。
が、元請けSIを経験して思うのは「おいしい仕事でもある」と言うこと。
技術者では無い人、とりわけ仕事に意義や理念を求めず、お金のためならある程度割り切れると言う人にはとても美味しい仕事だと思う。
技術者としてSIをオススメしない理由は多々あれど、一番大きいのはITに関する技術を必要とされないと言うこと。
元増田の内容にあるように、主な仕事は単価交渉や外注管理。システム開発はするな(別な会社に丸投げしろ)と会社は言う。
だが視点を変えてみると、元請けSIだと技術は問われないので、技術者で無くてもそんなに問題ない。
ただ向いてる人と言うのもあって、自分で仕事をしたくない、面倒なことは人に全部押し付けたい、人にどんな文句を言われようが気にしないメンタルを持っている、もちろん他人の痛みなんて分からないし分かりたくもない。
そんな人には天職だと思う。勝手な思い込みけど、杉村太蔵とか向いてそう。
収入は基本的にピンハネなので、奴隷のように安い単価で働いてくれる協力会社をたくさん抱えて、契約をどんどん取ってたくさん放り込めば良い。
協力会社にいくつかのプロジェクトを担当させておけば、文句を言われた際に営業に「発注減らすぞ」と遠回しに脅せばおとなしくなる。
ピンハネも相当なもんで、だいたい半分くらいは取っていた。なので給料も相当に良い。
A社はPM1名、残りは9名は全てB社。
元請けは一人の単価150万で受注する。
一ヶ月で入るお金を考えると
・A社に入るお金
150万円 x 10 = 1500万円
B社に払う経費：ピンハネ50%として75万 x 9 = 675万円
・B社に入るお金
75万 x 9 = 675万円
これを一人辺りで稼いだ金額で考えると
A社のPMは1500 - 675 = 825万円
B社は一人辺り75万円
825万稼ぐ人と、75万円稼ぐ人。給料に相当な差がでるのは明白だと思う。
で、ITだと元増田みたいなまともな技術者は理想だったり話に整合性を求めたがるので、こう言った下請けを使うPMと言う立場では冷酷になりきれない時がある。
協力会社なんて顎でこき使えばよいのに、相談を聞いて力になろうとしちゃったりする。
なのでそういう同僚を蹴落とすのは楽。勝手に潰れていったり、「改善しよう」と面倒な仕事を増やして周りからも疎まれる。
なんか書いてて悲しくなってきた。
私はそういう所で頑張った結果、人を人として見る能力が失われ、毎日嫌なことをしてる自分が嫌いになり、人を好きになることもできなくなる。
頑張って元請けSI会社に入ったのに、得たものは自分が嫌いで、人を好きになれず、ちょっと給料が良いことにすがっているだけの嫌なヤツだった。
ああ今夜は寒い。もう寝よう。
■背景と問題点
SI業界におけるシステム開発のプロジェクトでは、ソフトウェアの品質が問題になることが多い。
問題点は、知識不足や経験不足な人間が大量に放り込まれたプロジェクトでは低品質なクソコード（※1）を大量生産してしまう事にある。
※1：クソコードとは、可読性の低さ、保守性の低さ、コーディング規約違反、テストが不十分、静的解析の指摘結果が多い、命名の悪さなどが該当するコードである。
■解決方法
真っ先に思いつく品質向上手段としては、レビュー、指導（教育）が考えられると思う。ただ、コストがかかり浸透するまでに時間がかかるのが欠点だ。
そこで、人間の感性に訴える「羞恥心」をうまく利用する方法はどうだろうか？
クソコードの基準を作り、基準に満たないソースコードをコミットした人物を徹底的に「晒す」ことで、
危機意識が高まり、クソコードをコミットする前に見直しする結果、品質が上がると考える。
「晒す」とは、クソコードをコミットした人物の所属会社名と所属プロジェクトと氏名を館内放送するなどプロジェクトメンバーが一目瞭然で分かる公知の事実にすることである。
月末にクソコードコミットワーストランキングを作成し、食堂、トイレ、休憩スペースなどの目に付くあらゆる場所に掲示することで危機意識が生まれるだろう。
人月単価交渉の際にも基準値に満たない数値が出ていることを示すことで、具体的な根拠を持った単価の切り下げ交渉も可能だろう。
朝会・夕会があるのであれば、クソコード作成者を読み上げて周知の事実とするべきだろう。
請け負った会社単位でのクソコードコミットワーストランキングも作成し、会社ぐるみでの取り組みも強化させることで品質が向上するだろう。
■まとめ
プロジェクトメンバの意識が「クソコードをコミットすると恥をかく」を徹底させ、
きちんとしたものを作らなければならないという意識を芽生えさせる事が一番重要である。
ソフトウェアは目に見えないものなので、品質が分かりにくいが、
物作りの現場だとクソな部品を渡されれば次の工程の人間が困るのは目に見えている。
物作りの現場では、誰が不良品を作ったか？を特定されて、詰められるのは当たり前だろう。
だが、ソフトウェアの現場では未だそれを見ない。そろそろやっても良いのではないか？
読者の皆様はいかが考えるだろうか？
そろそろ報道が下火になってきた、神奈川の傾斜マンション事件。どうしても個人の犯罪に変換したい報道姿勢はどうかと思うのだが、安心するためには仕方ないのだろう。
しかし、現代においてマンション以上の社会基盤であるコンピューターシステムの設計にはどうして一級建築士のような資格制度がないのだろうか。東証が止まり、ニューヨークストックマーケットが止まり、空港業務がとまり、ＡＴＭがとまり、１月１日午前０時に流量規制を実施されるというのに、今回のマンションほど加熱した報道もなければ、犯人探しもない。実に奇妙だ。世界中がコンピューターシステム関係者を擁護しているのかもしれない。時折ほとぼりがさめたころに敗軍の将が兵を語る程度である。実に、実に奇妙だ。これほどの影響が出るのだから、もっともっと事件として扱うべきだろうし、設計には資格を設けるべきだろう。しかし、実際の設計現場には何の知識もない派遣社員があふれかえり、テストケースは過去のそれを流用し、他システムのソフトウェア設計を流用し、ハードウェア構成を流用しているだろうに。
今回の傾斜マンションは個人の財産が毀損したため「もしかしたら私のマンションも」という不安が背景にあるのは想像も理解もできる。しかし、あなたが使っているスマホに謎のチップが、プログラムが、世界のどこかのサーバにデータを送り続けている、グーグル検索記録が残り続ける、文字変換の履歴が残り続ける、ネットにつないだテレビ、レコーダから利用履歴がどこかのサーバに、ラインのログが残り続ける、あらゆるアクセスしたサイトにログが残り続けるのは不安ではないのだろうか。おそらく今回のマンションの事件は誰でも目に見えてわかるからこれほど煽情的な事件となったのだろう。ケータイショップ店員のグチ、家電量販店店員のグチ、とかをみると、説明してもわからない人の事例が目立つ。とにかくバカはバカだと思い知らされることを恐れるのだ。しならい、わからない、と言わないのだろうか。よく新人社員に「同じことを二回聞くな」という低能がいるが、それに通じる自己尊大化の患者だろう。
システム開発の現場にいると、マンションで例えるな、ちゃんとした長さの杭が届くことがマレだ。なんだかんだで届かない。杭が届けばまだいい方だ。杭が来たのだから。
