エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
redmineを使ったチケット管理の失敗のさせ方 - 文系プログラマによるTIPSブログ
Redmineを使ったチケット管理をしている方必見！ジワジワとredmineを壊して失敗させていく方法を公開しちゃいます。 チケット管理のアンチパターンとベストプラクティス - Javaプログラマのはしくれダイアリー こちらの記事の便乗ですが、私の今までのチケット管理経験から「こうすると失敗するよ」という実例を挙げてみようと思います。私はほぼredmineしか触っていないので、今回はredmineでのお話となります。 ※ 冒頭の記事と被る内容も多々有りますが、気にせず列挙していきます。 ※ 主にSI業界に関するチケット管理のお話です。 ※ 大規模プロジェクトは想定していません。多くても20人以内程度を想定した記事です。 これであなたも無事、失敗できる！ 進捗率をユーザの裁量で更新させる 対象バージョン「なるはや」 チケットの内容が途中から変わる 増殖するプロジェクト固有のトラッカー 「本日
プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
同じ開発チームの「批評家」とどう接すべきか悩んでいる
同じ開発プロジェクトのメンバーに、頭でっかちで、口は達者だが、まったく手を動かそうとしない、いわゆる「批評家」な人が居る。その人とどう接したら良いのかわからず、悩んでいる。（以下、「先生」と呼ぶ） 先生はあまり技術スキルが高く無かった。先生が担当する部分のシステム仕様や、そのシステムに関連するスキルの習得状況が芳しくないことと、そもそも基本的なプログラミングスキルも、低いとは言わないが、安心してまかせられるレベルではない、ということが分かってきたため、最終的には、スキルが求められる部分については、分割して他の人が分担して持つことになった。 先生はそれなりに時間ができ、スキルアップのために技術書を読み始めたようだった。それはとても良いことなのだが、どちらかというと、はじめての◯◯、とか、猫でもわかる◯◯、等を読むべき技術スキルだったにも関わらず、読み始めたのがデザインパターンやリファクタリン
ゲームサウンドの容量を減らすには 〜ステレオ／モノラル編〜 - スタジオ・サニーサイド
ラジオ体操で全身筋肉痛。こんにちは。banです。 えーちょっと今回から方針を変えまして、 サウンドが専門外のゲームクリエイターに、ゲームサウンドの取り回しのアレコレを知ってもらう、 というようなテーマで色々書いてみたいと思います。 ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ゲームの音屋の仕事に常時ついて回るのが「容量」「データサイズ」という問題ですね。 今はゲームの容量も肥大化して、昔のゲームでは必須だった爪に火を灯すがごとき容量倹約はせずとも良くなりましたが、 ダウンロード配信という新たな事情も発生してますので、すいません！容量減らして！という要望は時々あったりします。 最近も、とあるプロジェクトでクライアント様から 「サウンド容量をどうにか減らしたいんですが、どうすればいいですか？」 という相談を受けたことがあったのですが、 サウンドファイルの基本的な知識があれば、 音屋でなくとも容
[悪徳商法？支店]: エンジニアのモチベーションを根こそぎ奪う！たった７つの魔法の言葉
１．テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 ２．とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ
糞ゲーはだいたいこういう流れでプロジェクトが進む。
とりあえずプロデューサが作りたいゲームを語る。酒の席だったりする。 それを何となくプランナに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「ポケモンを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のゲーム」を作る事になるとバグとか糞とか以前に完成しない。 そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。 決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の
誰も幸せにならない「クリエイターかるた」が話題に - ゴールデンタイムズ
など、リアルすぎて見ているこっちが苦しくなってくるものも。 読んだ人からは 「おいやめろ、心が痛い」「胃がギュッてなる」 といったコメントも寄せられていた。 こうして今日も、クリエイターたちの尊い自己犠牲によって 社会はつつがなく回っているのであった……。 http://nlab.itmedia.co.jp/nl/articles/1205/15/news102.html 秀逸な札 抜粋 デザイナー あ アウトラインで来た文字原稿 え 絵は描けません。 か カッコいいのつくってくださいとりあえず こ コンペなのに校正がある さ 寂しいから余白埋めてください せ SECOM解除しなきゃ… そ 素材ファイルがjpg な なるほどですねが口癖 ひ 開くと落ちるファイル み 「皆これくらいできるよ？」 ろ ロゴ画像.ppt 映像制作者 あ 明日っていうのは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
