Murga

個人的に言いたいコト・主張・気持ち。

ゲームクリエイターへの漠然とした尊敬と憧れ

最近スマブラ SP をやっている。コンセプト、デザイン、音楽、ゲームバランス、どれを見ても素晴らしく、感動している。

大乱闘スマッシュブラザーズ SPECIAL - Switch

大乱闘スマッシュブラザーズ SPECIAL - Switch

僕みたいな人間でも楽しめるスゴさ

僕は「ゲーマー」と呼ぶには程遠い人間だ。遊んだゲームタイトル数も別に多くないし、やり込んだと自負できるゲームも数本しかない。

おまけに、練習を求められるゲームは苦手で、楽して勝ちまくりたいと思っている。ゲームでは一切のフラストレーションを溜めたくなく、もし「無敵モード」みたいなチートが存在したら、初回プレイから躊躇なく使って、それで楽しめる、変な人間なのだ。

そんな偏屈な人間でも、スマブラ SP は、イライラしながらも、何とかクリア出来る絶妙な難易度になっていて、爽快感もある。プログラマになってからというもの、ゲームをやって感じるのはこうしたユーザ目線での作り込みの細かさばかりである。

また、スマブラ SP に関していえば、ディレクターの桜井政博さんのインタビュー記事を読んで、そのディレクション能力、プロジェクトの遂行能力の高さを感じ、エンジニアとしても感心させられることばかりだ。

ゲームクリエイターに尊敬の念

任天堂繋がりだと、スーパーマリオオデッセイにも感動したし、亡くなった岩田聡社長の超人っぷりも尊敬している。なんというか、本当に一流の人って、「プログラミングしかできない」とかいうことはなくて、企画だってディレクションだって経営だってやれてしまうんだな、と思わされる。プログラミングしかできない人ってのは、二流・三流なんだなぁ、と。

あと、個人的に知っているものでいうと、「幕末志士」という2人組のゲーム実況者がいて、その片割れの西郷さんが作る自作ゲームにも感心している。

ツールとしてはよくある「WOLF エディタ」などを使っていて、シンプルなミニゲームが多く、イラストはお世辞にも上手とは言い難いのだが、相棒の坂本さんを笑わせるために毎回いろんな創意工夫を凝らしている。

生業にしているプロのゲームクリエイターと西郷さんを並べるのはズレているのかもしれないが、「誰かを楽しませるゲームを生み出す人」という意味では、プロ・アマの垣根を無視して、ゲームクリエイターと言えるかな、なんて思っている。

僕は業務アプリを主に開発する職業エンジニア・プログラマなので、ゲーム開発というものには触れたことがない。だから、PC・プログラミングのスキルを駆使して、人を笑わせる、楽しませるモノを作っているゲームクリエイターを尊敬するし、素敵な仕事だなぁと思っている。

業務アプリにも「楽しさ」を入れたい

僕が今まで開発に携わってきた業務アプリには、「使っていて楽しいこと」なんて求められるはずもなく、画面に動きもないし、ランダム性も何もない。

いや、普通に考えて業務アプリならそれで結構なのだが、僕は会社に入った当初から、「楽しい業務アプリは作れないもんかな?」とずっと考えていた。

毎日その画面を見て仕事するなら、楽しい画面である方がいいんじゃないか。ワケもなく開きたくなるような、面白いアプリである方がいいんじゃないか。そう思うのである。

B to C なアプリになると、ユーザビリティの中に多少は「インタラクティブ」な要素が求められることもあるが、ゲームほど「面白い」に突き抜けた作りになったことはないので、まだやれるんじゃないか、なんて思う。

ゲームクリエイターになりたいかというと、微妙

業務アプリで面白さ狙ってないで、ゲームクリエイター・ゲームプログラマにでも転向したらどうか、とも一瞬思ったが、それはそれで微妙だ。

それは、僕がプレイヤーとしてはひねくれているし、あまり「ゲーム全般」に対して思い入れがないからだ。ゲームが嫌いというワケではないが、「良い大人がいつまでゲームに必死になってんだ」という冷めた目は自分の中にあるし、自分が本気にならないモノに対して、「さぁ楽しいモノを作ろう!」という気概は、生まれにくいと思うのである。

面白いゲームを作る人たちを見て、近い同業者として凄いな、とは思うものの、自分もそうなりたいかというと、なんともいえない感じなのである。

素直でいる能力と、実行力

桜井政博さんのインタビュー記事なんかを見ていて強く思うのは、「ゲームは楽しい」「ゲームが楽しい」と素直に思うこと、思い続けることが大事なんだなぁと思う。

意識的に「子供でいよう」などと考えるのではなく、天性の好奇心を純粋に持ち続けた結果なんだろうなぁと。

「もういい歳だから」「マジになるようなことでもないし」と一度でも諦観を持ってしまったら、もう戻れないのだ。

楽しくないものよりは、楽しいものを作りたい。面白くできるなら、面白くしたい。

それを実際にやれるかどうかは、まず素直に楽しい事を楽しいと思う力が必要なんだと感じる。

その上で、一流のクリエイターになっていくには、現実的なしがらみにも立ち向かって、夢を具現化していく実行力が必要なんだろうな、なんて思う。


何が言いたかったのか、自分がどういう立場なのか、自分でもよく分からない。

モヤモヤしているけど、ゲームクリエイターのような、楽しいもの、面白い夢を提供できる人に、できることならなりたいし、そういう人たちのことに憧れて、尊敬していることは間違いない。

桜井政博のゲームについて思うことX

桜井政博のゲームについて思うことX

ウォーターフォール脳がほんのりと理解したアジャイル・スクラムの概要

前職は割とお堅いウォーターフォール式の現場がほとんどで、現職ではアジャイルチックな進め方をするようになってきた。

そんな中、実はイマイチアジャイル開発とかスクラムとかが指す意味が分かっていなくて、「この人が言う『アジャイル』と、自分が持っている『アジャイル』の概念がズレてるんじゃないか」と思うことがよくあったので、改めて調べてみた。

「アジャイル開発」は「心構え」

まず、「アジャイル」とよく云われる単語の、一般的な、辞書的な定義を確認する。コレは、エクストリーム・プログラミング (eXtreme Programming) の考案者で知られるケント・ベックってオジさんとかが考えた、アジャイルソフトウェア開発宣言で提唱されている価値観と原則のこと。

提唱されている価値観は以下の4つ。

  1. プロセスやツールよりも個人と対話
  2. 包括的なドキュメントよりも動くソフトウェア
  3. 契約交渉よりも顧客との協調
  4. 計画に従うことよりも変化への対応

これらについては、

左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

と記されており、決して「ドキュメント要らねえ」「計画しなくていい」って意味ではない。

そして、原則として触れられているのは以下の12項目。

  1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
  2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
  3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
  4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
  5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
  6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
  7. 動くソフトウェアこそが進捗の最も重要な尺度です。
  8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
  9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
  10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
  11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
  12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

この辺で、僕はちょっと「精神論っぽいなぁ」と感じてしまった。

  • 「価値のあるソフトウェアを速く継続的に提供」「一定のペースを継続的に維持」
    • ココで完成、って区切りを作らないでどうやって契約するつもりだろう。客側も成果物を定義しないで何を作らせたいんだか…
  • 「日々一緒に働かなければなりません」「フェイス・トゥ・フェイスで話をする」
    • 口頭伝達に頼るから「言った」「言わない」になるんじゃん、文書化しろよ
  • 「技術的卓越性と優れた設計」「シンプルさ」「自己組織的なチーム」
    • 日本の職業エンジニアにそんなスキル持った人間がどれだけ居るかねぇ、基礎スキルがないからどんな開発手法とっても上手くいかないんだよ

このような疑問がモヤモヤっと湧いた。

いくつかの前提がウォーターフォールとは異なる

そこからもう少し調べてみると、アジャイル開発という手法を選ぶ場合は、そもそも、ウォーターフォールな考え方をする時に前提としている事柄が異なるのである。例えば以下のような事柄は前提にしていない。

  • 何をどんな構成で作るか、事前に厳格に決める
    • 何が欲しくなるかは日々の情勢によってちょっとずつ変化する
    • 大枠として「こんなことを実現したい」はあるものの、システム構成も、実装する内容も、日々の状況に応じて変えることが前提
    • 要件 = Scope は事前に決まらないし、日々変更が入るモノとして携わる
  • 開発チームは工程に合わせて要員が増減する
    • 少数精鋭なチームで、メンバを固定する。これにより、チームがある期間内にかけられる時間は固定化される (5人チームなら、8時間/人 × 5人 × 1週間の営業日5日間、で、200時間、みたいなのが固定と捉える)
  • 要件に合わせて開発期間や費用を割り出す
    • アジャイルの場合、スプリントと呼ばれる区切りを設けることで、リリースまでの期間を固定する。要員変更もしないので、その期間内でかけられる作業量も上限が決まる
    • 固定化された期間と労働力 (コスト) の中で、実現できる要件のうち、重要なモノから順に着手する、という考え方
  • ドキュメントに関する細かな成果物責任・納品義務がある
    • あんまりない
    • そもそも何のためにドキュメントが必要だったかというと、ウォーターフォール式ではチームの要員が増減し、引き継ぎが発生するため、全てを文書化する必要があった
    • アジャイルの場合、チームメンバは少数で固定するし、毎日顔を突き合わせて密にコミュニケーションをとるので、ノウハウは各人が持ったまま、うまく摺り合わせて作業していける。だから余計なドキュメントは要らない
    • 極端な話、密なコミュニケーションによって、全ての事柄について認識齟齬がないことが確認できていれば、設計書も計画表も、そのチームにとっては必要ない、といえる
    • ただ、現実的には人間は忘れるし、誤解も生むので、要件一覧や、スプリント内でのタスク一覧などは、特に認識齟齬がないように文書化する。仕様書も情報共有のために必要な分だけ書く
    • お客さん側も、「動くソフトウェアさえあればええねん」という考え方で合意できていれば、納品義務も発生しないというワケ

個人的には、これらの前提が覆される、覆せるという事実に、目からウロコなところもあった。

要件は定まらない

ウォーターフォール式の時だってそうだったはずだ。せっかく要件定義書をガッツリ作っても、長期間の開発中に法改正があったりして、当初の想定どおりに作れなくなったりする。また、工程の終盤になって「やっぱりこの画面が欲しい」とか「この CSV がないと業務が回らない」とか言われて、炎上しながら無理くり実装したりすることもあるだろう。

要件定義書を作っている時は、確かにそれが欲しかったのだろう。でも、時間を経ると様々な状況が変化するし、それによって考慮不足や新たなアイデアが生まれてくるから、その当時決めたとおりのモノでは不足感があり、仕様変更したくなるワケだ。

ウォーターフォール式の要件定義という工程は、「要件を洗い出して決めていた」のではなく、「それ以降の仕様変更を受け付けないための契約書を作っていた」と言った方が、正しいかもしれない。でもそれは結局、お客さんが満足する結果にはなりにくい、ということは、これまで経験してきたはずだ。

だったら、お客さんが満足できることを第一優先して、要件は日々変えて調整していきながら、その瞬間その瞬間で一番重要なモノから実装してリリースしていきましょ、という考え方なのだろう。

余計なドキュメントは要らない

結局のところ、「要件を先に FIX しなきゃ」「納品する成果物の種類を定義しなきゃ」みたいな感覚って、「これまでそうしてきたから」でしかなくて、「今後もそうしないといけない」ワケじゃない。

既にみんな分かってるじゃん。設計書なんて書いてもお客さんは読まないし、開発した自分たちですら、ボリュームが多すぎてコード見た方が早くて正確だ、って。だからもう、最初から「そういうゴミになる資料は作らなくていいっすよね?」とお客さんと合意を取っちゃえばいいのだ。そうすれば、「絶対に作って残さないといけないドキュメント」なんて、かなり少なくなることは明らかだ。

僕が以前書いた「メモノートの違い」で言うと、開発中はずっとメモの考え方で動き、チームが解体されるようなタイミングで初めて、引き継ぎ等のためにノート的な情報が必要になるワケだ。そのようなやり方で行くことをお客さんと予め合意すれば、別にそれでいいのだ。

「XP」「スクラム」はアジャイルを実現するプラクティスの一つ

前述のとおり、「アジャイル開発」という言葉が示すのは、提唱された「4つの価値観と12の原則」のことしか指さない。これらだけ見ると、やっぱりまだ根性論っぽいというか、具体性に欠けるのだ。そりゃそうだ、提唱しているのは「価値観」までで、方法論ではないからだ。

結局のところ、「アジャイルソフトウェア開発宣言」が言っているのは、「今まで大事だとされてきたことより、コッチの事柄の方が大事だべな。で、それをどうやって実現していくかは、自分で考えてな」ってことなのだ。だからアジャイルという言葉だけ聞いても、あまりしっくりこないのだ。

コレだけだとしっくりこないので、具体的な方法論に落とし込んでいったのが、「エクストリーム・プログラミング (XP)」だとか、「スクラム」だとかいう手法なのである。これらは手法、方法論の一つであり、こうしたやり方ならアジャイル開発の価値観を守っていけると思うよ、というフレームワークなのだ。

最近話題の「スクラム」については、「認定スクラムマスター」という資格も出来上がっているくらい、具体的な手法が定められている。表面的な言葉だけ聞くと根性論っぽさがあるのだが、一応資格の中ではそれぞれの言葉や進め方、価値基準に定義があり、メンバはそれを遵守しないといけない。誰がどのように決めたにせよ、一人の思いつきの根性論ではなく、思考フレームワーク・意思決定フレームワークとして体系的にまとまっていることで、みんな従いやすいって魂胆なんだろう。

実際は「自分の頭で考える」が求められる

大元の価値観は「良いシステムを迅速に・継続的に構築することを目指す」ことに終始している。コレまでの「一回決めたこの仕様どおりのモノを作って」というモノづくりの考え方ではなく、「結果的にこういう価値を生み出したいから、それに合わせた良い感じのやり方を随時生み出してって〜」といった、サービス提供の考え方に近いのだと理解した。

だから、スクラムマスターなどは資格になっているとはいえ、実際チームに取り入れて作業する場合は、人・場所・状況に応じてルールの調整が必要になるだろう。もしかしたら「スクラム」ではない手法に転換することで上手くいく例もあるのかもしれない。いずれにせよ、求められるのは「より良い状態にしようと改善に努めていくこと」なのであって、お客さん側も「これだけのシステムをいつまでに」という考え方ではない、ということなのだ。

そんなワケで、どうしても巷の記事を読んでも、「正解」がない。

  • 具体的に作成するドキュメントってなんなの?雛形はないの?
    • → その瞬間に必要になったものを作るだけ。雛形はない。関係者が分かればいい。

アジャイル開発を実践したことがない、ウォーターフォール脳だった人間が理解したのは、こんな感じ。

参考

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

  • 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
  • 出版社/メーカー: オーム社
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)
  • 購入: 42人 クリック: 1,991回
  • この商品を含むブログ (257件) を見る