  |
はてなキーワード: ミドルウェアとは
日頃、自分の興味のあることに関する課題を発見し、それを解決するためにアプリ(小規模だけど)を開発し公開している。作ったものがたまにバズることがあって、その結果1日の広告収入が1万円を超えたこともあった。しかし、定期的に作ったアプリに対して使った技術要素やコーディング量を見返した時、これぐらいのものはxxさんなら自分より短時間かつ高クオリティで開発できるなと思うことがあるのだ。
興味があることに自分で課題を発見し実際に手を動かしているのですごい！みたいな話を聞いたことがあるが、理解はできても共感ができない。
常にネガティブな感情を抱いているわけでもなく、難しい箇所をうまくコーディングできた時は自分のことを天才だと感じることや、ミドルウェアを含むバックエンドからフロントエンドまで1人で開発できるようになり、昔の自分と比べて成長したと感じることはある。ただ、これらのポジティブな感情は一瞬で終わり、あっという間に上に書いたようなネガティブな感情が自分を支配するようになる。
レッドコーダーやKaggle Masterになるか未踏に採択されるなどのレベルに達すれば、自分を認めることが出来るような気はしているが、あいにくそこまでの能力は持ち合わせていない。
https://anond.hatelabo.jp/20180311003723 を見て書きたくなった
きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。
そうずっと教えられてきたし努力してきた。
業界2位のミドルウェアが、、1990年代にタイムスリップしたかのような継承拒否した継承構造で書かれていた。
世界的なOSSで3桁や4桁のスターがついているリポジトリのコードは、コピペの嵐。巨大なマージコミットやＦワード入りのコミットメッセージ。
有名なスタートアップのCTOのコードは、メタプログラミング黒魔術の塊だった。
リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。
でも、それはコピペまみれで、巨大のコミットの汚いコードだからできる。
同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。
優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコードを要求する。
他人にきれいなコードを要求するのは、他人のコードを読む時間を短くするためなのだろう。
きららファンタジアというスマホゲーで何か大きな問題が起こって大騒ぎになっているというのは Twitter の自分のタイムラインにちらほらと出てきていたので「そうなんだー」程度の認識だったのだけれど、その炎上のまとめと考察(https://smhn.info/201712-kirara-fantasia-cheat)を読む機会があってなるほどこれは大変な問題ですね、と思った。
それで僕は、サービスインからサービス終了までをほぼ全て見守ってきたあのゲームの事を久しぶりに思い出したので懐かしい思い出としてここに書き記しておこうと思う。
そのゲーム、仮にスキマとしよう。そのスキマはスマホゲーによくある隙間の時間を埋められるようなデザインをされたゲームで、大まかにいうと冒険者を組織してダンジョンへと冒険に出かけさせ、持ち帰った財宝を使って冒険者を強化して、また冒険に出かけさせるというサイクルのゲームなのだが、冒険中はユーザは特にすることがなくただ待っているだけという、冒険者を送り出して帰ってきたのを確認するだけの作業をその隙間の時間にやってね、というゲームだった。なお、スキマは単発のゲームというよりは、はるか昔のパソコンで動いていたゲームを始祖とする名のあるタイトル(仮にウィリーとしよう)を冠したゲームで、ルネサンスと名付けられたウィリーブランドの再生プロジェクトのうちの一つであった。僕はそのウィリーが好きだったのでとりあえず遊んでみようとダウンロードしたのであった。
まず、スキマのサービスイン直後だが、オンラインゲーの例に漏れずサービスイン直後に色々な問題を起こしてメンテにつぐメンテでまともに遊べる状態ではなかった。だいたい4,5日はメンテをしたり、たまにサービスしていたり、という感じだったのではないかと思う。そのサービスインから4,5日経ったあたりで、「このままでは安定したサービスが続けられないので長期メンテナンスに入る」といった感じのアナウンスと共に、メンテナンスに入った。このメンテナンスは一ヶ月とちょっとの間続いた。僕はサービスイン初日にはプレイできず長期メンテナンスに入る前に少し遊んだ程度だったのだが、遊んでみた所では「これは酷い」としか言いようがなかった。
まず動作がもっさりとしている。何かのボタンを押すたびに CONNECTING… というダイアログが出て2秒位は待たされる。場合によってはボタンを3,4回押さないと目的の事ができないのに押すたびに CONNECTING… なのである。次にタップに反応しない。ボタンを押すと書いたが押したつもりが押されていない事がしばしばある。この場合は CONNECTING… が出ないのでわかるのかと思いきや、1秒位経ってから CONNECTING… と出てあぁ、押していたのか、とわかったりするようなもっさり具合である(もちろん押していなかった時もあるので1秒後までは押せたか押せなかったを判別できなかったりする)。
また、バグと言っていいであろう謎の動作が多い。ダンジョンに送り出したパーティのダンジョン内部での行動がダンジョンログとして閲覧できるようになっており、そのダンジョンログは直前の3回までのログが観られるようになっているのだが、そのダンジョンログの表示される内容が複数が同じものになっていて実質的には3回のログはみられないであるとか、CONNECTING… が出るタイミングで他の部分をタップしてしまうと高確率でアプリが落ちるであるとか、特定の順番で装備している武器を変更すると攻撃力が最低値に固定されるであるとか、リリース記念かなにかで貰えるキャラがなぜか毎日もらえて同じキャラが増えていくであるとか、まぁ色々な問題があって面食らったものである。
そんな感じでサービスインを迎えたスキマなのであるが、こんなに酷い状態なのではユーザはどんな事を言っているのだろうとコミュニティを探した所、2chにスレッドが立っていた。案の定スキマのバグ報告スレと化しており、「あぁ、このゲームは本当に全然駄目なんだな」とほっとしたのを覚えている。僕はその頃からその2chのスレッドを眺めるようになった。また、こんな状態ではサービスが続けられないのはわかるけれど、一ヶ月程度のメンテナンスでなんとかなるものでもないだろうとも思ったので、せっかくなのでサービス終了まで看取ると面白いのではないかとも考えた。
一ヶ月と少し経った頃、スキマのサービスが再開された。まぁ残念ながら僕の予想は外れておらず、お世辞にもちゃんと遊べるとは言えない状態であった。とはいえ、本来は一回しか貰えないはずのキャラが複数回貰えるであるとかいった所に代表されるゲームとして守られるべきルールのようなものについてのバグの多くは直っており、残っている問題の多くはクライアントアプリ側の問題とサーバ側の負荷対策ができていない問題とみられ、クライアントアプリ側の問題は特定の操作をしなければ落ちはしないしサーバ側の問題はもっさりだけれど待てば処理はしてくれるので一応遊べないことはない状態だとは言えた。それでも、クライアントアプリ側でのUIの不思議な動作(押してるつもりでも押せていない、連打するとクラッシュ)に誘発されたと考えられる進行不能バグを代表とする理不尽な問題は沢山残っており、ユーザとしては不満が渦巻いていた。
そんなスキマではあるのだが、サービス再開の後はウィリーでは有名な人の名前を冠したイベントを行ったり、定期的に期間限定のダンジョンをオープンしたりといった運営を行っていた。もちろんバグはじんわりと直ってはいくのだが、特に劇的な直り方はせず、「俺サービス開始直後からログインできなくなっててまだログインできないんだけど」みたいな事を報告するユーザ(?)も2chでは散見されるという状態で、2chのスレッドは「スキマのバグを踏まないようにプレイするにはどうすれば良いのか」という情報を交換するための機能を果たしていた。
一ヶ月メンテからのサービス再開から3,4ヶ月経った頃、運営会社から開発会社の変更が発表された。曰く、外部の開発会社に制作を依頼して制作したのだが、不都合が多すぎてどうしようもないので開発を自社に引き取るということであった。その後一ヶ月程して「不都合収束クライアント」と銘打ったクライアントが配布される。この不都合収束クライアントで確かにいくつかのバグが修正されはしたのだが、もっさりとした動作が変わるわけではなく(プロトコルもサーバ側も修正されていないようであったので当然ではある)、操作によってはクライアントが強制終了していたのが強制終了はしなくなった、程度の修正であり、これを解決するには根本的な改革が必要であるとみてとれた。
そんなスキマではあったが、何故かサービスは終了せず、サービス1周年の時を迎えた。この時、スキマの開発体制についての発表もあった。現在のスキマのクライアントプログラムは改修を重ねていくが、それと平行して開発ミドルウェアを変更してフルスクラッチでクライアントを作り直している、という発表であった。2chのスレッドではフルスクラッチでクライアントを書き直すということで、バグの根治は当然として、目的の事を行うのに3〜4タップ必要であったりするというUI周りまで手がつけられるのではないか、という事を期待する声が上がったりもした。
また、この1周年の挨拶の3ヶ月後には新クライアントの開発状況は70%と発表された。
この頃からであろうか、僕が遊んでいる環境のみなのか、又は他の人ではあまり現れない問題であったのか、とにかく僕が遊んでいる環境では冒険からの帰還を行おうとすると変に時間がかかるようになった。この問題は何らかの原因で帰還操作が完了するまでの時間が少しづつ伸びていくという問題であった。この問題は後で僕には大きな問題として認識されるようになる。
この頃からは新クライアントを開発しているためなのか、旧クライアントの修正はあまり行われなくなり、定期的なイベントが行われるのみであった。思えばこの頃はスキマの遊び方(このようにするとバグを踏むのでこれはしない、であるとかいった遊ぶための作法)がわかっている人間しかスキマを遊んでおらず、運営側も積極的には宣伝もしていないため新しいユーザも増えなかったため、比較的安定した運営が行われていたのではないかと思われる。
また、恐らくこの頃であると思われるが、2chのスレッドで「スキマは冒険者が冒険をしてきたログを眺めることでそのダンジョンの攻略法を考えたりするゲームなんだけど、あまりにもバグが多すぎるから2chというログを読む事でスキマというゲームを攻略しているよね」といった書き込みが行われるなど、スキマをダンジョン攻略ゲーとして捉えるのではなく、バグ攻略ゲーとして捉えるというユーザが現れていた。
さて、一周年の時に発表された新クライアント開発は、その後3ヶ月程で70%まで出来ていると発表されたが、結局その新クライアントがお目見えしたのは2周年を目前に控えた頃であった。新クライアントのお披露目はAndroidでβテストという形で行われた。言い忘れていたがスキマはiOSでしかサービスされておらず、それまでAndroid版は存在しなかった。僕はAndroidもiOSも持っていたため、βテストに応募し、当選したので遊んでみたのである。
まず、フルスクラッチで制作されると言われていたのでUI周りも変わるのであろうと思っていたのは完全に裏切られた。見た目はほとんど何も変わらず、もちろんUIのタップ回数まで全く同じであった。しかも使用されているフォントが違うために文字が見切れていたりといった問題が発生しており、お世辞にも前のクライアントとくらべて良くなったとは言えなかった。また、恐らくはサーバ・クライアント間のプロトコルも何も変わっていないのか、プロトコルやサーバ側に起因する問題は依然として残っていた(武器や防具を鍛錬すると+の数値が上がるという仕様があるのだが、連続して鍛錬を行うと必ず1以上は上がるはずの鍛錬値が上がらなかったり下がったりするといった問題は残っていた)。また、動作もiOS版と比べるともっさりとした感じが強く、何のために作り直したのかわからないという感想であった。2chのスレッドの中ではこの新クライアントは単に今までの旧クライアントをAndroidに移植したものであり、本物の新クライアントはまだ開発中なのだと言って聞かない人が長いこと存在した程である。
その後、βテストでお披露目された新クライアントは3ヶ月後にAndroidでリリースされ、その後さらに3ヶ月後にiOSでも新クライアントがリリースされた。
鳴り物入りで導入された新クライアントであるが、先程も書いたように、旧クライアントと比べると確かに解決された部分もあるが、サーバ側が関わる問題は全く同じ問題を抱えており、新クライアント特有の問題が多く発見され、実質的には旧クライアントの方がバグが少ないという状態であった。
僕はβテスト以降は特にAndroid版で遊ぼうとはしていなかったため、新クライアントが先行リリースされたAndroid版を遊んでいた人達を眺めていたのだが、Android版で起こっていると2chで報告されている問題がそのままiOS版でも起こるとなると大変だと思って眺めている位には、Android版は阿鼻叫喚の様を呈していた。iOS版での新クライアントのリリースは3ヶ月遅れたが、この間Android版は何度もなんどもアップデートを繰り返し、その度に少しづつバグが修正されていくのをみて戦々恐々としていた。
iOS版の新クライアントがリリースされた直後、僕はスキマを遊ぶことができなくなった。これはゲームを起動した後すぐに「通信エラー」が表示されてタイトル画面に戻されるという問題で、これを回避する方法が全然わからなかったためだ。「あぁ、ログインボーナス貰えてたのがなくなっちゃうなぁ」と思ったのを覚えている。
しかし、この問題については2ch(正確にはTwitter経由であるのでTwitterの誰か)に「お知らせ」をタップしてからだと通信エラーが起こらない、というオカルトじみた書き込みがあり、それを信じてやってみると確かに通信エラーが起こらないということが確認できた。これで僕もスキマをプレイすることができるようになったのである。この時は本当に2chというログを読んでスキマというゲームを攻略している感じがしたものだった。
この時、僕は何故通信エラーが起こるのか、何故「お知らせ」をタップすると通信エラーが起こらないのか、といった事を確認したくなってiOS版の通信を眺めてみることにした。本来であればこのような行為を行うのは自分の主義に反するため、それまでは行わなかったのであるが、突然ゲームがプレイできなくなるというのは大変衝撃であったので、つい出来心で、という感じで眺めてみたのである。
クライアントとサーバ間の通信はHTTP、つまり平文で行われており簡単に通信内容をみることができた。タイトル画面から通信エラーが出るまでの通信内容はだいたい以下のような感じであった。
3. クライアントから並列で何らかの情報を取得するためのGETリクエストを送信
4. 並列で送られたリクエストへの返信をサーバが返すが、その全てに更新された(別の)セッションキーが入っている
6. クライアントで何らかの操作を行おうとしてサーバへリクエストを送信
つまり、3. のリクエストが並列で行われ、サーバが更新したセッションキーが 4. でクライアントに届けられるのであるが、恐らくは届いたセッションキーが前後してしまうことで壊れてしまったと考えられる。
これが、何故「お知らせ」をタップすると解消するのかであるが、実は「お知らせ」を取得するためのURLは http://…../login2 というURLへのGETリクエストであり、かつセッションキーを必要としておらず、このURLからのリクエストの返事にはセッションキーが含まれるという特殊なURLであったのだ。つまり、本来であれば 5. の状態の時には壊れたセッションキーを保持していたはずが、そこで「お知らせ」をタップすることで新しい(正しい)セッションキーを手にすることができるようになり、その後の通信はちゃんと行えるようになったのである(その後の通信では並列にリクエストを投げるパスは僕の観測した範囲では存在しないように見えた)。
この事に気づいたTwitterの人はどうやって気づいたのかはわからないが、よく見つけてくれたものである。ともかく、僕はこの情報に助けられ、スキマを再開することができた。
長くなったので https://anond.hatelabo.jp/20171221020636 へ続く
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
paizaを始めとしたSIerDisで大企業（日系）にはロクなエンジニアがいないと思われてるっぽいけどいるとこにはいるんですよ。
知ってる人を紹介。
意識の高い大学生や新入社員はこのあたりを目指すとみんなから尊敬されるぞ！
がんばって配属してもらおう。
http://anond.hatelabo.jp/20170309040708
運用なので実装や開発ということもなく、何かシステムに修正があればテスト、というような感じ。
先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、
やっぱり運用プロジェクトというせいかモチベーションが上がらない。
最近は毎朝起きるのも遅い。
以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり
会社に入ったばかりでやることはどれも新鮮。
少し難しい仕事も任されるようになってきてモチベーションもあったと思う。
それが今では不思議と朝起きたくないのだ。
起きるのがつらいというか億劫。
別に疲れが溜まっているわけではない。
目覚めは悪いどころかいつも目はぱっちりしている。
でも起きれない。ぎりぎりまで布団の中。
そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。
この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。
今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。
会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。
今では職場でも私生活でもいきいきしている。うらやましい限りだ。
自分はフリーランスにはなろうとは思わないけども、少なくとも今のプロジェクトは半年が限度かなーとは思ってる。
それに自分の市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。
そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。
運用プロジェクトの残念なところは、仕事の大半が顧客対応のコミュニケーションコストでつぶれること。
特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。
障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..
なんてことをつらつら書かなければいけなかったり。
なにより障害が発生したらものによっては休日にも出勤しなければならないこと。
まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。
体力には自身があるけども精神的にはわりときます。人によるのかな？
つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。
運用プロジェクトでは顧客対応が必須だ。なので顧客との話し合いは上手くなる。
例えばフレームワークの脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。
ハードウェア、ミドルウェアに障害が起きればそれに対する知識を駆使して対応を行う必要があるし、
ドメインが変わった、IPアドレスが変わった、となればシステムの運用や保守作業で影響がないか調査する必要がある。
他にも必要な知識として、プログラミング言語とSQLはそこそこかけて、DBクライアントやLinuxの操作、その他ミドルウェアの知識も必要になる。
なので現時点では自分のスキルはそこそこ伸びてはいるのかなーとは感じている。
理想は運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。
Ansibleとかはサーバー構築手順書をなくすことができるし、mavenやgemなどのパッケージ管理ツールはセットアップ手順の暗黙知をなくすことができる（なんのライブラリ入れるーとか）
人にあれこれ聞くより、コード見て大体わかるような感じになっているとすごく助かるんだよなぁ。
もしかしてそういう感じで仕事を続けていけば、英語圏とかでも仕事できるようになるのかなぁ。
vagrant up ← コレだけで開発環境揃う環境、素敵に開発に入りやすい
わしが1年1人でやっているやつ、ミドルウェア系には秘伝ミソが少し出来ているから、dockerで全部揃うようにしてみるかなぁ。Solr使っている部分とかしょうがないような気もしつつ、ローカルにあったほうが良いんだろうなぁ。あんま頻繁に開発しないし、そこは自分でやればいいか・・・。まあ多分solrのコンテナを立てれば良いんだろう。
元増田程の良い生活は出来てないけど、それなりに良い給料を貰って良い生活が出来ている同じ世代の独り語り。
自分は勉強出来なくて底辺高校出身の高卒だけど、同じくラッキーだったりが続いて転職の結果、
年収ランキングに入る一部上場IT企業に中途で入り、今の生活に至る。
インターネットが誕生して発展していく時代に生まれたから、ゲームオタク・パソコンオタクであることが武器になって、
(プログラム弄ってたり、適当なミドルウェアを入れて環境を構築したりが遊びになる)
ただ、そうなれたことの一端に
>でもそれも、そんなカードも、両親が必死になって繋いで手渡してくれた大切なカードだった。
これが大きいんだと思う。
親が好きに生きさせてくれたことで今があるんだなぁと言うこと。
思い返せば、小さい頃から勉強ができなくてテレビゲームばっかりやってたけど、親がそれを怒ることは無かった。
怒られることが無いから、勉強は別にしなくて良いものと思っていた。授業中は「なんでこんなことしてるんだろ。学校の先生ってのはうるさい人だ」位に思っていたと思う。
勿論勉強しなくちゃいけない時期にテレビゲームばっかりやってたから、wikipediaに底辺高校と書かれるような高校に入って
名も無き零細ITにしか就職できなかったけど、それも自分の行動の結果だから人のせいにしたり後悔するようなことは無かった。
どちらかと言うと大学に行けなかったことで、人より4年早く就職できたことのほうが大きかったと思う。
当時の現場が良かったのもあるけど、単調なコーディングやテスト手順書ばかりではなく、いろんなことをやらせてもらえた。
2000年問題の前はまだ中小規模の会社でも元請けが結構あって、今みたいに頭数揃えて人海戦術ばかりな業界じゃなかったしね。
エンタープライズなIT業界が労働集約型産業になっていく中、インターネットが発展したくさんの技術が生まれたことで、
結果として、少なくとも現時点では学歴が無くても良い生活が送れている。
いい大学に入って良い学歴を持つことは武器にはなるけど、別に成功が約束されているわけでは無いので、
自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。
彼のへの感想。
富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いから想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身が自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると（後述の富士通に入社して10年が経った人の話にもあるのだけど）新人の能力の客観的な判断材料って大学と資格（応用情報レベル以上）程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代で富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士卒しか居なかった覚えがある。あと確か2～3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。
ただ、20万人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、（自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた）、そういうのに入社して間もなく入ってしまうと自身の勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。（自分は炎上案件に放り込まれた新人が寮で死んでたとか話を聞いたことある）
はあ、としか。この人がこう判断した際の判断材料にするであろう自己の体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業の経営とか体制とか理解出来るんかね？と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分の体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的や巨大企業特有の問題があってそうなってるんだなって思う事が多々あった。
近い時期に入社したと思われる。具体的な話が自分の経験と一致してる。特に、富士通のソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか（特に学生なんかじゃ）判らないかなと。
それでこれらの話を見てどんな人が富士通（というか大企業）に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる（要するにそこそこの大学に行って卒業した人）、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであんまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解しやすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社は子会社で色々アルかもしれないけど。
入社は10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1～2年したら子会社の統廃合とのことで富士通本体と連携してる部署（自分がそうだった）は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由は実家の事業を継ぐ事にしたため。
入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と
富士通本体のソフト開発配属の人達で研修をやったのだけど、その際に富士通本体の人達と知り合った。（この際に全員のプロフィール冊子が配られた）そのときは流石子会社に入る人達と本体とじゃレベルが違うな～と思いましたね。（ちなみに自分はMARCHより下の院卒。）
自分が配属されたのは某製品部署のAPI部分チーム。その製品がC言語やJava言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPのポートにプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙でヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語のAPIをリニューアルするって開発してたのだけど、設計担当がJavaしかやったことない人で色々とC言語の流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね（ちなみに機能はそれサーチか？思うのもあった）。もっと酷かったのが初期製品のJavaの公開メソッドで、マニュアルには「このメソッドの引数○○を□□を指定した場合は戻り値のObjectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。
これは、ミドルウェアの開発をやってる人達って基本的にC言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSはWindowsとLinuxとSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。
それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkのAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0でGenericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計も実装も結構良い感じに出来たと思う。ああ、そういえばRuby用のAPIも効率化の開発ツールとかの名目で仕事中に勝手に作ってたなあ。他にもC言語のAPIも内部実装がクソすぎ！とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対にLDしてるんで完全に趣味なんだけどな。これでAPIはC言語とJavaと.NETになった訳だけど、現場の案件で使われたのってほぼ全てJavaだったと思う。（開発中のサーバのテスト用アプリはC言語だけど）。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業の仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟は必要かもね。
で、.NETのAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理と作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品の担当が増える事に。インストーラはWindowsがInstallShieldというクソみたいな言語上で作られたもの。LinuxとSolarisがシェルスクリプトでのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか）とか保守作業が大変だった覚えある。
んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品の派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味でC++で勉強してたので何とかなった。あと、結構OSの知識（プロセスとか）が必要でWindowsとLinuxとSolarisで動くコードを書く必要があってまあまあ大変でした（と言ってもifdefで切り分けるだけなんだけど）。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品のバッチ処理に使えないかとか話が出てきたあたりで自分が退職する事に。（退職の話は1年ぐらい前に話し合って決定済み）引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしまい実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。
振り返ってみて残業時間は月40～60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部（だったかな？）単位で残業禁止になってホントに残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通のソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか（そんなに深くはないけど）色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモを体験出来たのは良かったです（こなみ）。
「富士通を退職した話」を読んで、20年近く努めている側からの感想と疑問について書いてみたいと思います。
私も、情報科学を大学時代専攻した後、新人で山奥というかむしろ雲の上にある天空の工場に勤務してメインフレーム関連の仕事をしていました。
その工場に配属される新人は（希望すれば）寮に入るわけですが、高専卒は工場の敷地内にある山頂の寮で二人部屋、学士卒は山の５合目にあるアパートの一人部屋、修士とドクターは街中にあるマンションという感じでした。
街中の下界から工場がある天上界への通勤はバスで移動することになるのですが、わたしは、バスのディーゼルエンジンの排気ガスが苦手なので、頼み込んで工場の敷地内にある寮にしてほしいと願い出て、山頂の寮に特別に入れてもらいました。そもそもが２人で一部屋なのですが、学歴の関係か私は一人で２人部屋を使わせてもらっていたため、ものすごく広々と部屋が使えました。
わりと頼み込めば、人事や勤労も柔軟に対応してくれる会社という印象です。
２０年前でさえ、メインフレームは古いというイメージがありました。
ただ、私は古臭い部署に配属されたことは不幸とは思いませんでした。電話からスーパーコンピュータまで幅広く扱っている世界でも稀な会社に入ったからには、いろんなことを経験してみたい。
そのためには、そろそろ絶滅してしまいそうなメインフレームを今経験せずにいつ経験出来るのか？くらいな感じでむしろラッキーくらいに考えていました。
最新の流行を追いかけるのもそれはそれで面白いが、そういったものは出来合いのライブラリを組み合わせて流行を少し遅れて追っていく２位集団であるし、やりたければ個人で家でも出来るじゃないか程度の感覚です。
ただ、せっかくメインフレームの部署に来たのですが、私の担当はワークステーションで動作するUNIXやPCでの開発が主体でした。
そもそもが、メインフレームを扱っていた部署ですから、先輩の人達はあまりUNIXやPCに詳しくなかったので、大学でUNIXやPCを経験した新人が入ってきたことは非常に重宝されました。
その部署では開発言語は、社内の独自の言語（Cよりもさらに機械語に近い言語をマウスでグラフィカルに操作してコーディングする言語）を使っていました。もともとはメインフレーム用の言語なのですが、UNIXワークステーションやPC用にも
その言語コンパイラはあり、あわやその言語でUNIXの開発する羽目になりそうだったのですが、私は猛烈に反対して自分の意見を通しました。当時はJavaやRubyなどの言語は無くCが全盛でしたが、
その部署の開発メンバーはCをほとんど知らなかったのです。そこで、社内のカイゼン活動として、C言語の勉強会を開くことを提案し私が講師になってC言語をメンバーに習得してもらい、
PCやUNIXでの開発は独自言語ではなくC言語を利用することを認めさせました。
元の増田の方は、自分はエクセルのVBAソースが見れない立場のようだと言っていましたが、ソースをみようとしたらシートにロックがかかっていたのを見て諦めてしまったのではないでしょうか？
元のEXCELを使った業務が非効率であるならば、業務の改善活動として提案すれば、それを拒む上司というのはちょっと考えにくいです。
忙しい部署にも、改善活動のノルマが課せられるのですが、先輩はそういったことに関わっている時間が中々取れないので新人がそういった仕事をやると宣言しても拒むのはまずありえません。
下請けのプログラマーからみると富士通のような会社は中間搾取していて高給をとっているのに、仕事は丸投げという印象があるでしょうが、実際やってみると案外大変です。
私は、富士通本社のSE的な立場、グループ孫会社に出向して、そこから顧客先に派遣される４次受け５次受けのプログラマ両方を経験しましたが、はっきりと下請けの方が精神的に楽と感じました。
客商売や、自分でやっているわけではない人に依頼した仕事について、責任をとるのは非常に苦しいものがあります。そもそもプログラミングはとても楽しいというのもありますが。
私見ている範囲では違う部署に異動したいという希望は100％通りました。異動を希望しているのにその部が解散するまでその部署にいる羽目になった人など見たことがないです。
もちろん、「プロジェクトが佳境で君に今抜けてしまわれては困る」というケースはあるのですが、IT業界のプロジェクトの開発周期は年々短くなる一方ですから、割と早い段階で異動の希望は通る感じです。
もとの増田の方は巨大プロジェクトだったので大量の人がいるわけですが、こういった部署は異動の希望は通りやすいです。
なぜなら、新規プロジェクトで最も忙しいときは大量の人員を動員しているわけですが、バージョン２、バージョン３あるいはメンテナンスのフェーズに入ればそんなに大量の人員は必要がないので、会社としてもその部署の人員を異動させたいわけです。
けれど、プロジェクトで中核の技術を担っているようなメンバー、マイホームを天上界に立ててしまったメンバー、新しい仕事に対応しにくい高齢のメンバーは異動させにくいので、
EXCELをいじっているだけのような新人は異動の希望が通りやすいのです。
もとの増田も、もう少し我慢していれば希望が通った可能性は極めて高いですが、プロジェクトが佳境でまだ新人で入ったばかりといった状態では、もう少しその部署で頑張れと言われるだろうと思います。
ただし、異動先の都合もありますので、ここから出たいはほぼ１００％通りますが、あそこに行きたいは必ずしも通りません。
今更「京」のスーパーコンピュータをやりたいといっても、人気部署ですし、プロジェクトの最盛期は過ぎているのでその希望が通る可能性は低いでしょう。
色々な部署がある大きな会社では、管理職クラスは頻繁に異動が起こりますから、嫌いな上司はわりと直ぐにいなくなります。小さい会社だとそもそも部署が開発部と人事部と営業部しかないというかんじなので、上司がやめるか自分が辞めるまで、嫌な上司と付き合う羽目になりがちです。
新人研修期間が終わった後、人事の面談のチャンスがあるのですが、そこにはコツがあります。
「おおざっぱにはっきりと希望を言うこと」です。
いちばん最悪なのが、大学での研究を話し、それを活かせる部署に行きたいと話すことです。
人事の人は技術には詳しくないですから、研究内容が最先端であればあるほど、人事の人には通じないです。
キャッシュコヒーレンシが。。とか話すと、「よくわからないけどこの人は基本ソフトウェアに向いているのかな？だったら、自社でOSを開発しているメインフレーム回そう」という感じになってしまいます。
それよりは、人事の人が、会社組織のどの部署に配属すればいいかわかりやすいように、おおざっぱに希望をいうことです。
例えば、
上記のことを強い口調ではっきりというのが良いと思います。
そのうえで、できれば○○製品をやりたいだとか、こういった業種のSEをやりたい等の希望だすと、どの部署に配属すればいいか相手にも伝わり希望が通りやすくなります。
私の同期で入社して新人研修で山奥に配属されたバブル時代の末裔のようなおねーちゃんとか、数人は、割とはっきり希望をいって、下界に戻っていきました。
明らかに向き不向きがハッキリしていて、尚且つ向いている人が少ない開発に比べたら、運用の方が間口が広い(=向いている人が比較的多い)と一般には言われている。
この業界に入ってから数年前まで開発一筋で来て、それからつい最近まで運用チームに加わっていたのだが、とにかく他の人に比べて明らかに動けなかった。
そもそも自分は「パッと見で動いてんだったら放っときゃいいじゃん」という人間なので、毎日毎日ルーチンワークで目配せがずっと続くとか、その時点でゲンナリだった。
それから、監視対象の各機器(ストレージ・セキュリティ系アプライアンス・スイッチ等)や各種ミドルウェアはメーカーごとに仕様が違いすぎて、またその仕様も込み入っていることが面倒で、それぞれのオペレーションを覚えるのも苦痛だった。
てかそんなモノに、一体どう興味を持てというんだ？
当然、どれもこれも大まかに把握している程度に留まってしまい、そういう中途半端な理解だと、トラブった時に大変になると。
やたら読みにくいマニュアル片手に原因を探り、それでも分からないのでメーカーに問い合わせてログ提出→回答を元にオペレーション→やっぱり動かないみたいなケースが何度あったことか。
もちろん、そんな人間に重要な機器は任せられないので、自分などいてもいなくてもいいポジションに終始することになった。
そんな自分の経験から、運用業務に代表されるような、ああいう灯台守みたいな業務をテキパキこなせる人は心底凄いと思う。
個人的には運用なんてもう金輪際やりたくないけど、一つだけ、開発と違って基本何も起きなければ残業無しという点はとても魅力的なのだ。
一方、開発の「ややこしい物事を、コードやドキュメントという形で、可能な限りシンプルかつ分かりやすい内容にまとめていく」感覚が何者にも代え難いのは間違いないが、夜遅いのだけは本当に何とかして欲しい。
昔、一人屋台で小さく短い開発案件ばかりやっていた時は比較的時間の自由が効いたけど、今はもうそんな仕事ないし。
