  |
はてなキーワード: 結合テストとは
学歴がよくなくて、就職が困難だったので中小 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 でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、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 を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 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.jp www.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つ該当ではなく、複数持ちのプロジェクトキラーが何人かいました。
他の人も急に想定外の残業フォローをしなければならなくなるし、本人は無駄に悩み続ける時間増えるし、誰も幸せにならない感じでした。
まとめ
特に銀行のプロジェクトは、生産性の低い現場やずたぼろな構成管理など、環境的問題も多いことがわかりました。
同時に他責にせず、主体的に行動すれば、新規参入者でもそれなりに活躍できることもわかりました。
しかし、わたしの場合、２か月限定が配属前から決まっていたこともあり、
心までしんどくならずになんとか戦えたことが大きいかもしれません。
もし炎上案件に出会っても、 心や身体をやられるようなことがあれば即刻辞退をおすすめします。
残業による残業という負のスパイラルが、もし嫌なら、早く抜け出すほうがこれからの人生豊かです！
断言できます！！
転職して参画した案件（PHPでWeb業務システム構築）が、ネットで聞いてた「SIerあるある」まんまだった。
その中でも結合テストが謎。
1000項目以上あるテストケースの一つ一つ、心を込めてエビデンスを取っている。
・WinShotでログインから１動作ずつキャプチャとる（ボタンのところにカーソル合わせて「ここ押す」感まで出す）
・Apacheログ、アプリログ、試験前後のDBのdumpをとる
これ、誰が見るんだ。何のために取るんだ。
お客に対して「ちゃんとテストしたよ！証拠もあるよ！」くらいの意味しか見出せない（お客だってサマリーくらいしか見ないだろう）。
メンバー曰く、「不具合があった時にどういう状況でテストしたかを確認するため」とのこと。
どういうテストしたか、なんてテスターの不備を追求してる暇があるなら、さっさとバグを直せばいいじゃん。
そんなに吊るし上げしたいのか。
一番怖いのは誰も文句言わず黙々とキャプチャとってること（自分もだけど）。
はてブでよく見る意識高いIT系の記事では、EXCELとにらめっこするだけが仕事の技術力のないSEは今後淘汰されていくという話をよく見る
まさに俺のことだ。
入社して10年、EclipseもVisualStidioもロクに触っていない。
流行りのテキストエディタには触るけどやることは構築手順書の執筆だ。メモ帳でもできる。
日々やってる業務といえば要は代筆業。
営業が色んな客から仕事を取ってくる。仕事内容については、客によって方言がある。
あっちの客が要件定義と呼んでるやつはこっちの客は基本設計だ。そっちの客が機能テストと呼んでるやつはうちでは結合テストと単体テストの一部を指す。
こういうのをいちいち内情に合わせて翻訳し、うちのエンジニアに伝える。
エンジニアは単にアウトプットを出せばいいだけなじゃく、うちの会社の品質保証チームのルールに合わせて物をつくらないといけない。そうでないと会社の名前でリリースできない。
そんな内向きのルールで作った物をまたそれぞれの客向けに再翻訳してリリースする。チェックの結果足りないものは俺が書く。
世の中はアジャイルでカンバンでリーンだ。彼らの提唱した業務改善に従っているお陰で、一時期のように無駄な後戻りも属人的な作業もだいぶなくなった。
タスクをカンバンレベルで分割したことで、エンジニアの手が足りなくなった時にも技術力のない俺が手助けできるようになった。
要は仕様書類や評価計画書を代筆したりすればいい。ここは正直認める。
ただ、アウトプットをお納めする先の客はまだまだウォーターフォールのところばかりだ。奴らは○×設計書、△□評価報告書を要求する。そのギャップは誰が埋めるの？
はじめはエンジニアチームがみんなでやってたり管理者がやってたんだが、次第に俺に集約するようになった。
そうなったきっかけは、同僚よりわずかながら俺ができなかったからだ。その時点で俺が悪かったのは認める。
ただ、分業してるうちに同僚エンジニアたちは最新の技術と開発環境でどんどんスキルを上げるのに、
俺がやってることといえば客のフォーマットに従ったWORDにソースから自動生成されたクラス図を貼り付けて説明を書くとか
Redmineのバグチケット数をEXCELに集計して提出書類にするとか、そんなの。何の生産性もない。
このままこの会社で働き続けるなら問題ないと思う。特に俺だけ負荷が高いというわけでもない。
しかしこの環境がいつまで続くのか、誰も保障はできないだろう。
もし何かあった時、同僚エンジニア達は市場価値も高く、どんな環境でもやっていけるだろう
じゃあ俺は？EXCELかWORDしか使えないエンジニアでもない俺はこの会社から放り出されたら何もできない。
じゃあ何したらいいかっていうのも考えられない。日々仕事は積まれていくし、もう決定的な差がついた。
Javaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。
詳細設計のことだ。
ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。
てか、そんな物を読むくらいなら、現物のソース読めよって話だ。
だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。
何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。
「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。
それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。
でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。
負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。
なんでそんなに「日本語訳」が欲しいの？
もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。
そして元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。
それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。
とはいえ、別に何も「真実はソースただ一つ！」なんて言うつもりはない。
ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。
ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。
そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。
ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。
Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。
あまりコミニュケーションが得意ではないのもあって、入社直後は非常に苦労した。
正直人見知りだったのでわけのわからないことをのたまっていた時期もあった。
とはいえもう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字モデルをぜんぜん理解し切れてない。
誰か教えてくれ。
