シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
今回の記事ではエンジニアやIT業界ではすでに定着した感のあるポッドキャスト『rebuild.fm』の#123について触れてみたいと思う。 rebuild.fm いきなり横道にそれるが、podcastはランニング中や移動中に1.5倍速で流して聞けるのが便利。一方でメモがとれず終わった後にきちんと整理する時間を取らないと「要旨はなんだったのか」が曖昧になり自分に残らない感があるのが悩ましいですね。 今回のゲストである @naoya_itoさんが『エンジニアチームのリーダーシップ』というテーマについて『Fate/Zero』というアニメの11話「聖杯問答」になぞらえてうまく例えていた。 「聖杯問答」の内容について、超端的に言うと、世代を超えた3人の王が統治の仕方を論じ、民や臣に厚いタイプの王が大いなる野望を追いかけるタイプの王に負ける、という話。 趣旨：サーバントリーダーシップの是非 放送を通じた
「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。 第一期 サービスリリース前 自分でサービスをガリガリ作っている というかサービスを作ることしかしていない １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識 フルスタックエンジニアというある種の全能感を満喫する 第二期 サービスリリース後 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる エンジニアを採用（業務委託含む）する 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる でもまだまだ自分が圧倒的にメイン開発者 コードレビューやマージ、リリースは自分が全てやる システムの全体からディテール
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
どうも、セクションナインの 吉田真吾（@yoshidashingo）です。 昔FeBeで買ったドラッカーのマネジメントを聞き直して、1963年HBRに寄稿された「R&Dはなぜマネジメントできないか」を聞いてグッとくるところがあったので【自分としてR&Dに対して思うこと】をまとめておこうと思います。 IT企業のR&D部門はなにをやっているか 大手のベンダーから中小企業のWeb企業まで「R&D」が冠につく部門、職業あるいはミッションを与えられている人は相当多いと思います。なぜならこのロールに期待されていることが、次世代の企業のメシのタネを担っているからです。ただし「次世代の」というのがいつ頃を指し示すかによってこのロールに期待される研究内容に個々の大きな違いがあるのが実情だと思います。 大手ベンダーの製品に関するR&D部門であれば5〜10年後に市場に投入されるプロダクトの開発を行ってることもあ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 自己紹介 こんにちは。田村壽英（タムラ トシヒデ）です。 freee株式会社でプロダクトマネージャーをやり始めて早くも２ヶ月が経ちました。この２ヶ月間、どのようにPMとして動けば顧客にちゃんと価値を届けられるか、そのためにどうしたらfreeeの社員が熱狂をもって働けるかを悩みながら活動してきました。この記事では現時点での悩んだ結果を共有したいと思います。 背景 PMになるつい最近まではエンジニアとしてあるプロダクトのリーダーをしていました。そのときの悩みはだいたいこんなものでした。 今やっている開発が手一杯で次何するかをちゃんと考えられ
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
技術評論社傅様よりご恵贈頂きました。いつもすいません。 世界を動かすプロジェクトマネジメントの教科書 ~グローバルなチャレンジを成功させるOSの作り方 作者: 佐藤知一出版社/メーカー: 技術評論社発売日: 2015/09/17メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る こちらは初めてマネージャとなってチームを束ね、ひとつのプロジェクトを完遂させる為に何が必要なのかを書かれた入門書となっています。タイム・コンサルタントの日誌から というブログの中の人の一冊です。 WBSをちゃんと作る 本書の８割はここです。プロジェクトマネジメントの最大のポイントは、WBSが正しいかどうかです。間違ったタスクを管理してもしょうがないですから... タスクの妥当性を検証するには、それらのタスクを全て足して100となるかどうかで判断されます。簡単にいえば、抜け漏れがあってはならない
Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節 エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。 というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング（実装）」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。 エンジニアは製品を正しく作る エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。 エンジニアと
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 ■仰天の新人君 ネットでびっくり仰天な新人君の話を見かける。まだ、ビジネスマナー系の仰天話なら可愛いものだ。社会経験が無いので仕方がないと思える。シャレにならないのは能力に関する仰天ネタだ。 特に技術を売りにするIT系の業務で能力が足りないと致命的だ。コラムの題名にある、新人君にドキュメントの作成を頼んだら、三行しか書けていなかったというのは、私の経験した実話だ。 一般では仰天話かもしれないが、私としては予想通りだった。今回は、こういう新人君をフォローする立場で書いてみる。力無き新人君に代わって、無能な先輩方にツッコミを入れていきたいと思う。 ■できて当然というのは甘えだ できない人に対して、いきなり問題意識を押し付けるタイプの人が一定数いる。まず、こういう人はエン
会員事業部の森田です。 対象と内容 この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。 組織における分業と調整 組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。 分業の種類 事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを
PDCAは「小さな改善」を指すものではないし、そもそもWebサイト改善には向いてない。まずPDCAはP=計画ありきの「マネジメント」の話だし、Webはコントロールできない要素が多すぎて精度の高い計画立案が難しいからだ。 PDCAサイクルの出自は製造業の品質管理である。そしてPDCAという概念のキモは、「品質管理の話をしていると思ったらいつの間にかマネジメントの話をしていた。何を言っているのかry」である。例えば「C」は品質チェック作業はなく、品質のばらつき具合が事前の計画どおりだったかどうかを判断する。それはP=計画の検証そのものだ。製品の品質を管理するときに、単に品質チェックの「作業」を頑張ればいいのではない。品質の問題が生産工程全体のマネジメントの問題にスライドしていく。それがPDCAという概念の画期的な点だった。 だからPDCAというのは製造業だろうがWebだろうが、常にマネジメント
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ いろんなベンチャー企業から、異口同音に「エンジニアが足りない」という話を見聞きします。中には、「使えるやつがいない」とか言い出す髭を生やしたベンチャー社長とかもいたりします。 そんな人たちに一言モノ申したい。ええとな、人類がこの世に生まれてから今まで、エンジニアが余ってた時の方が少ないんだよ。 90
知人と話しながら、チケット駆動開発の理想と現実について気づいたことをメモ。 あくまでもメモであり、主張はない。 【1】Redmineを導入したならば、チケット駆動開発で運用するのが普通だと僕は思っていた。 しかし、実際の数多くの現場はそうではないですよ、と。 丁度、日本のソフトウェア開発の現場では、アジャイル開発ではなくWF型開発が主流であるのと同じように、と。 【1-1】チケット駆動開発はXPに影響を受けすぎているのでは？、と。 世間のアジャイル開発のイメージは、XPよりもScrumの方が有名だ。 Scrumのプロセスフレームワークの中で、タスクカードがチケットとして使われる場合が多いでしょう。 全ての作業をチケットにして作業をはじめる「チケット駆動」は特殊でしょう。 WF型開発の現場では、そうではない。 チケットの入力結果は、ガントチャートで確認する方が普通ですよ、と。 【1-2】チケ
日の出とともに起きるエンジニア この春で意図的に自分のライフスタイルをそれまでの「渋谷で月曜から飲んじゃうぜ！」パターンから完全に変えてから2年半が経ちます。現在自分は朝8時半に出勤、午後3時半〜4時くらいに退勤、あとは午後7時〜8時頃にまたオンラインになり家から必要な事を行う…という基本スケジュールをとっています。ステレオタイプなエンジニア象では夜中遅く暗い部屋でハックしているイメージがありますが、現在の自分は日の出とともに起き午後11時すぎには寝てしまう生活をしているエンジニアなのです。 幸いな事にプログラマー・エンジニアという仕事は周りの理解さえあれば伝統的なサラリーマンのステレオタイプから見たら明らかに異常なスケジュールでも特に生産性を落とさずに仕事を続けることができると仕事ですので、これを最大限利用させてもらっています。 自分は子育てのために意図的にこのような形を取っており、転職
最近、いくつかのデザインに取り組んでわかったことがあるので、書いておこうと思う。 ぼくは2,3年前にこの業界に入ってからずーっとフロントの実装畑でやってきた。 それは自分の意図していたものではなかったけど、前職のまぼろしという会社は実装が強みの会社だったので、デザインに触れることはほぼほぼなかった。 それもあってか、ぼくは「もうちょっとコストを考慮してほしい」「このあしらいが一体ユーザーにいくらのお金を落とさせるんだろう」とか、あげくの果てには「実装のことを考えたデザインをすべき」とまで考えていた。これらの考え方はぼくだけでなく、コーダーからよく同様の声が上がっている。 だけどデザイナーさんと接する機会が増えるごとに、デザインができるようになったら今までイラついていたことがどんな風に見えるのか確かめたいな、という気持ちになった。 それ以外にも「なにか作るとデザイナーばかり褒められて厳しい」
最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く