2015-03-19 エンジニアスタートアップは１人でいいから通訳を雇ってくれ 「エンジニアの言葉を通訳する人間が必要」 前の会社でよく言われていた言葉であり、「通訳」が必要なくらいエンジニアとビジネス側には隔たりがあるのだ。 私はマーケティングやファイナンスの人間だ。何をやっていくら儲けるかを考えるのが仕事。なので、無駄なコストをカットして、注力すべきところに投資したり上手にヘッジすることがミッションだ。 だが、その仕事の中でやっかいな存在にあたるがエンジニアだ。 彼らは何をしているのかよくわからない。外注のデザイナーやコーダーは何を作っているのかがよくわかるけど、正社員メンバーの、システム基盤？だのアルゴリズム？だのやっている人たちについてはまったくパフォーマンスがわからない。 部署横断のミーティングなんかやると温度差に驚く。 営業「営業の仕組みを変え、売上をキープしつつコストをダウン
2015-03-19 スタートアップにおける糞コードとエンジニアの役割について Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた 「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsblog.kentarok.org 4年前，俺はあるスタートアップで社長に「あなたそのものがリスクです」と言われた．別に相手は素晴らしい経歴を持った天の上の人間であるし，そういう方に見下されても構わない．しかし，「俺がコードを書いていること」が「リスクだ」と言われたことについては未だに納得行かない．コードはコードであり，それと戦っているだけだからだ．ゾッとした．恐ろしい言葉だった． 件のCTOの退職エントリ以来(ちなみに，社長及び社員の1人が上京した時，うちに泊めたことがあ
2015-03-19 技術的負債について スタートアップや新規事業に限った技術的負債の考え方f-shin.net ちょっとこの記事は酷い．品質と開発スピードを兼ね備えたコードは，そもそも致命的な技術的負債ではないだろう． 現代的なスタートアップのプロダクトでは，シンプルなものを作って世に出すというのはあまり起こらない．いわゆる「仕組み作り」と言われるものをやらなければならず，そのために何を作るかを練った場合，凄まじい天才で無い限り，様々な概念をつなげた複雑なシステムを作ることを考えてしまう．アイデアもガンガン出てくるし，その優先度もつけられずただデカくなっていく．その意味で，スタートアップ段階で必要になるコードの規模は思っていたより大きいことが多い．それを事前にうまく落とそうという試みがリーン・スタートアップであるとも言える． 例えば現在のマーケットで「猫の鳴き声を共有するサービス」があっ
日本マクドナルドホールディングス（以下、日本マクドナルド）が、昨年7月に発覚した中国食品会社の使用期限切れ鶏肉使用問題に端を発し、その後、立て続けに起こった異物混入問題で客離れを起こし、1971年7月に銀座三越（東京）に第1号店を開業して以来の未曾有の経営危機に直面している。 日本マクドナルドの2014年12月期決算は売上高約2223億円（前期比14.6％減）、営業損益は約67億円の赤字、最終損益は当初予想の170億円を48億円も上回り約218億円の大赤字となった。最終損益が赤字になるのは03年12月期以来、11年ぶりのことだ。ちなみにFC（フランチャイズチェーン）を加えた全店売上高は約4463億円（同11.5％減）。また店舗数は直営が1009店、FCが2084店の合計3093店であった。 創業以来の悲惨な決算に拍車をかけたのが、今年1月の既存店売上高が前年対比38.6％減と、4割近くも落
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ >> 「日本史なんかより、プログラミングを教えるべき」三木谷浩史氏と夏野剛氏が日本の技術者不足を嘆く こういう考え方、今っぽいし、悪くないとは思うんですけど。個人的に、プログラム教育とか論じてる人が「プログラマーとして飯を食ったことがある経営者」じゃないとちょっとゲンナリするよね。 僕は三木谷さんや
Inc.：フェイスブックのように競争力がある優良な組織を作りたいと思いますか？ フェイスブックの創設者でCEOのマーク・ザッカーバーグ氏によると、皆さんが考えている雇用方法の逆の発想で人を採用することが秘訣だそうです。 バルセロナで開催された公開Q&Aセッションにおいて、ザッカーバーグ氏は、「どのようにしてトップレベルの才能を持つ人材を引きつけているのか？」と尋ねられた際に、そこそこ程度の候補をうっかり採用してしまわないために彼が取り入れている、単純ではあるものの理にかなった経験則を明かしました。 「私は自分がその人の部下になりたいと思える人とだけ仕事をするようにしています。それが、私の経験則上では一番良い方法でした」と、ザッカーバーグ氏は語ります。同氏は、その好例としてフェイスブックCOOのシェリル・サンドバーグ氏を名指しで引き合いに出しています。 「もしフェイスブックが倒産して、私が何
高橋さんと「日本でもこういう感じのRuby Conferenceをやりたいねえ」という話もしてて、やるとしたら次のゴールデンウィークあたりがいいかな？ と考えてます。 ――青木峰郎（ruby-list:31889) はじめに 日本Ruby会議（RubyKaigi）は2006年から毎年開催されている、日本における事実上の公式Rubyカンファレンスです[1]。3回目の開催となった今年のRubyKaigi2008は、いくつかの課題を残しながらも基本的には成功したイベントだったと思います。怪我や混乱もなく無事に会期を終えることができたのも、さまざまなかたちでRubyKaigiの運営を支えてくださった方々と、参加者のみなさんのおかげです。この場を借りて御礼もうしあげます。 本記事では初回から運営に携わっていた者の個人的な視点から、RubyKaigiのこれまでをふりかえり、今後の展望をお伝えします。
Inc.：部下へのフィードバックというものは、あなたの属する組織が十分な成果を達成できるか否か、信頼関係とチームワークを強固なものにできるかどうか、あるいは相手の創造性や慎重さが引き出せるかどうかで大きく左右されます。あなたのフィードバックはいかがでしょうか？ 私は、フィードバックはリーダーシップを発揮する上で、最も強化すべき重要なスキルの1つである一方、最も人を委縮させるものでもあると考えています。多くの人はフィードバックをすることを恐れたり、避けたり、遠回しに伝えたり、あるいは称賛の間に批判をはさむ言い回しで少しぼかした伝え方をしてしまいしがちです。 ところが、そうすることでフィードバックを受けた人間に内容がきちんと伝わらなかったり、相手の気持ちを傷つけたり、成長や改善の機会の損失につながったりと、誰の得にもならないような状況が生まれてしまいます。 しかし、人間は成長しなくてはなりませ
最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段
やるべきことや目標があっても多忙でつい後回しにしてしまい、そのうち目標自体を忘れてしまう……ということは起こりがち。そんな時に便利なのが、やる気を維持しながら目標を達成できるようにする手帳「Passion Planner」で、Kickstarterで出資を行ったところ商品が届いたので、試しに使ってみたら特に目標を掲げていない人でも予想以上に使える手帳となっていました。 Passion Planner http://www.passionplanner.com/ これが「Passion Planner」。皮っぽい手触りの黒い手帳です。 手に持つとこのくらいの大きさ。今回到着したのは約21.6cm×14cmの「Passion Planner Compact」です。 iPhone 5と比較するとこんな感じ。 表面にはエンボス加工でロゴマークが入れられています。 横から見ると幅が1cm以上ありまし
「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
観て楽しい、やって楽しいゲームのデザインとは？ 2015年3月2日～6日（現地時間）、サンフランシスコ・モスコーニセンターにて、ゲームクリエイターを対象とした世界最大規模のセッション、GDC（ゲーム・デベロッパーズ・カンファレンス）2015が開催された。 今回注目したのは、Riot Gamesのリードデザイナー、ライアン"Morello"スコット氏のセッション。題して“スポーツを作る ～『League of Legends』のデザイン哲学”だ。ゲームを、競技的に厳格で戦略的な幅があり、プレイヤーのスキルが重要視され、遊んでも楽しく、観ていてもエキサイティングにするためには、どうデザインすべきか。『League of Legends』（以下、『LoL』）をe-Sportsにまで昇華させたゲームデザインとバランスの哲学について語られたのだ。このセッションは、ベテランゲームデザイナーのフランク・
＜前編のあらすじと後編のお話＞ 本企画のホストである伊藤直也（以下「naoya」）と、『フリークアウト』執行役員であり『ヤフー』のフェロー／名誉黒帯でもある明石信之（以下「明石」）。意外にも初顔合わせとなる二人だったが、Web業界を長年リードし続けてきたという共通項もあり、酒肴を愉しみながらのマネジメント談義は大いに盛り上がりを見せた。明石氏が『フリークアウト』に参画後、色を組織名にするなど、破天荒とも思える組織マネジメントの実例も披露され、その深い洞察にもとづく一手に、naoya氏は大いに感銘を受けるのだった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、明石氏の『フリークアウト』における取り組みを掘り下げていくことで、そのマネジメント論の神髄に迫っていきます。大の魚好きという点でも一致する二人の会話は、酒の力もあってますますヒートアップしていきます。 — naoya：チーム名の
Yahoo!メールのサービス劣化が著しい。 失敗した新UIへの移行Yahoo!メールはサービス開始当初からある古めかしいHTMLバージョンと、なかなか正規版に移行しないベータ版の新UIが何年も共存していたのだが、新UIはモバイル版での不具合が多く、なかなか移行がすすまないようだった。実際、私もベータ版は信頼度が低すぎて、一度使い始めたがすぐに旧UIに戻した。 つい最近になって、このベータ版を切り捨てて、別のバージョンの新UIへ全員強制的に移行したのだが、このバージョンも読み込みが非常に遅く、使い勝手が悪い。 古めかしい広告中心のビジネスモデルYahoo!メールのwebメールには広告がでかでかと表示される。有料版であるYahoo!プレミアムに加入しても、非表示になることはない。 GmailやOutlookは無料で広告が非表示になっている時代に、なぜ毎月金を払って広告を見せられ続けなくてはなら
やるべきタスクや進行中の作業、すでに完了したタスクなど、プロジェクトのタスクと進捗を「カンバン」で表し、複数のメンバーによる管理を可能にするサービスが「Taskulu」です。Taskuluでは「パーソナル・カンバン方式」と呼ばれる手法でタスクの見える化を行い、管理を容易にしています。 Taskulu | Role based project management https://taskulu.com/ ◆カンバン方式によるタスクの管理 いわゆる「カンバン方式」といえばトヨタ自動車が実用化させて世界に広がった独創的な生産方式のことを指しますが、この方式のメリットの一つは必要なモノを「見える化」することよって管理を容易にすることが挙げられます。この見える化による効率・正確性のアップを個人のタスク管理にも取り入れたのが「パーソナル・カンバン方式」とよばれるもので、個人や組織のタスクを「未実施・
業務改善の“やらされ感”をなくする方法とは 傍観者ばかりの“無関心な現場”で進める業務改善。あなたが部門の責任者や、改善活動の事務局など改善活動を率先する立場だったら、どのように進めていくでしょうか？ 一般に、業務改善は即効性のある効果が期待されることが多く、どうしても現場には「改善効果のアウトプット」が早く求められます。しかし、そこには動かない現場。変わりたくない社員という大きな壁が立ちはだかります。あなたはそんな現場に対して、イラッとしてしまうかもしれません。 「二度とやるものか…」と思っている社員に対して、頭ごなしに「やれ！」と言っても、うまくいかないのは目に見えています。改善に対する“やらされ感”をなくし、当事者意識を持たせていくかが業務改善の成功の鍵となります。 今回は、この“やらされ感”をいかに感じさせることなく、自ら積極的に関わっていくようにしていくかを考えてみま
先日、「ソフトウェアの開発における見積もり」が話題になっていたが、ふと設計書についても同様の事を感じていたのでタレコミしてみた。 以前大手SIでプログラマをしていたとき、自分一人のワンマンプロジェクトをいくつか持っており、それに加えてチームプロジェクトにプログラマとして参加していたのだが、自分のプロジェクトではプログラミング時に設計書を使う事はなかった。 いっぽう、チームプロジェクトでは設計書はあったが、内容は酷く古く、一貫性も無く、必要な情報が載っておらず、結局一番最初の開発以降、プログラムの改修時に設計書を参考にプログラミングをする人間は誰もいなかった。結果、素人の設計書通りに作られたチームプロジェクトのアプリケーションは駄作になり、私が設計書無しで取り組んだワンマンプロジェクトはどれも高い評価を受けた。 とはいえ、プログラムの完成後に設計書の作成を要求されたために設計書を書いた事は書
スマートフォンを使って自由にカメラのシャッターを切ることができるツールの「Triggertrap Ada」は、クラウドファンディングサイトKickstarterで目標金額の約6倍の資金を集めることに成功したのですが、結果的に製品化を実現できず集まった資金を出資者に返還することになり、プロジェクトは大失敗に終わりました。なぜ、圧倒的な支持を集めたにもかかわらずプロジェクトは失敗したのか、どうすればプロジェクトを成功させられるのかについて、Triggertrapのハジェ・ジャン・キャンプス代表が、プロジェクト失敗から学んだ教訓としてまとめています。そこにはKickstarterでプロジェクトを立ち上げる人も出資をする人も、知っておくべき教訓の数々が明らかにされています。 How a half-million dollar Kickstarter project can crash and bu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
