「仕様書」を含む日記 RSS

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

2018-06-14

コメントが欲しい場面

自分コードを書くとき

 

他人コードを読むとき

 

そんなかんじかなー?

コメント不要になっていく理由は、上記の裏返し?

各種ツール支援が充実して、コメント無しでも特に困らないなら、コメント無しでもOKと。

 

anond:20180614075256

2018-06-12

anond:20180612090821

では仕様書を作りましょう

からの追加オーダーは別料金となりますので、ここでしっかりとした仕様書を選定するのが大事です

ではまず、最も気になるであろう第三者視点から見た涙の形状ですけれども、弊社の方で事前にいくつかの案を(ry

2018-06-06

使われてるクラス仕様書ぐらいまとめやがれ

社内wiki存在せず上司聴くしか疑問点解決できないってなんやねんほんま。

コード見て動き理解しろって言われても限界あるよ…

2018-06-05

http://www.cocoamocchi.com/entry/project-bank-problemブコメの件

はてなってエンジニアが多いと思ってたけどNDAのことを知らないのが割りといて驚いている

秘密情報」は秘密保持契約書(NDA)の中で具体的に範囲が定められるので、契約書の文面を見ずにそんなことは秘密情報に当たらないとか外野は言えないんだが……

特定の社内向け仕様書を他社に開示する場合だと秘密情報は誰が見ても曖昧さのない範囲になることもあるけれど、要員の契約をするときに使うようなのは法務で用意している雛形そのままのことが多くいわゆる社外秘資料だけではなく財務状況とか業務内容まで秘密情報として挙げられているのが普通

Hに限らず、FでもIでも大して変わらない

もしかしてはてなに群がってるエンジニアってみんなサンデープログラマーなのか?ww

anond:20180605104643

SIerは、仕様書を書くのが設計ソース製造工程という思考から離れなれないから、ソース設計だというのが理解できない。

2018-06-04

ここもちろぐ

生産性志向SEが、IT業界での奮闘記や仕事生活で学んだことをはきだします。

 2018-05-15

みずほ銀行炎上プロジェクト支援に行ってきた話|問題

プロジェクト

gizeh-2272008_640

こんにちは。もちです。本日は、みずほ銀行プロジェクトで2か月限定支援に行った時のことを話したいと思います

あの頃は、ちょうどポケモンGOリリースされた時期でした。 プロジェクトのお昼休みに、わくわくしながらアプリを立ち上げて、メンバーの方と遊んだものです。

そんな次期システムが、いよいよ、2018年6月9日から徐々に移行開始されるそうです。

みずほ銀、9日からシステム移行 「世界最大級プロジェクト」 ATMネットバンク臨時休止日 (1/2)

みずほ銀行みずほ信託銀行は、入出金や口座管理などを担う勘定系システム統合した次期システムへの移行作業を9日から始める。4000億円超の資金を投じて進めてきた世界最大級プロジェクトが、最後のヤマ場を迎える。

www.itmedia.co.jp www.itmedia.co.jp

www.itmedia.co.jp

移行が発表されてから、「あの頃が懐かしい」と感じたため、せっかく浮かんだいろいろな想いを残そうと思って記事しました。

記事では問題点のみ扱い、

▼次記事で学んだことを記載します。

ここもちろぐ

ここもちろぐ

id:cocoamocchi

みずほ銀行炎上プロジェクト支援に行ってきた話|まなび編

みずほ銀行プロジェクトで2か月限定支援に行った時の話、まなび編です。 ▼前記事問題編はコチラ www.cocoamocchi.com 古参メンバー仕事を奪う デキる古参メンバーはとにかく忙しいです!! 新規参入者でもやり方さえ一度知れば、できそうな仕事もありそうだということで、積極的仕事を奪いにいきました。 たとえば…

2018-05-17 22:53

www.cocoamocchi.com

職場的に嫌だったこ

毎朝エレベータに長蛇の列

人気アトラクションかな?と思わせるほどの大行列タイミングが悪いと10分以上待たされました。

現場10Fくらいの階層だったので、階段も諦めました。。

スマホは鍵付きロッカーで集中管理

テストフェーズがちょうど一個上の段階に進んだためか、チーム内のスマホは鍵付きロッカーでしっかりと管理されるようになりました。

カバンも窓際に追いやられ、セキュリティ面が厳重でした。

荷物取りに行くだけで時間がかかりました。

インターネットが使えない

security-265130_640 これが一番厄介でした!!!

新入社員であれば、まずはググり力を鍛えろ!と先輩に教わるも方もいるのではないでしょうか。

わたしみたいなIT業界で働く方々は特にインターネットで調べまくる生き物です!

なのに使えないので厄介でした。

・・・はいっても、わたし場合は、こっそり休憩スペースにスマホを持ち出して調べてました。

他には、書籍にもお世話になりました。

ここで 「ネットが当たり前だと思うな、腕を磨こう」という教訓を得ました。

ありがとう執筆者の方々。

改めて書籍を生み出す方々に感謝です。

印刷用紙が真っ赤で読みづらすぎ

持ち出し抑止のために、プリンタ用紙が赤くなっておりました。

(特に持ち物チェックがあるわけではないので、悪意のある人なら持ち出せたかと思います。)

印刷してみるとまあ~わかりづらい。 気持ち的にもなんか落ち着かない。

でも一定の効果はきっとあったのだろう。。

残業前提の雰囲気

ただでさえ生産性の低い環境なのに、働き方もやっぱり残業ばかりされている方だらけでした。

特に既存メンバー古参者は大量に仕事を抱えているので、いつもヘトヘトです。

他の人へのレビューも、当然荒い。

また最終退館者名簿を見ると、お客さまサイドも負けずと毎日23時台まで残っているようでした。

※ちなみに

ごめんなさい、わたしは最長でも21時には帰りました!寝不足すぎると生産性ダダ下がり逆効果なので苦笑。

単体開発 バグ改修

私の場合、残念ながら新規開発部分は残ってなく、仕様取り込みやバグ改修をちょこっとやったくらいです。

開発ではなく、ほとんど仕様整理やJP1いじっている時間が多かったです。

命名規則がつらい

短い単語アルファベット1文字表現する文化があったため、それらをつなげて作成されるDBテーブル名やカラム名新規参入者にとってはしぬほど分かり辛かったです。

銀行システムなのに単体テストが荒い

1箇所の修正で5個もケースはないし、誰も見ないのではないかなというくらい、ゆるふわテスト結果が置いてあったりと、とてもじゃないけどもお金を扱うシステムだとは思いませんでした。

これ、結合テスト以降、バグ爆発するのでは?という印象だった。

今度、どなたか生き残った戦士に聞いてみたい。

構成管理がずたぼろ

the-1865639_640

ファイルサーバジャングル

階層がとにかく深く、無秩序に置かれた何千のフォルダ群はまさにジャングル

既存古参メンバーであったとしても、過去単体テスト仕様書の在り処を探すだけで10分以上かかっていました。

IDEなど開発に使用するツールも、各チーム持っている情報が異なっていて、結局、既存メンバーの持っているものを丸ごとコピーして使ってました。

テスト環境へのプログラム配置申請が3日ほどかかる

個々の期限がタイトにも関わらず、申請日時を厳守しなければならないのはつらかったです。

この申請は、数チームで1つのエクセルファイルにまとめて申請します。

プログラムファイル1つ1つのパス記載していくのですが、 誰かが1ファイル既述を誤るだけで、

申請した全チームのスケジュールが3日遅れます

どこぞやのチームのせいで2連続申請ミスされたこともあり、こちらとしてはたまったものではありませんでした。

しかしたら、誰かが休みたいがために、わざとミスしてるのではと疑いたくなるくらい大変でした。

まあ、とはいっても緊急リリースみたいな1~2日でできる裏技も時に使うことができたため、そこまでではなかったのかもしれません。

プロジェクトマネジメント

child-waving-goodbye-595429_640

メンバーが急に離脱する

うちの会社だけかもしれないけど、メンバー離脱が、作業指示を出しているチームリーダーまでなかなか届かない印象でした。

「来週からこの作業お願いするね」と言っていた矢先に、彼らがいなくなることを知らされる。

リーダーは大変です。多大なる無駄です。

作業工数ほとんど見積もられていない

これは、どこの炎上プロジェクトもですが、各タスクの期限だけ決まっていて、工数考慮されていない事案です。

この事案は仕方ない場面もありますので、メンバー側がリーダープロマネに少々寄り添って、自分仕事を考えていればOKです。

親切なプロジェクトじゃないのは分かっていることなので、他責にせず、ざっくりと工数を伝え、助けていきましょう。

新規参入者の実力が怪しい

少し言語知っている程度(for、if文はできるけど・・)で意思疎通の難しいプログラマー国籍わず、たくさんおりました。

猫の手も借りたいくらい忙しいプロジェクトだったので、自分主体的仕事を考え、動き、古参メンバーを助ける必要があります

しかし、

古参メンバーに何から何まですべて聞く

進捗が良くないことをごまかす

理解できていない部分をごまかす

よく分からないけど、なにかやばい

など、この中のどれか1つ該当ではなく、複数持ちのプロジェクトキラーが何人かいました。

特に進捗ごまかす人はひどかった。

他の人も急に想定外残業フォローをしなければならなくなるし、本人は無駄に悩み続ける時間増えるし、誰も幸せにならない感じでした。

まとめ

炎上プロジェクトには人的問題がつきものです。

特に銀行プロジェクトは、生産性の低い現場やずたぼろな構成管理など、環境問題も多いことがわかりました。

同時に他責にせず、主体的に行動すれば、新規参入者でもそれなりに活躍できることもわかりました。

しかし、わたし場合、2か月限定が配属前から決まっていたこともあり、

心までしんどくならずになんとか戦えたことが大きいかもしれません。

正直、炎上案件には参画したくない笑。

もし炎上案件出会っても、 心や身体をやられるようなことがあれば即刻辞退をおすすめします。

残業による残業という負のスパイラルが、もし嫌なら、早く抜け出すほうがこれから人生豊かです!

断言できます!!

一時的な損はあるかもしれませんが、長い人生においてそんなもの一瞬です。 ではでは、良き人生を!

2018-05-26

anond:20180525061819

最初にかっちりした設計書なり仕様書なりを仕上げればいいだけな気がするんだが...なぜそうしないんだろう?

2018-05-23

働く才能がないのでもう人生ダメかもしれない

・私について

20代後半 プログラマ

SES会社所属現在現場は2ヶ月目

資格 応用情報技術者

・悩み事

私は人並みの速度で作業することが、困難ということを確信しつつある。

今まで、数年経てば慣れてできるようになると自分に言い聞かせてきた。

しかし、たとえば、テストデータを作るのに工数に対して約2倍かかってしまうのだ。

作業のものは独力で遂行可能な内容だ。

1.基本設計と詳細設計インプットとする。

2.1をもとに画面遷移を網羅する引数テーブルデータ、想定結果、画面表示項目の表示をテスト仕様書記載する。

だが、「あのテストデータをどこと整合性合わせるんだっけ」「よくよく見たらテストパターンとして成立していなかった」という事象が発生する。

普通の人はうまくできているようなので、

私には普通の人に備わっているほどの記憶力が備わっていないのだと思う。

から不器用で、手を動かすアルバイトをしていたときに遅くて叱られていた覚えがある。

私は現代社会で働くことがやはりできないのかもしれない。

2018-05-15

仕様書企画書)を作れといわれた

初めてなので、全然からない。

サポート事務で、新しいことを提案(?)しようと思ってるんだけど

どういう事を書くべきなの?

プレゼン的に資料をまとめるとしたら

・現状の困りごと

解決策(今回の企画内容)

デメリット

メリット

・それらにかかる費用

・さぁどうする!

ってことになるんだろうけど、これじゃ浅いかな。

2018-05-11

PGになれば人付き合いとはオサラバ

そう信じていた。

全然違ったね。

仕様書解釈を巡っての調整業務はあるし、まともな仕事貰うためにはどうしても人脈が必要になる。

ときにはグっと堪えなきゃいけない事も多いし、逆に気を遣われすぎて疲れてしまうこともある。

勉強会をやるには仲間がいるし、1人で勉強するつもりでも他の開発者質問を投げかけるしかなくなる時だってある。

人付き合いだ。

どこまでも人付き合いだ。

逃げ切れない。

逃げ切れなかった。

人間は1人で生きていけるのかも知れないが、その生き方が出来る人種リストPGは入っていない。

2018-05-06

IT業界人手不足職場会社に対する所感

・本当に人が足りない会社はある

・人が足りないからと言って技術者労働者)が大切に扱われる事はまずない

人手不足会社職場旧態依然のままな事が多い

・実情を知らずに毎年、新卒新人が迷い込んでくるせいで潰れるほど深刻な会社は少ない

・実情を知らずに毎年、新卒新人が迷い込んでくるせいで潰れるほど深刻な職場も少ない

web業界は優秀な技術者が不足している・SI業界奴隷が不足している

人手不足現場で学べることはプログラミング以外、今いる会社職場限定技術である事が多い

人手不足現場で学べることはプログラミング以外、今いる会社職場限定知識である事が多い

人手不足現場で学べることはプログラミング以外、今いる会社職場限定価値観である事が多い

効率の悪さを技術者労働者)の努力カバーしている会社が多い

ミスを人のせいにしてシステムを見直さな

・不便な自社システムの素晴らしさを語る管理職おっさんがいる

業務ツールの使い勝手が異様に悪い職場が多い

業務量が多いわりに新卒だろうと短期で成果を求める会社職場が多い

名目上やる事は1つでも実際は雑用含めて50以上の業務を同時進行させてる現場が多い

・忙しさを美徳としている人が多い

・謎の社畜自慢をする人がいる(有給なんて未消化のまま消滅して当たり前だぜ)

Windows XPが当たり前のように存在する

Windows 2000が当たり前のように存在する

COBOLが現役

・分厚い紙の仕様書も現役

・目を通す必要のある1日のメールが100を超える時もある

SlackGit?なにそれ

息を吐くように暴言を吐きだす上司存在する

・気に入らないことをされると間違ってなくても怒る上司存在する

フレックス制を導入している事が多い(コアタイム9時~18時など)

有給を取ろうとすると怒られる

休日出勤はいなかった事にされる

就労に対する不満を口にすると村八分ならぬ職場八分もしくは社八分になる

自分が社内・職場内で最年少

技術者労働者)に対する社内での行動制限人権無視している

・なぜか技術者労働者)の扱いが雑、客や営業から高圧的な態度を取られる事が多い

転職しようとすると実務経験に難色を示される事が多い

・1日の生活サイクルが出社・退社・就寝になる事が多い

仕事以外の事をする余裕がない環境に置かれる

働き方改革?なにそれ

残業抑制?なにそれ

技術者待遇改善?うるせーな黙って働け

自己都合で優秀な人がどんどん辞めていく

・どんなに優秀でも辞めたら会社裏切り者あつかい

・40万を超える給与を貰える人が社員数の割にごく少数(社長幹部を除く100人中8人とか)

求人票や求人情報に掲載される待遇誇大広告

ベンチャー自称

2018-04-25

上司が俺に指示を出すとき

たとえば画面のレイアウトを変更しろというときに、俺の隣に座って紙にレイアウトを書き出す。

「ここはこうして、こっちはこうして」としゃべりながら。

で、途中で「いややっぱりここは、こうしたほうが分かりやすいかな」とか考えだしたりする。

これって「いろいろ考えてる俺ってかっこいいだろ」アピールなのかな。

きっちり仕様書とか書けとまでは言わないけど、ドローツールでも適当に書いて、できてから渡してくれたら一瞬で済むのにと思うわ。

目上の人間に、特に考えもまとめないで説明しだして、途中で「これはどうしようか」とかやってたら「お前考えをまとめてから来いよ」って言われるよな。

2018-04-20

sierとかちょれえわ そう思ってました

うーん。

ちょろくはないな。

知識経験もいらなくて、人から聞いた話を右から左に流しつつ、書類にハンコ押したり押してもらったりしつつ、たまーに仕様書とかのてにをは弄るだけでいいから、正直内容自体ペラペラなんだが、ちょろくはないな。

なんつうか、能力を使わんかわりにストレス耐性を消費していく感じだ。

正直、営業マンポジション的に大差ないし、理系文系なら全力で文系よりで、なんで理系から人引っ張ってきてコミュ障引き入れたりしちゃうのか理解不能

ぶっちゃけ代理店専門業みたいなもんだから存在価値のものが限りなく低い。

責任転嫁先となって、利害がぶつかりあったときに真ん中で土下座して怒りを収めるのがメインの仕事な気がする。

でも同時に、俺らがちょこちょこ理解度の低さから頓珍漢なことすることで関係者ストレスマッハになってたりするから総合的にはやっぱいらねーなと。

お金持ちが中間搾取仕掛けるための中継地点として用意されている実態のあるペーパーカンパニーみたいなもんなんじゃないかな。

トカゲの尻尾切りするためのジョイント部でもある。

ちょろいけどつらいわ。

仕事内容はつらいだけで中身がないかスキルも身につかないのが特につらい。

いる意味のない歯車からなあ。

トマソン廊下に挟まってるようなもんだ。

虚無。邪魔不要

工事現場安全おじさんもそうだけど、俺達みたいな存在価値のない立場人間を生み出して責任をそこに押し付けるのが最適解になるような法律業界ルール作らんで欲しいのよね。


寄生虫より

仕様書を書くためには実務の経験必要とすべき

実際にその工程で何をやるのかを自分経験として知らん人間仕様書を書いてることが多すぎるように思う。

「こういう風な機能実装してください。 工数このぐらい」と書いてる人間が、実際にその機能実装するにはどういう作業を積み重ねるのか、それにはそれぞれの作業にどれぐらいの手間がかかるのか、それらを正確に把握してないで、「相場がこれぐらいでしょ?」「どういう方法で?俺らが欲しいのは実際の機能であって、仕組みはどうでもいいよ」と仕様を出されてもお互いに不幸になるだけではないだろうか。

よくある笑い話としては「家のリフォームにおいて顧客ニーズに全て答えれば違法建築物の出来上がり」といった物があるが、まさにそのとおりだ。

世の中には、自分要求の中身がどういった意味を持つのかを分かってないままに仕様書を出す人間がたくさんおり、そういう人間今日もどこかで、妄想力逞しい謎の仕様が積み上げているのだ。

これでは童貞が「女のイカせかたマニュアル」を書くのと何も変わらん。

もうここまで来たら国が法律規制すべきだろう。

何の実務経験もない人間仕様書を書くべきではない。

何も知らない人間は既成品だけを購入すべきだし、実際、既成品で十分なのにわざわざオリジナルを求めてはLose-Loseの関係を築き上げたがる顧客の物凄く多いことには頭を悩ませる。

学校教育で既成品の素晴らしさを教えるべきだ。

2018-04-04

まりにもクソな客先常駐で厳しい

大企業A社の業務をA社のグループ会社B社が請け負い、それをB社から請負業務として受注して働いてる。

これが非常に厳しい。

まずPCスペックがひどい、Celeron B810にメモリ2GBのノートPCでもちろん画面解像度は1366x768で仕事をしている。

一応デュアルモニターではあるが、これは他部署の廃品を回収して設置したものでなんとスクエアだ。

次に仕様書がろくに手に入らない。

最新仕様書タスクはJIRAで管理されてるようだがもちろんアクセス権限など無い。

そのためB社に頼んでJIRAからExcelファイルデータを落としてきてもらって、共有サーバーに置いてもらう方法でなんとか解決している。

無論JIRAの更新を知るすべはないので、既知の問題をそうだとは知らずに必死に解析して無駄時間を過ごしたりもしている。

さらに、使用できる機材が古い。

とある規格に通信波形が準拠しているか調べなければいけない業務で、使用できるオシロ校正もされていない15年前のものだとは思わなかった。

こんなもの大丈夫なのだろうか、と思っていたら別会社が同一業務をまともな機材で実施しておりこちらで測定したデータは破棄された。


まともな環境であれば今の3割以下の労働時間で同等レベルの成果を出せると確信しているが、PCを購入したりJIRAへのアクセス権限を渡すよりは人件費として年間数百万円を湯水のように使うほうがいいらしい。

2018-04-02

変数ローマ字ホントやめてほしい

新しい案件に入るたびに思うこと

変数ローマ字を使うのをやめてほしい

MENSEKIとかCHOUSEIKINとかYOTEIHIDUKEとか読みづらすぎる

英語だと人によって違うから仕様書言葉をそのまま使うのはわかる

だが、ローマ字は読みづらすぎる


特に長い単語区切りがわかりづらすぎる

KAIINGENTEITOKUBETSURYOUKINとか何度見かしてやっと「ああ、会員限定特別料金のことね」ってなる

こういうので間がちょっとだけ違う似てる単語があるとミスしないとは言えない

いや短くても「HANIUE」が「範囲(上)」なんて脳内変換できなかったな


他には書いた人が漢字読めないと間違った読みになってたりする

HUKUREKI (履歴) とか GAIZON (既存) とかそういうこと


あとはカタカナ語英語でその他が日本語になってる

ただし、カタカナ語でも書いた人が英単語にできなかったものカタカナ

NETTOGUROSU」が「ネットグロス」になってる

net を gross へ変更するメソッドかと思う名前


言い出すとキリがないのでこの辺にして、自分が初期構築するなら日本語そのまま使おうと思った

2018-03-30

anond:20180330203321

そうかあー、それでマニュアル作れってことね。

現状意味不明システムなんでマニュアルないと使えないというなら仕方ない。

できれば利便性考慮して作り直して欲しいけど予算もないしって感じかな。

ただ、そのマニュアルを書くための仕様書ってのは。。。何書けばいいんだろう?想像できない

anond:20180330143930

もうこういう突っ込みしたくないんだけど、仕様書から納品までこぎつけた成果物がそこにあるんだから、使い方はマニュアルどうのこうのを抜きにしても理解できてなきゃおかしいよな?

マニュアルを読んで操作できなかったのはどこの誰だ? それは受け入れを行った人とは別人なのか?

anond:20180330141749

そう。

そんな物はいらない、マニュアルがどうあるべきかなんて常識だろ、と思ってたんだけど、渡されたものがあまりにひどかったので、もうこれはマニュアル仕様書必要事態だったのかも、と。

そうじゃないと、こっちからマニュアルについて文句言っても、仕様書に何をどこまで書くとの記載がない、って言われて逃げられる危険性があるから

ウェブ系の制作業務

本体ではなくマニュアル仕様書ってどうやって書くんだろう(書けばよかったんだろう)。

使い物にならない、読んでもさっぱりわからなくてまともに操作できないマニュアルが納品されてきた時、どういう交渉可能なんだろうか。

仕様書にない、とか、弊社のマニュアルはこういう形式から、とか言ってくるに決まってるからなあ。

anond:20180330133928

COBOLコーディングしてたけど、コーディング用紙に鉛筆コードを書いてた。

それをパンチャーの業者にだしてた。

仕様書鉛筆で書いてたな。

ワープロを導入しようって話が持ち上がったときに、ベテランが「仕事が増える」と猛反対してお流れになったこともあった。

ワープロを使ったことがあったら手書きより何倍も効率がよくて楽だとわかりそうだけど、ワープロは清書用という思い込みで正常な判断できなかったんだろうな。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん