9年前から4年弱ほど富士通にいたものです - Ryoの開発日記 Neo!
なんか下の増田がバズってたので乗っかってブクマ稼がせてもらいますね。 5年いた富士通を退職した理由 https://anond.hatelabo.jp/20190326233147 自分は2010年から2014年頭までの4年弱勤めてました。 担当業務はスパコンのミドルウェア開発。まあ、いわゆるスパコン京とかのやつですね。 詳しくは以下の退職エントリ参照 https://ryogrid.hatenablog.com/entry/20140120 で、書いてある内容だけど、多分嘘ではないのでしょう。開発機とかは確かに似たようなもんだったし。でも、自分の場合は、どうせ、SSHで開発用のサーバとかに入ってEmacsとかでコード書いてたのでスペックとか別にどうでも良かった。 というか、どこらへんの部署にいたか書いてないのでなんとも言えないというのが正直なところ。 せめて、事業部か、SI部門か、研究所
私が仕事をしてきた中で「最も合理的」と感じたリーダーの話。 | Books&Apps
もうずいぶん前のことになる。 あるIT業の業務改善プロジェクトに、私はいちメンバーとして参加した。 その会社のプロジェクトメンバーは全部で8名。期間は約9ヶ月だった。 経営陣肝いりの、それなりに大きいプロジェクトである。 そのため、プロジェクトマネジャーは、掛け値なしに優秀であった。 指示は的確で、果敢に新しいことにチャレンジするが、無用なリスクは取らず、守りが堅い。 メンバーとの関係も付かず離れずとバランスが良く、理想的な人物だった。 だが経験的に、プロジェクトメンバー全員が優秀であることはほぼない。 政治的な理由からか、教育効果を期待してなのか、リストラ予備軍だからなのか、それとも単なる人手不足なのか。 理由は様々だろうが、プロジェクトメンバーの中に、必ず２，３名はボンクラが含まれているのである。 そして、プロジェクトは一定の期間内に成果を出す、という厳しい制約があるため、無能の扱いを
デスマーチ・激務に巻き込まれたアナタが取るべき12の対策【メンバー編】 - プロジェクトマネジメントの話とか
新社会人になろうとしているあなたが、「デスマーチ」（＝不眠不休の連日徹夜の炎上プロジェクトを想定します）という激務の壁にぶつかったときに、当記事が何らかの参考になれば幸いです。 私は約10年間、下流工程寄りの仕事に従事した後、上流工程へシフトしました。プロジェクト炎上の火消しにPL（プロジェクトリーダー）やPM（プロジェクトマネージャー・プロマネ）らが右往左往するものの、最終的なしわ寄せが「実装を担う開発現場」に来てしまう現実を、何度も目の当たりに、いや、実際に経験してきました。 根本原因の解明が必要ではあるものの、一メンバーである個人の権限ではコントロールできない要素がほとんどだったりもするわけです。今回はメンバー側の視点として、デスマーチという激務のやり過ごし方、取るべき対処について考えてみましょう。もちろんIT業界以外の「絶賛激務進行中」なアナタもご一緒に！ スポンサーリンク １．責
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブルックスの法則
