  |
はてなキーワード: 仕様書とは
あまりコミニュケーションが得意ではないのもあって、入社直後は非常に苦労した。
正直人見知りだったのでわけのわからないことをのたまっていた時期もあった。
とはいえもう4年目であり色々と手馴れてきて精神的にも余裕ができてきた。
しかも、最近の現場は9時-5時で帰宅できるようになり肉体的にも余裕がでてきた。
と、ここらでレベルアップを図りたいと思っており色んな設計書の問題点を指摘した記事とかを読み漁ってきたわけだが
アジャイルだの詳細設計書がゴミだのいろいろ指摘しているのは見かけるのだが今の自分の現場と環境があまりにも違いすぎてピンとこないのだ。
なんせ、入社してからやったのがガチガチのウォータフォール型の開発でアジャイルだのなんだのをまったくやったこともないからだ。
Gitなんて使ったこともないし、eclipseでSVNでソースを管理し、古いシステムならCVSだって未だに現役がちがちだ。
幸いにもドキュメントはがっちり作ってあって過去のシステムがどういうものなのかはよくわかるようになっているが。
もちろん転職しちゃえとか色々まぁ考えようはあるが別に今の会社に大きく不満があるというわけではない。
そこでＳＥ経験の長いお歴々に色々尋ねたいことがある。
http://nantonaku-shiawase.hatenablog.com/entry/2014/05/18/012107
↑上記のサイトでウォーターフォール型開発の例を逐一説明してくれているがこんな一文がある。
ネットで検索すると、みんなが批判している。私も作ったことがない。というか時代遅れと言われがちなSIerの私ですら書いたことが無いのに、書かせる企業 is 何。
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
EXCEL設計書 Vol.1 怪文書大公開 | Same Old Lucky Day
詳しすぎる詳細設計書 - SiroKuro Page
ネットで検索すると、みんなが批判している。私も作ったことがない。
俺は入社してからずっとガチガチに詳細設計書を書いていたし、先輩も皆書いてる。
一体どこの世界の話なんだ。
いくつかの現場にも出向したがそこでも普通に詳細設計書を書いていたぞ？
どういうことなんだこれは。
でもよくよく考えたら、なんだか説明されている詳細設計書と機能設計書は俺が書いている「詳細設計書」ではひとつにまとまっている気がする。
そもそもそんなのないかも知れないが。
そこで尋ねたいのは事例として機能設計書や詳細設計書の具体例が欲しい。
書籍でもWEBページでもなんでもいい。
そうじゃないとなんだかそもそも話に付いていけない。
あと、詳細設計書がかけなくなりそうだ（切実）。
ところが俺の住んでいるところではExcelにテスト項目を俺が書いて俺が単体テストを手動でやって、結合テストも俺が手やる。
結果列に○だの×だの書いて失敗したらまたやり直しだ！
延々とこれを繰り返す。
別にそれがいやだといってるわけじゃなくて（嫌だけど）、皆テストとかどうやってんの。
テストとかそもそもやってんの？
アジャイルだの何だのに手を出すのもいいのかもしれないがそもそもウォータフォールなV字モデルをぜんぜん理解し切れてない。
誰か教えてくれ。
これは、社会科学の基本に則って、一見非効率に見えることも実は合理的な行動の結果なのだ、と、解釈するのが妥当じゃないかな。エンジニア的に「効率的」で幸せにする方法はGoogleその他の先行事例でよく知られており、日本でもウェブ系ではそのノウハウを取り入れている。渋谷のテクベンチャーで繰り広げられているおしゃれオフィス競争とか、Slack活用してDevOpeだーとか、社内食堂競争とかね。彼らのビジネスにとっては優秀なエンジニアをつなぎとめることが利益に直結するからだろう。大手SIでそれが取り入れられてないとすれば、それにはその理由があるからだ、と考えるのが妥当。
一番最初の元増田の指摘は技術に偏っており、会社のバランスシートや株価までみているような感じはしない。前の増田も、「売上が上がる」としか言っていないから、ROIとかTCOとか考えて妥当な提案かどうかは微妙だと思う。
Excel仕様書業界では、エンジニアを「効率的な仕事」で幸せにするよりも、ISOなんたら規定に従って書類を整えることの方が利益につながるんだろう。あとは規模の違いかな。何千人もエンジニアがいたらもう官僚的になるしかないよね。だから、「非効率」をあげつらう「エンジニア」は、会社の社会における立ち位置と収益構造がよく見えてないだけだと思う。もちろん、Excel仕様書その他に慣れているからという理由だけで不適切なところまで援用して、ミクロなレベルで非効率性が出ることはあると思う。ただ、「大手SIには非効率を尊ぶ社員が多い」というのはおそらく言い過ぎだろう。
さっさと転職しろ、というのは技術力に自信があり、エンジニアを大事にしてくれる環境にいたいのなら妥当なアドバイスではあると思う。ISOとか歴史とかでかさ上げされていた会社の力がなくなる分、会社の社会での立ち位置は下がるけどね。
http://anond.hatelabo.jp/20150526175312
↑を昔描いたんだけど
アニメ産業の問題はオリジナルで勝負しないことだってことってかいたら
わかってないなぁみたいな反論が来たんだけど
結局よくよく読んでみると、反論できてないっていうか
図星なんだろうなっていう結論に至ったわけですよ
まぁそんななか増田で
SIはやめておけ
http://anond.hatelabo.jp/20160123131828
なんてものが書かれてたわけ
読んでSIも似てるんだなっておもったよ
仕事の主導権が自社にない
受諾で孫請けでシコシコやるだけ
それで愚痴るｗ
俺たちが悪いんじゃない悪いのは上の奴らだってねｗ
プログラミングもできないSEが仕様書描いてるとかいうじゃんｗ
それでおいしいところ持っていかれるのも似てるよね
やっぱり思うわけよ
リスクも取らずにぶら下がってるごみみたいな連中が、自分を正当化するために上を叩くんだなって
教訓
受託はだめだね
アニメなんてメンテナンスもなにもないからSIとくらべるのもおかしいんだろうけど
アニメは幸い海外ではそんな盛んじゃないから、なんか日本は進んでるみたいに思われてるけど
あほみたいな人海戦術でCGもしょぼいのにぐりぐり動いただけですごいすごいともちあげるところみるとやっぱ遅れてるなぁって思う
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。
今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。
一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。
以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。
受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。
つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。
これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。
マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。
私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。
あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。
前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。
社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。
そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。
開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。
私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。
上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。
まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。
そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。
ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。
だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。
また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。
私は異動したが、彼は今でもそこにいると聞いた。
（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。
保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。
先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。
私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。
そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。
無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。
また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。
また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。
新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。
まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。
また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。
SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。
個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。
会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。
いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。
情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。
ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。
会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。
どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。
利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。
本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。
表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。
その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。
他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。
そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。
○朝食：なし
○昼食：おにぎり三つ
○調子
むきゅー！
お仕事さんを頑張った。
なんか共通メソッドの製造の割り振りをしていないという衝撃の事実が判明し、
「共通メソッドを作るのは、製造していってそれが始めて必要になった人が全体に周知して作り始める」という仕組みが導入された。
ぶっちゃけかなり面倒くさいのでわざと手を抜いて他の人が作ってくれるの待ったろかいな？ とも思ったけど、
全員がその態度だと巡り巡って面倒なことになりそうなので、渋々手を上げて僕が作ることにした。
したんだけど、メールとかwikiとか掲示板とかメッセンジャーみたいな便利グッズが無いので
「みなさん聞いてください、あっいやこっちの島の人だけでいいです、はい、あの共通メソッドのpiyopiyo1は僕が作ります、とりあえずメソッドのガワだけ作ったので呼ぶ人はpiyopiyo1って書いといてください、え？ はあ、はい、はい、じゃあpiyopiyo1じゃなくてpuyopuyo1になります、あっ引数は設計書通りですが、なんか型の定義が漏れてたので共通設計書書いた人はint型って明記しといてください、えっ？ intだと不味い？ なんで？ はあ、はい、はあ、え？ ああ、はい、はい、わかりました、じゃあクラス作るので呼ぶ人はまだ呼ばないでください。引数に渡すクラスの定義もまだなので、え？ ああ、ごめんなさい、すいません構造体作るのでとりあえずpiyopiyo1付近はちょっと保留にしておいてください、え？ ああはい、すいません、えーっと結論としてはpuyopuyo1付近は保留です」
みたいなことを全員に伝わるように大声で話して、
隣の席のインド人に分かりやすい日本語でもう一度話しするだけの簡単なお仕事こなす。
その後も同じようなことを二回ぐらいやった。
それと、プログラムの仕事あるあるで、今までもたびたびあったことなんだけど、
設計書に書いてあることがどうにも筋が通っていないように感じる（例えば、生年月日は必須項目なのに、リードオンリーで書き込み不可とするみたいな設定）
↓
色々ドキュメントを読み理解を深めるもやっぱり間違ってる気がする（例えば、他の項目を入力するとマスタ引きされて自動で入力される的なやつとか）
↓
↓
お客さんの業務がうんたらかんたらな特殊仕様が明らかになる（例えば、実はそもそもGUIでは編集オンリーで新規追加はさせないだとか）
その特殊仕様について全部仕様書に書くのは労力的に難しいのはわかるから、
一言申し送りというか、設計者さんと会話する時間をとって欲しいなあ。
今は別に和気あいあいとした雰囲気だからいいけど、これが機嫌悪い人だったり、そもそももう居ない人だったりすると俄然面倒くさくなる。
みたいな話を深堀さん似の同僚に話したら
「設計書に書いてあることが間違ってても責任は設計者にあるから私たちは気にしなくて良い」って言われた。
それもそうだなあ、と思ったので明日からはあんまり細かいことを気にせずに適当に書こうと思う。
と決心をした直後、
（「文字を青く赤くする」みたいな日本語としても破綻してる感じの記述）
「これも無視して作ったろかいな」と思うも、渋々設計者に聞きにいく。
そしてその上、似たようなことを僕の設計書でもやらかしてて、作る人に質問されて、
「あーもう面倒くさいなあ」ってなりました。
（自己弁護するとその点に関しては別の人が作業の横展開でまとめてやったときのミスで、僕自身が書いたものじゃないんだけど、まあ最終チェックしたのは僕だから僕のミスでもあるっていうなんとも面倒くさい）
いや本当よくあることだし、これが嫌とか、これがムカつくとじゃなくて、
この程度をコミュニケーションっていうと営業の人とかお客さんと仕様を打ち合わせる人とかに怒られそうだけど、
人と喋ったりするのが苦手なので、疲れるんですよね。
（チケット管理的なことをしてるプロジェクトだとそれ書いてIDコール的なのするだけで良いから楽で好きなんだけど、あれも結局ややこしくなってくると会話しなきゃいけないから、ちょっと楽程度なんだよなあ）
ネットでたまに「プログラマーは人と喋らなくても出来るから、コミュ障向け」みたいな言葉を見かけるけど、
プログラマーでこれなら、他の喋るのがメインのお仕事はどんなにツラいんだろう？ と怖くなってしまいます。
稲船氏のXbox One/PC新作『ReCore』は「今年後半に向けて準備中」
http://www.gamespark.jp/article/2016/01/06/62884.html
うん？ いつのまにWinでも出ることになったんだっけ？ となった。
PVの雰囲気がとっても楽しそうだけどゲーム性がなにもわからないから、早くプレイ動画がみたいですね。
舞台「カードファイト!!ヴァンガード」公演スタート、プロジェクターや役者を使ってカードバトルを再現
http://www.inside-games.jp/article/2016/01/06/94695.html
これ面白そうだな。
残念ながら東京まで行く予算はないから見に行けないけどDVDはちょっと欲しいかも。
プラチナゲームズ最新作『Scalebound』が2017年に発売延期
http://www.inside-games.jp/article/2016/01/06/94665.html
ってあれ？ プレイ動画出てたりするし、リコアより早いんじゃね？ とか予想してたら来年かー。
自閉症スペクトラム（アスペルガー）の人間に向く職業として、プログラマが挙げられているが、これは誤解を招くのでやめた方が良いと思う。
このあたりの特性から、コミュニケーションスキルが壊滅的になってしまうため、チーム作業やスクラム開発等に従事することがかなり厳しい。また、要件を聞いて設計するということもかなり厳しい。
では、どのあたりならいけるかとなると、コッテコテのSIer的ウォーターフォール開発での「PG」になってくる。このポジションは、仕様書に従ってコードを書けばよい（自閉症スペクトラムの人間は、会話よりも文章で伝えた方が良い）ので、比較的問題が出にくい。また、1つの作業に没頭してしまう傾向から、デバッグ関係が比較的得意なのと、（あまり良いことではないが）残業耐性が比較的高いというのも、「PG」向きではないかと思う。
○朝食：なし
○昼食：おにぎり三つ
○夕食：マクド
○調子
むきゅー。
それと、JavaScriptさんを書くお仕事もあって、
よいちょ！ うんちょ！ って一生懸命書いてたんだけど、仕様変更でほとんど意味が無くなった。
上流がちゃんと決定してないのに、下流に手をつけさせようってのが間違ってるんだよなあ。
決定してないっていうか、製造しようと思って仕様書に書いてないことやら何やらを質問すると
やぶ蛇をつつくことになって、二転三転することになる。
プログラマーとして下流工程をやってるとたびたびこういうことがあるんだけど、
いつもいつも面倒臭いなあ、上流工程の人たちちゃんと仕事してるんかいな、とイライラする。
普段はまあそんなもんか、と軽く流してるつもりなんだけど、今回のお仕事ではやたらと多い。
特に多いのが
「じゃあ作ってね、頑張って」
「むきゅー！ がんばるでち！」
むきゅむきゅちちゃいぴんぐー！
（四時間後）
「むきゅー？ なんだか理屈さんがあわないでち！ もちかちて、PIYOPIYOテーブルさんにカラムを一個作り忘れてるでちか？」
「え？ あっ本当だね、どうしようかなー」
「今回は短納期で出来るだけパッケージ標準で作るってルールで、その箇所は標準を逸脱した機能になるから、もう全部作らないことにしたよ」
「むきゅー？ 全部でちか？」
というパターン。
作らなくてよくなったから楽でいいんだけど、
その検討は作り始めてからするんじゃなくて、上流工程でやってほしいなあ。
なんていうか、穴を掘って埋める徒労感がある。
みたいなことを同僚さんと愚痴っていたら、
明日と月曜日で上流工程の大幅な見直し時間をとることになった。
それ自体は大歓迎なんだけど、その分下流工程が遅れるのは駄目らしく、残業やらでうまいことしてほしいと言われた。
こういこともあろうかと、前倒しで作業してたから休日出勤は多分しなくても大丈夫。
うーむ、来年は大変そうだなあ。
○心ちゃん
心ちゃんも暮らしてる咲-Saki-のアニメ版の一期を見ている。
僕が咲シリーズにハマったキッカケになった長野予選の中堅戦は本当にすばらしい出来だ。
国広さんと龍門渕さんのカップリングを見てはまったんだよなあ。
北から南からいろんな人が
毎月会社をはなれ 満員電車にゆられ
はるばると開発現場までくるという
ファイルサーバを漁り メンバーに尋ね
仕様書を探してきたが
ドッコイ！ そうは問屋がおろさない
PMが立ちふさがって言うことにゃ
わかってるだろうが来月にはリリースなんだよ……！？
仕様がなけりゃ君！ 仕様がなけりゃ
降りた方が身の為さ アンタのプロジェクト
現場はいい所さ 技術レベルは申し分なし
プロジェクトは大成功に決まってるさ 仕様があればネ！
作業をどう進めようとそりゃアンタの勝手さ
だけど仕様が無いからとソリティアするのはもっての他だよ
まして期日までに実装したいのなら
そうだよ！ 旧製品の挙動が仕様なのさ
そいつを真似てりゃまずまずさ！？
部長だって飲み会でいってたよ！
仕様がなけりゃ君！ 仕様がなけりゃ
降りた方が身の為さ アンタのプロジェクト
if n ＞= 100 then n = 100
条件: n が100以上 結果:nに100が代入される
みたいにソースコードと1対1に対応するように 書けという指示だったので、言われたように仕事をしてた。
テスト工程がある程度進んだ時に、その指示を出した当人がふらっとやってきて「バグ率は3%でないといけないから」と言ってまた去っていくのな。
元受けからバグ件数が0はおかしいって言われたんだろうけど、こんなテスト仕様書、コンパイラがバグらないかぎりバグ率0%にきまってるじゃん。
ソースもテスト仕様書もレビュー通ってハンコもらってるから変更しちゃいけないけど、仕方ないから適当に変更してバグを作って3%に調整したわ。
プログラム書くようになってあるプロジェクトで実践でも投入されるようになってから数年。当時の上司にプログラマって名乗っていいんじゃない？とか言われてプログラマという自認もできた。
もともとはSE的な立場として仕様書を書いたりしてた。ゲーム業界だからSEとはいわずに企画とかプランナーとか呼ばれる職種。書類仕事がメインで、自分でツール作るかスクリプター的な役目でないかぎりコードみたいなものを書いたりはしなかった。コード書くの楽しい。VBなんかに戻れないし、もう書く事もできないだろうな。
だからってわけでもないけれど、できる企画とダメな企画ってのがわかるのよね。プログラマ側からみての意見になるから、ディレクターからみて、とかデザイナーから見て、とかはまたちょっと違うのだと思うのだけど。
自分、ちょっとコードの読み書きできるのでわかってます、な体で仕様書書いてくるのだけど、全然穴だらけ。要件が不明なままフローだけ書いてくる。実際にやりたいことは何なの？そこを説明して実装はプログラマに任せようよ、と。
ゲーム作るのにはバージョン管理システムを導入するのが常。subversionとかgitとかあるでしょ。すごく便利なんだけど基本的にテキスト形式のファイルを管理するためのものなので、エクセルみたいなバイナリ突っ込まれると差分じゃなくて全部のバージョンが入るから容量を圧迫するの。
画像データはまだいいよ。githubがpsdの差分さえ教えてくれるからね。
文字情報メインなのに差分を見る事もできない。検索もできない。
ただ、データ管理としてのエクセルは優秀なのよ。ちょっとしたツールもつくれちゃうし。仕様書をエクセル方眼で書いてくるやつはカスだ。
俺も若い頃はよく使ってたけどMarkdownを知ってからは断然こっちの方が書きやすい。そしてなにより読みやすい。検索もできるし成型もできる。強調表示や画像も貼れる。文法も簡単だし覚えやすい。
Markdownは文字列情報だ。文章だ。文章は一次元的に表現される。つまり書く側が完全に整理した思考でないと書ききれない。読む側に理解させるにはどういった順番で説明をすればいいか考えてからでないと表現できない。おのずと書類の内容、精度が上がる。ただの文章だからこそだ。
エクセルはタブやらなんやらで並列なまま多次元情報としたまま表現できる。思考が整理されてなくても表現できてしまうし、表現した気になる。書いてる側の思考がまとまってないまま表現できてしまうあたりはエクセルの自由度の高さでもあるのだけど、通して読む事ができない形式でもあるので、読む側のことを考えていないクソみたいな仕様書も提出されてきてしまうのが難点。
企画「XXファイルのYYタブに書いてありますよ。ちゃんと読んでるんですか？」
殺意が沸くわ。
Photoshopなり何なりで書いた絵図をGyazoにでもあげてリンクだけMDに貼れよ。エクセルでシェイプ駆使して作るより早いだろ。
パワポの方がマシですわ。あれはページにスペースの制限があるから１ページ内にまとめよう、伝えようっていう意思と能力がないとまとめられないから。
要件を伝えるのもいいけどバランス調整するための調整項目だしなよ。調整できるようにするし、こっちも使う変数を見出すきっかけになるから助かるんだよね。
3Dアーティストのあげてくるデータも仕様書書くでしょ？あれの要件とかもまとめられないでしょ。ノードとか意味わかる？揺れもの数とか制限あるのわかる？
なんでもいいからゲームエンジン触れよ。Unityとか簡単じゃん。プログラム書かなくてもいいじゃん。
俺があれだけMarkdown簡単だから覚えろって言ってもエクセルで上げてくるし、古い知識のままアップデートされない人って存在が迷惑ですわ。
プランナーで説明が下手って終わってるよね。俺も下手だわ。よく怒られてた。ごめんなさい。これは別にプランナーに限った話ではないけれど、プランナーて人に伝えてなんぼなので職能としてこれがないのは致命的だよなぁ。
書いてすっきりしたので寝る。星くれ星くれ
私の上司は優秀だ。コミュニケーション能力が高い。感情的にならず、冷静に落ち着いて論理的に話す。相手が幹部クラスの人であっても部下であっても、そこは変わらない。業務遂行能力も高い。常に全体を見ていて自分の担当外であっても何か問題があれば自ら解決に向けて動く。この先どうなるか、リスクを予見する能力も高い。もし居なければこの事業はあっさり潰れてしまうだろう。もっと給料のいい会社に転職したらいいのにと思うことがしばしばある。
ただ、、その、、優秀すぎるのだ。
私が業務の相談に行っても、何か気に障るようなことがあると、表情が消え、冷たい目になる。表向きはきちんと聞いてやろうという言葉を発するが、表情と一致しないので怖い。私の能力が低いのだからしかたないが、できるだけ行きたくない。時間を割いてもらうのは申し訳ない。
提案書や仕様書といったドキュメントも10回、20回とレビューを繰り返していくうちに心が折れる。リバイスを繰り返し、フィックスする頃には、もはや別物。言われるがまま。思考停止。お客様にお見せするものだ。念入りなレビューが必要だ。当初の締切は過ぎている。その先のプロセスにかけられる時間は少ない。圧倒的な残業で巻き返す。そしてバーンアウトする。
私だけなのかもしれない。思い切って同僚に聞いてみたところ、同じことを感じているようだった。
人が入れ替わることも、新しい人が入ってくることも、自分が異動することもない。唯一人の上司の元に付き、日々業務をこなす。このまま無理して続けたとして、役職と権限を与えられたとしても、上司のように優秀でないのだから、今の事業を潰すきっかけを作ると思っている。
最近は気分が晴れないし、ストレスのせいか耳鳴りもひどくなってきた。自宅で業務に関係する勉強をしたり、趣味も楽しんだりもしていたが、そんな余裕もなくなった。今の会社、辞め時なのかもしれない。
＞ほかのサイトがやってるからとか、今までそうだったからとか、そうういうアホらしい理由で決められてるはず。
コーディングするほうは、仕様書通りにつくっているだけだし、設計者が何か問題になると困るから横並び的にそんな仕様にしているのだろな。
郵便番号や電話番号はハイフンを抜けとか、振込先は半角カナで入れろとか、システムで処理しろよそんなの、といつも思って某WEBサイトを使っている。
パスワードは英数のみ８ケタまでとか、パスワードリセットではなくてリマインドメールに記載されて送られてきたりすると、セキュリティ的にここの会社怪しすぎ、と不安になるので、ECサイトなんかではそこの会員登録を中止するね。
デザイナーとかアートディレクターってクライアントの課題を解決する立場なわけ。エンブレムとかロゴは企業の顔じゃん。
「テクノロジー系企業だから先進的で、だけど人との繋がりを大事にする会社だってことを主張したい」とかさあ、「古い歴史のある旅館だってことをアピールしたい」とかアホみたいに漠然としてたりもするけど何かの要件定義があって、それを達成するためにデザイン作業をするんだよ。
もしクラが「田舎のお土産だからあんまり洗練された感じじゃなくてむしろちょっと絵心のあるおばちゃんが描いたようなダサくて素人っぽい雰囲気出したい」とか言い出したらそれを達成するためにダサいロゴ作る。これもう絵心のあるおばちゃんに頼んだほうが早くねって思いながら作る。クラがダサいものを求めてるから。
ここでいやダサいもん作るんじゃなくて適切な提案しろよって言われるかもしんないけど、それお前ら的には「どう考えてもおかしい仕様書が来てどうしようもないけど仕様通りに作るしかない……」みたいな話なんだよ。
「飲食店だから食欲を増進させるために青をメインカラーに使う」ってくらいおかしかったら仕様バグだから確認するけどさあ、明らかに子供にしかうけない商品なのに「イメージ転換のために新しいロゴを作る。今までのイメージを壊してシックで大人向けにして」とか言われたって、はあそっすかーって頷くしかないじゃん。自爆する気配しか無くても。ここで「いや、この商品には合わないしイメージ壊しちゃまずいですよ。子供向けに作ります」って返事するのが正解なの？なんでデザイナーが商品の販売戦略とかイメージ戦略にまで口出しすんの？おかしいだろ。そんなイメージ転換したら売上落ちるかもしれないですけどホントにいいんですかって確認するのがせいぜいだ。
何が言いたいのかって、持て囃されてるロゴはこの要件定義をされてないわけ。強いて言うなら日本国民が求めてたっぽい「イケてる感じ、華やかに、日本風に」に沿ってる。作ったデザイナーの独断で。そりゃウケるだろうよ。
実際のコンペ時の条件は元ページが消えてるしググってもググっても情報出なくて検索力の低さを痛感してるんだけど、何かの記事で「展開性重視、前回の東京オリンピックロゴイメージの継承、対照的なパラリンピックのロゴも作成」とか見た記憶がある。
実際、採用されたロゴを見ると華やかでわかりやすい日本らしさはそんなに求められて無かったと思うんだけど。すげえシンプル路線だし。
なのに要件を無視しておれのかんがえたさいきょうのろごでざいんをドヤ顔で出してる奴はひたすらにうざいから滅びろ。作るなら元の求められるコンセプト確認してから作れ。「多くの人で支えられている日本」をコンセプトにとか言ってるけど、それお前が勝手に必要だと思ってるだけじゃねーか。
今日の夕飯何食べたい？
↓
人工知能に決めさせりゃいいだろ？
仕様書っていうのは、使う側が何をどうして欲しいか？を書くものであって
プログラマーが自分で仕様書書くならそもそも仕様書いらない。いきなりプログラム書いたほうが速い。
わざわざ日本語で書いているのは、プログラム言語が読めない人のために日本語で書いているのであって
天然ものの知能だって不具合だらけの仕様書作ったりするんだから
