なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
新しいディレクターが来て会議を変えた話
がっきー@漫画家総合垢 @gakky88NSR ゲーム開発時代の話。 開発の中盤、開発は難航していた。 会議はミスやトラブルの責任の追求が中心に行われ、処刑場になっていた。 ある日、新しいD（ディレクター）が配属された。 僕の大好きなゲームを作った人だった。 2017-02-10 22:39:45 がっきー@漫画家総合垢 @gakky88NSR Dが来て初めての会議。 リーダーはいつもの様にミスした者や遅れた者を探し、追求し、叱った。 Dはそれを見て笑った。 「ずっとこんな事してたの？」 「やめやめ！会議のやり方を変えます」 2017-02-10 22:40:07 がっきー@漫画家総合垢 @gakky88NSR 「まず、進捗の報告は出来てない物、問題のある物だけで良いです。 出来てる物は予定表で分かるから必要無い。 で、その問題がどうすれば解決出来るか、助けがいるなら何が欲しいかだけを話し
効率的に仕事するために考えて欲しい７つのこと - ゆとりずむ
こんにちは、らくからちゃです。 システム業界に身を置いておりますと、色んなお客様とお仕事をさせて貰う機会があります。システム構築はお客様との二人三脚。お客様の作業効率が弊社の作業効率に直結することも多いものの、横から『こうしたほうがええんとちゃうの？』とも言い出せず、悶々としてしまうときがあります。 そこで直接は言いづらい『ここらへん考えてみてほしいなー』という点について、だらだら適当に書いてみます。ありきたりのことしか書きませんが、どこかのプロジェクトの燃焼速度が多少なりとも遅くなれば幸いです。 例題 例えば、上司からこんな風に指示されたものとします マーケの部長が、修理案内の通知を封筒に詰めて送る作業をやってくれるひと探してるんだけど、お願いしてもいい？ 宛先と対象商品と諸々が書かれたA4用紙が1000人分くらい来るからさ、宛先が東日本なら茶色、西日本なら白色の窓付き封筒に入れて糊付け
平社員が経営陣に一言「全員辞表を出してください」朝倉祐介氏がミクシィ復活劇の舞台裏を振り返る
走らない馬を走らせる3要素「理、心、運」 朝倉祐介氏（以下、朝倉）：はい、朝倉でございます。 （参加者から「ミクシィ！」の声） 朝倉：私は、15歳の時に競馬の騎手の候補生としてキャリアをスタートしました。以来、会社の経営も含めて、世の中で起こるだいたいすべてのことは、馬に例えて理解をしています。 （会場笑） 今日は、「走らない馬の走らせ方」すなわち衰退期に入った会社をいかに立て直すか。これを、株式会社ミクシィでの企業再生の経験をベースにシェアできればと思います。 走らない馬を走らすにあたって、私は3つの要素が必要だと考えています。理、心、運。 理。これはすなわち戦略だとか方針。頭で考えることですね。心。これは頭で考えたことをやり抜くタフネスさ、エグゼキューションの部分。運は読んで字の通りです。 問題は、この理と心と運、後付けでどれぐらい結果に貢献していたのか。この比率なんですけれども、私、
２倍の早さで仕事が出来る人に２倍の仕事を振るのをやめて利益を2倍に増やした会社の話 - ゆとりずむ
こんにちは、らくからちゃです。 遅ればせながら、やっと弊社まで働き方改革の波がたどり着いたのか、社内でも色んな意見を耳にするようになりました。残業時間の制限やリモート勤務によるワーク・ライフ・バランスの改善など働く環境がよくして、労働生産性を高めて行く方法をみんなで考えるのは大変有意義なことです。 最近聞いた話で、面白いなあと思ったものがありましたので、簡単にご紹介したいと思います。 とある副社長の改革 ことの発端は、とある３０人ほどの規模のシステム開発会社の社長が体調を崩してダウンしてしまうところから始まります。取引量は毎月のように増えていたものの、そのことから生じる過労により、心身ともにダメージを受けすぎていたことが原因でした。 とはいえ、ひとりの会社では有りませんし、社員を路頭に迷わせることは出来ません。そこで社長は、以前から付き合いのあった別のシステム開発会社に『経営権を譲渡するか
CodeIQについてのお知らせ
2018年4月25日をもちまして、 『CodeIQ』のプログラミング腕試しサービス、年収確約スカウトサービスは、 ITエンジニアのための年収確約スカウトサービス『moffers by CodeIQ』https://moffers.jp/ へ一本化いたしました。 これまで多くのITエンジニアの方に『CodeIQ』をご利用いただきまして、 改めて心より深く御礼申し上げます。 また、エンジニアのためのWebマガジン「CodeIQ MAGAZINE」は、 リクナビNEXTジャーナル( https://next.rikunabi.com/journal/ )に一部の記事の移行を予定しております。 今後は『moffers by CodeIQ』にて、 ITエンジニアの皆様のより良い転職をサポートするために、より一層努めてまいりますので、 引き続きご愛顧のほど何卒よろしくお願い申し上げます。 また、Cod
タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話
何度か書いていますが、しんざきはシステム関係の仕事をしており、今はそんな大きくないチームの責任者です。自分でも色々作業しますが、一応マネジメントもする立場です。 今とはまた違うチームにいた頃、チームの統合・再編成が行われたことが何回かありました。 チームメンバーは増えたり減ったりしますが、大体毎度、新しいメンバーを何人かは見ることになります。 当たり前のことですが、知らないメンバーと一緒にやっていく際には、まずその人にどんなタスクを振るか、どうタスクを振るかを考えないといけません。 何か新しい技術に触れていくならどのようにスキルのキャッチアップをしてもらうか考えないといけませんし、引き継ぎがあるなら引き継ぎの計画を立てなくてはいけません。 だからチームの再編成の時には、本格的に仕事を始める前に、それぞれのメンバー、及びそれぞれのメンバーの以前の上司に必ず面談とヒアリングをします。いや、別に
ADHDで管理職をやっている者なんだが
週末の借金玉氏(id:syakkin_dama)のエントリやそれを受けて書かれたわかり手氏(id:ganbarezinrui)のエントリ、http://anond.hatelabo.jp/20170227005158 あたりのブコメとか読んでいて、随分と世知辛いねえ、と思ったのだけれど、良い場所が無いので増田にこれを書いている。たぶん超長い。 俺はタイトルに書いてあるようにADHD（診断済み）だ。典型的な注意欠陥・多動性が認められ、一方でASDの症状はゼロという純正ADHDマンである。なので先のお二方のエントリは全力で泣きながら、共感しすぎてヘドバン状態で読んだ。でもわからない人には何が「なので」なのか本気でわからないんだと思うし、それで正常なんだろうということも理解している。 んで、一般的なIT関連の企業で管理職をやっている。それなりに多様な部下もいる。業界的にブラックな香りがするWeb
開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
ぬるま湯 or 過重負荷のチームを脱却せよ–伊藤直也が「1人CTOナイト」で話したヒント - ログミーTech
2016年8月30日、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」が開催されました。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。本パートでは、伊藤氏がチームが抱える課題をいち早く見つけるためのフレーミングと1on1について話しました。 チームが最もベストな状態は「責任と心理的安全性が高い」 伊藤直也氏（以下、伊藤）：次は、「組織課題の発見とアプローチ」について。 僕が最近すごく気に入っている考え方がありまして、それが「心理的安全性と責任」という話なんですよね。『チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ』に書いていたもので、ここでもやはり「2
部下が全員働くママになったら、私の残業時間が減ったという話 | 自分の心を殺してはいけない| Gallup認定ストレングスコーチしずかみちこブログ
出勤の不安定さとその対策 働くママと一緒に仕事をする際に、まず頭に入れて置くべき点がある。 それは、出勤が不安定ということだ。 子供は常に体調を崩すと覚悟した 私自身には子供がいない。 なので、子供があんなにも熱を出すとは知らなかった。 子供が体調を崩す理由は山ほどある。 インフルエンザに食中毒。季節の変わり目。 溶連菌という言葉はこの時初めて聞いた。 メンバー2人ともが突然休み、一人でぽつんと呆然と始業時間を迎えたこともある。 対策は、スマホで この問題には対応方法があった。 メンバーが私たち3人のLINEのグループを作ってくれたのだ。 子供の具合が悪くなると、休日でも夜でもその段階で「長男、発熱中」などとLINEに書き込んでくれた。 朝になって突然子供の具合が悪くなったときは、朝の5時や6時の早い時点でそのことを知らせてくれた。 出社の状況が早い段階で分かると、仕事の調整が余裕を持って
ゼロからはじめるプロダクトマネージャー生活
フォーカスするためには、たぶんどうやってフォーカスするか（前回）に加えて、何にフォーカスするかを決める必要があって、今回は後者、つまり「フォーカスポイントを決める」方の話です。 スタートアップの初期は Y Combinator 的に言うところの Do things that don’t scale （スケールしないことをしよう）をはじめとした明確なフォーカスポイントがあると思います。ただ次第に自分たちでフォーカスポイントを決めなければいけなくなってきて、そのときにどのようにフォーカス先を意思決定すれば良いのか、どうすれば良い意思決定ができるのか、という問いが出てきて、その際に方法論の必要性が生じます。 そこで意思決定の方法論を検討するのですが、スタートアップのような情報不足や資源の制約下では、ゲーム理論をはじめとしたいわゆる規範的な normative 意思決定理論よりは、行動経済学や認知
仕事において「裁量がない」時の精神的負担は、想像するよりも遥かに大きい。
このメディアの書き手の一人である高須賀さんから、メッセージを頂いた。 高須賀さんは、月200時間以上の超長時間労働を経験されたということだったが「結構がんばれていた」という。 ただしそれは「指示を出す側」という条件付きの場合だった。 それでも指示出し側だったのもあって、結構みんながんばれてましたね。逆に指示出される側のコメディカルは、勤務時間が僕らよりも少なくてもバンバン消えてってましたし。やっぱり裁量の有無は大きいなぁと 私も同様の記憶が数多くある。 例えば、私が新人の時に一番キツイと感じた仕事が、実は「上司・先輩のコンサルタントへの同行」だった。 「上司や先輩のコンサルタントへの同行なんて、任せてればいいからラクじゃない」 という方もいるが、とんでもない。あれは一番負荷が大きい仕事の1つだ。 仕事に慣れておらず、自分だけでは何一つできない状態で、先輩からの指示だけ飛んで来る。 ・議事録
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
【翻訳】プロダクトマネジメントトライアングル - ninjinkun's diary
original: The Product Management Triangle (by Dan Schmidt) (translated by ninjinkun, reviewed by Kosuke) はじめに プロダクトマネジメントは多くのソフトウェア企業が重要だと認識している役割だ。それにもかかわらず、「プロダクトマネジメント」を正確な言葉で定義することは驚くほど難しい。自らを「プロダクトマネージャー」と呼ぶ人々は、企業ごとに全く違うことをやっている。彼らは異なるタイプのプロダクト、異なるタイプのチーム、異なる組織構造の中で働いている。このプロダクトマネジメントの立場の違いは、とても不毛だ。外の立場から見ていると、同じ肩書きの仕事を参照する際に、誤解を引き起こしているように見える。全てのプロダクトマネジメントの仕事を統合して、共通の話題を抽出しようとすると、価値を説明しようとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
UX MILK
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
開発組織マネジメントのコツ - Speaker Deck
Composer
