Are you sharing the full picture of your project with your team? – Mammoth ProjectAre you sharing the full picture of your project with your team? A new project management tool aimed to make your tasks visible. Try it for free! Did you know that 71% of all projects fail? Source：Standish Group (Chaos Report 2015)
リーンスタートアップにおけるMVP制作のポイント — revoltmark
※2021/6/21 追記更新 「良い事業アイデアを思い付いたんだけど、実際に立ち上げるためには、まず何をすればいいんだろう…？」 ハッカソンやアイデアソンといった言葉も当たり前になり、一昔前から見れば新規事業アイデア創出の需要も機会も増えているけれど、それと同時に、事業アイデアを思い付いてもどう形にしていけばいいのかが分からずに頓挫してしまったり、逆に突っ走って失敗してしまう、という声もよく耳にする。 アイデア創出の「次」に何をすればいいのか、日経新聞社主催『AG/SUM HARVEST』のアクセラレーター・プログラムで講演した内容をもとに、MVP制作のポイントについてまとめてみた。 リーンスタートアップのプロセス リーンスタートアップとは、まずはアイデアから最低限実用に足る製品（Minimum Viable Product）を作り、顧客の反応を検証しながら改良・軌道修正を行うという、構
正論なのに相手が動かない･･･ 頭の良い人ほどぶつかる壁の乗り越え方 | ハイクラス転職ならdoda X（デューダエックス）
doda X（旧：iX転職）は、パーソルキャリアが運営するハイクラス転職サービス。今すぐ転職しない方にも登録いただいています。 今の自分の市場価値を確かめてみましょう。 「よかれ」と思って課題の解決策を、必要なデータをそろえてまで提案しているのに、なぜか相手に通じない、動こうとしない。この人はやる気がないのか？ どうしてだ？ 論理的思考やプレゼンテーションが得意なビジネススキルの高い人ほど、上司や部下、ときには取引先に対して、こうした「歯がゆさ」を感じた経験があるかもしれません。 靴修理大手「ミスターミニット」の運営会社の若き社長、迫俊亮さんもその一人。三菱商事やベンチャー企業で培ったスキルで経営戦略を練り上げ、あるメンターにプレゼンしたところ･･･ ウザい。君が言っていることの90%は正しいんじゃない？ でも、外から来た人にいきなりそんな正論を言われて、現場の人は誰もついてこないよ。 と
プロジェクトの成功率を上げるために、チームリーダーができること・やるべきこと - ログミーTech
スマホアプリの分析プラットフォーム「F.O.X」が主催する、スタートアップで働くエンジニア向けコミュニティイベント「F.O.X Meetup」の第3回が開催されました。スタートアップのエンジニアが求めるナレッジをキャッチアップ・共有し、F.O.Xの持つノウハウを公開することで業界をさらに盛り上げることを目的としている本イベント。今回は、「スタートアップのチームビルド」をテーマに、経験豊富なプロジェクトリーダー達が自身の知見を披露します。株式会社マクアケの吉田慶章氏は、「さぁ！今すぐプロジェクトリーダーに立候補しよう」というテーマでプレゼンテーションを行いました。チームの特性に合わせたチームビルディングやマネジメント手法について、自身のノウハウを明かします。 プロジェクトをリードする技術 吉田慶章氏（以下、吉田）：こんばんは。よろしくお願いします。今日はプロジェクトリーダーの話をしようと思い
なぜふわっとした仕事を具体的なタスクに落とし込める人が少ないのか - teruyastarはかく語りき
blog.tinect.jp プロジェクトマネージャーの話らしく、抽象的な課題を具体的に落とし込むことができればそれだけで食っていける。転職の際はそこを強くアピールしたほうがいい。その能力を積むには実践と経験しかない。それはそのとおりかと。 でもこの記事には他に 「タスクをきちんと落とし込める人材が少ない。育たない。面接採用でもその能力は見抜けない。」というふわっとした課題がそこに発生している。主題ではないとしても「実践と経験つむしかない」は課題解決として弱い。 この記事で理想的な人は元スクエニCTO 橋本善久 が思い浮かぶ。 ロンチ大失敗したFF14を1から作り直した大黒柱の一人。 下のプレゼンは様々なタスク管理をコントロールする術が書かれている。 http://www.jp.square-enix.com/tech/openconference/library/2011/dldata/
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
「2位じゃダメ？」の事業仕分けで分かる、なぜ理系新卒が就活で面接を突破できないか
蓮舫さんの「2位じゃダメなんでしょうか？」発言で有名な、次世代スーパーコンピュータ開発の事業仕分け。 さて、その事業仕分けなんですが、「面白い」んですよ。コンテンツとして。こんな面白いものを楽しまないなんてもったいない。「2位じゃダメなんでしょうか？」発言を知っているだけでは、ラピュタで「バルス」のシーンだけを観たことがあるようなものです！ というわけで、音声ファイルと議事録を公開しておきます。晩酌のお供に、子供の夜泣きにぜひどうぞ。流し聴きをオススメします。 知っとくとよい前提知識 事業仕分け当時(2009年)、プロジェクトの雲行きは怪しかった 総予算1,154億円のうち、仕分け当時すでに100億円の予算超過をしていた スーパーカミオカンデ1個分の予算超過 当時のアメリカでのスパコン開発状況では、仮に日本がスパコンランキングTOP500で世界一をとったとしても一瞬で終わることが予想されて
リーダーをやって見えたこと、メモ
とあるプロジェクトのリーダーというか、会社でちょっとした仕事のまとめ役をやった。 そんな中で見えたことがあったのでメモ。今後の自分のために。 あとリーダー経験がやたら就活で重視されたのも分かった気がした。 ＜リーダーから見た印象の良い行動＞ ・レスポンスが早い（最重要） とりあえず、「見ました！了解です！」くらいがあるのと無いのとじゃ全然違う。 というか、リーダーの立場って結局独りよがり感すごいのでレスポンスあるとかなり安心します。はい。 ・少しでもいいから改善策を提案してくれる ほんとーに些細なこともでいい。一番はこちらが作った何かを改良してくれるの最高。ちょっと記載もれしてたところ指摘とかでもいい。 別に自分がわかっててあえて後から書こうとしてたところも「ここ抜けてると思います」っていうのでもいい。 何も言わずにいる人より全然良い。というかちょっとしたことがクリティカルヒットなので、こ
今までに経験した中で最悪の開発環境について書く
なんとなく吐きだしてみる。老害の昔語りなので興味ない人はスルー推奨。 時は2000年代初頭、俺は最初に就職した独立系SIerから4次請けの派遣として某銀行の営業店システム開発に参加していた。 新卒で入社して、二つ目のプロジェクトだった。当時は最先端であったJavaでのプロジェクトということで、ずいぶんと喜んだことは記憶している。 1フロアが丸ごとプロジェクトルームとなっており、プロジェクト統括の事業部長が常に怒号をあげながらフロアを徘徊するなかで、15インチCRTディスプレイ(当然液晶なんかじゃない)がようやく置ける狭い机とパイプ椅子で、右も左もわからないまま、Excelで書かれた仕様書と向き合い、秀丸エディタ(当時はEclipseがまだ生まれていなかった)でジャバを書いていた。 デスマであったかというと、今思うとそこまでデスってはいなかったように思う。頻繁にリスケが行われていたのでプロジ
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
アジャイル開発手法 (スクラム、XP) の導入事例 - GMOインターネットグループ グループ研究開発本部
はじめまして、次世代システム研究室の A.F. です。 今回のエントリーでは私たちが日々の業務で取り組んでいる『アジャイル開発手法 (スクラム、XP)』の導入事例について紹介させて頂きます。次世代システム研究室の重要なミッションは『GMO インターネットグループの重要なプロジェクトの成功を技術面でサポートする』ことですが、そのため自ずと携わるプロジェクトは多岐にわたります。例えば EC やソーシャルゲーム、広告技術と各プロジェクトで目的も規模もユーザーも異なりますが、Web サービスとして共通しているのはいずれも『変化が激しい』『不確実な要素が多い』という点です。 開発側のスケジュールやリソースといったものから技術的な実現可能性、対象となるユーザーやマーケット、はたまたそれを取り巻く環境など様々な不確実要素を抱えながら開発を行うわけですが、その中で最初から全ての要件を定義することは難しいで
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
Team Geek を読んで、実践し始めたこと
Fitzpatrik と Collins-Sussman「Team Geek」を読んだ。体系化された方法論として書かれているわけではないので、内容をそのまま紹介することが難しい。この本で問題であると指摘されていることのうち、自分がやってきたこと、どう対処しようとしているかを書いておく。 ※ 誤字脱字、分かりにくい表現、スタイルをリライト。ロジックはそのまま。-- 2014/04/24 8時半ごろ で、でたーw 天才じゃないのがばれるのが嫌だから、途中の成果を隠奴〜w Most programmers are afraid to share work they've just started, because it means peers will see the mistakes and know the author of the code is not a genius. これは自分に
U理論が面白い - 西尾泰和のはてなダイアリー
U理論の本を流し読みしてたけど、これは結構面白い。 PDCAサイクル(計画→実行→評価→改善)は、既にサイクルが回っている人にとっては納得感があるのだろうけども、回ってない人にやらせようとすると「で、計画はどうやって立てるの？」で悩んで止まってしまったり、逆に問題に対する知識が不足してる可能性に無自覚なまま、詳細すぎる計画を立ててしまって、後からわかった情報で瓦解したりする。 科学的思考法の「仮説→実験→検証→修正」のサイクルでも、流行りのリーンスタートアップの「仮説検証のサイクルを高速に回せ」でも、やっぱり実際にやろうとすると「で、仮説はどうやって見つけるの」というところでつまずく人がいる。 この手の「サイクル」に入る手前でつまずいている問題について、僕はいままで「まず観察を」と言ってきたのだけど、U理論はこの部分を7段階に分けて考えている。 一つ目は、物事を既成概念に当てはめて見ている
優れた仕事のために必要な6つのビジネススキル
優れた仕事のためにはたくさんのスキルを習得する必要はありません。目標を達成し、成果を出すために必要なスキルはどんなビジネスにも共通します。例えば、私たちのように専門的なサービスを提供するエージェンシーでも、商品を販売する事業会社でも、同じように情報を収集し、提案し、プロジェクトを管理し、改善することが求められます。一緒に働くチームのためにも、ビジネススキルの習得は重要です。異なる専門性を持った仲間同士が共通するスキルを持つことで、チーム内の「摩擦」が減り、業務の品質や効率が大きく改善されます。 1. オブジェクティブ（目的を問う） あなたのチームには目的を意識していない行動がどれだけあるでしょうか？以前から、皆そうしているから。そういう決まりだから。クライアントに言われたから。目的が理解されていない行動の多くは無駄だと言えます。何のために、どれだけのリソースを費やし、何を得ようとしているの
エンジニアとして「頑張る」ということ - 銀の人のメモ帳
プロジェクトにアサインされた段階で、これはデスマになりそうだな、と感じることがある。 そういう時、僕は、プロジェクトを管理している人に「デスマは絶対にしない」ということと「残業もしない」という旨を伝えている。 これは、決して「頑張らない」という事ではなくて、スケジュールや予算の調整は、エンジニアより上のレイヤーの人間が「頑張る」べきことだと考えているから、そう言っている。 エンジニアとして僕が「頑張る」べきことは、例えば自分を含めたプロジェクトメンバーのスキルアップであったり、開発効率向上等によって工数を短縮出来ないかを考え、実行することであったり、プロジェクトで得たノウハウを次に活かせるような形で保存・共有することだと思っている。 実際は、様々な状況でデスマや残業をせざるを得ない事が多々ある。会社として頑張らなければならなかったり、金銭的なものであったり、色々な事情がある。 そうなったら
帰宅難民2000人を無料収容した 帝国ホテル(プレジデントオンライン) - 経済 - livedoor ニュース
2013年8月19日 14時15分 by ライブドアニュース編集部 東日本大震災で帰宅難民2000人に対してロビーを開放した帝国ホテル東京 2005年から大規模災害の対策マニュアルづくりに取り組んでいた 日頃の備えにより、毛布やペットボトルの水、保存食などの無料提供が実現した ■6年前からの備えが当日に生きたが起きた11年3月11日、金曜日。震度5の揺れがあった東京では交通網が完全にマヒ状態となり、街は約10万人の「帰宅難民」で溢れ返った。タクシーはつかまらず、道路は大渋滞。営業中の店は少なく、あっても満席で入れない。大多数の人はトイレや空腹、寒さを我慢しながら歩き続けるしかなかった。 その夜、行き場をなくした2000人の人々のためにロビーや宴会場を開放したばかりか、毛布やペットボトルの水、保存食などを無料で提供したのが日比谷の帝国東京である。当日、陣頭指揮を執ったチーフデューティマネージ
オバマ大統領の再選を勝ち取ったITチームは、どんなメンバーで構成されていたのか？
2012年のアメリカ大統領選挙は、バラク・オバマ現職大統領の勝利に終わりました。アメリカ大統領選挙とは、いわば米国でもっとも巨大なマーケティングキャンペーンであり、明確な期限があり失敗できないプロジェクトの1つです。 今回のオバマ氏のキャンペーンで話題になったのは、ITの活用とその効果でした。 詳細を報じたTIME誌の記事「Inside the Secret World of the Data Crunchers Who Helped Obama Win」によると、オバマ氏の地元シカゴに置かれた選挙対策本部にある「The Cave」と呼ばれる部屋では、効果的な手を打つために各州の有権者のデータを統合、その嗜好や動向を把握、分析。その結果ジョージ・クルーニー氏の影響力が高いと判断して彼による食事会を設けて資金集めに成功したり、スイングステート呼ばれ、勝敗の鍵を握る激戦州での選挙結果をさまざま
JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
