  |
はてなキーワード:結合テストとは
未だに結合テスト、システムテストの工程ではEXCELの仕様書を元にパソコンまたはスマホで手打鍵してスクショを取ってペタペタ貼り付けるプロセスが主流
一時期は自動化の流れがあったが、ここ数年で明らかに後退した。セキュリティ要求が高くなり、それとテスト自動化は相性が悪いからだ
まあbot対策仕込んでるのに自動テストツールが動いたらそのbot対策は無能確定なので仕方がないのだが
それとスマホ認証の世界で最近普及してるFIDO認証、あれもテスト自動化の敵だ。FIDOを入れたシステムにはログインすら出来ないからテストが成り立たない。外してテストする手もあるが、二要素認証が必要な機能のテストには向かない、というかテストが成り立たない
セキュリティ強化を進めるのは良いが、その結果「手作業でスクショペタペタ」という忌まわしい作業が増えてしまうというのはもっと知られるべき
あと、ロゴとかデザインを決めさせて服とか看板で出す場合、商標権や意匠権の問題があって、京アニ事件の青葉被告レベルの妄言でも普通に認められる。
VisualStudio2022のai補完機能みたいに自分が書いたコードから学習しました。
今まで○○な修正をしていて次も同じことやってそうなので、確認を取ったうえで実際にやる程度なら、問題にはならない。
単体テストや結合テストの生成もノウハウはあるけど、特許が絡んでなければ、aiを使ったところで問題にはならん。
ただ、ここらへんは自然言語でコーティングしたのをaiが特定の言語に変換してるだけなので人間が書いたほうが今の所は圧倒的に速いけどな。
今のシステムは夫婦の苗字が一緒であることが大前提でシステムが動いている……今その現場に俺はいる……
いろんなことが「夫婦は苗字一緒だよね？一緒なら夫婦ってこことだね！」で動いている…。「子供の名前も夫婦と一緒だよね！」「夫婦である判定は姓が一緒かどうか！」って審査もたくさんある……今から確認することすら想像しただけで血涙を流しそう。
それが別姓OKになったら…う、うううおおおおおおおおおおおおおおおおおあおあああああああああああああああああああああああああああああああああああああああああああああ！！！！！！！終わりだ終わり！現場は血反吐を吐いて終わる。最低10年くらいは開発期間欲しい。10年は誇張している。そんくらい終わる。夫婦別姓派推進の人が総理になったらとここ最近部署が重い。みんな「これが「1、2年でよろ！」なんていわれたらウケるね」と渇いた笑いをしている。今日も「夫婦別姓推進の人がトップになったらどうしよう」と出社早々話してた。あんな温厚で、親バカで暴言なんか吐かないマジ優しくてしっかりしていた部長も「やばいね！！」というだけのbotと化している。壊れちゃった。
ただでさえ振り仮名つけるだけでもこんな地獄と化しているのに…？！え？！夫婦別姓も？！？！？！？！？？！１１？！？！？！人もあと50000人くらいいないと死にますが！？？！？結合テスト誰作るんです？！！振り仮名でこの量なんですけど、倍以上はゆうにありますよね！？？！！！！で、誰がそれをやるんですか？！？！？え？！2、3人で？！？！？人員と給料100倍にしろ！！！！「それが仕事だろ」と言われそうだがそういう話じゃない！限度！限度がアンの！仕事ってのは「この量・仕事内容ならこの給料、うん！それで満足！」ってなる場合だ！！！！夫婦別姓のシステムにしてね！あ、期日は1、2年くらいで給料変わらず！よろしく！なんてアホか！！！！！！！！だいたい振り仮名のやつもおせーんだよ！！！！！！！！！！！なんで？！要件が8割くらい時間持って行くから結局テストが0.5くらいしか時間ねーじゃねーか！！いつもそうだよ！！！最初に提示した「テストは最低4は欲しいですね」が4ですらねぇ！！！それで「間違いだらけですよ？ちゃんとテストしたんですか」なんて言うなや！！！！！！時間ねーんだよ！！！！っつてんだろ！！！！！！！
●省、てめーだよてめー！！！絶対現場知らんだろ！知ってたらそんな期日と要件にせんわ！！！！！！！！！！！！！！！！現場にこい！！！！！！！！！
じゃあ開発10年でいいよって言われたら…まぁ…いいか…開発＜だけ＞で10年なら……
こんな感じでデかいことが期日短めで来なきゃめっちゃ楽しい仕事なんだが、機能の根本から変わる仕事の場合、何故か●省は普段と同じ感じで仕事を振ってくる…なぜ…なぜ……規模が……違う……だろ……どうして……君らも地獄なのはわかっている……霞が関の忙しさは比じゃない……だが……こっちもな、違う地獄でな……いや、もしかして●省君はずっと期日を適切に設定しているけど、現場にはそれが行き届いていないとかか…？やはり下請けシステムがカスということか…？それならすまん……でもな……ずっとこうなんだ………
夫婦別姓に「名前変更手続きしなくて楽だね！」くらいで賛同しているやつが一番腹立つな。どうして今、同姓にするシステムなのかよく考えてくれ……夫婦（家庭）守るためなんだよ……同姓で良いじゃん……苗字だけでアイデンティティ保つの危なすぎるからもっと世界と人生を楽しんだほうがええで……振り仮名つける方が5000倍くらい意味ある。
ちなみに男女以外の性別を増やした場合・同性婚も同じくらい現場は終わります。どう転んでも終わるのでは？そうしたら同時に皆さんのインフラは終わります。慈善活動ではないんでね。さようなら。
IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。
SESを脱退し、そこそこ大手のIT企業の正社員になれた。しかし、そこはこれまでのSESで客先常駐していたような企業とは違い、あまり体制的には良くはなかった。
工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。
1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。
工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計、実装/単体テスト、結合テスト、総合テスト、などのサブ番号に分割して、工数を登録することである。
さらにセキュリティ教育などは個々の案件と無関係なことが多いので、維持管理用の工数番号が振られていることもある。
リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。
さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業したかを15分単位などで記載する。
工数管理のいいところは、作業をサボりにくくなることだ。作業効率が客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。
工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベルで工数を消費する。あとトイレなどにつける工数などもない。
しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。
その形式上すら煩わしいらしく、若手の意見をバリバリ言う人から、
・工数管理は全く意味がない。適当な工数を入力していても誰もチェックしていないのか、何も言ってこない。
・工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システムは不要である。工数管理システムと勤怠システムを一本化すべきだ。
などの意見が出ていた。
そりゃあ工数管理が根付いてない企業に工数管理を行えばそうなるでしょう。
工数管理は業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。
結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。
つまり、当社はよく言えば従業員の意見が通りやすい、悪く言えば従業員のわがままが通ってしまう企業なのだ。
従業員の意見を尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務は改善できない。
これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。
工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員のわがままが通ってしまうのだ。
(まあ当社の工数管理はテキトーだからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的に業務は改善していたと思うが。)
PDCAはPlan, Do, Check,Actionの頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。
実行した後は必ず振り返り(Check)を行いなさい。
当社もPDCAの概念はあるし、週報という形でそれを実現している。
しかしその概念は根付いておらず、週報以外ではPDCAは無視している。
つまり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。
振り返りも当然実施しない。実行のみがある。Do, Do, Doである。
これは作業者レベルでそうであるし、案件レベルでもそうだ。案件はたしかに最後には振り返りの資料を作成する必要がある。しかし、これは単に作成しなきゃいけないから作成してるだけで、綺麗事をまとめた振り返りである。
本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去をグダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽な対策が記載される。
当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。
私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの？」と詰められて終わりだ。指摘するなら十分な資料の作成と具体的な対応策の準備、そして責任と人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。
と書かれていた。
本来は、業務改善は個々のチームだけの問題ではないので、上層部でマニュアル化してルール化すべきではないのか？
アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか？
それをなぜ、個々のチームに依頼する？
業務改善といえばマニュアルの作成や設計書フォーマットの作成だ。
それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである。
しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。
フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。
当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。
これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者に相談しやすくもなる。
こういった業務改善は本来は上層部が率先して枠組みを作るべきだ。しかしやらない。
上層部に知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。
当社はとにかく従業員の声が大きい。強い。
業務改善などの施策を出しても、従業員が納得しないと続かない。
そういう文化を変えるのは並大抵のことでは出来ない。
環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。
仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。
仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。
2024/05/1510:48
工数管理すべきなのは、成果物ではなくサービスを提供する人なのかもしれない。例えばPMなど。
当社の開発チームは、開発者やPM以外にも、君必要なの？何やってる人なの？打ち合わせには参加してるけど、ただの工数食い虫じゃね？みたいな人もいるのです。
学歴がよくなくて、就職が困難だったので中小SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力してもAtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) →PM (御用聞き) →プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果のWBS に合わせないと、顧客からDM で瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していないWBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事がDM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて24/365 で停止しないWebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事でmalloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊なPCI Express のカードからベンダーが用意しているSDK でデータ引っこ抜いてWebAPI へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。SQL を直書きするのはシンドイ。
結局SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外はフレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript でPrisma 使うのが、型安全でよさそうだなと思っている。
デプロイをEC2 直でやったりECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング,Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今はGithub Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由でAzure Pipelines でCI/CDフローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline がGUIからしか設定できないのが辛みだった。
これを知らずに、コンソールでポチポチしていたので、IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
念願叶ってプログラマとして生計を立てるようになって、はや8ヶ月。
アラフォーでの思い切ったキャリアチェンジを後悔したことはないし、毎日楽しいことの連続だけれど、俺はいまプログラマとしての伸び悩みを猛烈に実感している。
具体的には、オブジェクト指向とかデザインパターンとか単体・結合テストとか適切なエラーハンドリングとかアルゴリズムとか、納品物としてプログラムに一定の品質を担保するスキルが圧倒的に不足している気がする。
一応日々勉強はしているものの、納期に追われているとどうしても手癖でコードを書くようになってしまうし、社内にコードレビューの文化がまだ根付いていないので添削してもらう機会もなく、なかなかスキルが身に付いていかない。
プログラマのみんなはどこでそういった知識を得て、どうコードに活かすのだろう？
とにかく毎日書きまくって手癖を克服あるいはブラッシュアップして、あとはコードレビューしてもらえるように社内環境を整えるしかないんだろうか。
30歳で転職を5回実行したぐらいには無能である。（そのうち正社員は二つ）
もっと正確にいえば、パソコンカタカタやっているのだが、派遣先から切られたことも多いので
多分会社を9社ぐらいを転々としている（概ね相手先都合で切られる）
そうなるたびに経歴書を書かねばいけないのだが
もちろん世の中にはこういったもののサンプルにはこと欠かさないのは知っている。
知っているが使い物にはならない
------------------------------------------------------------------------------------------
20xx年xx月～現在 ／ 保険業界 営業支援システム開発 開発環境 規模
保険業界大手の営業業務の実績、予算、顧客などを一元管理する営業支援システムの開発をプロジェクト提案から実施。
【業務内容】
【実績・取り組み】
・導入後も顧客へのヒアリングを継続し、随時システムを改善。また、改修を想定し、ソースコードを書き換えやすいように設計。
【言語】
【OS】
【DB】
全xx名
------------------------------------------------------------------------
こんな（私から見たらご大層）経歴は何も持っていない。
直近の作業も上から出された通りの設定を打ち込んでいくという作業だけである。
誰か無能な社員の経歴書の書き方とか増田でもNoteでもいいので書いてくれないか
私も知っていたら書くのだが、なにせやり方が知らないのだ。
今朝、某ブックマークサイトにて大手SIerにおけるクソ設計書について少しばかり話題が盛り上がった。
SIerのシステム開発方法や、所謂「炎上案件」というのは具体的にどういうことなのか、できる限り思い出して書いてみたいと思う。
所属したプロジェクトは3件で、1つ前に所属したプロジェクトはコロナ騒動の直前の2020年1月である。
これを読んでいる人の中には、私よりも玄人なSE、もしくはPMがいるかもしれない。
手持ちのサンプルが少ない故に「ちげーよ！」ということもあるかもしれないが、そこは大目に見ていただけると幸いだ。
まず、ITに携わるシステム屋とはいえ、SIerとベンチャーWeb系は規模と客層も違うし、開発手法も違うと思われる。
開発手法というのは、「ウォーターフォール（各工程を最初から着実に終わらせる手法）」、「アジャイル（短い機能追加を繰り返していく手法）」が一般的にも有名だと思う。
開発手法には「ウォーターフォール」のさらに上の「メテオフォール」というのがある。本気の炎上、アジャイルのようにウォーターフォールする開発という意味だ。
（何を言っているのかわからないかもしれないが、私も何を言ってるのかわからない。https://eiki.hatenablog.jp/entry/meteo_fall）
多重下請けに所属しているSEが「メテオフォール」をかけられたら、もう刃傷沙汰にでもならないと逃げられないと思っていい。
炎上案件のSIerの客層は、金融系・公共インフラ系がほとんどだ、7割そうだろう。（※適当）
自社開発系はさておき、受託Web系やパッケージベンダ系の客層は、小規模案件のプロジェクトもある程度あると思う。
金融・公共インフラ系はべらぼうに規模がデカい。馬鹿みたいな工数が掛かる。
【要件定義 ＋設計開発UT＋結合テスト＋システムテスト＋ユーザー受け入れテスト＋システム移行】 ＋追加要件開発（保守運用）。
大雑把に言うと、「ちょっと顧客情報DBを参照してWebに表示させるシステムが欲しい」として受注した場合、約4000万円がお会計となる。
現行システムのリプレイスだとしても、2000～3000万円はかかる。高い（※謎仕様の現行システムだと炎上不可避案件となりさらに膨れ上がる）
当然、数千万円案件となるとプロパーの社員では人手が足らなくなる。
すると登場するのが「派遣社員（SES）」あるいは「下請け」というシステムだ。
会社によって異なるが、だいたい4～9割が「派遣」や「下請け」の割合となっている。
それでも工数不足になってしまったプロジェクトは、そこから鬼出勤をカマす。
納期を過ぎたらさあ大変、開発経費・損害賠償がSIerの自腹になってしまう。
それで最初に書いた「ウォーターフォール」ってのは何なのか？ってことになる。
「ウォーターフォール」＝「各工程（要件定義、設計、テスト）で客の承認を得て合意を握った上で着実にマイルストーンを固めていく」
「何のために固めるのか？」＝「手戻りを起こさないため（白目）、責任を押し付けられないようにするために」
と、ここまで前置きを書いて疲れてしまったので、続く。
駄文失礼。
エンジニアをしているが、
テスト仕様書を書きますねって言ってくれるディレクターがいる。
インフラからアプリケーションまで一人でやっているからか、自分の仕事を奪われたようでちょっと悔しくなった。
これではシステム屋ではなくて、ただのプログラマーでは無いか…。
そこまで手が回らないって情けなくなってしまう。
ただ、
ディレクターがやってくれるのはあくまで総合テストの事であって、
それに、時間がないから「実際に使ってみて変な所があったら教えて？」
って言うつもりだったのを前もって準備してくれるのだから想定どおりでありがたいこと。
自分だって、ディレクターをした時は、エンジニアの為に色々補助や書類周りの作成してたっけ…。
素直にありがとうって言ってもいいよね。
設計書を読んでプログラムを書くにも、その設計の前提知識の理解がないと進まない
たしかにその期間で業務仕様はある程度頭に入った、けれど理解には程遠い
その後は自分の担当機能の実装に必要な知識を、その場その場で掻き集めるといった感じ、全体の仕様理解なんてカケラもできない
その後の結合テスト、システムテスト、ユーザーテストの補佐、そしてリリース後の運用フォローときて、ようやく何を使っていたか、業務仕様の全体像を想像する程度にはなった
1年と少しかかった
振り返って思う
近々の自分の仕事に関わらない情報は説明されても頭にとどめて置くのは難しい
業務仕様についての2週間のトレーニングを1カ月、3カ月と増やしてもたぶん理解が大きく増えることはなかった
すぐに必要でない知識を大量に与えられても一定以上のものは受け取れないのだ
得た知識からなんらかのアクションを起こし（詳細設計、実装、テスト）、そのフィードバックがあることで、業務仕様理解が進むんだと感じている
例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。
「コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「２１００年に２月２９日はあるか」という処理までチェックするものです。」
リソースが無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。
極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。
ライブラリの単体テストでは、「２１００年に２月２９日はあるか」というテストを行うかもしれない。
しかし、結合テスト、システムテストとテスト局面が進むたびに、いちいち「２１００年に２月２９日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。
「２１００年に２月２９日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。
ここもちろぐ
生産性志向のSEが、IT業界での奮闘記や仕事や生活で学んだことをはきだします。
2018-05-15
gizeh-2272008_640
こんにちは。もちです。本日は、みずほ銀行のプロジェクトで2か月限定支援に行った時のことを話したいと思います。
あの頃は、ちょうどポケモンGOがリリースされた時期でした。プロジェクトのお昼休みに、わくわくしながらアプリを立ち上げて、メンバーの方と遊んだものです。
そんな次期システムが、いよいよ、2018年6月9日から徐々に移行開始されるそうです。
みずほ銀、9日からシステム移行 「世界最大級のプロジェクト」 ATMやネットバンクに臨時休止日 (1/2)
みずほ銀行とみずほ信託銀行は、入出金や口座管理などを担う勘定系システムを統合した次期システムへの移行作業を9日から始める。4000億円超の資金を投じて進めてきた世界最大級のプロジェクトが、最後のヤマ場を迎える。
www.itmedia.co.jpwww.itmedia.co.jp
移行が発表されてから、「あの頃が懐かしい」と感じたため、せっかく浮かんだいろいろな想いを残そうと思って記事にしました。
ここもちろぐ
ここもちろぐ
みずほ銀行のプロジェクトで2か月限定支援に行った時の話、まなび編です。 ▼前記事の問題編はコチラwww.cocoamocchi.com古参メンバーの仕事を奪う デキる古参メンバーはとにかく忙しいです！！新規参入者でもやり方さえ一度知れば、できそうな仕事もありそうだということで、積極的に仕事を奪いにいきました。 たとえば…
2018-05-17 22:53
www.cocoamocchi.com
毎朝エレベータに長蛇の列
人気アトラクションかな？と思わせるほどの大行列でタイミングが悪いと10分以上待たされました。
テストフェーズがちょうど一個上の段階に進んだためか、チーム内のスマホは鍵付きロッカーでしっかりと管理されるようになりました。
インターネットが使えない
security-265130_640 これが一番厄介でした！！！
新入社員であれば、まずはググり力を鍛えろ！と先輩に教わるも方もいるのではないでしょうか。
わたしみたいなIT業界で働く方々は特にインターネットで調べまくる生き物です！
なのに使えないので厄介でした。
・・・とはいっても、わたしの場合は、こっそり休憩スペースにスマホを持ち出して調べてました。
他には、書籍にもお世話になりました。
ここで 「ネットが当たり前だと思うな、腕を磨こう」という教訓を得ました。
印刷用紙が真っ赤で読みづらすぎ
持ち出し抑止のために、プリンタ用紙が赤くなっておりました。
(特に持ち物チェックがあるわけではないので、悪意のある人なら持ち出せたかと思います。)
印刷してみるとまあ～わかりづらい。気持ち的にもなんか落ち着かない。
でも一定の効果はきっとあったのだろう。。
ただでさえ生産性の低い環境なのに、働き方もやっぱり残業ばかりされている方だらけでした。
特に既存メンバーの古参者は大量に仕事を抱えているので、いつもヘトヘトです。
他の人へのレビューも、当然荒い。
また最終退館者名簿を見ると、お客さまサイドも負けずと毎日23時台まで残っているようでした。
※ちなみに
ごめんなさい、わたしは最長でも21時には帰りました！寝不足すぎると生産性がダダ下がり逆効果なので苦笑。
単体開発バグ改修
私の場合、残念ながら新規開発部分は残ってなく、仕様取り込みやバグ改修をちょこっとやったくらいです。
開発ではなく、ほとんど仕様整理やJP1いじっている時間が多かったです。
命名規則がつらい
短い単語をアルファベット1文字で表現する文化があったため、それらをつなげて作成されるDBのテーブル名やカラム名が新規参入者にとってはしぬほど分かり辛かったです。
1箇所の修正で5個もケースはないし、誰も見ないのではないかなというくらい、ゆるふわなテスト結果が置いてあったりと、とてもじゃないけどもお金を扱うシステムだとは思いませんでした。
これ、結合テスト以降、バグ爆発するのでは？という印象だった。
the-1865639_640
階層がとにかく深く、無秩序に置かれた何千のフォルダ群はまさにジャングル。
既存の古参メンバーであったとしても、過去の単体テスト仕様書の在り処を探すだけで10分以上かかっていました。
IDEなど開発に使用するツールも、各チーム持っている情報が異なっていて、結局、既存メンバーの持っているものを丸ごとコピーして使ってました。
個々の期限がタイトにも関わらず、申請日時を厳守しなければならないのはつらかったです。
この申請は、数チームで1つのエクセルファイルにまとめて申請します。
プログラムファイル１つ１つのパスを記載していくのですが、 誰かが1ファイル既述を誤るだけで、
どこぞやのチームのせいで2連続申請ミスされたこともあり、こちらとしてはたまったものではありませんでした。
もしかしたら、誰かが休みたいがために、わざとミスしてるのではと疑いたくなるくらい大変でした。
まあ、とはいっても緊急リリースみたいな１～2日でできる裏技も時に使うことができたため、そこまでではなかったのかもしれません。
プロジェクトマネジメント
child-waving-goodbye-595429_640
うちの会社だけかもしれないけど、メンバーの離脱が、作業指示を出しているチームリーダーまでなかなか届かない印象でした。
「来週からこの作業お願いするね」と言っていた矢先に、彼らがいなくなることを知らされる。
これは、どこの炎上プロジェクトもですが、各タスクの期限だけ決まっていて、工数は考慮されていない事案です。
この事案は仕方ない場面もありますので、メンバー側がリーダーやプロマネに少々寄り添って、自分で仕事を考えていればOKです。
親切なプロジェクトじゃないのは分かっていることなので、他責にせず、ざっくりと工数を伝え、助けていきましょう。
新規参入者の実力が怪しい
少し言語知っている程度(for、if文はできるけど・・)で意思疎通の難しいプログラマーが国籍問わず、たくさんおりました。
猫の手も借りたいくらい忙しいプロジェクトだったので、自分で主体的に仕事を考え、動き、古参メンバーを助ける必要があります。
しかし、
進捗が良くないことをごまかす
など、この中のどれか1つ該当ではなく、複数持ちのプロジェクトキラーが何人かいました。
他の人も急に想定外の残業フォローをしなければならなくなるし、本人は無駄に悩み続ける時間増えるし、誰も幸せにならない感じでした。
まとめ
特に銀行のプロジェクトは、生産性の低い現場やずたぼろな構成管理など、環境的問題も多いことがわかりました。
同時に他責にせず、主体的に行動すれば、新規参入者でもそれなりに活躍できることもわかりました。
しかし、わたしの場合、２か月限定が配属前から決まっていたこともあり、
心までしんどくならずになんとか戦えたことが大きいかもしれません。
もし炎上案件に出会っても、 心や身体をやられるようなことがあれば即刻辞退をおすすめします。
残業による残業という負のスパイラルが、もし嫌なら、早く抜け出すほうがこれからの人生豊かです！
断言できます！！
