インセプションデッキについて

■ なんでインセプションデッキ?

ゲーム開発のプロジェクトにおいて、今まではプロジェクト計画書を作っていた。

ここで、アジャイルサムライで提唱されているインセプションデッキの枠組みをプロジェクト計画に応用できないか?という考えで、このメモを描いている。

 

■ われわれはなぜここにいるのか?

大いに夢を語るのもよいし、現実的な落としどころを書くのもよい。

プロジェクトの根幹にかかわる理由を一つ選びだし、赤でくくることが重要である。

 

■ エレベーターピッチ

以下の内容を考えて言語化すること。

・これから作ろうとしているプロダクトは誰向け?

・一言で表すとどんなプロダクト?

・コアとなる価値は何か?

・競合との差別化はどのような部分か?

 

■ パッケージデザイン

最初にこれを作ることが重要である。販売サイトにおける、自分の商品の価値をアピールする文章は、そのまま自分が商品を作る時に力を入れるべき部分となる。だから先にパッケージデザインを作っておくことが重要である。

これは別の記事で述べたい。

 

 

■ やらないことリスト

きちんと決めておくこと。どこに力をかけて、どこに力をかけないかが明確になる。

 

トレードオフスライダー

機能、期間、予算、品質について、どれを優先度を高くするかを決めるためにつけるもの。

 

■ プロジェクトの期間を決める

プロジェクトの期間が長くなるほど、プロジェクトの失敗のリスクは高まる。

 

 

 

 

 

これからの方針について

 

ダウンロード販売できる商品を作っていく

なぜ、ダウンロード販売かというと、やることがシンプルだからである。

「商品を作る」⇒「サイトに登録して売る」これだけ。

自分が望まない限りは、他の人がここにかかわったりしないし、自分のペースで仕事を進められる点はとても良いといえる。

 

■ 2次創作はあまり自分に適していなかった。

2次創作のイラストを描いて、pixivなどにしばらく投稿していた。

しかし、あまり伸びなかったし、そもそも2次創作で評価をもらうためにイラストを描くことは楽しいか?と聞かれると疑問である。正直作業していて、あまり楽しくはない。このまま無理して続けても、どこかで破綻しそうである。

 

■ イラストだけで勝負するのは自分には合っていない。

たとえば、イラストコンテストで受賞しよう、とか、Twitterでいいねが1万つく絵を描いてやろうとか、そういったことは私は、少なくとも今は目指してはいけない。

理由は、私は絵そのものにそこまで深く興味を抱けていないからである。

 

2020/12/14 - 2020/12/20 まとめ

一週間のまとめである。 

 

■ 2020/12/14

カフェイン断ちを始めた。

1日目。

うっかり緑茶を飲まないように気を付ける必要がある。

しばらくは、麦茶中心の生活である。

 

■ 2020/12/15

頭痛で一日ダウンしていた。

貴重な一日だが、おそらく何か間違いがあって、

このような状況になったのだろう。

ここはひとまず、体調を整えるところからスタートしたい。 

 

■ 2020/12/16

PowerShellの使い方をいろいろ調べた。

そして、簡単なScriptを作成することはできるようになった。

今後の目標としては、より高度なScriptを作れるようになるように精進していきたい。

 

・ひさびさにRPGツクールを起動した。

色々とまた、作ってみよう。

 

■ 2020/12/17

 また、足がとても痛かった。仕事中はどうにか耐えたが、帰りに整体病院によって見た。リハビリとして腰を温めて伸ばす機械によるリハビリを行った。

 

■ 2020/12/18

 帰りにサーティーワンのアイスクリームを買って帰って家族で食べた。

 

■ 2020/12/19

参考になるゲームを買ってプレイしてみた。

ポケモンセンターにひさびさに言ってみた。外で食事をするのも久しぶりである。 

横浜にあるナンとカレーの店で食べた。

 

■ 2020/12/20

前日に買ったゲームをプレイ。参考にはなりそうである。掃除機をかけて、風呂掃除もした。

子供を抱っこやおんぶしてあげたら喜んでいた。またたべっこ動物のチョコレート味も気に入ってくれたようである。

 

 

 

 

子供への読み聞かせ作戦 2020/12/12

子供に読み聞かせを行った。

本に興味を持ってもらい、言葉に興味を持ってもらうことによって、発語につなげようという作戦である。

 

■ 今日の本

オツベルと象

反省点として、漢字が多くて少し難しかったかもしれない。

 

■ 感じたこと

やはり、すぐに本を破ろうとしてしまう。

ただ、本に興味をもって、自分のものにしようとする姿勢には可能性を感じた。

また、話しかけることによって、本に近づいてきてくれるので、親子の距離は縮まったように感じた。

 

明日からは本を変えて行ってみることも考えてみる。

例えば、「アンパンマン図鑑」とか。

 

■ やること

新しい本を買ってきて、読んであげる。

 

 

振り返りのやり方 KPT

振り返りはできれば毎日やったほうがいい。

継続できないのは、ハードルを高くしてしまっているから。

できるだけ、ハードルを上げすぎずに、毎日継続して行えるようにする。

 

■「 よかったこと」「わるかったこと」「行動計画」を定期的に振り返る。

 

■ 具体的には?一例

・よかったこと

解析が早く進んだ

 アタリを付けてから、解析するという工程を設けたことが、結果的に効率的に働いた

 過去の調査経験が生かされた

・悪かったこと

 会議の進み方が悪かった

・行動計画

 〇日目の時点で、会議がすんでいなければ、以下を行う。

 会議で着地点が明確でない議題はリジェクトすることを宣言しておく。

 

■ 振り返りで守ること

・ ちょっとしたことでもあげてみる

 

・ 行動計画は具体的なアクションに落とし込むこと

 「~~に気を付ける」などはアクションとは言えない。メモを取る、付箋を貼る、など具体的な行動でないといけない。

 

・ 継続の難易度を上げないこと

 すべてを完璧にやろうとすると継続が難しくなる。できることから少しずつ慶全していくことが望ましい。

 改善案がうまくいかなかったら、あとでやめることも自由である。

 

・ふりかえりの時間を決める

 一日の最後にやる、とかいう風に決めておく。

 最大で何分間でやるかも決めておく。

 

・できれば短いスパンで行えるようにするのが良い。

 5分でもよいから時間を作ること。

 

 

アジャイル開発について

 

■ どうしてアジャイル開発が必要なのか?

・スペックレビューで要件がFIXしないことが多いから

・開発期間中、最終フェーズにおいても要件の追加、変更などが発生するから。

・製品をリリースしても、変化した市場のニーズにマッチしていないから

 それにより、時間をかけて開発しても、ほとんどの機能がユーザーに利用されない事態となる。

・市場のニーズを確認する方法がない

⇒ これらを解決するために変化を許容し、容易に軌道修正できる仕組みが必要。

 

アジャイル開発(スクラム)とは?

複雑なプロダクトを開発、維持するためのフレームワーク

要件が不定、規模が壮大であるなど。

枠組みであり、実際のやり方はチームごとにカスタマイズが必要である。

 

アジャイルウォーターフォールの違いは?

やらなければいけないことは同じである。

★最終目標:モノを作ること

① 何を作るか?

② どう実現するか?

③ いつまでに出来るか?

④ 作る

⑤ 確認する

⑥ 完成

ウォーターフォールの場合

① 要件定義

② 設計

③ 見積と計画

④ 開発

⑤ テスト

アジャイルの進め方

インセプションデッキ

② ストーリー収集

③ スプリント0

④ スプリント

⑤ リリーススプリント

■ やり方の違い

★WFでは、目標を最初に決めて1直線にすすむ。

したがって、準備、計画が最重要であった。一度進んだら後戻りできないので、開発に着手するまえにどう実現するかまできちんと決めておく必要があった。

したがって、目標が不明瞭な状態においてはうまくいかない方法であるとも言える。

アジャイルでは近くに的を設置して、確実にあて、その都度方向を確認する。そして、確認しながら最終的なゴールに向かって進めていく。

つまり、作るたびに「何が必要か?」「どう実現するか?」といったことを確認するフェーズを設けて作成していくのである。

逆を返せば、「無駄なものを作らない」ことと「無駄なことはしない」ということが重要である。

 

アジャイルマニュフェスト(ケントベック、マーティンファウラー、ケンシュウェイバーらによって採択された)

・プロセスやツールより人と人同士の相互作用を重視する

・包括的なドキュメントより動作するソフトウェアを重視する

・契約上の交渉よりも顧客との協調を重視する

・計画に従うことよりも変化に対応することを重視する

 

■ 登場人物

★ プロダクトオーナー

 製品に対して責任を持ち機能に優先順位をつける人

スクラムマスター

 スクラムプロセスがうまくいくように外部からチームを守る人

★ チーム

 プロダクトの開発を行う。製品の成功に向けて最大限の努力をコミットする。

ステークホルダー

 製品の利用者、出資者、管理職などの利害関係者。

 

 

■ イベント

★ プロダクトバックログ

 製品の機能をストーリー形式で記載する。プロダクトオーナーが優先順位をつけ、プランニングポーカーで相対見積もり、項目の追加はいつでも自由だが、プロダクトオーナーが優先順位を決める。

★ Doneの定義

 何をもって「完了」とするかを定義したリスト

★ スプリントの計画会議

 プロダクトバックログを再度分析・評価し、ログアイテムを選択する。たま選択した項目をタスクにばらす。

★ タスク

 時間で見積もられたタスク

★ スプリントバックログ

 そのスプリント期間中に行うタスクのリスト

★ スプリントレビュー

 スプリント中の成果である動作するソフトウェアをデモする

★ デイリースクラム

 毎日チームメンバーが以下の3つの質問に答える

・昨日やったこと

・今日やること

・困っていること

★ バーンダウンチャート

 スプリントタスクの推定残り時間を更新してグラフにプロットする

★ スプリント

 各スプリントの期間は固定でありスプリント実施中は外部からの変更要求を拒否する

★ ふりかえり

 スプリントの中での改善事項を話し合い次に繋げる

 

 

【日記】Gitとかバージョン管理とか 身体のリラックスとか

 

 

今まではテーマごとに記事を書いていたが、今後は日記形式に戻そうと思う。

その日に起きたことを書いて、あとで振り返るためである。

 

■ GitLab

GitLabの使い方、まだ完全に理解しきれていないところがある。

マージリクエストとかイシューとか。

慣れていかないといけない。

 

■ TortoiseGitとの兼ね合い

TortoiseGitからGitにコミットしてから、GitLabに反映されるまで多少時間がかかるみたい。コミットが反映されていないから焦った。

また、ブランチをGitLab上で切ったが、それとは違うところにコミットされている(かのように見える)現象も起きてしまった。

あとから、マージリクエストを出すときにくっつけるブランチをチェンジしたが、マージリクエストとイシューやコミットとの関連付けがうまくいっていなかったようだ。

 

 ■ 体をリラックスさせる方法について

続けている。

身体に無用な力が入ってしまっているので、それを取り除くように、息を吐きながら体の力をゆっくりと抜いていく、というのをやってみている。

 

それと、「やってやる!」というような強気の気持ちを引き出す方法について模索している。