なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。 - Qiita
「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用（業務委託含む）する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール
若い会社でエンジニア組織の上司として大切にしていること3つ - netmark.jp
4月、新生活、な雰囲気。 というわけでたまにはポエミーなことも書いてみます。 新たに部下を持つことになった人もいると思うので、 そんな人に役に立つかもしれない、 私が上司として大切にしていること3つを紹介します。 前提として、 HRやリーダーシップについて大学院やものの本である程度知識はつけているものの、 きちんとした専門のトレーニングを受けているわけではありません。 なにか勘違いとかがあれば教えてください。 人材マネジメントも組織マネジメントもプロジェクトマネジメントも得意なわけではないですが、 現実的に直轄の部下が20人近くいるわけで、 なかなかに悩ましいところであるわけです。 短期的な視点と長期的な視点は両方持ちつつ、 落とし所を探しながら日々過ごしています。 その1: 自分を基準にしない 思い遣りがないと感じられるかもしれませんが、 「自分だったらどうか」 「自分だったらどう感じる
新サービスを立ち上げる際、エンジニアとしてやって良かった 9個の事 - Money Forward Developers Blog
エンジニアの渋谷です。 マネーフォワードは3月30日に【給与計算ソフト - MFクラウド給与】という新サービスをローンチさせていただきました。 マネーフォワード、クラウド型給与計算ソフト『MFクラウド給与』(β版)を無料提供開始～法改正や税制改正にも自動対応。企業の給与計算・労務をもっとスマートに～ クラウド給与計算ソフト マネーフォワード クラウド上で完結する本格的な給与計算サービスとして、リアルタイム給与計算機能や料率自動反映などを備えております。 本サービスの企画自体は、昨年年末に３人でスタートし、年明けから様々な方にお手伝いいただきながら、約３ヶ月の開発期間でローンチしました。 今回は、新サービスをゼロから作り上げるにあたり、エンジニアとしてやって良かった、と思えた事を９つばかり紹介させていただきます。 １：リリース前確認シート 企画がスタートした時に、【ビジョン】【ミッション】と
そろそろ「プログラマー35歳定年説」を徹底論破しとくか - 書架とラフレンツェ
世の中に流布している「プログラマー35年定年説」は、大きく以下の3つに分類できる。 プログラマーは激務なので、35歳を過ぎると体力低下のために続けられなくなる(体力低下説) プログラマーは常に新しい情報を吸収しなければならないが、35歳を超えると脳の働きが低下して新しいことを覚えられなくなるために続けられなくなる(学習能力低下説) プログラマーは35歳を超えると開発ではない業務を求められるようになるので、技術職としてのプログラマーのキャリアが途絶える(マネージメント原因説) 以下、ひとつずつ検証していく。 体力低下説 まず1つ目の「体力低下説」だが、これについてはそれほど深く考る必要がなさそうに思える。周知の通り気力や体力には個体差があり、若くても元気がないひともいれば歳をとっても元気なひともいる。また、35歳あたりの体力低下の原因としては、単純な加齢というよりも生活習慣の要因の方が大きそ
多種多様な基準から見るプログラマの市場価値 | POSTD
私は毎日、 Teamed.io で働くことに興味のあるプログラマから何通かメールをもらいます。彼らへの最初の質問は「あなたのレートは？」（ 当社は時給ベースで給与を計算します ）ということです。何より驚かされるのは、2つの方向性で、誤った試算をしているプログラマが多く見られるということです。 時給5ドルから500ドル（600円から60,000円）まで答えはさまざまです。決して否定はしませんが、私自身で代案を出してみます。このブログ記事では、どういった要素を計算に入れるか、または入れないかを述べたいと思います。私の個人的なキャリアもありますが、これが業界のスタンダードとは思わないでください。あくまで客観的で論理的だと思っていますが。それでは説明しましょう。 オープンソースへのコントリビューション ソフトウェア開発者にとってまずポイントとなり、かつ重要となる特性です。あなたはオープンソースプロ
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とそ..
新米マネージャが管理する小規模プロジェクトにおいて発生する諸問題とその対策について※マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。 「自分が開発すればこのくらいでできる」問題上司「この間言ってたプロジェクトの見積もりできた？」 マネージャ「たぶん2週間ぐらいでできますよ！wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です！」 デザイナ「完全オリジナルのwordpressデザイン2週間か、なんとかなるかな?」 プログラマ「PHP未経験なんだけど大丈夫かなあ…」 .... 略 .... 上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない？」 マネージャ「違うんですよ！デザイナーが全然テンプレートの使い方覚えてくれないし、あのプログラマ人PHPわからないとか言って仕事中にPHPの本とか読んでるから遅れたん
ソフトウェア開発時に気をつけてる振る舞い - futoase
他人と開発する多人数開発(2名以上)のお話。 なんとなく思ってること。 修正してください 仕様が変更になった上での変更であれば、修正ではない。 ので、「変更した理由」と「変更して欲しい意図」を説明する。 その前に一言、「修正」とかチケットで「修正」とつけてはいけない。 その人は「変更前の仕様」を充足した形で実装していたのだから。 バグを出した後の言葉かけ 僕は率直に、見つかってよかったと思うし、そう表現するのだけど、 人によって追い詰める言葉を発してしまう。 追い詰めると、次バグが見つかっても「気が付かなかったフリ」をされてしまう。 そうなると品質が下がる。意味が無い。 話を自己の経験100%で話してしまう 自分が得られた知見は重要なんだけど 働いてきた場所は10も無いだろう。というので 50%ぐらいに抑えて、後は他社の事例とか、 なんか優れたようなドキュメントとか開発の歴史事例とか それ
ソフトウェアエンジニアがたどる成長過程と失敗の行きつく先 | POSTD
これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり
ソフトウェアエンジニアリングにおける認知バイアス5つ | POSTD
人間の論理は、私たちがプログラミングして毎日使っているマシンの論理とは違って完璧ではありません。人間は間違えますし、悪い精神的習慣を確立してしまいますし、エンジニアとして成功するための能力に悪影響を及ぼす認知バイアスをたくさん持っています。ソフトウェアエンジニアとして定期的に目にする一般的なバイアスのうち5つを見ていきたいと思います。 1. 根本的な帰属の誤り 根本的な帰属の誤りは、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアスとも。 （参照） これは私のお気に入りの認知バイアスです。”至る所で”見られるからです。道で誰かに行く手を遮られると、その人を完全に嫌なヤツだと思ってしまいますが、自分が同じことをしてしまう時は、相手が見えていなかったとか、会議があって遅刻できなくて急いでいたといった理由があります。誰かがバグを
「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova
http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem（個人批判をしない建設的な障害の振返りミーティング）というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが
転職活動してて訊きたいことのメモ
転職先に訊きたいチェックリスト.md 制度 有休… 病休… 育休… 年収（月給、賞与など）… 残業代… 早朝/深夜手当… 休出手当… 住宅補助… 通勤補助… 資格手当… 人事評価… 自動車/自転車通勤… 健康保険… 保養施設… 部活動… 退職金… 確定拠出年金… ストック・オプション… 社員割引… 資格取得補助… 社内教育… 社外セミナ/カンファレンス/勉強会補助… 稼動日/休日… 個人の働き方 残業… フレックス勤務… リモート勤務… スーツ/カジュアル… BGM… 転勤… 職場 PC… モニタ… 机・椅子… 島固定/個室・ブース/フリーアドレス… 空調… ホワイトボード… 本棚… ロッカー… 休憩場… 自販機… ランチ… 業務ツール エディタ… IDE… ブラウザ… ドキュメント… グラフィクス… 翻訳… ターミナル… 仮想化… 継続的インテグレーション… レビュー… 静的コード解析/
何年か会社で働いてきて、なんとなく気付いたことや思ったことを淡々とまとめてみる | 感謝のライフハック
■誰もが「自分ばっかり忙しい」と思っている 後輩も先輩も、派遣もバイトも、みんな「自分は大変だ。自分に仕事が回ってきて、自分ばっかり忙しい」と思っている。 仕事ができないと思っていた後輩の口癖は 「俺は忙しいんです」 だ。あんまり、仕事は抱えていないはずなんだけど・・・。 Chromeのインストールも自分でできないような派遣の方も、ある仕事の進捗を尋ねたら、 「私は忙しいんです」 と言っていた。 仕事ができる先輩も、 「俺ばっかり仕事が回ってきやがる」 みたいに言っていた。 誰もがみんな、自分はすごく忙しくて、自分ばっかり頑張っているように思っているのだ。 みんな、主観で忙しいのである。 ただ、そんな中、本当に仕事もできて人間的にもカッコイイ先輩は、どんなに仕事が回ってきても、黙々と、淡々とこなしていた。 こういう人になりたいと思った。 ■マネジメントと将棋の関係 大企業だとありがちなんだ
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
リソースが足りない時にプロダクトマネージャーとして身に付けておきたい10の心構え | ライフハッカー・ジャパン
あなたは、スタートアップまたは大きい組織の商品開発チームの一員です。すべてが緊急で、すぐに終わらせなければならないことばかり。リソースは足りないが、何とか帳尻を合わせなければ。不安が襲う。モチベーションは、悲観や皮肉に姿を変える。すべてが悪くなり始める。かつてないほどに悪く。 そんな経験はもうこりごり。そんなあなたのために、リソースがまったく足りない状況で、迫りくる困難をどうやって乗り越えていけばいいか、私が経験から学んだ10の教訓をお伝えします。 1. パニックにならない 言うは易しですが、パニックにならないことが何よりも大事。冷静でいなければならないときにイライラするのは、もっとも避けなければなりません。事態は、思ったよりも悪くないはず。そう、決して。 だから、お茶を飲みましょう。散歩に行きましょう。同僚と話しましょう。心をすっきりさせましょう。すっきりした心は、大切な資産です。 2.
アーキテクチャ設計の難しさについて - arclamp
アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ
プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビューの話