開発チーム

ウィキペディア小見出し辞書

開発チーム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/06/17 08:46 UTC 版)

「OMORI」の記事における「開発チーム」の解説

OMOCATにはゲーム制作の経験がなく、また当初は一年限りの小さなプロジェクトになる予定だったが、時が経つにつれ規模が大きくなり、完成には多くの人の助けが必要となった。クリエイティブ・ディレクターとシナリオとイラストはOMOCATが、開発はゲームデベロッパーのARCHEIAが担当。2014年時点で開発チームはこの2人のみだったが、2人ではゲームで実現したいことが実現できないことが分かり、開発と並行しつつ開発チームの増員も行っていた。2019年時点ではアメリカ人、メキシコ人、イタリア人による8人がメイン開発チームとして制作が進められた。会話シーンの組み立てやクエストの構造など技術的なことはOCEANが、バトルシステムと戦闘バランスに加えお笑い担当はSLEEPYKUYAが、イラストやアニメーションはMINCEDが、マップのタイルセットやドットアニメなどはEMSが担当している。作業は多くのメンバーが開始当初からリモートで行った。

開発チーム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2016/06/04 08:01 UTC 版)

「GNU Classpath」の記事における「開発チーム」の解説

プロジェクトチームには70名の開発者がおり（うち、約20名が常時活動している）、管理者が1名活動している。管理者は法律面の対応をし、定期的なリリースの実行と品質管理にも関与する。管理者はCVSへのアクセス許可も行う。 他のプロジェクトとは異なり、GNU Classpathには正式な階層構造がない。技術的に可能な者が可能なことをしており、明確な分担は存在しない。コード修正はまずディスカッションリストにパッチとして投稿され、問題があればそこで議論される。毎日、5件から8件のパッチ投稿がある。 プロジェクトは独自のテストスイート (Mauve) を使っている。175,000項目のテストが毎日実行され、公式のAPIと互換が保たれていることが確認されている。

開発チーム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/01/21 22:50 UTC 版)

「Apache Harmony」の記事における「開発チーム」の解説

立ち上がるとすぐに、プロジェクトは既に開発に着手していたいくつかの会社から大きなコード寄贈を受けて動き出した。しかしながらメーリングリスト上での全般的な議論は常に開かれていた。 その後、プロジェクトにはASF管理者によりアパッチ流の開発方式を取り入れたことにより、大きく成功したといえるだろう。2006年11月時点で、プロジェクトチームのコミッターは16人の開発者及び、IBMとインテルに属する16の開発チームで構成されていた。

開発チーム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/08/06 21:18 UTC 版)

「ファミスタシリーズ」の記事における「開発チーム」の解説

初代をはじめ、ファミコン版では多くの作品で「PICCARI」「ぴつかり」「ピッカリ」の入った開発チーム名をクレジットしていた。初代・'93は「PICCARI PRO」。'87は「PICCARI GAMES」。'88-89は「やぐち ぴつかりいず」'92は「PICCARI TEAM」と明記されていた。ファミコン版以外では、PCE版1作目は「ピッカリドームのグランドキーパーズ」、PCE版'91やスーパーファミスタは先述の「PICCARI PRO」をそれぞれクレジットしていた。チーム名とともに、電球を描いたシンボルマークなどを表示する場合もあった。「PICCARI」を冠したチーム名以外では、『スーパーファミスタ3』のエンディングで「パースタ3チーム」の名義をクレジットした。 また、「PICCARI」を冠した開発チーム名はファミスタ以外の作品にもクレジットされる場合があり、『スター・ウォーズ』ではエンディングに「PICCARI GAMES」、『ファミリーテニス』ではエンディングに「PICCARI CLUB」、『プロテニス ワールドコート』ではエンディングに「ぴっかりプロ」のチーム名がそれぞれクレジットされた。

開発チーム

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/08/07 05:19 UTC 版)

「アジャイルソフトウェア開発」の記事における「開発チーム」の解説

アジャイルは価値提供に関して経験を通じた学び・適応を重視する。それは人間/開発チームにも同様のことが言える。もし開発チーム全体が問題仮説の実証に携わり続けていればチームには経験が蓄積し、適応時により良い問題仮説をチーム全体から提唱できる。逆に開発チームが指示された解決策の実装にのみ従事していると問題仮説に関する経験は蓄積しない。また他者への価値提供を担う権限と責任を持つチームは高い意欲を持つことができる。指示された解決策の実装のみを担っても意欲は高まらない。 提供する価値の最大化がアジャイルの目的である。その価値を提供するソフトウェアは人間の手によって開発される。ゆえにアジャイルソフトウェア開発は開発プロセスより開発する人間/チームを重視する。価値を最大化できるチームは自己組織的なチームである。すなわち価値提供を担うことで高い意欲を持ち、問題設定・解決策提案・実装・適応をチーム自ら繰り返し経験を積み能力があり、それらをチームの権限と責任でおこなえるチームである。アジャイルソフトウェア開発ではチームの能力を信頼しチームの自己組織化に必要な環境・権限・責任をチームに付与することで提供価値を最大化する。 チームの構成は自由であるが、典型的にはエンジニア・デザイナー・プロダクトマネージャー・マーケター、他にもテスト担当者・テクニカルライタ・管理職などが見られる。