兼務による体制構築はプロジェクトの効率を損なわせる｜mtx2s
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事のマルチタスク化やミーティングの増加に苦しむ原因になります。組織の観点からも、兼務への依存は、知識の偏りや負荷の偏りという弊害をもたらすことに繋がりかねません。プロジェクトの観点から見ると、兼務という形での「人的リソースの共有」は、プロジェクト間での「リソースの競合」を引き起こしやすく、それが市場投入までの時間を長くする要
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
反インターネット論者としてのひろゆき - メロンダウト
２ちゃんねる創設者のひろゆき（敬称略）がインフルエンサー２位になり、政府に助言したと話題になっている。賠償金云々の問題は脇に置いておくとして、なぜ彼があそこまでウケているのだろうか。 個人的に、ひろゆきは反インターネット論者だと思っている。ひろゆきほどに日本のインターネットを代表する人間はあまりいなく、彼をネット論客として見る向きもあるけれど、むしろ逆なのではないだろうか。 近年、ネット上ではエコーチェンバー（先鋭化）現象が事を欠かず、政治的な議論においては党派性に埋没したものを多く見かけるようになった。ツイッターをはじめとしたネット空間でのそれは多くの人から見ると「近づきたくないもの」に成り果ててしまったのだろう。下手なことを書けば立花や福永や「は」の人に訴えられてめんどくさいことになる。君子危うきに近寄らずではないが、政治や議論が党派性に吸収されるとNoと言うことすらできなくなり、しま
SES企業はやめた方がいいですか？ - komagataのブログ
プログラミングスクールのフィヨルドブートキャンプを運営していて、就職に関するアドバイスを求められることも多いです。SESについてはよく訊かれるのでここにまとめて回答しておきます。 SESとは SES(System Engineering Service)とはソフトウェア開発・運用・保守における委託契約の一種です。特定の業務に対してエンジニアを派遣し、エンジニアリングの能力を時間で提供します。 他に一般的な契約として請負契約があります。（特定派遣については2018年に廃止されました） この二つは主に報酬の対象が違います。 SES：労働時間に対して報酬を支払う。 請負：成果物に対して報酬を支払う。 SESはその時間働いていれば必ずお金がもらえますが、請負は成果物（システム）ができなかったら報酬が貰えません。 請負が成果物によって報酬が出るか決まるということは、「成果物とは何か？」ということを事
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
プログラミングが出来る - Diary
プログラミングが出来る と一言で言ってしまうのはあまりよくなくて、ある程度分割して考えるほうがいいと思っている。 自分が必要なものを作ることができる みんながもっている共通の課題のうち、自分の技術力で解決可能なものを見つけて、解決するプロダクトを作ることができる 同僚と協調しながら製品を作ることができる おおまかにいって「プログラミングが出来る」というのはこの3個のスキルに分割できるのではないかと思っている。そして、これらはそれぞれあまり関係がない。 自分の課題を高速に解決することができるが、それを製品や OSS にまとめてリリースすることは出来ない人 優れた OSS のポートフォリオを持っているが、同僚という立場の人と協調することはあまり得意ではない人 業務としてプログラミングで成果を出してきているが、別に趣味で自分のためになんか作ったりはしてない人 ゲームを自作しているが、別にそれで食
ふき出しのレトリック 〜マンガの修辞学〜
2008/05/25 : サイトを移転（「いま」見ているのが、移転先のサイトです） 2008/10/04 : 「使う目的別のまとめページ」をバージョンアップ 2008/10/04 : 倒置反復に画像を追加して加筆 2008/09/26 : 脚韻のページにある内容を、かなりに変更 2008/09/20 : 島村瀧太郎（抱月）『新美辞学』のページを作成 2008/09/07 : 隠喩に画像を追加して、加筆 2008/08/30 : 設疑法を追加 2008/08/23 : 直喩に画像を追加して、加筆 2008/08/16 : 韻文を追加、押韻・頭韻・音数律に加筆 2008/07/19 : 祈願法を追加、緩叙法（付加）に画像をつけ足して加筆 2008/07/18 : カウンタが100,000を突破（祝） 2008/07/12 : 「使う目的別のまとめページ」というものをつくり
プログラミングはそれ自体が目的であっていい - mizchi log
これ読んで思ったこと。 プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思
プログラミングは「名前」が9割。 - このブログは証明できない。
プログラミングというのは、名前をつける行為なんだと思う。 プログラミングで一番大切なこと。 もしも、プログラマーじゃない人に、「プログラミングで一番大切なことは？」と聞かれたら、迷わず「名前」だと答える。もちろん、人それぞれだし、自分はスキルの高いプログラマーじゃないよ、と前置きして。 名前が9割と言ったときの、9割という部分は人によってだいぶ差があるんだと思う。もっと小さいかもしれない。けれど、名前が重要だという点に関しては、反対するプログラマーはいないんじゃないだろうか。 時代や環境で変わる名前。 いま僕がイメージしてる名前というのは、変数名だったり関数名だったりクラス名だったり、とにかくいろいろ。さらに、JavaScriptとか高階関数をバリバリ使うような場合など、名前をつけないという選択肢もある。 なんとなくJavaScriptと書いたんだけど、名前はプログラミング言語や開発環境や
論理的であるかのごとくに装って、根拠のないイチャモンをつける 13+2 の方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
ちょっと挑発（コレの最後）してみたけど、どうせ反応はないだろな。しらけてしまわないうちに自分でテンション上げて解説を書いてみました。 内容： 前がき 本編 定義の違いを真偽の議論にすり替える 言ってもない事を否定して印象操作をする 傾向や量に関する主張に、勝手に全称限量子を付けてしまう とある階層でなされた主張を、別な階層で否定する 権威や前例に訴える 権威や前例に訴える 別バージョン 論点ズラシ、意図・論点の曲解 論点ズラシ、意図・論点の曲解 感情バージョン 意味もなく自分の経験や知識を強調 問題点を他の事情により帳消しにする 意味不明でもいいから難しそうなことを言ってみる 普通とは異なる解釈を持ち出す 反論されたときは最小コストでごまかす 余計なお世話な悪口も辞さない 言い張る 後がき 前がき すぐあとに続く「本編」では、ホントに「根拠のないイチャモンをつける方法」、もう少し正確に言う
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
会心のおじさんが描けた！プロ漫画家が「おじさんキャラを生み出す」苦悩と技をベストテンで公開 - QJWeb クイック・ジャパン ウェブ
（採用担当者向け）エンジニア採用をする上での基礎知識 / recruting_engineer_basic