management-for-game-development.connpass.com
場所は、株式会社アカツキが入っているビルです。
今回は懇親会出なかったので、発表していた内容のうち、印象に残った物だけピックアップします。
▼登壇者(名前間違えているかもしれません、すみません)
〇株式会社アカツキ 湯前慶太さん
・元エンジニアリーダー
・COOからの依頼で、プロジェクトマネージャに任命されたらしい
・エンジニア12名のチームと言っていたので、それなりにちゃんとしたスマフォアプリ一本作るレベルの規模のプロジェクト管理を任されたと想像
・話を聞いている限り、行っていたのは「観察」「問題認識」「問題解決法考察」「実践」
・スクラムは、出てきた問題を解決する為の「手段」として、取り入れたのかなという印象
・ただ、何故スクラムにしようと思ったのかは、話の内容からは汲み取れなかった
・どこにでも有る問題として挙がっていたもの
・会議の進め方(効率が悪く感じたそう)
・朝会の質の悪さ(やる事やった事を言うだけなら、要らない)
・作業フローの不明瞭さ(どこかのセクションに情報の伝達漏れが発生するフロー)
・開発陣が問題をエスカレーションしてくれない
・作業の属人化
・チーム内意識がバラバラ
受託なのか内製なのかわからないけど、受託であって、取引先を巻き込んでこの辺りの問題解決ができたのであれば、その交渉力と説得力は凄い事だと思った。
ただ、たまにいなくなってみるのも面白い発言を聞いている限り、恐らく内製プロダクトなんだろうなと想像。
〇株式会社ヒストリア 佐々木瞬さん
・代表取締役
・こっちは、スクラムというプロジェクトマネジメントの歴史や考え方の基礎的なお話がメイン
・スクラムはIT業界から輸入された物らしい
・プロジェクトマネジメントを語る上では
・SCRUM及びアジャイル的ソフトウェア開発等、プロジェクトの進め方を定めた物
・アジャイル系の知識をベースとしたソフトウェア群
・自動ビルド自動テスト(Jenkins)
・BTS(バグトラッキングシステムの事だと思う)(RedMine、JIRA)
・ソースコード管理(SVN、GIT、Perforce)
という物がある事を知っとくとよさげ
・プロジェクトマネジメントの定義は、プロジェクトを成功させるために行われる活動と言っていた
⇒成功とは、品質コスト納期において、プロジェクトの目標を満たす事
⇒納期通りになるようにスケジュールを管理する事ではないとの事。
⇒ここの考え方が、ディベロッパーとパブリッシャーで認識がずれていて、うまく行かないプロジェクトをずっと見てきた気がする。
⇒つまり、何が目標で達成すべきことなのか。この辺は深く考察するにあたりする。別記事で考える(もう眠い)
・主な開発手法
・ウォーターフォール開発
⇒今だと、全てこれだと厳しいだろうと言われているらしい
⇒これだと、本来は仕様書を一度FIXしたら、もう変えない
⇒根柢の仕様が変わると、手戻りコストが半端なく高い
⇒要件がはっきりしていてブレが無い物に関しては、こっちの方がいい
・アジャイル系開発
⇒計画ー実践ーQA-レビュー
・某会社は、プロトタイプはアジャイル、量産本番はウォーターフォールの方がいいと言っていたところもあった
・2001年 アジャイルソフトウェア開発宣言
⇒ググると出てくる
⇒今では、SCRUMは一定そうに定着したと思っているらしい
⇒とてもそうとは思えないが…。
▼株式会社ドリコム Smithさん
・ゲーム基盤技術部
・ドリコム内部の話をしてもらった
・1から組織を作ろうと思うと、様々な社内政治や予算制約を受けるから、色々工夫しないといけないよ、という理解をした
・やりたい事=それがどの程度ビジネス上の価値があるのか定量化出来る事⇒経営陣レイヤーへの説得材料(予算獲得の為と理解)というのがあるので、軽々しく新しい事をやろうとすると、コストが馬鹿でかいみたいに大きくなるという話をしていた記憶
▼感想
プロジェクトマネジメントにおいて、スクラムは手段の一つであり、プロジェクトマネジメントを円滑に行うのに大事なのは、手段その物よりも
「観察」「問題認識」「問題解決法考察」「実践」
この辺りを常に意識して、最善を常に考えて実践に移す事だと改めて思った。
いわゆるPDCAサイクルとか言われてる物かな。
恐らく、今のプロジェクトでうまく行った方法は、次のプロジェクトではそのままではうまく行かなくなるんだろうなとも思う。参考にはなると思うが。
ただ、問題認識をした後の問題解決法を考察する段階になると、各種知識や経験が生きてくるはずなので、
その辺りはちゃんと勉強していった方がいいんだろうなとも思う。
後は、ディベロッパー-パブリッシャー間の関係があると、力の関係次第で何をどうやってもコントロールしようがない状況が出てくると思う。
そのような状況では、スクラムとかウォーターフォールとか手段の問題以前に、もっと根本的な何か対策を取らないといけないのではないかと思う。
つまり、なんていうか、手段を考える前にプロジェクトマネジメントとは何なのか、というもっと基本的なところから考える必要があると感じる。
この辺をちゃんと考えて実践できる人が、プロジェクトマネジメントをしないと、何をやっても無駄だと思うし、それが仕事と認識してない、出来ない人を任命してはいけないだろうなと思った。