60歳を越えても「楽しい」と言える、クリエイター人生 元PlayStationジャパンスタジオ代表が語る、仕事のおもしろさ
60歳を越えても「楽しい」と言えるクリエイター人生 宮田：というところで、時間が迫ってきたそうなので、いただいている質問に答えていければと思います。まず事前にいただいた質問から何個か取り上げてみたいと思います。 これは前回「ゲームクリエイターヒストリア」に出ていただいた神崎建三さんからの質問です。もしかしたら見ていただいているかもしれないですが「何歳までゲーム業界で働こうと考えていますか？」という質問です（笑）。 桐田：（笑）。ほぼほぼ棺桶に片足を突っ込んでいるようなこともありましたし「何歳まで」と別に決めてはないですけど、仕事をするのが楽しいと思えるうちは続けたいなと。だから「何歳」って区切りは、今のところ決めてないですね。 宮田：なるほどですね。逆に今も楽しいということですよね。 桐田：以前のプロデューサーをやってた時の楽しさに比べれば、半減なんですけど（笑）。でも楽しさのほうがまだ勝
『ときメモ』『どこいつ』プロデューサーは、面接で何を見ていた？ 「ゲームやろうぜ！プロジェクト」で重視された“尖った才能”
オーディションで着目したのは「尖った才能」 宮田：「素人じゃ無理だ」って話が最初はありつつも「どんなプロも最初は素人じゃないか」というお話を打ち合わせでもされていましたよね。それを聞いたとき「確かに」と思いました。「素人からプロになるプロセスを分解していくことで、プロは作っていけるんじゃないか」って話を聞かせていただいてて。 確かにそういった観点で考えると、次のクリエイターを生むところで「ゲームやろうぜ！」は、ものすごいプロジェクトだったなと個人的には思っております。 桐田：僕自身もすごくおもしろさは感じていました。いろんな人と出会えるんですよ。全国各地、主要都市でのオーディションは面接みたいなものですからね。オーディション自体は私が担当してた時に6回ぐらいやっていて。 その時に、全国各地の主要都市でホテルを借りて面接をするんです。ただ、その前にエントリーシートで書類選考をするんですが、書
PSソフト『どこでもいっしょ』を生んだ、名プロジェクトの舞台裏 入社初日に与えられた「素人にゲームを作らせたい」という指令
「桐田さん、実は今日は面接なんだ」でSCEに入社 宮田：では、次のヒストリーポイントに移ります。 ここから次の会社に移られるというところで。開発部署の責任者になって、いろいろトライされたあとに、一区切りついたというところで。ソニー・コンピュータエンタテインメント（以下、SCE）さんに転職されていますね。 桐田：そうですね。そういう意味で言うと、在庫も作ってしまったし、それ以外にも会社に迷惑をかけた部分もあったので。もうそろそろ次のステップも含めて、1回会社を辞めようかなって決めて。まずは辞めると宣言して、2週間後くらいに辞めて、そのあとにどうしようかなと考えて。 宮田：のんびりして。 桐田：そうです、のんびりして。 宮田：だいたい何歳ぐらいの時ですか？ 桐田：34〜35歳かな。 宮田：ゲーム業界でも10年以上やって、一番脂が乗っているタイミングですよね。 桐田：脂が乗っているかどうかはわか
ファミコン誕生前の1980年には“ゲームの貿易”が盛んだった 『ときメモ』『どこいつ』プロデューサーが語る、業界40年の歴史
ゲーム業界で仕事をしているデザイナー、プランナー、エンジニアなどのクリエイター向けに、キャリアデザインをテーマに実施するセミナーイベント「クリエイターヒストリア」。業界で成功を納めているクリエイターは、今までどのようなキャリアを歩んで行ったんだろう……？ という、現在に至るまでの努力や道のり、人生の転機など、その歴史に迫っていきます。本記事では、名作『ときめきメモリアル』『どこでもいっしょ』などをプロデュースし、PlayStationのジャパンスタジオ長を経験された桐田富和氏をゲストに迎え、ゲーム業界歴40年の歴史を紐解きます。 続きの記事はこちら 「クリエイター人生で一番おもしろかったプロジェクトは？」 司会者：本日は、第3回クリエイターヒストリア「元PlayStationジャパンスタジオの代表に聞く！ クリエイター人生で一番おもしろかったプロジェクトは!?」にご参加いただきまして、誠に
『ときめきメモリアル』は、不採算による“開発中止”寸前だった 開発責任者が下した「あと半年待ってやればいいじゃん」の英断
営業担当だったのに、いきなり「ゲーム開発の責任者やれ」 宮田大介氏（以下、宮田）：では次に移っていきましょうか。 営業という立ち位置から、実際に野球ゲームをプロデュースするって話に移っていって。そのあと、実際の開発統括部長になられる感じですよね。 桐田富和氏（以下、桐田）：ええ、そうですね。「営業をずっと極めていく」って言ったら大げさですけど「ずっとコナミの中でやっていくんだ」という思いはあったんですけど。いきなり、あるタイミングで「ゲームの開発の責任者やれ」って言われて。 宮田：（笑）。 桐田：意味がわからないですよ（笑）。でもいろいろ話を聞くと、当時の家庭用ゲーム機は任天堂さんの圧倒的なマーケットシェアだし、PCエンジンの市場もあって。海外に目を向けると、アメリカはセガの「ジェネシス」というのがあるぞと。日本にも「メガドライブ」というゲーム機があったんですけど。 日本では大きな市場じゃ
『鬼滅』も『スラダン』も、起承転結ではなく「起“転”承結」 ベストセラー著者が見つけた、読者の心をつかむストーリーの作り方
「起“転”承結」の発見 柳瀬博一氏（以下、柳瀬）：いきなり話がポンと変わるんですけど、この本の中身で一番、僕が改めて今後参考にしたいなと思ったのが、起承転結から起“転”承結の話なんですよ。 古賀史健氏（以下、古賀）：はい。はい。 柳瀬：起“転”承結のほうがいいじゃんって、なんで発見しました？ 古賀：もう10年ぐらい前ですけど、若いライターから「原稿の書き方がわからない」という相談を受けたことがありました。どういう流れでどう書いていけばいいかわからないという、ぼんやりした相談だったんですけど。 その時に、まず最初に月並みな一般論から始めて、その一般論をバンと覆す、「しかし○○なのだ！」みたいな、ひっくり返す要素で読者の人をびっくりさせて、それに対する説明があって、最後にいいかたちの結論が入れば、それで1,000文字〜2,000文字のコンテンツは簡単につくれると思うよ、みたいな説明の仕方だった
「自分の未来予測を信じてちょっと意地を張ってみる」 まつもとゆきひろ氏がRubyに型宣言を入れない理由
「自分の未来予測を信じてちょっと意地を張ってみる」 まつもとゆきひろ氏がRubyに型宣言を入れない理由 #17 動的型付け言語と大規模開発 テーマは「動的型付け言語と大規模開発」 まつもとゆきひろ氏：まつもとゆきひろです。Matzチャンネル17回目ということでお送りします。ちょっと前になりますが9月28日に私が技術顧問を始めたクラウドサーカスという会社さんがテックイベントを開催されて、その時のテーマが「動的型付け言語と大規模開発」というテーマでした。 その時に話したこととか、話そうとしたこと、話そうと思っていたんだけど時間の関係で話せなかったことなどを補足する意味も含めて今日はちょっと放送しようかと思います。というか、分量が多いので2回に分けて話そうかなと思っています。 このクラウドサーカスのイベントのテーマは別に私から指定したわけではなくて、先方が「こんなテーマで話したいんだ」とか「聞き
「Webに対して不満があるからWebブラウザに手を加える」は大げさか？ 植山類氏が語る、“クレイジーなアイデアに挑戦する”ということ
Blue Whale Systems株式会社の植山類氏は、「LLVM lld」「mold」が解決したプログラムのビルドの問題を例に、“大きな問題”を解決することについて話しました。全3回。前回はこちらから。 サーバーサイドのアプリケーションで分散処理をさせる必要は本当にあるのか？ 植山類氏：「では、大きな問題って何？」という話で、いくつか例を挙げてみたいと思います。これは必ずしもそうするべきという話ではなくて、エンジニアリングはトレードオフなので、すべての選択肢に良いところもあれば悪いところもあります。 ただ、検討もしない、最初から考えてもみないというのは、それはそれで正しいエンジニアリングとは言えないので、気づきを与えるという意味で「こういうふうに考えてみることもできるんじゃないの」という話をいくつかしたいと思います。 このセッションを見ている方で、サーバーサイドのアプリケーションを書い
コンパイラが作ったバイナリをつなぎ合わせるプログラム 「lld」の作者が語る、リンカの仕組み
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。植山氏は、制作中のリンカである「mold」について発表しました。全2回。前半は、リンカの概要について話しました。 LLVMのリンカ「lld」オリジナルの作者 植山類氏：植山類です。今僕が作っているmoldというリンカについて発表します。 今回の発表の概要です。リンカが何かを知っている人はそんなにたくさんいないと思うので、まず説明します。次に、「mold」のポイントは速いことなのですが、速いと何がうれしいのかを説明します。そのあと、どれくらい速いのかを説明した上で、どう実現されているのか、概要を紹介します。詳細になると何時間あっても終わらないので、かなりハイレベルな話をします。 自己紹介のスライドを入れていませんが、僕はリンカを何度か作ったことがあって、LLVMのlld
Google製GNU gold以上の速さを実現 超高速リンカ「mold」を支えるテクニック
Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。rui314氏は、制作中のリンカである「mold」について発表しました。全2回。後半は「mold」速さと、その高速化を実現するテクニックについて話しました。前半はこちら。 リンカが速いと何がうれしいのか 植山類氏（以下、植山）：リンカが速くなって何がうれしいのか。普通にうれしいです。プログラムを書いているとうれしいことがわかると思いますが、makeを実行すると、普通は自分が直前に変更したファイルしかビルドしないので、デバッグをしていると1つのファイルを編集してビルドすることになります。 コンパイラは1つだけのファイルをコンパイルするのはそこそこ速いですが、リンカは基本的には実行ファイルを丸ごと作ります。全体の入力を一気に受け取って出力するため、差分コンパイルであっても
「LLVM lld」「mold」が解決した、リンクが遅い問題 間違った思い込みの解消に必要だったのは“クレイジーな人”
Blue Whale Systems株式会社の植山類氏は、「LLVM lld」「mold」が解決したプログラムのビルドの問題を例に、“大きな問題”を解決することについて話しました。全3回。 1個の本質的な問題を解いてしまうほうが細かいことを考えるよりも簡単 植山類氏：では始めます。本日、機会をいただいて講演をすることになった植山と申します。この講演の内容は「大きな問題のほうが小さな問題より解くのは簡単だ」というタイトルです。 どういう趣旨かというと、常に簡単だというわけではないのですが、いろいろな場面で、1個の本質的な問題をドッカンと解いてしまうほうが、いろいろな細かいことを考えるよりも簡単なことが多いという話です。 そういうソリューションが往々にして見逃されがちということがけっこうあって、そういうことにどうやって挑戦していくのかという気持ちの話を、僕がそういう大きな問題を解決した経験を踏
いかにもなフリー素材の使いすぎが資料を安っぽくする プロが教える、プレゼン資料で使うビジュアル選定のポイント
東京・立川を拠点に起業に関連したさまざまなイベントを開催しているStartup Hub Tokyo TAMA。本記事では、『秒で使えるパワポ術』『秒で伝わるパワポ術』の著者で、シリョサク株式会社代表の豊間根青地氏が登壇したイベントの様子をお届けします。今回は、伝わりやすさの3要素の3つ目「画像」ついて語られました。 前回の記事はこちら 資料に使ってほしい2つのビジュアル要素 豊間根青地氏（以下、豊間根）：最後に画像の話をさらっとして終わるんですが、今、2つのスライドを作りました。 文字と色の話で、バリューチェーンのスライドとお客さまの声のスライドを作った。これだけでも、一応内容としてわかるのはわかるんだけど、なんか寂しいですね。殺風景なわけです。なので、これにビジュアルの要素を足していきます。 ビジネスシーンでスライドを作る時の、使ってほしいビジュアルの要素は2つありまして、「アイコン」と
資料作成のコツは、「2行以内」で答えて“心のひろゆき”がツッコむ プロが伝授する、資料をわかりやすくする4つのツッコミどころ
東京・立川を拠点に起業に関連したさまざまなイベントを開催しているStartup Hub Tokyo TAMA。本記事では、『秒で使えるパワポ術』『秒で伝わるパワポ術』の著者で、シリョサク株式会社代表の豊間根青地氏が登壇したイベントの様子をお届けします。今回は、まず答えて後から根拠をくっつける姿勢や、階層箇条書きの長所について語られました。 前回の記事はこちら まず答えて、根拠は後からくっつける 豊間根青地氏（以下、豊間根）：ということで、問いが設計できたところで、答えを整理していきます。ここで一番お伝えしたいのは、まずは端的に「2行以内」で答えるということです。先ほど作った問いに答えていくわけですが、まずはシンプルに答えてください。問いに対して5行とか6行とかダラダラ書くと、答えにならないんですね。 みなさんもたぶん身に覚えがあると思います。みなさんの身の回りに、質問すると質問への回答で返
文章が3行以上続くパワポ資料は読まれない まず全体像が伝わる、拾い読みできる提案資料の作り方
東京・立川を拠点に起業に関連したさまざまなイベントを開催しているStartup Hub Tokyo TAMA。本記事では、『秒で使えるパワポ術』『秒で伝わるパワポ術』の著者で、シリョサク株式会社代表の豊間根青地氏が登壇したイベントの様子をお届けします。今回は、スライドの本質や、スライドを見やすくするポイントについて語られました。 前回の記事はこちら スライドの本質 豊間根青地氏（以下、豊間根）：あと2つですね。「構造を図解にする」という話をしていきます。ここでお話しするのは、要はタイトルとキーメッセージが作れましたと。そのスライドで答えは決まったんだけど、じゃあその根拠・理由をどう作るかというところの考え方をお話しします。 いわゆるスライドの中に載せるコンテンツ、図表の話をしていくわけですが、最初に意識いただきたいのは、みなさんがパワポのスライドをどういうイメージで捉えるかという話です。
「Rubyは落ちるか、伸びるかの岐路に立っている」 まつもとゆきひろ氏が語る、30年後に向けた生存戦略
プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。4回目は、Rubyコミュニティが生存するために必要なことについて。前回はこちら。 Rubyコミュニティが生存するためには何が必要か まつもとゆきひろ氏（以下、まつもと）：さて、これらの教訓をもとに、Rubyの未来はどうなるかについて考えてみましょう。 教訓をもう1回まとめておきますね。アイデアだけでは、価値がない。単純さは、いつもいいこととは限らない。仕様が大きいことは、いつもい
まつもとゆきひろ氏が“幻のPerl6”から学んだ教訓 「OSSの最大の敵」と「セカンドシステムの危険性」
プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。3回目は、「Second System Syndrome」について。前回はこちら。 退屈は最大の敵 まつもとゆきひろ氏：次はPerlですね。ここまでですでに4回ぐらいPerlの話題が出てきています。なぜかというと、私はPerlが大好きなんですね。実は、Perlが大好きなんですが、Perlのプログラミングは大好きじゃないんですね。あと、Perlのソースコードも大好きじゃないんですね
単純すぎて流行らなかった「FORTH」、複雑すぎてうまくいかなかった「PL/I」 まつもとゆきひろ氏が過去から学んだ、プログラミング言語のあるべき姿
プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。2回目は、「単純さはいつも最高ではない」と「大きいことはいつもいいことではない」について。前回はこちら。 単純さはいつも最高ではない まつもとゆきひろ氏：「最も単純なプログラミング言語は何ですか？」という質問をするとですね……文法的にという意味なんですけども。 初期の言語として、Lisp、FORTH、APLなど、みんな1960年代ぐらいに作られた言語ですが、こういうものが挙げられ
「アイデアだけでは意味がない、実装されて初めて意味がある」 世界最古のプログラミング言語から学ぶ教訓
プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。1回目は、「アイデアだけでは十分ではない」について。 Ruby開発のきっかけ まつもとゆきひろ氏：じゃあ、始めます。Rubyを作り始めた記録が残っているんですが、その当時勤めていた会社の先輩にあたる人が、本を書くという話になったんですね。 その時に、彼は『プログラミング言語を作りながら学ぶオブジェクト指向』という本を書くと言ってきたんですね。編集の人と話をしていく中で「どういう企
ソフトウェアが“死”を迎えないためにできること Ruby30年を振り返って語る、発展におけるバランスの難しさ
Qiita Conferenceは、ソフトウェア開発者が集まり、最新の技術や最先端の挑戦・ソフトウェアの未来についての考えや知見を共有し、つながる場を創出する、「Qiita」が開催するオンライン技術カンファレンスです。ここでプログラミング言語Rubyの生みの親であるまつもとゆきひろ氏が登壇。最後に、ソフトウェアが死を迎えないために、それぞれの時期でできることについて話します。前回はこちらから。 なぜソフトウェアは死んでしまうのか まつもとゆきひろ氏（以下、まつもと）：今度は横軸、時間軸です。ソフトウェアの寿命って意外と短いんですよね。開発のほうでいうと、毎年新しいWebアプリケーションフレームワークとか、なんとかツールみたいなものがどんどん出てくるんですけど、数年経つと何か違うものに取って代わられるみたいなことが頻繁に起きるんですよね。 物によるんですが、アプリケーションとかだと数年。2年
mod_perlからFastCGI、PSGIまでの今昔物語 時代の移り変わりに伴うデプロイ手法の変化
「YAPC（Yet Another Perl Conference）」は、Perlを軸としたITに関わるすべての人のためのカンファレンスです。ここで面白法人カヤックのmacopy氏が「デプロイ今昔物語 〜CGIからサーバーレスまで〜」をテーマに登壇。続いて、mod_perl、FastCGI、PSGIについて話します。前回はこちらから。 mod_perlの手法 macopy氏：というわけで、mod_perlの話をします。mod_perlは「Apacheの中にPerlのインタプリタを組み込んでしまいましょう」という発想（のこと）ですね。 Apacheの中にもMPMという、どういうふうにプロセスを立ち上げておくか、リクエスト・レスポンスを処理するかを決めるモジュールがあります。それによってプロセスやマルチスレッドを処理したりするんですが、そのワーカーの中にmod_perlがロードされて、その中に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
