Posts Tagged ‘考え方’
ゲーム開発から学ぶコンセプトを共有する4つのポイント
Demiurge StudiosでデベロッパをしているEddie Scholtzさんが書いたゲーム開発を始める際の心がけが話題に上がっていました。EddieさんはShoot Many Robots、Borderlands、Rock Band Country Track Pack、Rock Band Metal Track Pack、Godfather 2などの開発に携わったそうです。
そんなEddieさんによると最初に大事なのは下記のポイント。
- そのゲームが面白そうに見えるかどうかのフィードバックをなるべく早く得る
大量の開発費をリスキーなアイデアに費やすなら、コンセプトビデオを公開して反応を見てみる。 - 開発チームに確かなビジョンを伝える
ドキュメントを読んだだけでは開発者はそれぞれ異なるイメージを抱くかもしれない。 - 詳細を早く伝える
100ページもあるドキュメントよりも数分の動画が効果的 - 説明が難しい機能はイラストを書いて説明してみる
誰も実現しなかったアイデアは説明しづらい
エントリには実際にヒットしたゲームのコンセプトビデオの実例が示されていました。ゲームという事でやや特殊ではありますが、リッチなアプリケーションのコンセプトを伝えるのには動画を使うというのはいいアイデアかもしれませんね。特にユーザーインターフェースについては言葉や文章でうまく説明できなかったり、スライドではどうもイメージが伝わらないという経験には心当たりがありませんか?この例に学ぶなら動画というのが1つの処方箋になりそうです。
ヒットしたゲームのコンセプトビデオの例
via:http://www.eddiescholtz.com/entry/starting-a-game
良いデベロッパになる為の13のTIPS
読みやすいTIPSのリストが話題になるのは洋の東西を問わず見られる現象です。ハンガリーのブタペストのデベロッパ、Csaba Okronaさんが書いた記事が話題になっていました。さっそくその項目を見てみましょう。
- レッスン1 全体像を理解せよ
コーディング作業だけに囚われず、ビジネスやプロジェクト等の面からも理解する。 - レッスン2 自分の時間を確保せよ
残業や早出は結局バグを招く。スピードは良いデザインと正しいアーキテクチャから生まれる。 - レッスン3 間違った時は考え方を変えるチャンス
既存の技術で問題が遅くなってきたような場合は新しい技術へ移行する。ただし既存の技術がうまく行っている場合にただトレンドを追ったりはしない - レッスン4 脳を鍛え続けろ
日々のタスク以外の鍛錬を行え。コードゴルフなどはよい例 - レッスン5 人生を大事にする
特に重要。残業が続けば燃え尽きるのも早い。 - レッスン6 集中
マルチタスクを避け、1つの事に集中する。 - レッスン7 自己を貫け
一度や二度の失敗でくじけずに失敗から学ぶ。ずっとうまく行かないならば別の方法を考える機会(レッスン3) - レッスン8 計測せよ
推測だけで方法を決めずにベンチマークなどをとって判断する。人間の感覚は当てにならない - レッスン9 コードのパフォーマンスだけに拘らない
550ミリ秒を500ミリ秒に短縮してもユーザーには分からない - レッスン10 機能を落とす事も考える
どうしても期日に間に合わない場合は必要性が低い部分を切り落として後に回す事もできる。実際この業界では良くある事だ。 - レッスン11 コーディングスタンダードを守れ
たとえチームで開発をしてなくてもコードに一貫性を持たせろ - レッスン12 テストせよ
テストも仕事の一部。テスト用の環境やツールを使えるようにしておく - レッスン13 ユーザビリティ
ユーザーインターフェースを開発する時は常にユーザーの利便性を頭に置く。
Csabaさんの10年の経験の中で感じた経験則だそうですが、とても自然なリストですね。今年現場に入ったような新人のエンジニアにあなたが伝えたいと思う事とかなり共通する部分もあるのでは?遠くハンガリーの地でもこんな事を考えている人(ちなみに漫画好きで仏教徒らしい)が居ると思うのも面白いなと思います。あなたが自分の経験から伝えたい事はなんですか?
成功するスタートアップのパターン
「こんなサービスを運営するスタートアップを企業したら、どうなる?」という脳内起業に日々忙しい皆さんに面白い情報です。先日公開されたStartup Genome Reportが複数の媒体(TechCrunch, GigaOM)で話題になっていました。この記事ではスタートアップについていくつかの視点からみた面白い考察を提示しています。いくつか面白そうな所を抜粋します。
業種別、ステージ別の収益の推移パターン
発見期、確認期、効率期、拡大期の4つのステージでの収益のパターンを業種別に示した図です。たとえば購読モデルの場合、サービスの拡大の時期に大きく収益の成長が望めることになります。
企業の動機の内訳
企業のマインドにはいろいろな性質があるという分析のチャートです。4時間労働ライフスタイルだけバランスが突出しているのが気がかりですが、性質の具体例は下記のような感じ。
- 自動化推進家(手作業が必要だったものを自動化して提供する)
Google, Dropbox, Eventbrite, Slideshare, Mint, Pandora, Kickstarter, Hunch, Zynga, Playdom, Modcloth, Box.net, Basecamp, Hipmunk. - 社会変革家(一般多数のユーザにリーチし、寡占になりやすい)
eBay, OkCupid, Skype, Airbnb, Craigslist, Etsy, IMVU, Flickr, LinkedIn, Yelp, Aardvark, Facebook, Twitter, Foursquare, YouTube, Mechanical Turk, MyYearbook, Prosper, PayPal, Quora - 構築家(スモールエンタープライズ向けに成功例のあるプロダクトをリビルド等)
PBworks, Uservoice, Mixpanel, Dimdim, HubSpot, Marketo, Xignite, Zendesk, GetSatisfaction, Flowtown - 野心家(エンタープライズでの売上を注視)
Oracle, Salesforce, MySQL, Red Hat, Jive, Ariba, Rapleaf, Involver, BazaarVoice, Atlassian, BuddyMedia, Palantir, NetSuite, Passkey, WorkDay, Apptio, Zuora, Cloudera, Splunk, SuccessFactor, Yammer, Postini
その他、リポートからピックアップされていた5つのポイント。
- 変化を恐れない
- 師匠を探せ
- 投資家を気にしすぎるな
- 技術サポートを受けろ
- ふさわしく計画する
なんというかあまたの星になっていったスタートアップ達の事が考慮されていない気もしますが、夢を描く時に参考にする事ができそうです。また列挙されている具体例ひとつひとつについて調べてみても新たな発見がありそうですね。他にも面白そうなチャートがありますので原文をご覧になってみてください。
同じレポートの記事の和訳記事
http://www.startup-dating.com/2011/05/startup-genome/
データ=富の時代
Stephen O’Gradyさんによるデータこそが重要であるという主旨のセッションの資料が話題になっていました。IBM、マイクロソフト、グーグル、FacebookといったIT界のトッププレイヤーの移り変わりを4つの段階に分類しています。曰く。
- 第一世代(IBM) ハードウェアが富であり、ソフトウェアではない
- 第二世代(マイクロソフト) ソフトウェアが富である
- 第三世代(グーグル) 富はソフトウェアの中にはないが、差異を作っている
- 第四世代(Facebook Twitter) ソフトウェアは差異ですらなく、価値はデータである
ソーシャルグラフの重要性などは広く知られていますし、たしかにサービスやソフトウェアの機能の差というのは少なくなって来ている気がしますね。スライドにはグラフなどもあります。
優れたプログラマの姿勢トップ10
Steve Rileyさんがブログに書いていた記事がリバイバルでバズっていました。「The Top 10 Attributes of a Great Programmer」と題して優れたプログラマが持っている姿勢をリストアップしています。
- 優れた問題解決者であること
- 物事を遂行すると同時に怠惰である
- 他人のコードを理解する
- プログラミングへの情熱
- 学びたいという欲求の為に学ぶ
- 数学が得意
- コミュニケーションスキル
- ディベートに強い
- 超楽観主義者
- 超悲観主義者
本人の体験ベースで書かれていることもあり納得しやすい項目ですね。記事内ではさらに追加の10項目として時間の見積もり力やスキルを他のプログラマに伝えられるといった内容も挙げられています。またコメント欄でも20件以上のリプライがあり、いろいろ指摘が出ています。
- 11個目にユーモアのセンスを追加だ
- Emacsのアウトラインモードを使うと思考の助けになるよ
- 12番:優れた英語力
- 優れたプログラマを具体的に挙げて欲しいな
皆さんは優れたプログラマとは何だと思いますか?
via:http://programmingmatters.com/the-top-10-attributes-of-a-great-programmer/
わがままなプログラマにならない為の10のルール
「エゴレスプログラミング」という言葉があります。アメリカのコンピューター科学者、ジェラルド・ワインバーグ氏によって『プログラミングの心理学』にて取り上げられた思想です。プログラマ同士が協調する事で最終的なコードの品質が向上するという思想です。プログラマが協調できていないムードだとコードの品質が下がると言い換えてもなんだか思い当たるフシのある感じです。1970年代からある考え方ですが、ちょうど話題になっていました。さてそのエゴレスプログラミングの為の十戒は下記のようになっています。
- 自分が失敗をする事を認める
- コードは自分自身ではない
- どれだけ空手を知っているかは重要ではない。他にもっと知っている人がいる
- 相談なしにコードを書き換えない
- 自分よりも知識が無い人に対して尊敬と敬意と忍耐を持って接する
- 唯一不変な事は、世界は変わるという事
- 権威は立場からではなく知識から生まれる
- 自分が信じるものの為に戦え、ただし敗北は礼儀正しく認めよ
- オフィスでコードを書くだけの人になるな
- 人物ではなくコードを批評する。人には親切にし、コードには遠慮しない
このルールは1971年に作られたものですが、これらのルールの逆を行く人物を想像してみるとたしかにちょっと同じチームになるのは遠慮したい感じですね。考えさせられる内容なので原文もご覧ください。残念ながら日本語の書籍は手に入れづらい状況のようですが、英語のKindle版はすぐに手に入れる事ができます。
補足
ワインバーグ氏は現在、闘病中です。Twitterにて直近の様子を伺い知る事ができます。著作も多く広く読まれている物が多数です。
参考:
濃縮還元オレンジニュース Gerald M. Weinberg氏,胸腺癌で余命わずか
プログラミングの6大10項目リスト(青木靖氏のサイト内)
via:http://www.codinghorror.com/blog/2007/03/top-6-list-of-programming-top-10-lists.html
私がオープンソースに参加しない理由
Brandon Haysさんのブログ、TEHDAILYFLUXにて投稿されたオープンソースに関する記事が話題になっていました。このブログをご覧になっている方はオープンソースで作られたソフトウェアの利用の経験がある人がほとんどかと思いますが、オープンソースのソフトウェアを開発する側に回った事のある方は少ないのではと思います。この記事ではどうしてオープンソースに参加できないのかについての著者なりの理由が列挙されていました。
- 認定証も表彰も技能章も無い
- 何処から始めればいいのかはっきりしない
- ガイドラインはメンテナーにとっては有益だけど、私にとってはそうではない
- オープンソースは私のような人よりも優れた人の為のものである
- 参加しようとすると自分が劣っているように感じてしまう
- 時間がない
- 孤独感
ここの理由の背景は元エントリにて述べられていますが、とても正直な感想のように感じます。たしかにオープンソースへ参加するというのは妙に敷居が高いように感じますよね。なおコメント欄には「そんな事ないよ!」とオープンソース宣教師の方々が大量襲来しています。いくつか抜き出してみると、
- それは考え過ぎだよ
- もっと優れた人の為のものなのではというのはみんなが感じる劣等感(インポスター症候群)だよ、克服しなきゃ
- 貢献したいからという動機はうまく行かない。作るものもないのにC言語を学ぶようなものだ
あなたにもオープンソースに参加しようと思ったけど、しなかった理由があればぜひコメント欄、ツイートでお願いします。
via:http://brandonhays.com/blog/2011/05/03/why-i-still-dont-contribute-to-open-source/
追記 ツイートで頂いた感想