【島国大和】無茶ぶりはなぜ生まれるのか？ どうすれば避けられるのか？
【島国大和】無茶ぶりはなぜ生まれるのか？ どうすれば避けられるのか？ ライター：島国大和 島国大和 / 不景気の波にもがく，正体はそっとしておいて欲しいゲーム開発者 島国大和のド畜生 出張所ブログ：http://dochikushow.blog3.fc2.com/ かつてのゲーム業界の労働環境は，本当にえぐかったとよく言われます。休出や徹夜は当たり前，初任給で買うのは寝袋。 自分もゲーム業界に来たばかりの頃，先輩から，「イスを並べて寝るときは，背もたれを互い違いにすると落ちにくい」という，ありがたいアドバイスをもらったことがあります。 ほかにも，休日にオフィスで殺虫用のくん煙剤を焚いたら，机の下で寝ていたプログラマが何人もあぶり出されたとか，業務の過酷さに耐えかねて失踪したディレクターをMMORPGの街に探しに行ったとか。 ひどい話はいっぱい聞きましたし，実際に体験したこともあります。 な
ほんとうにあった開発生産性が爆下がりする話 - Qiita
昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。 しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。 この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。 (私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください ) 修正前のコードはコメントアウトで残す 当時、ウォーターフォールで開発していました。 ウォーターフォールでは開発工程とテスト工程が分かれています。 開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。 問題はここからです。 とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、
スタートアップ1人目EMが1年でやってきたこと｜Yoshiki Iida
こんにちは、ログラスでエンジニアリングマネージャー（以下EM）をしております飯田です。 昨年12月にEMをはじめましたという記事を書いてから早くも3Qの月日が流れ現在4Q目を過ごしています。 私自身は前職でも現職でもエンジニア→EMというキャリアとなっており、現職ログラスでも1人目EMとして立ち上げを行ってきました。 当時EM取り組むにあたり、掲げていたことがいくつかあります。ざっくりまとめると、 エンジニア ⇄ EMで必要であれば柔軟に行き来できるようなフレキシブルな組織を作りたい スタートアップの初期フェーズから盤石なマネジメント基盤を作りたい 長期でパフォームし続けられる組織を作りたい です。 この記事ではこの3Qの中で取り組んできたことと、それによって上記のやりたかったことに近づいたのか？をご紹介できればと思います。 スタートアップのマネジメントのスケールに悩んでいる人（EMに関わ
開発組織をデザインするための3つの観点 - エス・エム・エス エンジニア テックブログ
@sunaot です。前に一緒に働いていた同僚からこんな質問が来ました。 組織が肥大化しすぎてアレコレうまく行かない事が増えてきたので『ユニコーン企業のひみつ』を読みました。 他にも他社の事例とかも見ていたりするのですが組織の布陣とか参考になるおすすめの書籍などありますか？ 今はマネージャーをやっていて組織の設計に困っているようです。回答をするために考えてみたのですが、開発組織の組織デザインをピンポイントで語った本というのがありません。『ユニコーン企業のひみつ』は Web のサービス会社のチーム開発について語った良い本なのですが、組織論ではないためほしいところとやや違ってきそうです*1。 そこで、同じような悩みを抱えている人に向けてサービス会社の開発組織の組織デザインについて、実際に6年以上試行錯誤してきた立場から考えるべき観点というのをまとめてみようと思います。 結論から言ってしまうと、
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
永和システムマネジメントを辞めました - takkanm’s blog
題意通りですが、永和システムマネジメント(以下 ESM)を 2020/01 の末日をもって辞めました。 新卒入社からずっとで 13 年と 10 ヶ月の勤続となります。 私が就活をしていた 2005 年は、ちまたで LAMP が流行りだした頃でしたが、当時は Ruby で仕事できる職場などはありませんでした。 そこで、当時は Linux に関われる会社を探していたときに、地元の企業で Linux のディバイスドライバ開発の仕事がある会社を発見しました。 それが、ESM との出会いでした。なので、実はアジャイルソフトウェア開発とか XP という文脈はまったく触れずに入社を決めていました。 そういうのに強い会社というのは、内定もらった後の WEB+DB かソフトウェアデザインの記事で知りました。 私のお仕事としてのキャリアは Linux のディバイスドライバ開発プロジェクトからスタートします。
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
