ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる６つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ
落ちこぼれディレクターに贈る「失敗を回避する術=自分セーフティネット」の作り方 : LINE Corporation ディレクターブログ
こんにちは、livedoor Blog担当の眞子裕介です。 今回は、さんざん失敗を重ねた落ちこぼれディレクターの私が、自らの経験を基に学んだ「失敗を回避する術=自分セーフティネット」について説明したいと思います。 この「失敗を回避する術=自分セーフティネット」を身につければ、いまより打率が上がるはずです！ これまでの悲しい体験から私が学んだ技を生かして、皆さんのプロジェクト遂行に役立てていただだければ最高です。 経験の多い会社であれば、すでに先輩たちが作ってこられたフォーマットやチェックリストなどの資料、組織体系の中に「失敗を回避する術」がすでに折り込み済みなのかもしれません。私がライブドアに入社した2005年当時は、ライブドアは「谷底に突き落として、這い上がってこい」の精神が蔓延しており、ディレクターの技術を身につけていなかった私は、自ら失敗を重ねつつ、周りのひとの仕事をまねながら学んで
それでもエンジニアがミーティングに出るべき理由 ： nabokov7; rehash - livedoor Blog
エンジニアがミーティングを嫌う理由はいい視点だと思う。いわれてみればそのとおり。 それでも個人的な経験でいうと，ミーティングに出るようになってからの方がストレスが軽くなった気がする。 ↓なんでかっていうと，こういうことを後になって言わなくても済むから。
「長く使える技術力を自分に蓄えていく」―はてな伊藤直也氏がジュンク堂書店大阪本店トークセッションに登場 | gihyo.jp
2008年8月23日(土)、ジュンク堂書店大阪本店にて、(株)はてなの伊藤直也氏によるトークセッションが開催された。今回のイベントは、『［24時間365日］サーバ/インフラを支える技術』（伊藤直也／勝見祐己／田中慎司／ひろせまさあき／安井真伸／横川和哉著、技術評論社）発刊に関連して、ジュンク堂書店大阪本店企画／主催で実現された。 はてな伊藤直也氏 私にとっての技術書、読書 今回のテーマは「私と技術書」。トーク中に「プログラミングは世界を変える（※注）」「ハッカーになりたい」、そんな率直な思いを言葉にした伊藤氏にとっての技術書とは、読書とは、いかなるものなのだろうか。 テーマは「私と技術書」 ※注） 伊藤氏は、小学校時代のパソピア7（東芝製パソコン）でのプログラミング体験に始まり、数々のソフトウェア、インターネットで世界が変わったその時期に高校／大学時代を過ごし、ユーザ数
10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
はじめてのRFP――発注時に意思疎通をスムーズにする提案依頼書の作り方 | 安く!早く!を実現するサイト制作の発注マニュアル
発注の基本はRFP作りから 発注をマスターしてベストな提案を引き出す いちから覚える提案依頼書の作り方 制作会社など外部の業者に対して、具体的になにをしてもらいたいかの提案要求を伝える際に必要となるのが提案依頼書（RFP：Request for Proposal）だ。場合によっては、口頭の打ち合わせベースで仕事を進めることもあるかもしれないが、RFPを作ると作らないでは仕事の進め方に大きな差が出る。ここでは、RFPを作るときに必要な基本の要素を紹介しよう。 取材・文：編集部 協力：高橋 宏祐（富士通株式会社 コーポレートブランド室 担当部長） 富士通でエンジニア職を経験した後、1998年より富士通のウェブマスターとしてウェブ戦略を企画実行。2002年6月に富士通ウェブ・アクセシビリティ指針を公開し、日本のアクセシビリティ普及をリードする。2003年にFUJITSUウェブ・ユニバーサルデザイ
タスクを視覚的に整理する : LINE Corporation ディレクターブログ
こんにちは。『livedoor Blog』担当の早岡です。 どのサービスにおいても開発・運用の「タスク優先順位」が存在します。サービスの規模が大きくなればなるほど、ディレクターはタスクの“交通整理”に頭を悩ますことになります。今回は『livedoor Blog』を開発・運用していくにあたって、私がどの様な形でタスク整理をしているかを書きたいと思います。 ■プロジェクトの種類を分ける。 『livedoor Blog』のプロジェクトは大きく３つのタイプに分類されます。 (1) 収益重視のプロジェクト コンテンツ連動型広告や、他媒体とのタイアップなど「お金に直結するタスク」がここに含まれます。 (2) ユーザー満足度向上のためのプロジェクト 「どういう機能を追加すればもっと便利になるか」「ユーザーの要望に応えるにはどうしたらよいか」といったタスクがここに含まれます。 ※現在は「fixdap」とい
IT業界を震撼させた2chスレ『ブラック会社に勤めてるんだが・・・』ここに終焉。泣いた。*ホームページを作る人のネタ帳
久しぶりに膨大な時間を2chスレッドに費やしてしまった。 私がウェブ業界で働いているからなのかはわからないのですが、心に残りまくるスレ。 その名も 『ブラック会社に勤めてるんだが、もう限界かもしれない』 はっきり言って、これがネタであろうと無かろうと、この物語は本当に面白かった。 プログラマやウェブ業界のかなり厳しい内情が暴露されているのもそうですが、複雑な人間関係の表現が非常にうまいため、見ていて飽きません。 最後妙に泣けてしまうところもこのスレの投稿者の文章が魅力的だからだと思う。 かなり有名なお話なので、既に知っている人は多いと思いますが、まだ一度も見た事が無いと言う人がいれば暇なときにでも見れるようハムスター速報2ろぐさんのエントリを、ここにまとめておきます。 スレッドまとめ ブラック会社に勤めてるんだが、もう俺は限界かもしれない ブラック会社に勤めてるんだが、もう俺は限界かもしれ
GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日本ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ
3,500円以下で泊まる！東京の格安ホテル
カプセルホテルではありません。出張にも便利！女性も安心！きれい！東京にもそんな大満足の格安ホテルが増えています。
受託開発事業から自社媒体事業へシフトするための意識改革のポイントとは？ - livedoor ディレクター Blog
こんにちは、小久保です。今回は受託開発事業と自社媒体事業におけるディレクターの意識の違いについて書きたいと思います。 弊社はもともとウェブ関連のSI事業から始まっており、私が入社した5年前もほとんどの仕事がウェブの受託開発・運用でした。 そこから紆余曲折がありながら、現在のメディア事業中心の会社へと変化してきたわけですが、その過程における組織変更はまさに試行錯誤の連続でした。 以前、面白法人カヤックの柳澤社長が「受託開発と自社開発の両立」という記事を書かれていましたが、この記事を読んだときに「やっぱりどこも同じような悩みをかかえているんだなぁ」と激しく共感したことを覚えています。 ところで皆さんは、受託事業と自社媒体事業について一般的にどのようなイメージを持たれているでしょうか？ 弊社が事業シフトの過渡期にあったときに頻繁に出ていた声は以下のようなものでした。 受託 = クライアントに詰め
404 Blog Not Found:書評 - チーム ハックス
2007年07月25日05:30 カテゴリ書評/画評/品評 書評 - チーム ハックス 献本御礼。 チーム ハックス 大橋悦夫 / 佐々木正悟 シゴタノ！ - 『チームハックス』序章(1)「仕事の進捗」を共有できるか？前作同様、佐々木正悟さんとの共著作なのですが、今回は特に、文字通り2人の「チームハックス」を駆使して書き上げた一冊となりました。 前作「スピード ハックス」の三倍面白かった。 本書「チーム ハックス」は、日本におけるGTD本の今や第一人者である感もある著者たちが、今度は「チームワーク」をハックした本。 目次 - シゴタノ！ - 『チームハックス』序章(1)「仕事の進捗」を共有できるか？より はじめに 序章 チームはすべて「共有」から始まる 第1章 ビジョンを共有するチームを作る 第2章 「質問」でメンバーの力を巧みに引き出す 第3章 コミュニケションの「困難」を克服する 第4
エンジニアに「イラっときた」瞬間 - ＠IT自分戦略研究所
エンジニアとそうでない人とでは、エンジニアに対して「イラっ」とくるツボが違うらしい。もし相手に「イラっ」ときたらこう対処しよう。（Tech総研／リクルートの記事を再編集して掲載） 今回のアンケート調査では、エンジニアと、営業職・事務職などの非エンジニアの両方に「イラっとした瞬間」を聞いてみた。職種が違うとイライラするところに違いが出るのだろうか。さっそく見ていきたい。 ■「専門用語の多用」はやっぱり嫌われる！ アンケートで得られた回答は、どれもビジネスパーソンとしては問題があるものばかり（図1）。気になるのは、エンジニアと非エンジニアで明らかに回答数に差が出ている項目。非エンジニアとのやりとりをする際は、コミュニケーションエラーを回避するために、非エンジニアの回答が多い項目に気を付けた方がいい。例えばトップに挙げられた「専門用語が多い」という点はその代表格で、それほど専門的な用語ではなかっ
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
中小企業にプログラマはいらない:Geekなぺーじ
「Small ISVs: You need Developers, not Programmers」という記事がありました。 2003年5月の記事のようです。 半分根性論な気もしましたが、この記事の視点は非常に面白かったです。 そうなのかもと思う面もありました。 この記事を書いている人は25人の社員がいるソフトウェアベンダを運営しているそうです。 6年間会社を続けてわかったこととしては「小規模な企業にプログラマは居てはならない」だそうです。 必要なのは「プログラマ」ではなく「開発者」だそうです。 以下が駄目な「プログラマ」の特徴だそうです。 小規模企業では以下のような人は「いらない」そうです。 新しい機能を実装することばかりする たまにバグを修正する 仕様書を書かない ドキュメンテーションを書く手伝いをしない 自動化されたテストを作成しない テスト実行を手助けしない 開発環境を最新に保たな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PC
そんなプログラマは必要ない！優秀なプログラマの8つの条件*ホームページを作る人のネタ帳
http://fairyware.jp/jaws/index.htm