11/15 スタートアップ・リーダーシップ・プログラムにて、事業起業を考えている皆さんに向けてお話した内容を加筆修正して公開しました。 http://startupleadership.jp/Read less
11/15 スタートアップ・リーダーシップ・プログラムにて、事業起業を考えている皆さんに向けてお話した内容を加筆修正して公開しました。 http://startupleadership.jp/Read less
転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1
内輪受けは止めにしようではないか LSD LAB で公開されている UIデザイナー不要説は、テクノロジーと付き合うデザイナーであれば一読しておきたい記事のひとつです。私が記事を読んで感じた課題は、 UI デザインが重要視されているかどうかということではなく、果たしてデザイナーは デザインを営業できているかどうかというところです。 たとえビジネスゴールが共有されていたとしても、デザイナーが考える UI デザインの価値と、それ以外の方が考える UI デザインの価値が異なることがあります。特にデザイナーが考える価値は、内輪受けになりやすいことが多々あるように思えます。デザイナーが「すごく良いよね」「イケてるね」というものは、ほとんどの場合デザイナー以外には理解されません。内輪で分かりやすい言葉や感覚で語りかけても、聞き手は「?」(価値を感じない)になってしまいます。 今でもデザイナーのなかでは「
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか?画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
ユーザーストーリーとは? 1. ユーザーストーリーとはhttp://www.flickr.com/photos/cannedtuna/4674434821/ 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外
プロマネ初心者に送るプロジェクト管理の基礎知識まとめ:アジャイル時代のプロジェクトマネジメント入門(1)(1/2 ページ) プロジェクト管理の基礎からアジャイル開発の理想と現実、成功例と失敗例、を紹介し、ベストプラクティスを提案する連載。初回は、そもそもプロジェクトとは、プロジェクト管理とは何かについて解説し、プロジェクト推進における4+1のフェーズを紹介する。 連載目次 理想と現実、成功例と失敗例からベストプラクティスを提案 本連載では、「アジャイル時代のプロジェクトマネジメント」というテーマで、プロジェクトマネジメント/プロジェクト管理の基礎から、アジャイル開発の理想と現実、成功例と失敗例、そして最後にベストプラクティスの提案を数回にわたって進めていきます。Cuonの石川と申します。よろしくお願いします。 主に、システム開発/Webサービス開発のプロジェクトに関わるエンジニアの参考にな
起業してアプリを出す。 一言で言ってしまえば簡単なんですけど、最初のそのアプリリリースの時に失敗する人が少なくない気がします。 僕の観測範囲だけでも、独立してアプリを出そうとして開発に失敗、「作り直し→リリース延期」となるケースを定期的に目撃しますので、それなりにそういう失敗をする人はいるんじゃないでしょうか。これが20代の若手が失敗したというならまだ分かるんですが、経営者としてすでに十分な実績のある、僕自身も尊敬するような方がその陥穽に陥ったりしていますので、これはもう能力とか才能の問題でなくて、むしろ「知識」の問題なんじゃないかと思うんですね。 そういう僕も、kiznaというアプリを出そうとして落とし穴にはまってしまい、結局日の目を見なかったという苦い経験をしていますので、こういう経験はちゃんと共有して、無駄な犠牲者が出ないようにすべきだと思うわけです。 というわけで、初めてアプリを出
良いプロダクトは、良い「問い」から生まれる 小野裕史氏(以下、小野):今までアイデアの持ち上がり方みたいな話だったんですけども、それではどう実行、最終的なプロダクトにしていくかっていうのは、結構ここがさらに次のハードルになっていくと思うんですが。ここの部分をいかに実現していくかという部分においての、ハック面でもいいですし、文化面でも構わないので教えてください。 須藤憲司氏(以下、須藤):そうですね。佐々木さんのアプローチとすごく似ているというか、我々も、今規模がちっちゃいんで、僕らすごく「問い」を大事にしていて。要は、ある物を作りたい、ある事を解決したいというときに、良い問いだと熱狂できるんですよね。 この問題を解決しようっていうときに、数名が集まって「よし!」ってテンションが上がってディスカッションが活発になってくる。良い問いを、いかに生み出せるかってすごく大事かなと思っていて。 その問
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
図1 かんばんとプル生産方式 図1は、かんばんシステムの抽象的なモデルです。図1で示されているのは、上流と下流の2つのプロセスであり、上流プロセスが下流プロセスに部品を供給しています。最終的な顧客に製品を供給するために、プロセスは部品を生産し、その部品を下流に流し込まなければなりません。しかし、多すぎてはいけません。過剰生産は最悪のムダだと考えられます。そこで、過剰生産を防ぐため、上流が完成した部品を下流に押し出す(プッシュ)のでなく、その代わりに、下流が上流から自発的に部品を取ってきます(プル)。部品が置かれる場所は、「ストア」と呼ばれます。(または、「スーパーマーケット」3 - 大野耐一氏 がアメリカのスーパーマーケットに行った時にかんばんの最初の考えを手に入れました。そこでは、店の人ではなく顧客自身が店の中で必要なものを取りに行きます。) ストアは上流に置かれ、WIPの「バッファ」や
This document provides a summary of various web development topics and resources, including responsive design, Android fragmentation, Google services, Material Design, web components, and more. It discusses principles like universality and accessibility, and recommends actions like focusing on building interfaces in HTML/CSS directly instead of Photoshop. Links are provided to additional articles
第3回SRA関西セミナー チケット駆動開発による「ソフトウェア開発の現場力向上」 のご案内(2013/9/12) http://www.sra.co.jp/public/sra/event_seminar/seminar2013/130912.shtml 【公開】講演資料「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索 http://forza.cocolog-nifty.com/blog/2013/09/redmine-tidd-63.html 【告知】「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」を講演します: プログラマの思索 http://forza.cocolog-nifty.com/blog/2013/08/redmine-1953.html
先日の土曜日に、はてな主催で行われたイベントで現在のチームで行っているフローを紹介しながらデザイナーがXMLを書くと良いことについて発表してきました。 ちなみにXMLというのはAndroidのレイアウトを制御するための言語です。 なぜデザイナーがコーディングまでやるといいと思っているのか、感じていることを少し書きます。 カンプは実装と違う カンプと実際に動くものとは全然違います。例えばタイトルと本文が動的に入るようなアプリを制作しているとします。とすると、自分が想定しないくらい長いタイトルをつける人がいれば、めちゃくちゃ短い本文を連続して書く人もいるかもしれません。どんな文章が入ってもいい感じに見せたいのですが、PhotoshopやIllustrator上だと想像がしずらいです。 また、カンプでボタンのon/offのパターンを作った場合も同様です。実際使ってみると色の変化が大げさだなとか、
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
Redmine 0.9から、チケットのステータスを更新すると進捗率も同時に更新されるよう設定することができるようになります。 これまで、「新規」「担当」「終了」などのチケットのステータスと10%単位の値を選択する進捗率は独立した項目でした。そのため、進捗率を入力する運用を行っていた場合、ステータスを「終了」にしてさらに進捗率も100%にするという操作が必要で、やや面倒でした。 0.9から新たに追加されるチケットのステータスによる進捗の算出を使用すると、チケットのステータスと進捗率を関連づけることができます。これにより、ステータスを変更すれば同時に進捗率もあらかじめ定義済みの値に更新されるようになり、進捗率の更新漏れがなくなります。ただし、この機能を使用すると、進捗率の手入力はできなくなります。 進捗率は、基準を明確にしておかなければ担当者の主観が影響し、担当者ごとに数字のばらつきが発生しが
時間をかける つまらない想像話を以下に書く。 失敗してはいけない。成功しなければ行けないプロダクトだ。 企画から色々と実装アイディア、目的とするユーザー像を聞いている。 それに見合ったシステムを実装しなければならない。 あと6ヶ月で。その間は徹底的に企画と話をする。 部長と話しをして、駄目だったら作りなおす。 6ヶ月の間、エクセル上にガントチャートを引き、開発スケジュールを引いた。 企画・営業は2名。そのうち1名はマネージャ的な担当を行う。 部長は最終決定を下す(と聞かされている)。 エンジニアは3名。チームとしてはまあ良いほうだろう。 3ヶ月後 何を作っているのかわからなくなってきた。 具体像もわからない。 エクセルに書いたガントチャートは、意味を成していない。 ガントチャートを直そうと思うと、他の予定もずらさなければいけなくなり、 だるくなってだれも更新しようとしない。 システム全体の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く