  |
はてなキーワード: 仕様変更とは
【波紋】twitterがサイトの仕様変更をしたものの…ガラケーユーザー困惑 - Togetterまとめ
何でこいつらスマホ使わないの？
いまどきガラケー使ってるのって、安さ優先で通話とメールだけに絞ります、って人だけでしょ？
TwitterみたいなWebサービスは利用しないことが前提じゃないの？
ガラケーってそもそもWebを閲覧できるようには作られてないでしょ？
これまで閲覧できていたのは単なる温情にすぎないわけだよね？
時代に取り残された連中をあわれんだTwitter社の慈悲だよね？
これまでさんざん恵んでもらっていた豚が、ちょっと餌をもらえなかったくらいで喚くんじゃねえよ、って感じだよね？
「ぼくちんは賢い消費者だからガラケーで十分」って、それで十分なのは必死でガラケー対応している人たちがいるからでしょ？
職場で一人だけPC使わず仕事して「周りが合わせてくれるから手書きで十分なんだ」とか言ってる人がいたらぶん殴るでしょ？
まず340時間がピンと来ない人に言うと、8時間勤務で20日働いたとしたら160時間ね。
つまり定時で帰ってる人の倍以上働いてると思ってもらっていい。
ただ、うちの会社が恐ろしいのは、その状態で平気で次のプロジェクトにいれようとしてること。
ちなみにまだ今のプロジェクトは終わってなくてGWも返上してるんだけど、おそらく奴ら（自称ディレクター）は平行でやらせようとしてる。
奴ら（自称ディレクター）は当然のように早く帰って、要件管理もスケジュール管理もせずにる。
奴ら（自称ディレクター）がやってることは工数聞いてスケジュール表を埋めるだけ。
仕様変更があっても、スケジュール調整もせず、テストもせず、というかそもそも仕様を全く把握していない。
最初は経験が浅いから仕方ないのかなと思っていたけど、いつまで経っても変わらず。
いつもは多少は目をつぶってやるけど、さすがに無理だからスケジュールなんとかしろよと詰めても
人がいないからなんとかしてよ、とかヘラヘラしながら、お先に失礼しますーとか言って帰る。
外注出すなり、派遣入れるなり、手はいくらでもあるだろって言っても手配するのがめんどくさいのか何もやらず。
よくあるweb系受託会社なんだけど、いいかげん転職を視野にいれてもいいのかな。
プログラマの人たちは意識高くていい職場だと思うけどこのままだと、体がつぶれる気がする。
他の会社も同じようなもんなんですかね。
https://twitter.com/tsuki_akari/status/585859760399880192
これ、別にこの人がこう思うのはこの人の自由だし、水島努を非難するつもりはまったくない。繰り返すからな。この人と水島監督に悪意はありません。
でもさ、これって「「 感動 」を食べるだけで生きていける」と何が違うの？一緒じゃん。こんな動機がないとやってけないような業界がクソなんだろ。
宮森と仕事したいとか言ってる社会人もたくさんいるけどさ、あんなスケジュール管理で現場に押しつけるようなクソ上司のどこがいいの？
お前らSEは仕様変更がどうのこうの日々騒いでるじゃん？あれなに？ミサワなの？「仕様変更まじつれーっす」ってミサワだったの？木下誠一と宮森あおいのせいで撮影がどんだけ苦労してると思ってんの？
会議なんか潰せ、会議するのは作らない人間とかいう小島秀夫の発言嬉々としてRTしてたけどさ、メールで済むような内容メールで済ませろつった平岡叩きまくってたのは何なの？
rep2という 2ch.net ブラウザがある。一種のクラウドリーダーであり、WWWブラウザの機能を持つ様々な機器からインターネットを介して利用する。個人的な読み書き情報を一箇所に集めることが出来るのが強みだ。2ch.net以外にも、2ch系の掲示板、したらばなどを並行して利用することが出来る。利用するためには、サーバ運用に関する若干の知識が必要になることから、一部の物好きに愛用されてきた。
しかしこれが、おそらく明日から 2ch.net に対して使えなくなる。理由は 2ch.net の仕様変更だ。
2ch.net の利用環境や運用環境は、匿名である代わり、大規模なオープン性をもって育ってきた。しかしそれがクローズドな方向に移行しつつある。
私に対策を考えることは、能力的に出来ないのだが、rep2を細々と使ってきた身として、くだらない書き込みを延々と受け止めてくれた 2ch.net と rep2 に謝意を述べたくなった。
ありがとうございます。お世話になりました。
アノニマスの坊や達、こんばんは
僕だよ。
前回の記事
ハッカーになりたい君たちの要望に応えるべく再び黄泉の国から舞い戻ってきたよ。
ハッカー…素晴らしい響きだ。
皆それになりたいと思う。
ハッカーになりたいという若い子は恐らくクラッカーみたいなのになりたがっているだろう。
中高生くらいならばなりたいと思っても、どうなるのか誰も教えてくれない。
親切な人たちが教えてくれるYahoo知恵袋などで『ハッカーになりたいです』とか書くとどうだ？
「貴方のいっているのはクラッカーですね？ハッカーとは別物ですよ」
清く正しい中学生がなんだか気を利かせて、「ホワイトハッカーになりたいです」とか「ハッカーになりたいです違法行為はしません」
などなど、変に気を使っている。
そうだ！なろう！！裏の世界の人間になろう！！そして世界を変えるんだ！！
ハッカーと言っても色々居るわけだ。
撮り鉄とか葬式鉄とか、ウィルスをばらまくハッカーとか、脆弱性を見つけて小銭稼ぐハッカーとか、OS作るハッカーとか、セキュリティポリシー精読して炎上させるハッカーとかね。
ウィルスというのは細胞を持たないが遺伝子をもつ最小の生物なのだが、細胞を持たないため非生物とも言われている構造体だ。非生物らしく結晶化もできる。
宿主となる細胞に増殖をしていく。
そのウィルスがコンピュータ世界に入り込み進化したものがコンピュータウィルスと言われていて、生命の謎を握る存在なのだ。
こう言われてもピンとこないだろうから、君たちにわかりやすいモノで表現するとすると
つまり『電光超人グリッドマン』に出てくる怪獣のようなものだと思ってくれればいい。
ブラック、そう闇と言われるハッカーたちは自分や自分の所属する集団のために違法行為を厭わない連中だ。
プログラマはスキルによってその仕事のスピードは20倍にも40倍にも開きが出ると言われている。
その特A級のハッカーはウィザードと言われるが、そのとおり魔導士のような不思議な力を使う。
しかし謎の力の仕様変更により納期は変わらず工数が9人月になった。
にもかかわらずだ納期は間に合い、しかも！稼働時間も3人月分しか計上されていない。
これは何処かのタイミングで時を止めていると言われている。
たまに勤務管理システム上は有休になっているが、入館ログには出勤の形跡があることがある。
これは休みと仕事の状態が重なり合っている量子力学的な状態を不思議な力で作り出しているのだ。
量子コンピュータは0の状態と1の状態が一つのビットで同時に表現できると言われているが、ブラックハッカーはすでに人間の身でありながら実現しているのだ。
事実量子コンピュータはブラックハッカーの脳を再現する形で実現しようとしている。
量子コンピュータを作っている企業の下請けに大量のブラックハッカーが居るのもそういうわけだ。
ウィルスをばらまくハッカーもいると言ったがブラックハッカーもその能力を持っている。
例えばインフルエンザやエボラ出血熱などを持って出勤するのも彼ら得意技の一つだ。
また、違法行為も厭わない。
どんな違法行為をやっているかは良い子の皆が真似をしてしまっては困るのでとてもここでは言えないがね…
ブラックハッカーたちは暗黒の存在とは言え我々の社会には無くてはならないものになってしまっている。
闇が深い金融業界や、日本国政府もこのブラックハッカーに頼らざるえなくなっているのだ。
おそらくマイナンバーではブラックハッカーのそうそうたる面々が集うことになるだろう。
どうだろう。
なる方法は簡単だ。
「神はXをつかうのか？」という質問について答えようと思う。
良い質問だ。
でも、いつだったか1000年位前の公会議で神はXを使うという事になったんだよ。
裏の人間は黒い画面を好み、黒い画面でいろいろやろうと思っていた。
だが、次第に艦これもやりたくなってきた。
そのうち艦これやりたさに信仰を捨てWindowsに走るものや、過激派組織APPLEに見を投じる者も出てきた。
しかし信仰心の篤い者達は我慢したBashでなんとかやろうと我慢した。
VimでTwitterをやったり、Wgetでテキストサイトを見たりしていた。
だが、XVIDEOSの誘惑には勝てなかったのだ。
その当時のハッカーたちはLinuxでもXVIDEOSを見るシステムを開発しようとした。
それが『XVIDEOS Window System』つまりXだ。
Xは黒い画面とXVIDEOSの間から妥協として生まれたが、そのうちそれでも良いかという空気になりXは流行った。
なんとDMMに登録するとAVの動画も見れるサービスがあることをしることになった。
Linuxでは艦これは出来てもDMMの動画を見ることは出来ない。
悪しきWMVで公開されてDRMがかかっているし、ストリーミングも何故か映らないのだ！！
XVIDEOSの細切れで続きが何処にあるかわからないAVよりも、有料だけども安心して見れるDMMのほうが良いというものが増え
そうやってLinuxは信者数を減らしてしまい今では生きる場所は裏社会のみになってしまったのさ。
そういう経緯があるので、神はXを使っていることになっている。
http://anond.hatelabo.jp/20150211201344
「編集者」とひと口に言ってもいろいろなタイプがいて、雑誌社で記者をやっている人が編集者を名乗っていることもあるし、雑誌編集部で編集長やデスクの使い走りしかやってない人や、編集プロダクション所属で実質はDTPオペレータという人もいる。書籍の編集者でも、作家様が執筆するような文芸書担当と実用書担当ではずいぶん仕事内容が違うし、漫画や写真集、辞書みたいな特殊ジャンルもある。さらに会社や個人によって仕事のやり方が違ったりするので、「編集者の仕事」を一概に定義するのは難しい。
ただ、あえて定義すれば「本や雑誌を作ること」で、ある程度抽象化した形でなら大まかな流れは紹介できるんじゃないかと思ったのでまとめてみた。以下は原則として版元所属の実用書系の書籍編集者の仕事を想定。文芸や漫画の世界はよう知らん。
企画は「思い付きを口走ること」でも「まだ世の中に存在しない何か」を探すことでもありません。満たされていない需要を探し出して、それを満たす商品の製作を計画することです。そのために常日頃から情報を集めつつ、有望なアイディアを見つけたら市場調査、著者候補をはじめとした関係者へのコンタクト、概要記述、目次案作成、仮タイトル考案、収支シミュレーション作成、プロモーションの概要計画作成などを行ないます。版元所属の書籍編集者にとっては、企画が一番重要な仕事です。
版元所属の書籍編集者なら、定期的に開催される「企画会議」で企画をプレゼンして経営陣や営業部門を説得して企画を進める了承を得ます。企画会議にかける前に編集部内で行なう編集会議にかけ、編集長の了承を得る必要があることもあります（書籍編集者は独立性が高いので不要のこともある）。企画を企画会議より先に進めるには、企画した編集者の過去の実績や根回しも結構重要だったりします。
本来は著者の仕事です。「てにをは」はもちろん、取材や権利処理も含めて原稿完成の全責任を負うのは著者です。本来は。しかし、実用書系の著者に商品にできるレベルの文章を書ける人はほぼいません。原稿は少なくとも再構成、場合によっては全面的にリライトしなければならないことがほとんどです。これを自身で行なうか、外部のライターなどに発注するかは編集者によります。刊行点数のノルマに余裕があり、著者が書けなければ企画をボツにするという編集者もいます。また、長年ブログを書いているなどと言って妙な自信を持っていてリライトなどに対して「一字一句変えるな！」などと言い出す著者もたまにいますが、こういう著者を説得（というか説教）するのも編集者の仕事です。言うまでもありませんが、たかだか2,000文字のブログ記事と、200ページ超の書籍のための文章はまったくの別物です。
原稿がある程度そろったら、紙面の形に組版します。版元所属の書籍編集者の場合は、ほとんどの場合外部の編集プロダクションへ発注します（単純な縦組みの文芸書などでは印刷所に依頼することもあるようです）。これらに関する価格交渉なども、編集者の重要な仕事のひとつです。
校正紙（組版された紙面）を目視で確認する作業です。校正紙を著者に送り、内容を確認してもらう「著者校正」もここで行ないます。修正の量にもよりますが、2～3回繰り返すのが一般的です。
装丁（カバーデザインなど）についても、外部のデザイナーに発注するのが一般的です。とはいえ丸投げで済むわけではなく、書籍の内容や競合の状況によってデザインの方向性を考え、それにそったデザインのできるデザイナーを探し、デザイナーに方向性を伝えるための資料を集め、文字原稿についてはすべて編集者側で用意した上で、デザイナーと複数回のやり取りをします。
組版や装丁の目処が立ち、ページ数も大体決まったあたりで印刷所に見積もりを依頼します。見積もりの額によっては、デザイナーに装丁の仕様変更を依頼することもあります。特色、UV、箔押し、型押しの使用は慎重に。必要な場合はここで印刷所に束見本（つかみほん）の作成を依頼することもあります。
ページ数が決まり、カバーデザインもほぼ完成したら、いわゆる「部決会議」（部数決定会議）にて部数、価格、発売日などが決定されます。営業部門などからの要望によって、タイトルやカバーデザインの変更を要請されることもあります。過去の実績や知名度によっては著者や編集者の無理が通ることもありえますが、これらの最終決定権は原則として資金的なリスクを負う経営者にあります。意見が通らなかった場合には、過去の不甲斐ない自分を恨みましょう。
部数や価格が決定したら、印刷所へのデータ入稿作業を行ないます。売上スリップやバーコードのデータを作成するのもこのタイミングです。印刷所からはプルーフや色校正が出てくるので確認します。ここでの確認漏れはそのまま印刷事故につながるので、売上スリップやバーコード、奥付などの最終確認は複数部署による回覧で行ないます。
入稿作業が終わると見本が出てくるのまで間に少し時間ができるので、著者との契約作業を進めておきます。契約書は出版社ごとに統一されているのが一般的で、タイトルや著者名、部数、価格などを書き込んで著者に送り、記名捺印したものを返送してもらいます。刷り印税がある場合には、支払伝票の起票などもこの段階で行ないます。編集プロダクションやデザイナーへの支払い手続きもこのタイミングで。
入稿作業後しばらくすると見本が届くので、まずは修正原本となる数冊を除いてから、著者をはじめとした関係者に数冊ずつ発送します。社内外へ見本を持参しつつ、挨拶をして回ることもあります。続いて雑誌社や有名ブロガーなどへの献本を行ない、書評を依頼したりもします。書籍編集者の通常の業務としては、これでひと段落ついたことになります。
書籍編集者が行なう通常の販促活動としては、いわゆる献本のほかにも、書店に配布する注文書の原稿作成などがあります。しかし、書店営業や広告に関しては原則として営業部門が主体となって行なうことになっていて、編集部側が勝手に進めることはできないのが一般的です。結果として書籍編集者が行なう販促活動は、営業部門のサポートや、著者によるイベントのサポートなどが中心となります。
実は世の中には間違いのない書籍というのはほとんどなく、それほど厚くない書籍の中にも複数の間違いが含まれていたりします。これを自分で見つけたり、著者や読者から報告を受けたときに記録しておき、増刷といったタイミングで修正するのも書籍編集者の仕事です。増刷時には、著者への報告や見本の発送、刷り印税なら支払伝票の起票といった作業もあります。さらに、刊行から時間が経ち、内容の更新をする必要がありそうな場合には、増刷の代わりに改訂版の刊行を企画することもあります。
以上です。改めて書き出してみると思っていた以上にやることが多かったと感じたのですがいかがでしょうか？また、原稿制作は重要であっても一部でしかなく、原稿さえあれば書籍が出るというわけではないということもおわかりいただけたかと思います。一般的な実用書の編集者は、この流れを同時並行して年間5～10点程度進めることになります。編集者が何の仕事をする人かという疑問解決の参考になれば幸いです。
PGは、まず見積もりを依頼されます。この時ほとんどの場合、要求仕様書が無いか、あっても伝聞で情報が欠落もしくはエラーを起こしています。残念ながらエラー訂正機構は装備されていません。CRC、せめてパリティでも入っていればちょっとは違うかもしれません。期待出来ませんが。
ここでプロジェクトマネージャー（又は管理者・経営者等。以後PMと称する）から「最速でやった場合」「割り込みが入らない場合」「君がやった場合」or「部署内で最高ランクのPGがやった場合」「仕様変更が無い場合」という条件が付きます。
底辺PG諸君。ここでこの言葉を額面通りに受け取ってはいけません。
「【最速で】3ヶ月かかります」
と答えたらPMは【普通に】3ヶ月の工程を工程表に書き、見積書に3人月分の金額を書きます。そしてこれは後述する危険と隣り合わせとなります。
この危険を経験したPGは大抵リスクを込みで【黙って】見積もりを伝えます。
しかしPMはお見通しです。「高い」「そんなに時間がかかるわけが無い」と言い、受け付けません。何故なら実はPMの頭の中では既に「3ヶ月」なのです。PMは追い込むために見積もりの詳細を聞いてきます。
ここで素直に「リスク込み」と答えてはいけません。既にPMは前述の前提条件を述べているからです。無下に却下されます。
戦いたいPGかつPMが同じ会社であれば「後学のためにPMの詳細見積もりをお聞かせ下さい」と聞いてみるのも良いでしょう。ただし確実に印象悪化は避けられません。PMが発注元の場合は禁句です。まずキレます。そのまま発注されない事もあるでしょう。発注されなかった事を喜びましょう。
なぜキレるか。それは簡単です。「明確で論理的な理由が無いから」です。理由が無い上に実は既に予算が決まっており、それを超える事は許されません。予算を超えた見積もりはPMがさらに上層部・経営陣から怒られる事を意味するからです。理由が無いから理由をPGに考えさせているのです。PMが仕事をした気にさせるのも底辺PGの役目です。
予算を超えた見積もりはあり得ませんので、答えは「がんばります」しか残りません。しかしPMはそれすらもPGの口から言わせたいのです。でもよく考えて下さい。あなたの脳はオーバークロック出来ますか？
底辺PGが出来る事は、PMやユーザーが分からないように期間と予算を加算するくらいです。
一応、市場原理が働くため、安い方がいいに決まっています。金払いのいいユーザーや元請けってのはあんまり無いです。そして金払いの悪い所ほど後々してやられますので、最初の予算の付け方でどういう所かが大体予測出来ます。
そんなわけで、予算と期間に品質と内容は関わりがありません。もちろん企業の使命として、安くて良い品を、安くても利益を、は追求してしかるべきなのですが、日本の場合質と金額が比例するのは極一部。IT業では基本的に、安くて良い品を出来るだけ高速に、がモットーです。受注しなければ会社がやっていけないのは分かりますが、「安さ」だけしか売り物に出来ない会社は、IT会社として失格でしょう。
かくして、短納期低予算のプロジェクトが組まれるわけです。そのPMの理論からすると、高速バスで東京から新大阪へ行く方が、新幹線のぞみの指定席グリーン車で行くより高く、書留速達の郵便より普通郵便の方が値段が高い、という事になりますが。質、時間、価格の何がIT業と違うんでしょうか。
実のところ発注や作業開始は遅れている事が多く、納期に間に合わせるには発注前に作業を開始せざるを得ない場合が8割ほどです。実はここにも罠が仕掛けられています。
作業に取りかかろうとようやく出てきた仕様書を見ると、見積もり時の時と変わっていたり、追加されていたり、未だに仕様が無い場合がほとんどです。
「こんなものをこんな期間で出来やしない！」と憤慨してはいけません。なぜなら
という答えが返ってくるだけです。PMが見積もらない理由がここです。PMに見積もりを聞いてはいけない理由がここです。これは後々まで効いてきますので注意が必要です。「前提条件と違う」と反論するのは無駄です。PMはそれは忘れています。そもそも考えて発言していないので口が勝手に脊髄反射で言った事であり脳は関知していないのかもしれません。PMにとって最重要な事は「PG自身が言った事」です。そう、工程表にも議事録にも「3ヶ月」という数字のみが記載され、いわゆる「リスク」は何処にも書かれて残っていません。
PMやユーザーは絶対にリスクや前提条件を書き残しません。それがこの業界の伝統ある慣習だからです。
ここで言った言わないの不毛な戦いをしてもいいのですが、確実に査定は最低です。もしプロジェクトから外されたらそれは喜びましょう。
管理者や経営陣等からは「やる前に出来ない言うな。やってから言え」と怒られます。残念ながらこれも真に受けてはいけません。
設計、構築など作業をしている間もどんどん仕様変更・追加は流れ込みます。
PMは工程進捗を把握しているのでは無く、PGが【自ら】工程表や報告書に纏めます。遅延していれば遅延の理由も書き、挽回策があればそれも書きます。しかしPG個人が取れる挽回策などたかがしれています。と言うよりそれが分かっていれば遅延などしません。他の策は既に実行済みなので、挽回策には「残業・休日出勤」くらいしか書く事が残りません。しかしこれは現実にこれしか書く必要がありません。なぜならPMはこれ以外の挽回策は理解不能だからです。
仮に報告をしても「早すぎる。もっとやってみてから」「がんばれ」という答えが返ってくる事でしょう。
遅れを放置するPMもいますが、許容範囲はPMにもよりますがある程度遅れが見えてくるとPMから追求がやってくるようになります。
「なぜこんなになるまで報告しなかった」
そう、報告出来る時期というのは非常に限られています。多分プロジェクト工程（今の例なら3ヶ月）の中の30分くらいです。それより早いと相手にされず、それよりも遅いと怒られます。報告時期を見誤らないのもPG業の技です。
実装が難しかったり、無理難題は多々あり、その上工程が遅延しているので、相談をしに行きます。しかし、それは無駄です。
「自分で考えろ」
「やってから言ってるんじゃねぇ。やる前に言え」
他似たような答えしか返ってきません。非常に非生産的です。理不尽です。時間の無駄と考え報告・相談に行かないPGも多いとか。非生産的ですが、一応相談はしておきましょう。ただし時間は取られないように。
同僚やチーム員に相談してもいいのですが、昨今のプロジェクトは人員がスタンドアロンで動いています。したがって、隣の人やチーム員がが何をやっているのか知らない事が非常に多く、相談出来ない事も多いのです。PGにメンタル病が多いのは実は理由がここにあると自分は思っています。孤立感が半端無いのです。まぁ、元を追えば、そいういうチームを組む事、教育訓練しない事など、実は管理者・経営者が「カイゼン」や「効率向上」を題目に目の前の超短期的コスト削減だけを考えている結果なので、PGとしては何も出来る事はありません。管理者・経営者は中長期について考える必要が無いからです。なぜなら「その頃には自分は満額の退職金を貰って定年退職済み」だから。
実のところ単独の仕事をしていればいい、と言う事はあり得ません。同じプロジェクトの中からも割り込みや、他のプロジェクト・部からも割り込みは多々入ります。
始めに言ったじゃん。どうにかして。というのは無駄です。覚えてないし、「会社員なら当たり前だ」という答えが返ってくるだけです。「15分だけ」「ちょっとだけ」が頻発しますが、塵も積もればなんとやら、です。ちなみにこの件は査定・人事評価には全く影響がありません。
相談すれば「午前中はこの仕事、午後はこの仕事、定時後はこの仕事をすれば並列同時が可能だ」とあたかも新発見超名案を出したかのように返されるのが落ちです。そう、1日が24時間しかない事は忘れ去られ、PGが人間である事は忘れ去られ、思考の分断は効率を激しく低下させる事を知らないのです。
ここで断る勇気を持つのが大事ですが、職場内の雰囲気は格段に悪化します。評価は「人でなし」「自分勝手」「自分本位」「冷たい」。これらの視線に耐えられるのなら断りましょう。こちらからすれば「自分の時間を奪う方がよっぽど人でなしだ」と言い返したい気分です。
テスト工程も始まり、遅延が激しくなる上に、バグが発見されさらに遅延という状況が始まります。
ソフトウェアである以上、バグが無いプログラムなんてのはあり得ないのでバグを出す事自体は不可避です。
ところがPMは激しく怒り出します。バグの発見はPMに一報が行きPMが怒られるからです。
底辺PGはバグを出す毎にこっぴどく怒られます。中には仕様変更の事実がPGまで伝わっていないのにバグ扱いされる事も多々あります。
バグを出すと修正、テスト、再発防止策の考案などの厄介事が増えます。
再発防止策は通常「どうやったら自動的にそうならないか」を考えますが、あまりに根幹すぎるので、底辺PGの身分では権限が無く、出来る事が限られます。そしてPMが理解出来る策を考えねばなりません。結果「テストを増やす」「チェックシートを作る」とかになりがちです。しまいには「チェックシートのチェックシートを作る」などという意味不明の現象に陥ったプロジェクトを何度も見ています。
厳しく、それは厳しく怒られる上に、チームの前でさらし者にされる事、人格を否定される事も多々あるので、PGはバグを出さないように、見つけても出来るだけ極秘裏に解決しようとします。
「恐怖駆動型開発」
というもので、日本の場合ほとんどがこの開発手法をとられていると聞きます。この開発手法は書籍になっておらず、書籍としてよく売られているのはアジャイルな開発手法の本が多いです。知識として持っているのはいいと思いますが、役に立たないと思いますねぇ、恐怖駆動型開発の前には。まわりの人間も恐怖に巻き込まれないようにするため、どんどんスタンドアロン化が加速します。
その上、バグを隠すようになり、バグが出るようなテストを避けるようになるため、短期的に収束しているようにみえます。だから効果絶大と見るようです。リリースしてからが楽しみですね。
PMが空想から覚め、もう救いようが無くなった事が事実と認識出来るようになった時、ようやく、2度目の相談・報告時期が訪れます。ただし、PMの第1声は「どうしたらいい？」です。そんな事が分かっているのなら実行済みなので、黙っているしかありません。
するとPMは「何人入れれば良い？」と聞いてきます。意味が分かりません。IT業を労働集約型産業と勘違いしているのが未だに存在している事に驚きです。頭脳集約型の形態に人を入れて解決しようとはどういう脳をしているのか。一度解剖してみたいものです。多分、高校を受験する中学3年生の受験者が100人集まれば旧帝大の入試に合格すると考えているのでしょう。もしくは1Km走というのは1000人が一斉に1m踏み出せば1Km走った事と同じ記録である、と考えているのでしょう。
脳を電通で直結出来れば若干違うかもしれませんが、IT業の1＋1は2では無く、良くて1.5。ましてやこれで増えていくのは3～4人までが限界でそれ以上は人を入れても上がらないどころか、マイナスになる事が常。
PGなら他のプロジェクト、他の部、他の会社に信頼出来るエース級のPGを何人か知っているかと思います。なのでついPMに「エース級を3人」等と提案しがちです。しかしこれは叶わぬ望みです。その提案に対する答えは「そんな事出来るわけないだろ」です。そりゃそうです。予算が無いのだから。
自分の仕事があるのに、何故かこの後から来た人員を纏めるようPMから指示が出ます。PMが指示出来ないからです。破綻は間近です。いや、既に破綻しています。
プログラムが出来上がっていく以上、バグをつぶす速度以上の割合でバグを注入していく事になります。
「混乱しているプロジェクトに人を入れれば、なお混乱するだけ」
という有名な文を実感する事でしょう。なお、実感するのはPGだけであり、PMは実感出来ません。
この辺で思わぬ事態が発覚します。実は発注が遅れていた事です。
発注日以前にドキュメントがあっては監査にひっかかるため、今まで作ったドキュメントを作り直しをしなければならないという、まさに想定外の事態です。ほとんどのドキュメントには作った日付や判子が押されているはずです。それを全部作り直しするのです。納期は間際です。これも納期までに間に合わさねばなりません。
PM（重ねて書くが、プロジェクトマネージャだけでなく管理者や経営者も含む）が発狂し始めます。宛先は底辺PGです。
中には「お前を精神的に追い詰めるしか手がねーんだよ」とストレートに言ってくれるPMもいたりしますが、あまり出会った事は無いですね。
あの手この手で精神的圧迫を始めます。圧迫すれば脳がオーバークロックして作業が進むと考えているからです。残念な事に、脳の別の部位がオーバークロックしてショートしてしまいます。
こういうプロジェクトを経験し、運がいいのか実力なのか、生き残った人達がSEとなり、いずれPMとなっていきます。
不思議な事に日本では、PGが成長してSEに、SEが成長してPMに、とクラスチェンジするものだと考えられている会社が多のですが。
自分としては、座標軸のX,Y,Z軸の様にPG軸とSE軸とPM軸と全く異なるベクトルだと考えています。X軸の先にY軸Z軸があるわけでは無い、と。もちろん、軸に沿っているだけでは無く、他の軸のベクトルも併せ持つのもよいエンジニアでしょうし、ベクトルの方向を伸ばし続けるのもよいエンジニアでしょう。
ところが、クラスチェンジするものだと管理者・経営者は思っているから、給与体系もPG＜SE＜PMとなっていたりします。この時代錯誤的階級社会はどうにかならないものでしょうか。
自分はPMを否定しているわけではありません。いいPMの元でいい仕事をしたい、と思っているだけです。今までに何度かそういう良い経験をした事はあります。それは成功経験としてモチベーションを保つために必要な事なのです。
PG至上主義でもありません。分業形態として、SEやPMは必要不可欠だと思っています。ただ、PGを粗末に扱っておきながら高品質の製品を要求する風習・慣習が納得出来ないだけなのです。
数千コミットのリポジトリを開発チーム4〜5人ほどで、入れ替わり立ち替わり開発・運用・保守を行っている。
自分は携わって数ヶ月だけど、チームメンバのスキルとコミット差分の相関性について気がついた。
もちろん行数だけで推し量るなんて馬鹿げているけれど、いまのチームに上記の傾向があるのは間違いない。
バンナムの人ありがとう。僕がバトルオペレーションに出会ったのは2013年10月17日だ。会社の人に誘われて久しぶりにやった、そして初めてまともにPSNアカウントを運用した思い入れのあるゲームだ。このゲームは、一戦闘ごとに撃墜スコアが出るので、腕を磨けば短期的に結果が出るという報酬欲求を満たしてくれた。
また、一番輝いていた人には☆がつく。(与ダメトップ、スコア貢献度、アシストトップは数字が黄色くなる)初めは武器の切替もままならなかったけれど、スコアを稼いでうまいですね、とチャットで言われたり、称賛システム(戦闘結果画面で誰か一人に○ボタンで称賛が出来る。)が僕のモチベーション維持に大いに貢献してくれた。基本無料のゲームで課金は気が進まなかったけれど、もともとガンダムが好きなのもあり、大いに課金をした。後悔はしていない。
初めて1年以上経つが、アップデートによる機体追加、仕様変更による機体運用のトレンドの変化でプレイヤーを飽きさせない工夫が出来ている。僕が現在でもプレイ動画やwikiを見て現在のトレンドの把握と腕磨きに奔走している理由の一つだ。
バトルオペレーションは(大げさかもしれないが)人生も変えてくれたと思う。常々僕は仕事で生き辛さを感じていたけれど、このゲームを始めてから、その原因は「他者から継続して承認され続けていないからだ」と気づく事が出来た。「現にうまくなれば短期的に結果が出るバトルオペレーションは続けていられるじゃないか」と思うようになった。今は人より少しだけ上に立つ仕事だけれども、人生において誰でも最初は二等兵01で、尉官、左官になるまで経験値を積ませるためには、短期的に評価を与える必要があると思っている。
バトルオペレーションは心理学に基づいて作られたゲームだと思う。2012年に表彰されたゲームであるが、短期的な報酬が枯渇気味の現代社会において、ヒットは必然だったと言える。これはガンダムゲームであるが、キャラを変更するだけでほかのゲームにも転化出来る形式なので、今後も手を変え品を変えてリリースし、僕みたいな承認欲求の強い人を救ってほしいと思う。
× 俗にいう「使えないシステム」ってやつをつかまされたのかもしれない。 ○ 俗にいう「必須機能を伝え忘れたまま完成しちゃった」から、「使えないシステムをつかまされた」という設定でいこう（ゝω・）ﾃﾍﾍﾟﾛ
× 今、WEBアプリみたいので、業務ツール作っているんだけど完成が見えてきた段階で実はボロボロのものが出来上がってることに気が付いてきた。 ○ 業務ツールの作成を依頼したけど、完成段階まで必須機能を盛り込み忘れたことに今更気付いたどうしよう（ゝω・）ﾃﾍﾍﾟﾛ
× 全部CSVっていう言語でしか出せない。 ○ 全部CSVっていう形式でしか出せない。カティア言語とか形式とかよくわかんないや（ゝω・）ﾃﾍﾍﾟﾛ
× CSVをエクセルで開くとところどころ文字化けになってて全然使えないし、 ○ 何の文字コードで普段扱うかとか誰も気にせず完成しちゃったから文字化けで業務が回らず困った（ゝω・）ﾃﾍﾍﾟﾛ
× そもそも罫線もないしページングもされてない。 ○ ただのデータの羅列なので罫線もないしページングも当然あるわけないんだけど、そこは作り手の問題にしちゃえ（ゝω・）ﾃﾍﾍﾟﾛ
× ベンダーにそういったら「それは無理」の一点張り。 ○ ろんもちロハで作り直して（ゝω・）ﾃﾍﾍﾟﾛ ってベンダーに頼んだら「それは無理」の一点張り。
× コンサルはベンダーの瑕疵だからなおさせろ、ベンダーはやらない、で膠着状態。 ○ コンサルはベンダーの瑕疵という事にして無料で直させろ、って難癖で膠着状態に持ち込むことにひとまず成功★（ゝω・）ﾃﾍﾍﾟﾛ
× CSVだけじゃなくてほかにも必要な集計が画面上でできなかったり、そもそも機能自体が欠落していたりとかしてどうにもならない。 ○ 他の機能も必須なところを頼み忘れた・確認し忘れてたけど、まあ今頃言っても仕方ないよね（ゝω・）ﾃﾍﾍﾟﾛ
× このまま話がすすまないで納期間に合わなくなったら大変なことになるって言っても ○ このまま話がすすまないで納期間に合わなくなったら大変なことになるって脅しても（ゝω・）ﾃﾍﾍﾟﾛ
× 「仕様変更で納期が延びるのは当然だし、その場合再見積もりになる」とかサラッというし。 ○ 「仕様変更で納期が延びるのは当然だし、その場合再見積もりになる」とか当然のことを言われたので、イラッ★（ゝω・）ﾃﾍﾍﾟﾛ
× 20代のクソガキが！ ○ 理屈すっ飛ばして、相手が若造だから全て悪いことにしちゃえッ（ゝω・）ﾃﾍﾍﾟﾛ
× つうか仕様変更じゃねーしおめーの能力不足でこっちが迷惑こうむってんの！ ○ 必要な機能を後からお願いは仕様追加だし、それに今更気付いたのはこっちの能力不足だけどこっちが迷惑って事でﾖﾛﾋﾟｺ（ゝω・）ﾃﾍﾍﾟﾛ
× って、ベンダーに文句言ったところで何かが変わるとは思えない。だからといって追加で払う金もない。裁判する時間も金もない。死にそうです。 ○ って、ベンダーに無理筋通すしかないし、お金もないし時間もないしお金もないし、恫喝系で実績のあるコンサルお探し中。（ゝω・）ﾃﾍﾍﾟﾛ
元々の仕様に「エクセルで出力するよ」って書かれてるなら、さっさと裁判して勝てば良いし、
元々の仕様に「エクセル」の「エ」の字も無いなら、さっさと裁判して負ければ良い。単純な話すぎる。
そういえば、「20代のクソガキが！」みたいに相手の若さを理由に罵倒する態度って、
このまま話がすすまないで納期間に合わなくなったら大変なことになるって言っても「仕様変更で納期が延びるのは当然だし、その場合再見積もりになる」とかサラッというし。20代のクソガキが！
横だけど。
俺は、若い時は訳分らないまま相手の機嫌を損ねないようになんでもやるやる言っちゃって、結局大炎上で大赤字になるわ相手に訴えられそうになるわで、結局３００万しかもらってないのに１年以上かけたから軽く１０００万以上の赤字になった。しかも、信頼関係築けないまま数年たってシステム総入れ替えで終了（その時の予算は数千万だったらしい・・）。ってのを経験してから失注、解約覚悟で厳しいことも言えるようになった。
俗にいう「使えないシステム」ってやつをつかまされたのかもしれない。
今、WEBアプリみたいので、業務ツール作っているんだけど完成が見えてきた段階で実はボロボロのものが出来上がってることに気が付いてきた。たとえば月報とか日報みたいなアウトプットが必要なデータが10種類ぐらいあるんだけど、全部CSVっていう言語でしか出せない。CSVをエクセルで開くとところどころ文字化けになってて全然使えないし、そもそも罫線もないしページングもされてない。社外のコンサルに聞いても、CSVは機械同士がやり取りするための言語で、人が使うデータはエクセルで出せるようにするのが普通って言っている。ベンダーにそういったら「それは無理」の一点張り。コンサルはベンダーの瑕疵だからなおさせろ、ベンダーはやらない、で膠着状態。CSVだけじゃなくてほかにも必要な集計が画面上でできなかったり、そもそも機能自体が欠落していたりとかしてどうにもならない。
このまま話がすすまないで納期間に合わなくなったら大変なことになるって言っても「仕様変更で納期が延びるのは当然だし、その場合再見積もりになる」とかサラッというし。20代のクソガキが！つうか仕様変更じゃねーしおめーの能力不足でこっちが迷惑こうむってんの！って、ベンダーに文句言ったところで何かが変わるとは思えない。だからといって追加で払う金もない。裁判する時間も金もない。死にそうです。
自分はとあるwebサービスを新規で立ち上げようとしてるペーペーのエンジニアだ。
サーバーサイド出身の人間でLAMPに理解力があるエンジニアだと思っていい。
そいつが初のクライアント側の実装をやることになったんだが、いろいろ覚えることが多くて大変なんだ。
いろんなバッドノウハウを踏みまくるなか、プロジェクトの中で一番大変なのは新しく覚える言語ではなく、
フレームワーク使い倒すでもなくて、プロジェクトに参加してる人間達だということに最近気づいた。
政治力と置き換えていいかもしれない。
この政治力が足りないとうまく立ち回れない。
この話を通すには誰かと仲良くなっていると通りやすいとか、
立場で話を進めて何を言ったかではなくて、誰が言ったかになってたりなど。
中には勇敢に立ち向かって行く人がいるが、玉砕してるのを間近で見てる人間はもう戦うことをやめる。
そんな闇を抱えたプロジェクトに新しく人が入ることもある。
自分も完全同意で、確かに意味がわからない。だが、負けたのだ。
過程を説明し、我々の闇を知ってもらうと大抵は納得してもらえる。
いやそれでもまだ問題は山積みだ。
しかし、ここでも"誰が"コードを書いてるかによってコメントが2chのように荒れたりする。
やる気が削がれる。
そして納期。
納期を守らなければ売り上げが0円で、開発してるものもただの文字列でしかない。
価値あるものをユーザーに届けるというゴールを誰が見ているんだろうか？
社内の取り決めやふんわり決まった仮決めの仕様で進むことで度重なる仕様変更。
それに疲れたメンバーの退職に全力阻止するプロジェクトマネージャー。
どうしてこうなってしまったんだろう。
