「ミドルウェア」を含む日記 RSS

はてなキーワード: ミドルウェアとは

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-10-12

プログラミング界隈で言語フレームワークミドルウェアの移り変わりについていかなきゃいけないつらさなんて話はよくあるが

デザインとかその他表現そもそも表現に限らずなんだって流行り廃りはあるから

そこで生き残ってる人は結局アップデートしてんだよな

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

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開発環境構築コース

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ファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

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)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

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)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (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, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

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チェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-06-27

anond:20170627155813

スクリプト言語楽しいと思う人はアプリ寄りのことをしたいんだろうから

大学にいる間はまぁ我慢しておくんだな。

大学じゃアプリ開発なんて教えてくれないし、教えることができない。

情報系の学部で C を教えない方がおかしいだろう。

君たち大学生は将来コンパイラを書くかもしれないしOSミドルウェアの開発を

期待されてるんだよ。アプリ屋になることなど期待されてない。

2017-05-20

大企業に隠れているすごいエンジニア

paizaを始めとしたSIerDisで大企業(日系)にはロクなエンジニアがいないと思われてるっぽいけどいるとこにはいるんですよ。

知ってる人を紹介。

意識の高い大学生新入社員はこのあたりを目指すとみんなから尊敬されるぞ!



外部に出してる情報は少ないね

がんばって配属してもらおう。

2017-05-06

しかプログラミング一つにしても業界によって必要スキルは異なるわけだし、

Web系ならScala,JS,Ruby,ミドルウェアならC++,Java,システムならJava,分析ならPython,Ruby…)

会社必要になる知識漏れなく教えるなんてことは無理だと思う。

2017-05-05

http://anond.hatelabo.jp/20170504083902

エンジニアリング勘違いしてる人がときどきいるけど、エンジニアリングってのは工場を作ることであって、ライン工になることではない。

ソフトウェアエンジニアリングにおいてファクトリーはフレームワーク(あるいはミドルウェア)である

大企業においてフレームワーク(ミドルウェア)を作る仕事は専用の部署があり、名だたるOSSコミッタなど一流のプログラマーが在籍している。

2017-04-24

攻殻機動隊日本産業を後押ししてる

自分の周りの機械系やミドルウェア系の若い技術者の中には攻殻機動隊を見て今の道を目指したと言っている人が多い。

そういう意味で言えば攻殻機動隊日本産業を後押ししていると言える。

もう少し一般化して言うと、SF作品の持つ役割は思った以上に大きいのかもしれない。

小説でもアニメでもゲームでも面白いSF作品が生まれることを切に願う。

個人的には最近ではサイコパスが超面白かった。

2017-04-06

wordpress高速化が楽しくなってきた。

VPSミドルウェアwebサーバを変えたり、Mysqlチューニングやらなんやらで高速化してるんだけど

gtmetrix.comでハイスコアが出るとうれしい!ゲーム好きな人気持ちがなんとなくわかった。

でも、wordpressに書く記事がない。

高速化の経緯を記事にすればいいのかもしれないけどそっちにはあまり興味がない。

チューニングカーの同好会みたいなwordpress高速化同好会いかな?

2017-03-15

毎朝ぎりぎり出社の運用エンジニアです

今日会社障害対応

最近やっているプロジェクトはつまらない。

今やっている仕事の50%は運用プロジェクト関係

運用なので実装や開発ということもなく、何かシステム修正があればテスト、というような感じ。

障害も頻発するわけではないがそれでもつらい。

先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、

やっぱり運用プロジェクトというせいかモチベーションが上がらない。

最近は毎朝起きるのも遅い。

乗る電車もいつもぎりぎり間に合う電車

以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり

本を読んだり、ランニングをしたり自由に過ごしていた。

会社にはみんなよりも1時間早く来ていた。

きっとその頃は仕事が楽しかったのだろう。

会社に入ったばかりでやることはどれも新鮮。

少し難しい仕事も任されるようになってきてモチベーションもあったと思う。

仕事楽しいだけでなく充実感があった。

それが今では不思議と朝起きたくないのだ。

起きるのがつらいというか億劫

別に疲れが溜まっているわけではない。

目覚めは悪いどころかいつも目はぱっちりしている。

でも起きれない。ぎりぎりまで布団の中。

そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。

まり憂鬱なのだ会社に行くのが。

この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。

今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。

会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。

そういって同僚はフリーランス転職した。

今では職場でも私生活でもいきいきしている。うらやましい限りだ。

自分フリーランスにはなろうとは思わないけども、少なくとも今のプロジェクト半年が限度かなーとは思ってる。

同じ環境にずっと居ても成長できるか不安だし。

それに自分市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。

そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。

運用プロジェクトの残念なところは、仕事の大半が顧客対応コミュニケーションコストでつぶれること。

特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。

障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..

なんてことをつらつら書かなければいけなかったり。

なにより障害が発生したらものによっては休日にも出勤しなければならないこと。

まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。

体力には自身があるけども精神的にはわりときます。人によるのかな?

つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。

運用プロジェクトでは顧客対応必須だ。なので顧客との話し合いは上手くなる。

あと、運用エンジニアには広範な知識が求められる。

例えばフレームワーク脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。

ハードウェアミドルウェア障害が起きればそれに対する知識を駆使して対応を行う必要があるし、

ドメインが変わった、IPアドレスが変わった、となればシステム運用保守作業で影響がないか調査する必要がある。

なのでそのような対応を考える機会があるので勉強にはなる。

他にも必要知識として、プログラミング言語SQLはそこそこかけて、DBクライアントLinux操作、その他ミドルウェア知識必要になる。

なので現時点では自分スキルはそこそこ伸びてはいるのかなーとは感じている。

そんなこんなで運用プロジェクトは色々大変だよってことです。

理想運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。

めんどくさいことが多いけどもつまらなすぎて潰れないようにとりあえずがんばります

明日仕事ですね。みなさん一緒にがんばりましょう。

2017-02-26

自動化って

暗黙知をなくす作業でもあるなぁと思った。

Ansibleとかはサーバー構築手順書をなくすことができるし、mavengemなどのパッケージ管理ツールセットアップ手順の暗黙知をなくすことができる(なんのライブラリ入れるーとか)

人にあれこれ聞くより、コード見て大体わかるような感じになっているとすごく助かるんだよなぁ。

もしかしてそういう感じで仕事を続けていけば、英語圏とかでも仕事できるようになるのかなぁ。

vagrant up ← コレだけで開発環境揃う環境、素敵に開発に入りやす

わしが1年1人でやっているやつ、ミドルウェア系には秘伝ミソが少し出来ているから、dockerで全部揃うようにしてみるかなぁ。Solr使っている部分とかしょうがないような気もしつつ、ローカルにあったほうが良いんだろうなぁ。あんま頻繁に開発しないし、そこは自分でやればいいか・・・。まあ多分solrコンテナを立てれば良いんだろう。

2016-10-07

http://anond.hatelabo.jp/20161006152658

元増田程の良い生活は出来てないけど、それなりに良い給料を貰って良い生活が出来ている同じ世代の独り語り。

収入民間給与実態統計とかで上位10%に入るくらい。

自分勉強出来なくて底辺高校出身高卒だけど、同じくラッキーだったりが続いて転職の結果、

年収ランキングに入る一部上場IT企業に中途で入り、今の生活に至る。

インターネット誕生して発展していく時代に生まれたから、ゲームオタクパソコンオタクであることが武器になって、

好きなことを仕事にできる業界に進んだことが大きいとは思う。

(プログラム弄ってたり、適当ミドルウェアを入れて環境を構築したりが遊びになる)

ただ、そうなれたことの一端に

>でもそれも、そんなカードも、両親が必死になって繋いで手渡してくれた大切なカードだった。

これが大きいんだと思う。

親が好きに生きさせてくれたことで今があるんだなぁと言うこと。

思い返せば、小さい頃から勉強ができなくてテレビゲームばっかりやってたけど、親がそれを怒ることは無かった。

怒られることが無いから、勉強別にしなくて良いものと思っていた。授業中は「なんでこんなことしてるんだろ。学校先生ってのはうるさい人だ」位に思っていたと思う。

勿論勉強しなくちゃいけない時期にテレビゲームばっかりやってたから、wikipedia底辺高校と書かれるような高校に入って

名も無き零細ITしか就職できなかったけど、それも自分の行動の結果だから人のせいにしたり後悔するようなことは無かった。

どちらかと言うと大学に行けなかったことで、人より4年早く就職できたことのほうが大きかったと思う。

当時の現場が良かったのもあるけど、単調なコーディングテスト手順書ばかりではなく、いろんなことをやらせてもらえた。

2000年問題の前はまだ中小規模の会社でも元請け結構あって、今みたいに頭数揃えて人海戦術ばかりな業界じゃなかったしね。

エンタープライズIT業界労働集約産業になっていく中、インターネットが発展したくさんの技術が生まれたことで、

オタク知識武器になる時代が続いている。

結果として、少なくとも現時点では学歴が無くても良い生活が送れている。

何か幸せかってのは生きてみなくちゃ分からいね

いい大学に入って良い学歴を持つことは武器にはなるけど、別に成功約束されているわけでは無いので、

生きていく力や生きる目的を探すことも大事時代になってきてるのかなと言うこと。

2016-06-20

だめだ。

仕事中だが、我慢できない。

このくそ素人どもが。何年ITにいるんだよ。

ミドルウェアディレクトリパーミッションときにはまるとか、マジありえない会話が聞こえてきて戦慄している。

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2016-04-16

富士通20年勤務している側から見たお話

富士通退職した話」を読んで、20年近く努めている側から感想と疑問について書いてみたいと思います

山奥の工場

私も、情報科学大学時代専攻した後、新人で山奥というかむしろ雲の上にある天空工場に勤務してメインフレーム関連の仕事をしていました。

その工場に配属される新人は(希望すれば)寮に入るわけですが、高専卒は工場敷地内にある山頂の寮で二人部屋、学士卒は山の5合目にあるアパートの一人部屋、修士ドクターは街中にあるマンションという感じでした。

街中の下界から工場がある天上界への通勤バスで移動することになるのですが、わたしは、バスディーゼルエンジン排気ガスが苦手なので、頼み込んで工場敷地内にある寮にしてほしいと願い出て、山頂の寮に特別に入れてもらいました。そもそもが2人で一部屋なのですが、学歴関係か私は一人で2人部屋を使わせてもらっていたため、ものすごく広々と部屋が使えました。

わりと頼み込めば、人事や勤労も柔軟に対応してくれる会社という印象です。

メインフレームというレガシー業務

20年前でさえ、メインフレームは古いというイメージがありました。

ただ、私は古臭い部署に配属されたことは不幸とは思いませんでした。電話からスーパーコンピュータまで幅広く扱っている世界でも稀な会社に入ったからには、いろんなことを経験してみたい。

そのためには、そろそろ絶滅してしまいそうなメインフレームを今経験せずにいつ経験出来るのか?くらいな感じでむしろラッキーくらいに考えていました。

最新の流行を追いかけるのもそれはそれで面白いが、そういったものは出来合いのライブラリを組み合わせて流行を少し遅れて追っていく2位集団であるし、やりたければ個人で家でも出来るじゃないか程度の感覚です。

自分意見が割と通る環境

ただ、せっかくメインフレーム部署に来たのですが、私の担当ワークステーションで動作するUNIXPCでの開発が主体でした。

そもそもが、メインフレームを扱っていた部署ですから、先輩の人達はあまりUNIXPCに詳しくなかったので、大学UNIXPC経験した新人が入ってきたことは非常に重宝されました。

その部署では開発言語は、社内の独自言語(Cよりもさら機械語に近い言語マウスグラフィカルに操作してコーディングする言語)を使っていました。もともとはメインフレーム用の言語なのですが、UNIXワークステーションPC用にも

その言語コンパイラはあり、あわやその言語UNIXの開発する羽目になりそうだったのですが、私は猛烈に反対して自分意見を通しました。当時はJavaRubyなどの言語は無くCが全盛でしたが、

その部署の開発メンバーはCをほとんど知らなかったのです。そこで、社内のカイゼン活動として、C言語勉強会を開くことを提案し私が講師になってC言語メンバー習得してもらい、

PCUNIXでの開発は独自言語ではなくC言語を利用することを認めさせました。

元の増田の方は、自分エクセルVBAソースが見れない立場のようだと言っていましたが、ソースをみようとしたらシートにロックがかかっていたのを見て諦めてしまったのではないでしょうか?

元のEXCELを使った業務が非効率であるならば、業務改善活動として提案すれば、それを拒む上司というのはちょっと考えにくいです。

忙しい部署にも、改善活動ノルマが課せられるのですが、先輩はそういったことに関わっている時間が中々取れないので新人がそういった仕事をやると宣言しても拒むのはまずありえません。

案外苦労するゼネコン

下請けプログラマーからみると富士通のような会社中間搾取していて高給をとっているのに、仕事は丸投げという印象があるでしょうが、実際やってみると案外大変です。

私は、富士通本社SE的な立場グループ会社に出向して、そこから顧客先に派遣される4次受け5次受けのプログラマ両方を経験しましたが、はっきりと下請けの方が精神的に楽と感じました。

商売や、自分でやっているわけではない人に依頼した仕事について、責任をとるのは非常に苦しいものがあります。そもそもプログラミングはとても楽しいというのもありますが。

異動の希望はまず通る

私見ている範囲では違う部署に異動したいという希望100%通りました。異動を希望しているのにその部が解散するまでその部署にいる羽目になった人など見たことがないです。

もちろん、「プロジェクトが佳境で君に今抜けてしまわれては困る」というケースはあるのですが、IT業界プロジェクトの開発周期は年々短くなる一方ですから、割と早い段階で異動の希望は通る感じです。

もとの増田の方は巨大プロジェクトだったので大量の人がいるわけですが、こういった部署は異動の希望は通りやすいです。

なぜなら、新規プロジェクトで最も忙しいときは大量の人員を動員しているわけですが、バージョン2、バージョン3あるいはメンテナンスフェーズに入ればそんなに大量の人員必要がないので、会社としてもその部署人員を異動させたいわけです。

けれど、プロジェクトで中核の技術を担っているようなメンバーマイホーム天上界に立ててしまったメンバー、新しい仕事対応しにくい高齢メンバーは異動させにくいので、

EXCELをいじっているだけのような新人は異動の希望が通りやすいのです。

もとの増田も、もう少し我慢していれば希望が通った可能性は極めて高いですが、プロジェクトが佳境でまだ新人で入ったばかりといった状態では、もう少しその部署で頑張れと言われるだろうと思います

ただし、異動先の都合もありますので、ここから出たいはほぼ100%通りますが、あそこに行きたいは必ずしも通りません。

今更「京」スーパーコンピュータをやりたいといっても、人気部署ですし、プロジェクトの最盛期は過ぎているのでその希望が通る可能性は低いでしょう。

嫌な上司はすぐにいなくなる

色々な部署がある大きな会社では、管理職クラスは頻繁に異動が起こりますから、嫌いな上司はわりと直ぐにいなくなります。小さい会社だとそもそも部署が開発部と人事部営業部しかないというかんじなので、上司がやめるか自分が辞めるまで、嫌な上司と付き合う羽目になりがちです。

入社時の部署希望のコツ

新人研修期間が終わった後、人事の面談のチャンスがあるのですが、そこにはコツがあります

「おおざっぱにはっきりと希望を言うこと」です。

いちばん最悪なのが、大学での研究を話し、それを活かせる部署に行きたいと話すことです。

人事の人は技術には詳しくないですから研究内容が最先端であればあるほど、人事の人には通じないです。

キャッシュコヒーレンシが。。とか話すと、「よくわからないけどこの人は基本ソフトウェアに向いているのかな?だったら、自社でOSを開発しているメインフレーム回そう」という感じになってしまます

それよりは、人事の人が、会社組織のどの部署に配属すればいいかわかりやすいように、おおざっぱに希望をいうことです。

例えば、

上記のことを強い口調ではっきりというのが良いと思います

そのうえで、できれば○○製品をやりたいだとか、こういった業種のSEをやりたい等の希望だすと、どの部署に配属すればいいか相手にも伝わり希望が通りやすくなります

私の同期で入社して新人研修で山奥に配属されたバブル時代末裔のようなおねーちゃんとか、数人は、割とはっきり希望をいって、下界に戻っていきました。

2016-04-13

運用に向いている人が羨ましい

明らかに向き不向きがハッキリしていて、尚且つ向いている人が少ない開発に比べたら、運用の方が間口が広い(=向いている人が比較的多い)と一般には言われている。

しかし、自分は全く向いていなかった。


この業界に入ってから数年前まで開発一筋で来て、それからつい最近まで運用チームに加わっていたのだが、とにかく他の人に比べて明らかに動けなかった。

そもそも自分は「パッと見で動いてんだったら放っときゃいいじゃん」という人間なので、毎日毎日ルーチンワークで目配せがずっと続くとか、その時点でゲンナリだった。

それから監視対象の各機器(ストレージセキュリティアプライアンススイッチ等)や各種ミドルウェアメーカーごとに仕様が違いすぎて、またその仕様も込み入っていることが面倒で、それぞれのオペレーションを覚えるのも苦痛だった。

てかそんなモノに、一体どう興味を持てというんだ?

当然、どれもこれも大まかに把握している程度に留まってしまい、そういう中途半端理解だと、トラブった時に大変になると。

やたら読みにくいマニュアル片手に原因を探り、それでも分からないのでメーカーに問い合わせてログ提出→回答を元にオペレーション→やっぱり動かないみたいなケースが何度あったことか。

もちろん、そんな人間重要機器は任せられないので、自分などいてもいなくてもいいポジションに終始することになった。

正直、昼間の8時間は死んだ人間として過ごしていたに等しい。

あい経験はもう懲り懲りだ。


そんな自分経験から運用業務代表されるような、ああい灯台守みたいな業務をテキパキこなせる人は心底凄いと思う。

個人的には運用なんてもう金輪際やりたくないけど、一つだけ、開発と違って基本何も起きなければ残業無しという点はとても魅力的なのだ

一方、開発の「ややこしい物事を、コードドキュメントという形で、可能な限りシンプルかつ分かりやすい内容にまとめていく」感覚が何者にも代え難いのは間違いないが、夜遅いのだけは本当に何とかして欲しい。

昔、一人屋台で小さく短い開発案件ばかりやっていた時は比較時間自由が効いたけど、今はもうそんな仕事ないし。


そうなると、これからは身体が続く限り開発に従事し、本当にキツくなったら・・・一応経験ありの構築業務鞍替えするのかな。

2016-03-18

http://anond.hatelabo.jp/20160318203612

セカンドライフ時代ヘッドマウントディスプレイは、2メートル先に小さなディスプレイがあるだけだった。

今のOculusRiftを発端とする、広視野角型のヘッドマウントディスプレイは、解像度犠牲にする代わりに

左右100度程度の視野角で視界全体を覆ってくれる。

しかも、頭の動きに合わせて画面が変化するので、まるでその空間に居るような錯覚を感じるんだ。


リアルタイム描写でも、例えば、アンリアルエンジンというミドルウェアで作られたCG

少なくとも、セカンドライフ時代CGとはくらべものにならないくらい、本物らしい絵が作れるんだよ。

2016-03-10

得手不得手

イベントパーティに行った時、何に興味を示すかは人それぞれだろう。

「どんな人が来ているかな」「どんな食べ物が出るかな」などなど。


自分場合、そういう場所だと、演出ライトフォーカスしてしまう。

ライトの点滅を眺めながら、それがどんなパターンで動いているか見極めようとし、分かったら「ああ、なるほど」と勝手に喜んだり。

まり、世の中のあらゆる物事について、ルール法則性と言われるようなパターンを見出す形で理解しようとするのだ。

世界パターン化というアプローチによって抽象的に捉えようとすると言い換えれば聞こえはいいが、自分で作った思い込みに囚われやす性格とも言える。


そんな自分にとって、プログラミングなんて簡単な仕事の部類に入る。

コンピュータ人間と違って全く融通が効かないし、指示命令であるプログラムコンピュータ行間を読まないことを前提に書かないと動かないし、何よりコンピュータの側が操作する人間気持ちを汲んでくれることは絶対にない。

こう書くと極めて面倒なシロモノに思うかもしれないが、実はコンピュータに通じる共通パターンみたいなものがあって、それさえ分かってしまえば、あとはポイントを押さえ大いに効率よくやることが可能なのだ

からこそ、自分にとってプログラミングは好相性とも言える。

はいえ流石に家に帰ってまでプログラムを組みたいほどではないが、それでも仕事にしたのは人生の選択として自分をほめてやりたい。

もちろんシステム開発に占めるプログラミング割合は低い方なのだが、客が本当に欲しいものと、実装が楽になる方法の両方を常に勘案するという手法仕事を進めているので、今のところ大事故はやらかしていない。

また、「マニュアルを読んでその通りにする」のもこれまた得意。

そこに来てプログラミングの土台となるミドルウェアは「とりあえずこうすれば動くよ、そんな難しくないからやってみ?」みたいなスタートアップのための情報が必ずあるので、これまた「動かなくてギブアップ」という経験は皆無。


一方で、同じITであっても、アプライアンスストレージ管理がメインとなる、運用仕事は全く苦手だったり。

メーカー・機種ごとに色々違っていて標準的手法があまりないところに、それぞれ細かいところまで見ていかないといけないこともあって、自分お得意のパターン化があまり通用しないので、その時点で攻略する情熱や興味をを失ってしまうというか。


しか機械相手ならまだいい。

一番苦手なのは人間相手」だ。

要するにコミュニケーションが苦手なのだ

人間パターン化がほとんど通用しない相手の最たるもので、そんなパターン化とか考える暇があるなら、もっと目の前にいる相手のことをきちんと観察しろよって話である

しかし脳がパターン思考最適化してしまったせいか、相手ありきの現物合わせが全くできないのだ。

「どういう言い方や持って行き方だと、最もスムーズ意思を伝えられるか」は「相手が何を思ってその言動になっているか」という想像力問題になるが、その想像力自分には少しも備わっていない。

なのでマニュアルなんて読んでも時間無駄だし、多分そういう分野はマニュアルというよりレッスンor稽古or練習がモノを言う世界なので、マニュアルのものナンセンスという可能性が高い。

じゃあ練習すればって?誰を練習相手に?という取っ掛かりで詰んでいたり。

そもそも「パターン化できない」時点で「うわめんどくせー」と感じてしまう時点で、これ以上のコミュ力の成長は望めないだろう。

でも、もしこういうことが上手くできたら人生更に楽しいだろうなーとも思うので、なんとも悔しい。

お陰で、自分はこのままだとリーダー営業職をこなせる可能性はゼロだし、多分それは機会損失でもある。まあ無理にやって周囲に迷惑かけるよりはマシだけど。


これは余談だが、それもあってか、フィクション世界で目にする「人好き系リーダー」は、自分が最も好みのキャラだったりする。無い物ねだりの変形だろう。

ここ数年だと、ラブライブ!高坂穂乃果マイブームかな。

アニメ第一期ラスト3話の大ポカも含めて、愛すべきキャラだと思っている。

2016-01-25

http://anond.hatelabo.jp/20160123172824

私は以前、製薬会社実験データデータベースや様々な表示システムを作ったりマイクロアレイ解析などしてた。

その手の仕事をしている人は、社内に主にたった5人しか居なかった。

ネットワーク管理化学物質合成などする人は他にいた。実験する人はもちろん大勢いた。

知らないが、日本だと最大手でもこの手の仕事をしているのは合計数十人位ではないかと思う。

一方、世界大手企業だと数百人居たりする。

伝聞や想像だた、金融は多分世界比でもっと少ないだろう。

自動車企業だとそんなに悪くないかもしれない。

人工知能もっと居そうだけど新しい技術開発をできるのは日本で数十人も居ないのかもしれない。

例えば、リアルタイム3D画像認識技術が開発された頃日本にそれを十分理解できる人もあまりいなかった。

日本応用数学の分野は非常に規模が小さい。

科学研究を調べるとわかるが何にしても非常に人数が少ない。

相当重要テーマでも世界で数十人しか研究者が居ないのはよくあること。

例えば、量子コンピューターに関して調べてみると想像つくだろう。

一方、量子コンピューターを学ぶのはそれほど難しくない。本屋に本が何冊も売っている。

量子コンピューター研究者ネタが無いのかわからないが最近重力と関連付けたり無理やり感がある。

前世紀末に新卒就職したソフト企業最初20人以上のチームで開発したが、今では滅多にないだろう。

転職後は大規模なシステムにも使われているミドルウェアのコアを開発したが数人のチームだった。

まり技術を求められる仕事は非常に人が少ない。

今後私が主にやる仕事基本的に一人や数人ですることになる。

会社管理をしてもらうために存在するようなもの給料がどうとかは全く興味がない。

何をするにしても、地球上における到達状況を把握し、全生産活動理解すべしと思う。

例えば、ソフトウェアにはどのような種類があるか、そしてどの程度の規模で開発されているか大手企業はどうか、

十年後はどのようになっているだろうかと言うことをなるべく把握すべきだと思う。

ソフトに限らず、現在地球人エネルギー源などや多くの科学技術に関してそうすべきだと思う。

科学技術に限らず、社会自体理解もすべきで、特に兵器テロ犯罪などの背景など理解しておくべきだろう。

そこまで来ると、世界的な諜報機関なども普通存在だなと思えるようになって十分想像できるようになる。

そして、人類を超えた存在視野に入るようになってくる・・・

2015-11-08

http://anond.hatelabo.jp/20151107114532

そうだね。[上]君みたいな人材を伸ばすために、技術的にもビジネス的にもお互いがやりがいのある案件を、中年が生み出していかないとだめだね。

[中]はまだ様子見な部分があるけど、[下]は、来年以降に配属されてくる[上][中]にどんどん抜かれていくだろうな。

自分理系でもなかったし、IT転職する前は営業職だったので、ある程度のレベルまでは誰でも到達できると勝手に思ってた。

向き不向きって本当にあるんだね。

幸いうちは上流から下流。下流もアプリインフラなど。アプリwebモバイルもあるし、プログラムっていうカテゴリならミドルウェアモジュール作ったり、ドライバ作ったりもある。今後はbigqueryやディープラーニングみたいな分野も力を入れていく。

[上]君にはいろんなレイヤを。[中]君は2年くらいのスパンで開発のイロハを。[下]君は、申し訳ないがおそらく手をかけれるのは今年いっぱいくらいだろうから、開発から手を引かせるかもしれない。ひょっとしたら他に向いている作業があるかもしれないしね。製品サポートとかセールス周りとか。

自分部署は毎年数人だからなんとか見てあげれるけど、大企業で数十~数百で新卒とってるとこは、派閥も面倒だろうし、やっかみも多いだろし、大変だろうな。

2015-11-04

横には広がらなかったデキない俺の話

一口IT土方と言っても色々な仕事があるが、その中でもブラックという悪名大元になっている、開発の仕事新卒から手がけて10年になったタイミングで、上司から「人の上に立つキャリアに行かないなら、技術者として横への広がりを」と勧められ(加えて開発の仕事あんまり取れない事情もあり)、そこから数年ほど運用チームの一員として業務をやってきたが・・・俺にはこの仕事センスがまるっきり無いことが判明しただけに終わった。

というか、今はもう運用という仕事に対して憎悪感情しか沸かない。心底嫌気が差ししまった。

以下、色々向いていなかった系の主張メインの言い訳


俺が長く手がけた開発は必ずゴールがあり、それを踏まえた細部への落し込みの段取り仕事の核となる。そしてこの段取りを進める忙しさが常にあり、上手く行かなくなった時はブラック激務が待っていると。

一方の運用は、開発と比べたら桁違いにヒマで、しかもゴールがない。しかし、その緩やかな時間の中で日々業務改善に頭を巡らせ、より上手い回し方を工夫することが肝要である

まず俺は、この時間感覚仕事感覚の違いに、結局どうしても慣れなかった。ヒマに任せてひたすら惰眠を貪ってしまい、働かないオッサンに成り果ててていた。

多分このまま行ったら、給料泥棒としていずれ切られるだろう。


それから、今時のシステムにはサーバスイッチのみならず、大小様々なアプライアンスが含まれる。それもアプライアンスが基幹装置だったりすることは全く珍しくないので、こいつらの監視は非常に重要なのだ・・・俺はこのアプライアンスというやつに全く興味が持てなかった。

真面目な運用者なら仕組みや機能を率先して調べ、業務改善や次期システム提案に噛ませるなんてするんだろうけど、俺の場合「よくわからんブラックボックスで、でもなんかよろしくやってんだね、じゃあそれでいいんじゃね?」程度にしか思えず、出来れば障害の1つも起きないなら無視したいものだった。

これはもう運用者としては致命的にダメセンスだろう。開発で例えるなら「ミドルウェアに興味ない」とか「クラスライブラリフレームワークに興味ない」と言っているようなものである


うそう、開発と運用の違いと言ったら、確実に対立するポイントがある。

それは非機能要件の取り扱い。

開発にとって非機能要件というのは「障害発生時の検証用や、機能要件の異常系処理など、恙無くシステムを動かすのに最低限必要な仕組み以外は手を出したくないもの」だったりする。基本的に手を入れ始めたらキリがないので、やればやるほど仕事が増えてしまうのに、それに見合ったカネも時間も用意されていないことが多い(というかそんな見積もりを客に出すのは無理)からである

一方の運用にとっては「機能要件は満たせていて当たり前で、その上で特に障害時の対応を中心とした非機能要件はきちんと作られるべきものであるシステムトラブルで矢面に立つの運用者であり、そこで手も足も出なければ存在意義を問われるのだから当然だろう。

このように非機能要件だけ取っても、同じシステム屋なのに見ているポイントが全く違う。

それらが積もり積もった結果、開発から見た運用

「正直気にしたって仕方ないような細かいところまで質問してきて、いちいちこっちの回答を言質に取って、その上で文句ばっかり付けてくる面倒な奴ら」

となるし、運用から見た開発は

「いつも中途半端なモノを作り逃げし、いざという時も要領を得ない曖昧なことしか言えない、信用出来ない奴ら」

となる。

こういう、ともすれば対立の原因になる認識の違いを踏まえ、身も心も運用者になることが、俺にはできなかったと言ってもいい。


というわけで、これから俺はまた開発に戻る。

「流しのオッサンコーダー」として半年~1年単位現場を点々とすることになると思うが、何年も椅子に座ってログを眺めているようで眺めていないよりは会社に貢献できるだろう。

或いは若手開発者育成という名の、ブラック環境に飲まれないノウハウとか、「ハイリスクノーリターン」を避けるサバイバル術伝授とかやってもいいかなーと思っている。若手をOJTで潰すのは許せないので。

この場合、「この人にはどういう言い方をしたら通じるのか」という問題が今以上に重要になるだろうけど、それくらいは受けて立たないとという感じ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん