「仕様書」を含む日記 RSS

はてなキーワード: 仕様書とは

2020-10-09

anond:20201008200239

御社プロマネの指示通りに働いてた派遣の人に責任押し付けんなよ

だいたいテスト仕様書作るかどうかも社内での標準成果物規定されてないのが原因だし、PMOとか監査機関置いてない御社体制問題だろ

anond:20201008200239

検査仕様書の大切さ」の話かと思ったら「社員に嫁をあてがうことの大切さ」の話だった。

anond:20201009063641

派遣会社IT関連のテスター募集をすると素人が応募してくることが多いって話。

テスターなら技術のない自分でもなんとか潜り込める、と思うアホな人が一定数いるらしい。

そんな人は派遣登録させなきゃいいんだけど派遣会社はとりあえず登録し「突っ込めるところがあれば突っ込む」。

こういうプロジェクトなんてそういう登録者の突っ込み先としては美味しかっただろうね。

もちろん、契約検査仕様書作成が含まれているのにそれが出来ない人を派遣するわけだから契約違反と言われれば反論出来ないけど。

anond:20201008200239

派遣を切るくだりにかなり違和感がある。

増田社のプロマネ検査仕様書を作らなくてよいと指示した(作る指示をしなかった)から

検査仕様書存在しないのであって、派遣がサボったか検査仕様書存在していないわけではないので

首を切る理由検査仕様書を持ち出すのは変だし

契約更新タイミングで「検査仕様書を今後は書いてもらいますよ」という念押しした話なのだとすると

派遣会社が「検査仕様書作るスキルいからやりたくない」というようなことを言い出すとも考えにくい。

一般派遣会社っていうのは、出来もしないことを出来ると言ってでも契約取ろうとするものだ。

anond:20201008200239

テスト仕様書でも設計書でも、「御社の制定フォームに則って作成するのでテンプレートいただきたい」と言うと、「制定フォームなんかない。経験豊富なのだからスクラッチで作れるでしょう?」と返された現場もある

PJ仕様書をこっそり見せてもらって、ふんわり似せて作るけどそんなんでいいのか?

anond:20201008200239

詳細は省くけど、仕様書とか設計書がない+要件定義ドキュメント顧客へのヒアリング無し(面通しNG)などでテスト仕様書を作れって言われる現場は実際にあるんだぜ…。

リニューアル前の動いている状態か、ライバルアプリと同じ動きが正の2パターン自分の知ってる範囲だけど、それすら無く、開発側ですら五里霧中で作ってる案件もあると思う。

2020-10-08

検査仕様書なしでシステム開発するとどうなるか?

検査仕様書なしでシステムを開発するとどうなるのか?

ある炎上プロジェクトの建て直しを通じて嫌と言うほど思い知らされた。

そのプロジェクト顧客が一番怒っていたのは「一体どういうテストをしてリリースしてるんだ?」という点だった。

プロジェクトの建て直しはやり慣れているのでまずは検査仕様書レビューして検査項目の強化だな、とか軽く考えていた。

でもプロマネ検査仕様書を見せてくれと言っても整理できてないから待ってくれ、の一点張り

まずは社内の人間で見るだけだから整理なんていらないよ、と説得しても頑固に出さない。

なんとそいつ検査仕様書なしでテスト(うちの会社定義ではそんなもんはテストと言わないけど)して顧客リリースしてた。

全く動かないシステムリリース

顧客は「全く動かない」と怒っていたが僕はいくらそれはないだろ、顧客が話を盛っているんだろうと甘く考えていた。

しかし、プロジェクト自称テスター新規動作環境を作って導入させてみようとしたら見事に出来なかった。。。

なんとその自称テスターはいつも試行錯誤しながらテスト環境を作り、試行錯誤しながら何とか動けばテストOKとしていたと言う。

これでは顧客が動かないと怒り狂うのは当然だった。

派遣検査仕様書を作らなくていい!?

もちろん検査仕様書があればさすがにここまでバカ事態にはならない。

検査仕様書顧客へ納品する契約になっているし、社内規定でも検査仕様書なしなんて通らない。

プロマネを問い詰めると呆れたことに派遣検査仕様書を作るのはおかしいなんて言い出した。

うちの会社では通常、検査仕様書派遣テスターが作っていて派遣テスター契約内容も「検査仕様書作成」となっている。

念のために炎上プロジェクト派遣契約書を確認してみたが内容は同じだった。

派遣テスター派遣会社にも膨大な費用が支払われていた。

一体、派遣テスター契約通りの仕事をさせずに何をやらせていたのか?

なんと「ある一定時間適当に(検査仕様書なしで)システムを触る」ことをテストだと言い張った。

マンガのような自称パフォーマンステスト

顧客は「そちらのパフォーマンステストの成績だけは満足しているがうちでは動作していない」とも言っていた。

とてつもなく悪い予感がして聞き取りを進めると時間ストップウォッチで計測したと言う。

普通なテストコードを書く派遣テスターが計測ポイントを埋め込むのになぜストップウォッチ?

この段階でテストコードを書ける派遣テスタープロジェクトに1人もいないことがわかった。

全社的にテスト自動化が進められているのになぜ!?

さら実装したというプログラマー確認すると、実装が難しいので後回しにしていると言う。

テスターに頼まれストップウォッチで計測できるように処理を数万回か繰り返すコードだけ入れたと。

まりほとんど空の処理を数万回ブン回すだけの意味のないコードの実行時間パフォーマンステストの成績として顧客に提出されていた。

顧客のところで動かないのは当然だ、実装出来てないんだから。。。

このことを僕の上司に報告すると「そんなマンガのようなことがうちの会社現実にあるのか、、、」と頭を抱えていた。

会社の信用に直結するのと他にも多くの仕事を出す大口顧客のため上司から役員へ報告することになった。

検査仕様書なしに意を唱えるプログラマーに頑固者のレッテル貼り

パフォーマンス要求される難しい処理の実装ができてないのに、スケジュール上では実装の進捗がほぼ100%になっている。

プロマネを問い詰めると他にも似たような箇所がいくつかあるらしい。

じゃあ、その難しい部分も含めて一体いつ実装が終わるのかわかるようにスケジュールを引き直してくれ、と言ったが彼には出来なかった。

実装できるプログラマがいないからだという。

しかに開発現場プログラム言語入門書を読みながら仕事しているプログラマーが多かった。

不審に思って開発体制資料過去プログラマー契約書を確認するとプロジェクト初期には僕も一緒に仕事したことがある超優秀なプログラマーが2人いた。

しかし、2人ともプロジェクト途中で契約解除となっている。

契約解除の経緯についてプロマネを問い詰めると「仕事段取りが悪いか契約更新しなかった」と言う。

僕は2人をよく知っていたのですぐに嘘だとわかった。

プロジェクトメンバーに話を聞くと、2人は「今のテストはまずいですよ」とプロマネ提言したらしい。

でもプロマネは頑固に検査仕様書なしでのテストを強行し、再度2人が提言すると「彼らは頑固者だから仕事ができない」などレッテル貼りするようになったという。

そして2人とも契約解除し、入門書を読みながら仕事するレベルプログラマーけが残って実装完了スケジュールすらひけなくなったというわけだ。

プロマネは涙を流しながら机を叩き部屋を出ていった

社内での対策会議プロマネはなぜ検査仕様書を作らないのか当然追求された。

僕に言ったのと同様に「派遣検査仕様書を作るのはおかし・・・」と言おうものなら、役員

「だったら誰が作るんだよ!? 派遣が作らないなら社員が作るのか!? 社員に作る時間がないか派遣が作るんだろうが!!」

検査仕様書を作れないテスターなんてうちにはまったく要らない人材だよ、そんな要らない人材いくら支払ったかわかってんのか!?」

と大声で反論する。

プロマネ

派遣検査仕様書を作らない会社もあります・・・

言い訳しても

他所会社なんて知らねーよ!!うちの会社はうちのルールでやるのが当然だろうが!!」

と火に油を注いだだけだった。

検査仕様書なしに異論を唱えたプログラマー契約解除した理由をここで説明してみろ!!」

そんな追求をされているうちにプロマネをまったく明後日の方向の話を始めた。

「これはパワハラですよ。声が大きいかパワハラです。」

眼鏡の後ろから涙をボロボロ流しながら机を叩いた。

「これはパ!、(机を叩く)、ワ!、(机を叩く)、ハ!、(机を叩く)、ラ!、(机を叩く)」

そして猛ダッシュ会議室を出ていったが、引き止める者は誰もいなかった。

僕は呆れるのを通り越してこんな人間がうちの会社プロマネやって会社の信用を失墜させたのか、と思うと情けなくなった。

後日、プロマネ本社役員からパワハラを受けたと訴えたが相手にされず、懲戒免職となった。

プロマネとしての力量不足でプロジェクトを失敗させたなら懲戒免職なんてありえないが、彼の場合は社内規定にも顧客との契約にも故意に背き頑固に検査仕様書否定した結果、失敗させたのだから仕方がない。

普通なプロジェクトの建て直しでは(体調不良などで)プロマネがいないのは困るもんだが彼の場合特に困ることはなかった。

検査仕様書を作らなくていいと主張されるなら裁判所を通してください

プロジェクトメンバーは大幅に入れ替えるしかなった。

特に役員の言う通り、検査仕様書を作れないテスターなんてうちの会社では全く必要ない。

テスター派遣していた会社への説明はあっという間に終わった。

同席した役員が「検査仕様書を作れないなら支払いはできません。契約書の作業内容検査仕様書作成とあるのにやらなくていいと主張されるなら裁判所を通してください。」と言ったからだ。

派遣会社も彼のように「検査仕様書を作らせない派遣先もあるのですが・・・」と切り出したが「だったらそういう会社とだけ取引すればいいでしょう。うちは検査仕様書すら作れない会社とおつきあいする気はまったくありません。」と返されて終わった。

なぜ彼は頑固に検査仕様書否定したのか?

なぜ彼はプロジェクトをこれだけ大炎上させながら頑固に検査仕様書否定し続けたのか?

いくら彼と話をしてもまったく埒があかずわからなかった。

ただ、プロジェクトメンバーから彼がある女性派遣テスターと男女の関係にあったと聞いた。

彼女テスターといっても検査仕様書が作れないのでプロジェクト内での彼女存在正当化するために彼がおかしなことを言い始めたんじゃないかと噂されていた。

それが本当なら呆れるを通り越して同じ会社人間して情けないし、おぞましいとしか言いようがない。

もう彼と話すことは永遠にないだろうから真相はわからないが。

IT業界で「Excelスクショ」が無くならない理由

1.本番障害時の悪者探しに使う

「当時のテストはどうだったか」を調査するために使う。もちろんExcelで作られたテスト仕様書とセットである

2.客が受け入れ試験エビデンスとして使う

これは実際にいろんな客がやっている。SIゼネコンじゃなくてその先に居る発注者担当者が、受け入れ試験を「やったことにする」ために、SIerが納品したExcelスクリーンショット資料を流用するのだ。著作権は納品時点で発注者帰属するから流用しても法的には問題ない。なお増田外資系の客がこの行動をやっているのを目にしたことがあるので、国内ダメ事業会社情シスだけの傾向ではないようだ。

Excelスクショは客が求めるからやり続けられているわけであり、客の意識が変わらない限りこの文化は消えないだろう。

2020-10-07

マニュアル法律仕様書で「Yする」が義務を表すのはごく一般的日本語で、法律分野に限らない

「このボタンを押したら画面を更新する」とか、「営業日誌には、その日の天候を記録する」とか、「注文を受けたら、発送担当に連絡する」とか。

[][][]

https://b.hatena.ne.jp/entry/s/note.com/benli/n/n6f8968eb63ef

仕様書とか契約書に出てくる shall は must と同じかそれ以上に強い強制力を表す助動詞よね

に対して

https://b.hatena.ne.jp/entry/s/note.com/benli/n/n6f8968eb63ef

いいえそんな事全くありません。そのつもりで読む分には問題ないですがその認識仕様書を書くのだけはやめてください。

と。

そのつもりで読む分には問題ないですがその認識仕様書を書くのだけはやめて

仕様書はどう書かれるかも大事だが、どう読まれるかも等しく大事だと思う。書かれていることと読まれ理解する内容が一致するのが理想。だが「そのつもりで読む分には問題ないですがその認識仕様書を書くのだけはやめて」とある

google:仕様書 shall must

他の人はこちらも検索google:契約書 shall must 違い

https://www.businesslawyers.jp/practices/960

英文契約書における権利義務の定め方

 契約書は、当事者権利義務規定するものですから権利義務の定め方は契約作成における最も基本的な事項といえます

 英文契約書における権利義務の定め方には、一般的に、助動詞として、「must」や「can」ではなく、「shall」や「may」を用いるという特徴があります

義務を定める場合(shall)

 英文契約書において、義務を定める場合には一般的に「shall」が用いられます英文契約書を日本語に訳す場面では、「shall」を「~しなければならない」と訳すのが一般的です。

仕様書上記契約書だが)等を書く際の「作法」を言いたいのだろうか。shall-mustの表記ゆれをせず厳格にせよ、みたいな。

https://b.hatena.ne.jp/entry/s/note.com/benli/n/n6f8968eb63ef

契約書や仕様書のshallはmustと基本的には等しく、絶対的要求事項を表す。(超えるニュアンスは無いが)

こういうことが言いたいのだろうか。つまり超えるニュアンスは無い、と。

だとしたら「そのつもりで読む分には問題ないですが」ということはなく、多少なりとも問題ありそう。

2020-10-03

anond:20201003082451

コードが書けない奴を使ったテスターなんて

テスト仕様書に従ったあるいはランダム適当な手動テストしかできないだろ

ユニットテストコードやe2eテストコードが書けるとは思えない

手動テストしてエビデンススクショがいいところ

2020-10-02

anond:20201002005259

ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニア実装言語仕様書を読んでいるだけで、更にその仕様書半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学発明言語化しただけのものだ。

ベイエリアから流れてくる電波をキャッチするアンテナがあればよかった幸せ時代は終わってしまったということか・・・

事業が分かるエンジニアがいない

https://b.hatena.ne.jp/entry/s/www.timakin.com/posts/hacker-and-suits/

IT技術者のイメージ確立した頃のITというのは基本的技術収益性を決定していた。ビジネス人間からすれば「おかしなこと」で、普通に考えれば顧客が何を求めているか問題だ、という意識があったはずだ。

例えば、(フォードの速い馬車という意味ではなく)顧客ミント味のガムを求めていることが判明したとする。当然、ミント味のガムを製造すれば儲かる! のだが、ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニア実装言語仕様書を読んでいるだけで、更にその仕様書半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学発明言語化しただけのものだ。つまりITにおいては、顧客が何を言おうと、経営者が何を提供したくとも、カリフォルニア国立大学研究室学生が決めたルールに逆らうことは許されなかった(経営者的糖衣構文を使わずに言えば、実際に技術的に不可能)し、商業的に成功するプロジェクトとは「ルールの中で安価に実現可能もの」と「顧客が欲しているもの」の共通部分のみを的確に選んで提供することができたプロジェクトだけだった。「技術が分かる経営者」とは、現時点の最新のルールを深く把握し、損益にどう出るかイメージを掴みながら商品企画を選べる経営者だった。

ただ僕も不思議だったのは、3[他部署を巻きこみプロジェクトを推進できる]にいるエンジニアですら「事業がわかる」エンジニアとしての評価を得られないケースがあると言うことです。ユーザーにいいものを届けたいし努力をしているつもりだけど、膨大な負荷がかかっているし経営層は何もわかってくれないということで、奥歯を噛み締めながらその場を乗り切っている方は少なくないのかな、と思います

これはまさに「技術収益性を決定するのは、本来おかしなこと」という経営層の理解と、「現世で現実的可能かどうかが最優先」というエンジニア間の乖離ではないだろうか? 経営層は顧客価値提供して対価を受け取りたいのであり、学術的な努力目標を数多く達成したいわけでは、本来はないのだ。だから部署を巻き込んで膨大な負荷を受け止め新しい技術的知見を得ても、まったく意味がない。過去技術的な制約を解除することには大きな意味があった。今はそうでもない。高い技術それそのものによる金銭価値は少なくなったのだ。その結果、顧客が支払う金銭を最大化する製品設計価値は上昇したし、そもそもから低くはなかった。

そして、もちろん実行力も大事なのですが、彼らとの共通言語を持った上で会話ができる、具体的には採用方針を考えたりビジネスの状況を踏まえた塩梅での技術選定をしたり、さらには企業の将来像を共に議論するというある種の机上のフェーズですら、彼らは欲して止みません。それさえできれば多少の評価が得られるというのが、隠れた事実のように感じています(もちろん、それが良いとは言ってません)。視座が4にあるだけで相当な評価を得られるということですね。当然議論してるとしばらくしたら人事や社内管理事業ブラッシュアップ、営業など、全ての方面で駆けずり回ることにはなるのですが。

となると、自らのキャリアに集中したい、技術力への危機感がいい意味で強いエンジニアであればあるほど例の三大美徳に殉じた方が技術者として成長するし、それで評価を獲得できる会社転職するのが良い、となります。そして経営からしてもそういうタイプの人だと同じレイヤー議論をしてくれることへの期待値が高くないので、自然と「事業をわかって」くれないタイプだと見做して配置換えを行います。全てではないですが、こうした負の循環によって過剰にテックリードがいる組織が僕の頭にぼんやりかぶことがあります

「優れたエンジニアは汎用的な問題解決能力が高く、その能力を是非とも経営でも生かしてほしい。あとは興味を持ってくれる人がいるかどうかだけなんだ…」という意見経営層が漏らすパターンはこっち寄りです。そしてあくま個人の嗜好性の問題なので、解決難易度が非常に高く、共通解も存在しません。1つ目の問題のように配置換えで多少解決できることではありません。

以上のような理由から経営層はエンジニアにも「事業をわかって」欲しいと思いながら、その期待値を高く設定することができずにいるという印象を受けました。

まとめると、既存製品の改修にしろ製品企画しろ採用企業内の人員配置しろサプライヤや親会社との折衝にしろ、まず収益性KPIに選び、検討項目を洗い出し、貪欲裏付けを持って改善するエンジニア能力を活かしてほしいという話だ。顧客からの売り上げを最大化する商品企画ができないエンジニアが多い、それが要点だろう。この文章にはエンジニア経営者言語が疎通しない理由が詰まっている。話の要点を短くまとめていない。要点をまとめないことを要求している。要点を省いている。だから技術的な制約と戦うエンジニアには通じないのだ。正直に企業顧客からの売り上げで成り立っている。だからできれば商品企画の段階でも収益性第一企画進行が出来る奴が欲しい。そして社内外を問わずオジサンが求めているのは常に出会いだ。だから収益の話をグダグダ伸ばせること、酌ができることは必須だ」と言えばいいのだ。


昭和はそれで済んでいたはずだ。いつから日本語はこんなに空疎になった?

2020-09-30

追記あり任天堂を辞めてから5年以上が経った

追記はしないつもりでいた。

でも、ある1人だけにコメントを返させてもらう。

https://anond.hatelabo.jp/20201001022747

衝撃を受けた。

ここまであなたの心を傷つけるとは思ってもみなかった。

でも、あなたにだから正直に言わせてもらうけど、辞めたことは後悔していない。

5年以上が経ったとは言いつつ、もっともっと、かなり昔の話なので当時の感情を思い出すのは難しいけど、それでも転職という答えが幸せになるための道だったんだよ。

日記は2つともすべて読ませてもらった。

ありがとう。顔も知らないあなた幸せを願っています



新卒入社した。もうかなり昔のことだ。

文系学部出身で、事務職で応募して、もの凄く面倒くさいエントリーシートを書いて、何度かの面接の後に採用された。

企画部門への配属だった。生産管理希望していたけど通らなかった。

増田でこんなことを書いている以上は察してもらえると思うが、俺は失敗した側の人間だ。

任天堂は素晴らしい会社だ。世界に誇ることができる。でも、考えが甘かった。俺には適合しなかった。

気持ちの整理はついている。別に1万字とか書き殴るとかではないので、もし暇だったら読んでほしい。

大学3年の秋になって、いよいよ就職活動を始めることになって、大学フリースペース名前は忘れた。インターネットができる端末とか、調べものができる書棚が置いてある広い建物だった)で四季報を読みながら応募先を決めていた。

どこに応募するかを決めるにあたって、色々と考えた。

「将来、どういう人生を送りたいのか?」

人生優先順位仕事を何番目に持ってくる予定なのか?」

社会人になっても今の趣味を続けたい?」

そして、考えがまとまった。

ゆっくりしていて、まったりしている会社がいい」

趣味大事人間だった。おっさんと呼ばれる年になった今でも続けている。

そういう生活ができるのであれば、年収は低くてもよかった。

それで、四季報インターネットを見て、そういう雰囲気会社を見つけては説明会に申し込んだ。

なぜ、任天堂を選んだのかというと、上の条件を満たす可能性のある会社だと思ったからだ。実際にそんなことはなかったのだが。

後は、当時所属していた学際サークルの先輩が、任天堂に入りたいと豪語していたけど普通に落ちていたからだ。その先輩は、サークルの中でも指折りの実力者だった。

京都大学に現役で合格して、4年間の学生生活謳歌して、サークル活動では常に頼られていて、住友商事内定して、同志社大学サッカー部キャプテンが当時付き合っていたチアリーダーの子口説き落として、数年後には結婚して、今では新しい家のブランドを作る仕事をしている。

そんなレベル超人が一次面接でお祈りされるなんて、どんな会社なんだろうと思った。

俺が通っていたのは一流の大学ではなかったけど、それでも受けてみようと思った。

採用試験の内容は述べない。俺の体験談面白くないと思うし、年を経て記憶がだいぶ怪しくなっている。インターネットで、採用試験がどんなものかを紹介しているページがあるけど、まさにそんな感じだった。

書類選考勉強のできない人を落とした後で、『創造性』がありそうか?というのをつぶさに見る。



本題に入る。

俺はプロ世界を嘗めていた。仕事にかける情熱が同期と比べて明らかに低かった。社会人として生きる覚悟が足りていなかった。

いわゆるゲームプランナー見習いから始まった。

プランナーというのは、ファミコン時代マリオで例えると…土管はここに置くとか、空中のブロックをどこにするとか、1UPのキノコは右に流れるべきか左に流れるべきか、みたいなことを考える。

大体の会社ではそうだと思うが、新入社員に任される仕事は“形”や“答え”のあるものだ。俺が最初に任された仕事は、企画部門の中でも相当に定型的なものだった。

超すごい人達ゲームデザインをして、レベルの高い人たちが上記プランニングを済ませて、さあ開発だ!となる辺りの段階だ。

ぜんぜんダメだった。ダメ過ぎて上司や先輩に怒られ放題だった。お前情熱を感じねーんだよ、みたいなことをよく言われた。その度にムカついたけど、知能も知性も知識も足りなさすぎて、黙って耐えるのがやっとだった。

たぶん同期にも馬鹿にされていた。なんであんなのが入ってきたの?って言われていた可能性が俺の中では90%くらいある。

任天堂社員にはどんなイメージがある?キラキラしているイメージだろうか。

実際に見てみればわかる。総合商社とか銀行員とかコンサルとか、そういうのとは異なる人種だ。一応は製造業なので、見た目は大人しめな人が多い。

でも、中味は違う。元気があって、溌剌としていて、自分意見をはっきり言えて、他人意見を受け入れる力があって、何より頭がいい。俺みたいのもいるけど少数派だ。

2年目、3年目も同じような仕事内容だった。いわゆる“答え”のある仕事レベルの高い同期は本格的な企画仕事に進んでいた。みんなが知っているようなゲームタイトル制作会議20代若者が出て行って、父親くらいの年齢の社会人と侃々諤々の議論をしていた。

当時の俺は、今のよくない状況を肯定的に考えていた。むしろ喜んでいた。

なぜかって、このまま永遠に形のある仕事、答えのある仕事をしていれば、企画を出す仕事をしなくてもいいからだ。当時の俺は、自分アイデアが世の中に出ることに関心はなかった。ただ、毎日定時に帰って、それなりの額の給料をもらって、土日祝日趣味を楽しんで…そんな生活に満足していた。

毎年のように事務系の部署に異動希望を出して、「いつかは通るだろう。俺のような者を企画に置いておくはずがない」とアホみたいなことを考えていた。

地獄が訪れるのに時間はかからなかった。

先輩がひとり、またひとりと消えていき、気が付くと俺は中堅社員になっていた。ある年の4月、初めて企画らしい仕事を主担当として任されることになった。

実力が足りていなかった。あるゲーム操作画面や説明画面、設定画面なんかを手掛けることになった。今風の言葉で言うとユーザーインターフェースだ。

ゼロ状態から仕様書設計書を作るだけの力はなかった。それでも、今まで自分が作ってきたやつをツギハギして、どうにかしたつもりだった。

上司や先輩から、「ここわかりにくくない?俺はこっちの画面に行ってしまうよ」と言われても反論できなかった。自信がなかった。自信がないか上司を押し切ることができない。上司の方も、そんな奴の意見をそのまま通すことはできない。

それで悟った。これまで俺は、上の人たちが作ってくれたパーツを組み合わせてただけなんだって自分では何ひとつ創造していないんだって再確認させられた。

今までパズルをやっていたのだ。任天堂が作らないといけないのはパズルのものなのに。

結局、納期オーバーした。上司はそれでも俺を諦めることはなかった。最後まで作らせてくれた。もしこれを読んでいるあなた記憶の中に、あのゲーム操作画面はわかりにくかったというのがあれば俺のせいかもしれない。個人的謝罪する。

ゲームの開発が終わる頃に転職活動を始めた。

今度こそ、本気でゆっくりまったりしている会社を探そうと思った。地元である京都がいいなと思ったのでリクナビ登録したものの、ぜんぜんうまくいかなかった。

ゲーム会社からは100通以上のメッセージが来る一方で、志望していた機械メーカー化学メーカー事務職オファーは少なかった。応募しても書類選考で落とされる。15社に応募したけど、結局ぜんぶ書類選考で落ちた。

今ではわかる。中途採用なのに、事務職として必要経験が全くなかったのだ。部品調達はやったことがないし、社会保険手続きもできないし、法律に詳しいわけでもない。

もういい年だし、一流の大学を出ているわけでもない。

それから何か月もかけて、年収が低くてもいいので“ゆっくりまったり”を実現できるかもしれない会社を見つけた。どうやったらそこに入れるかを考え、情報収集をして、研究対策を重ねて、3度の試験の後に採用通知を受け取ることができた。転職活動を始めて1年後のことだった。

退職を告げた時の、上司や先輩からの引き止めの言葉を覚えている。

「せっかくモノになりかけてるのに」

ストレスに耐える力は一人前だからもっと時間をかけてみれば」

「あと1年だけでも働こうよ」

一言一句は合ってないが、おおよそこんな内容だった。手帳に書き留めていたから、そこまで違ってはいないだろう。

社交辞令なのか、それとも本気で言っているのか判断がつかなかった。

あの会社で働くだけの資質が俺にはなかった。創造的な仕事馬鹿にしていた。もうその時点でゲーム会社にいる資格はない。

あの頃の俺は会社を冒とくするだけでなく、一緒に働く仲間も含めて冒とくしていたのだ。子どもだったから気が付くことはなかった。



最後に、これを書くにあたってヤフー知恵袋などを読んでいたところ、任天堂に入りたい人の疑問が予想外に多かったので、その辺りも主観ベースちょっと書いてみる。

問.どんな人が内定を取れるのか?

答.ホームページ採用情報に書いてある。あれは美辞麗句ではなくて、本当にそういう人を欲しいと思っている。つまり、以下の要素を持っていると判断されれば採用される。

創造性な活動をしてきた

ゲームへの情熱がある

学習ができる(特に英語

 この3つが採用試験で見られるはずだ。

 ①の創造性は、学生時代の実績を見られる。例えば、学生時代部活をしていなくて、サークルに入っていなくて、でもゲームにのめり込んでいて~みたいな人は多分落ちる。

 面接で、学生時代の実績についてガッツリ聞かれるからだ。創造的な活動とはどんなことかと言うと、正直何でもいい。自分の考えがあって、主体的に動いて、それでいて周囲と協調ができていればどんな活動でもいい(結果がいいのに越したことはない)。

 自分場合は、大学生や専門学生だけでプロ歌手バンドを呼んでライブを実行する学際サークル活動していた。はっきりって端役だった。分かりやすい例でいうと…今季アニメの「やはり俺の青春ラブコメはまちがっている。完」で説明する。

 卒業生のためのプロパーティー実施することになって、ゆきのんが実行委員長で、いろはすイベント準備の統括的なポジションで、八幡が影の参謀みたいな役割だったと思う。

 俺がやっていたのは、いろはすの下で働く生徒達だ。会場のセットをしたり、参加者の受付をしたり、集客用のフライヤーを撒いたりするような、そういう下働きポジションで部分リーダーをしていた。

 創造性といってもこのぐらいでいい。自分の考えがあって、主体的に動くことができて、その過程他者を巻き込む経験をしていれば何でもいい。面接で何を聞かれても自分言葉で話せるはずだ。

 ただし、アピールは忘れないように。自分経験が100かなと思ったら、頑張って膨らませて500にする。それ程度なら問題ない。あなたが受ける会社だって、自社の魅力が100だとしたら1000にしてアピールしている。

 ②のゲームへの情熱言わずもがなだ。この業界は、ゲームへの熱い思いがないと生き残ることはできない。実際、俺は生き残れなかった。

 想像してほしい。新しい案を立ててプランを作っていかないといけないのに、何も思い浮かばずに席に座っているだけの自分を。それでいて時間は流れていく。もうすぐ打合せだ!となって、何が何でも間に合わせようとするも、会議で恥をかくために資料を作っているとしか思えない精神状態になる。

 そんな自分が嫌になって、ますます精神が追い詰められてうつ的な症状が出る。かつての俺だ。でも、情熱があればなんとかなることもある。情熱さえ生きていれば、アイデアが枯渇しても、他社や他人から少しだけパクッて、自分アイデアとつなぎ合わせるなどして窮地を乗り切れる。

 ゲーム業界に名を残すような人でも、ポンポンアイデアが湧いてきて、企画会議も余裕でプレゼンテーションをしているかといえば、そんなことはない。あの人達必死で藻掻いている。どんなに残業が少ない会社でも、社命が懸かった仕事に取り組んでいる人はとんでもない量の仕事をこなさないといけないし、土日祝日関係ない。

 夢というのは、一度叶えて終わりじゃない。死ぬまで叶え続けないといけない。

 あなたが志望する会社採用されて、志望するポジションになれたとする。「夢は叶った!めでたしめでたし」じゃない。

 例えば、ゲームを作る会社で働いている間は、健やかなる時も、病める時も、ずっとゲームのことを考えなければならない。止めた時点で、あなたの夢は終わったことになる。あなたにとってのゲームはそこまでの存在だったということだ。

 ③の学習ができるというのは、新しいことを能動的な姿勢で覚えていけるということだ。特に英語ができないと仕事で詰まることがある。事務系は英語の読み書きだけでなく、海外販売会社等と電話でやり取りしないといけない場面がそれなりにある。

 企画系だろうと、デザイン系だろうと、開発系だろうと、どの部門であっても「学習ができる」ことが必須だ。この業界は変化が早いので、去年まで使っていたソフトウェアが今年から全く新しい物に切り替わることもある。世間の変化に対応して、どんなゲームが人気になるのか、どんなゲーム社会の役に立つのか絶えずアンテナを張っている必要がある。なにより、他社がいいゲームを出してきたら研究しなければならない。他社のゲームプレイできるのではない。プレイしなければならないのだ。

 だから学習ができる人でないと務まらない。知らないことでも、興味のないことでも、やりたくないことでも取り組んで、知識技術を自らの血肉にする。そういう人を任天堂は(というかすべての会社は)求めている。



書き過ぎた。反省している。

今でも思うことがある。俺はあの会社感謝しているが、果たしてどこまで感謝しているのか?確信を持てずにいる。

時間が経てば、感謝以外の本当の気持ちがわかるのかもしれない。

ここまで読んでくれた人に感謝する。

まらなかったらごめんなさい。面白かったなら幸いです。

2020-09-19

他の民族、他の部族文化風習を、必要範囲理解妥協をする

ということと

話し合うということは同じではない。

話し合うというのは、日本代表的集団のやり方であり、

あるいみプログラム仕様書日本語で書け、英語で書くなみたいな話である

大切なことは、相手尊重し譲り合うことであって

話し合い、会議、打ち合わせという、事をすることではない。

普段会議仕事ではないプログラムしている時間仕事だと主張している

プログラマーらしくない。

 

我々にとって、お客様へのヒアリング重要ではあるが

作戦会議は、仕事の本流とは言い難い。

プログラム時間がメインの仕事であり、同業者での話し合いは副業である

 

この文化の違いが

揉めたんだろうなぁ

 

日本語を書いている時間仕事時間

というのは、そういう仕事もあるが・・・

まぁ、ごめんね。察して

2020-09-04

今すぐ俺野イマ・俺野ミライ差し替えろってことでいいの?

官僚に任せると時間かかりすぎるからキャラ設定だけ俺が今作っちまうからこれで仕様書速攻で出そうな。

俺野イマ俺野ミライ
暑い日にはパンイチ全裸に謎の技術自動モザイク
暑い日は水道水ガブ飲み好物は合成万能食5型
現代公営住宅に住んでる電子世界に住んでて本体の脳は国の管理下
働かずに暮らすことを望んでいる知能水準が低く労働権利を認められていない
平行世界自分を名乗る幻覚に悩まされている肉体を持つ権利の素晴らしさを伝えたい
地球環境については考えていない地球に生身で暮らせることに憧れしかない

2020-09-02

anond:20200902202859

いや、仕様書とか報告書基本的PCで書くんだけど。

それにこれからオンライン増えるし、チャットコミュニケーションもどんどん増えてる。

その中で作業速度遅いの気にならないのか?正直タイピングですら思考に対して遅いし、変換も面倒だからタイプじゃない入力ツールがあったら乗り換えたいくらいだから、ダラダラタイピングしてる人が理解できない。

2020-08-10

経歴書を書くのが苦手だ。

私は糞無能である。どれぐらい無能かというと

30歳で転職を5回実行したぐらいには無能である。(そのうち正社員は二つ)

もっと正確にいえば、パソコンタカタやっているのだが、派遣先から切られたことも多いので

多分会社を9社ぐらいを転々としている(概ね相手先都合で切られる)

そうなるたびに経歴書を書かねばいけないのだが

経歴書に書くことが何も思い浮かばないのである

もちろん世の中にはこういったものサンプルにはこと欠かさないのは知っている。

知っているが使い物にはならない

例えばネット検索して一番上の経歴書はこれである

------------------------------------------------------------------------------------------

20xx年xx月~現在 / 保険業界 営業支援システム開発 開発環境 規模

プロジェクト概要

保険業大手営業業務の実績、予算顧客などを一元管理する営業支援システムの開発をプロジェクト提案から実施

担当フェーズ

要件定義、基本設計、詳細設計結合テスト運用保守

業務内容】

クライアントへのヒアリング仕様書作成

営業支援システム設計、開発、導入、テスト

運用保守メンテナンス

【実績・取り組み】

・導入後も顧客へのヒアリング継続し、随時システム改善。また、改修を想定し、ソースコードを書き換えやすいように設計

言語

PHP

Java

OS

AIX

Windows

DB

SQL Server

Oracle

全xx名

リーダー

------------------------------------------------------------------------

こんな(私から見たらご大層)経歴は何も持っていない。

直近の作業も上から出された通りの設定を打ち込んでいくという作業だけである

誰か無能社員の経歴書の書き方とか増田でもNoteでもいいので書いてくれないか

私も知っていたら書くのだが、なにせやり方が知らないのだ。

2020-08-02

[]2020年7月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ



あとで読むタグの数は去年の水準に戻ったように見える。

AWSによるクラウド入門」が2つ入っているのは?s=09というパラメータが付いているのと付いていないとので割れたせい。

筋トレとか睡眠とか健康関連がちらほら。

2020-07-28

anond:20200728164253

それは仕様書内を固める方式で作ってないだけでは

2020-07-26

anond:20200726225552

フルスクラッチ仕様調べながらC言語でBMPからJpegへの変換プログラムは書けるけど給付金は無理な地方がある。すくなくとも、自治体の使っている日本語おかしいとかのレベル仕様書がしっかりしている産業界の規格書では比べられないとしても 一部自治体はひどすぎる。

それにたいして、がんばれ!という言葉をかけるとするとそりゃぁ、日本語間違えても気がつかねーはなぁ。誤字脱字。

複数の条件を満たした上での可能性の話を

勝手に条件絞った上に、確定の話に読み取って

それだけで上手くいくはずがない

とか反論してくるプログラマ

仕様書も書けないどころか読めない、当然プログラムバグだらけになる

非常に厳しいと言わざるを得ない

2020-07-21

anond:20200721203120

すみません、私もそうなんだけどね。やっぱり作り終わったあとに仕様書を書くとかくそだりーので逃げたことあります

ログイン ユーザー登録
ようこそ ゲスト さん