  |
はてなキーワード:単体テストとは
新卒2年目で、システムインテグレータ勤務1年です。
システム開発をやりたくて、SEとしてのスキルを伸ばしたいという目標がありました。
会社の研修では、C#、HTMLなどを学び、6人班で1つのシステムを作成する開発実習をしました。
そこでは、私は「ユーザ一覧画面」を担当していましたが、エラーを起こしてしまいました。
その結果、班の人に怒られて、「あなたは開発やらなくていい」と言われました。
結局、開発は全くできず、発表用のパワーポイントを作る羽目になりました。
システム開発をやりたいと主張しても全くやらせてもらえませんでした。
仕事内容も、簡単なシステム改修や単体テストなどの単純作業や資料作成でした。
上司に質問をしてもうまく通じなかったり、「あなたが客先で仕事するのが心配」「あなたがコミュニケーションをとることで業務に支障が出る」「任せられる仕事が少ない」と評価されてしまいました・・。
「このままだとやばい！！」と思い、転職活動へ。エージェントに登録しました。
しかし、職務経歴書を見せると「あなたの職務経歴書だとどこも転職できない！」「勉強しないと転職できない！」と言われてしまいました。
神クラス（GodObject）は、ソフトウェア設計においてアンチパターン（避けるべき設計手法）として知られています。
これは、過剰に多くの責任を持ちすぎるクラスやオブジェクトのことであり、ソフトウェアの保守性や拡張性、可読性に大きな問題を引き起こします。
以下では、「いかに大変か」「なぜ大変か」「どのように大変か」を徹底的に具体的に解説します。
public class ApplicationManager { privateMap<String,User>users; private DatabaseConnectiondb; privateLoggerlogger; privateGUIgui; private NetworkClientclient; publicvoid startApplication() { connectToDatabase(); loadUsers();gui.showLoginScreen(); } publicvoid processUserInput(String input) {logger.log("Input received: " + input); if (input.equals("logout")) {gui.showLoginScreen(); } else {client.send(input); } } // ...more than 5000 lines of code}
ソフトウェア開発において「コード補完・単体テストの自動生成」から出発し、「願っただけで全てがすぐに叶う状態（完全自動生成）」を最終目標として、段階を詳細に示す。
⸻
【第1段階：コード補完・単体テストの自動生成（2023年～2024年）】
•GPTシリーズやCopilotをはじめとした現時点の技術水準。
•開発者の意図をある程度予測して関数単位の補完・簡易なテストコードを生成可能。
⸻
【第2段階：仕様書・要件からの関数レベル自動実装（2024年～2026年）】
•AIが自然言語で書かれた仕様を関数レベルで直接コードに翻訳。
•開発者が関数定義やインターフェース設計を自然言語で伝えるとコードが生成される。
•AIがテストコードをさらに詳細に自動生成し、境界値分析・異常系シナリオにも対応。
⸻
【第3段階：コンポーネント～モジュールレベルの自動生成（2026年～2028年）】
•システム要件や簡易な設計書を基に、AIがより大きな単位でコードを生成する。
•特定のフレームワークやライブラリを適切に自動選定・使用可能。
•UI/UX設計も、要件をAIが受け取りプロトタイプを自動作成。
⸻
【第4段階：アプリケーションの全体設計から初期プロトタイプ自動生成（2028年～2030年）】
•アプリケーション全体の要件定義やビジネスロジックを自然言語で指定すると、AIがアーキテクチャ選定から初期プロトタイプ生成まで対応。
•開発者の役割はプロトタイプ検証・調整・デバッグが中心となる。
• 多くの標準的なシステム開発では、開発期間が大幅に短縮される。
⸻
【第5段階：AIによる自律的アプリケーション構築と運用保守（2030年～2033年）】
•自然言語または口頭での依頼だけで、要件定義・設計・実装・運用までAIが自律的に行う。
• 実行環境の自動構築（クラウド環境やインフラの自動調整）まで含めてAIが担当。
•AIはフィードバックをもとに、改善・改修・自動アップデートを実施。
⸻
【第6段階：概念や意図のみで動的にシステムが生成される状態（2033年～2037年）】
• 「こうしたい」「こうあればいいな」という抽象的・概念的な願いをAIが完全に理解し、システム全体が即座に動的に生成される。
•開発者の役割はAIの生成結果を最小限のチェック、倫理的監視、法的責任の判断に限定される。
•システムはリアルタイムに利用者の要望を把握し、動的に再構成や最適化を行い続ける。
⸻
【最終段階：願っただけで全てがすぐに叶う状態（2037年以降）】
• 完全に人間の意図・願望のみでソフトウェアシステムが瞬時に具現化される世界。
•AIが人間の思考・感情・状況を正確に読み取り、意識的な操作や指示を必要としない。
•現実世界との統合（物理環境への影響・IoTデバイス・ロボティクスとの連動）が完全に実現される。
• 開発という概念自体が消滅し、人間の願望と現実の境界が事実上消失する状態。
⸻
あと、ロゴとかデザインを決めさせて服とか看板で出す場合、商標権や意匠権の問題があって、京アニ事件の青葉被告レベルの妄言でも普通に認められる。
VisualStudio2022のai補完機能みたいに自分が書いたコードから学習しました。
今まで○○な修正をしていて次も同じことやってそうなので、確認を取ったうえで実際にやる程度なら、問題にはならない。
単体テストや結合テストの生成もノウハウはあるけど、特許が絡んでなければ、aiを使ったところで問題にはならん。
ただ、ここらへんは自然言語でコーティングしたのをaiが特定の言語に変換してるだけなので人間が書いたほうが今の所は圧倒的に速いけどな。
いやいや、単体テスト仕様書は大事やで！確かに地味かもしれんけど、これがあるからこそ安心してシステムが動くんやで。モチベーション？そんなん、未来の自分が「あの時ちゃんと仕様書作っといて良かったわ～」って感謝するに決まってるやろ！それに、大体ちゃんと動いてるって油断してたら、予期せぬバグが潜んでるかもしれんで？しっかりやっとき！いや、何でそんなに偉そうに言うてんねん！自分も一緒にやろか！
単体テストというのは、画面を手動で操作してスクリーンショットを撮る仕事だった。エクセルで仕様書を書き、レビューをしていたが、レビューアーはテストケースよりも、枠線の整え方に気を配っていた。
誰かが自動テストを導入しようと言い出した。「再現性がある」「保守性が高まる」「もっと良くなる」と口々に言われていた。
でも、テストコードを開発する工数はどうするのか、開発コードが増えればさらに大変になるのではないかと不安があった。
それでも、これが実現すれば、何かが大きく変わる予感がした。
アプリケーションフレームワークはStrutsだった。フォームをポストする瞬間にカオスが生じ、50行の無駄なコードを書き、100行の読みにくいコードを理解することが技術者の条件だった。
ある人が「レイヤリング」という概念を持ち出し、別の誰かが「DI」と言い出した。アプリケーションアーキテクチャという言葉も登場し、ファウラーという人物の名前も聞こえるようになった。
新しい構造が提案され、それに影響を受けながら、「いつかは美しいアプリケーション構造が生まれるのかもしれない」と夢を抱いていた。
当時、PerlでCGIを作っていたが、PHPやRubyが登場した時は、正直Web"サイト"を作るためのものだと侮っていた。
しかし、次々と洗練されたWebアプリケーションフレームワークが生まれ、StrutsやJavaEEよりもはるかに使いやすくなっていった。
数多くのWebフレームワークの中で、どれを選ぶべきか悩みながら、「いつか完璧なWebフレームワークが現れるかもしれない」と期待していた。
サーバーは冗長化され、ReversProxyを使い、セキュリティのために構成を変更してきた。そしてクラウドが登場し、Dockerなんて本番で使えないと言っていた時代から、
気がつけばどこに存在するのかもわからないクラスターの中で、コンテナアプリが動いている時代になった痛快だ。
かつてLinuxマシン一台を「鯖」と呼んでいた時代から、世界は目まぐるしく変化し続けるとかと思っていた。
誰かがAjaxと言い出し、別の誰かがReactと言い出した。「こんな方法でHTMLを作って良いのだろうか？」と疑問に思いつつも、「Webはアプリケーションだ」という感覚が強まっていた。Webアプリケーションがどう進化していくのか、未来を感じることができた
私たちは、ソフトウェアを開発すること自体に大変さを感じていた。新しい技術やフレームワークが次々と登場し、その都度課題が解決される一方で、新たな課題が生まれる。これほど面白いことはなかった。そしてエンジニアたちには一体感があり、誰もが自分なりの方法で課題を解決し、そのフィードバックループが世界を動かしていた。だからこそ、今は少しつまらない。変化は穏やかになり、「お金を稼ぐ」という目標だけが共通となり、課題は個々の事象に閉じ込められている。しかし、それが悪いことではない。ただ、私たちの時代が変わったのだ。
かつては、私たちの目の前には普遍的な課題があり、それぞれがそれぞれの場所で課題を解決し、そのフィードバックループが世界を動かしていた。
生成AIで例えると、それをどう使うかではなく、エンジニアが一丸となって生成AIをチューニングしていた。世界情勢で例えると、世の中の飢餓を全世界の人がアイディア出して、解決しようとしてたいた。
今でも、普遍的な課題は世界中に転がっているが、それらは高度で、私たちには手が届かないものが増えてしまった。
ITは面白かった。プログラミングが分かるだけで、世界の課題を一緒に解決できる時代だった。それぞれが自分の場所で働くだけで、世界を動かしていた。そんな時代が終わってしまったと感じる。
老害といえば昔話だろ！
偉っそうなリーダーがいてね。
普通はこの手法は最後の手段として使用するもんでしょう。他の方法を試して、それでもダメだった時に最後の手段として上司経由で指導するもんでしょ。
リーダーとしていろいろ試行錯誤してから、最後の手段として上司に報告とかすべきでしょ。
この問題、相手も正しい。ミスはダメなことなのだから。自分は強くは相手に言えない。ミスしたのは自分なのだから。しかし腑に落ちない。
いろいろ考えてみたが、騒音トラブルなどの近隣トラブルで例えると次のようになる。
横の家が21時頃なのに煩い。
どちらも正しいだろう。
人間関係を築く必要のない赤の他人になら、①がベストだ。相手も不快にはならない。
しかし、相手が子ども会などで接点を持つ可能性がある相手だと、いきなり警察に通報するのはカドが立つ。②がベストになる。
この事例はとても近いと思う。人間関係を築く必要があるかないか、の違いだ。つまりこれは、リーダーには人間関係を築く気がない、ということだ。リーダーを仲間と思ってるのがダメなのだ。リーダーは第三者の人。客先の嫌な人、と思えば良いのだ。
ひとまず、作業をするとミスをする可能性が増えるので、なるべく作業することを控え、何度も確認を行うことでミスを発生させないようにした。これまでは自主的に目についた問題は積極的に対応してきたが、依頼があったものだけ直すようにした。
そしてこんな働き方は性に合わないので仕事を辞めることにした。
ミスについて：
ミスをする人=能力の低い人、ではない。人間誰しも作業をすれば必ずミスは発生する。確認すればミスは減るが、それでも限界がある。バグのないシステムはない。
私はそこそこ仕事が早くミスもない人、と職場に思われていたはずだ。仕事を辞めると伝えた時は引き留めが入ったし、○○さんがいなくなった後が怖いです、なども言われた。
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以外にも、君必要なの？何やってる人なの？打ち合わせには参加してるけど、ただの工数食い虫じゃね？みたいな人もいるのです。
開発手法でしっくり来てるのがAndy HuntさんのTracer Bullet Developmentで、開発の方向性を示すのに試作を作る方法。
1. 主要なシステムオブジェクトを定義。UI、サーバー、ロジックビット、データベース抽象化レイヤー等。
3.データフローを実現するためにAPI とその戻り値をコーディング。
4.単体テストを使用してAPI の予想される使用法を文書化。
5. 各API に必要な量の既定のデータ (別名、ダミーデータ、偽のデータ、ハードコーディングされたデータ) を追加して、API が「実行」されるようにする。
6. あらかじめ用意されたデータを実際の機能に段階的に置き換える。
7.コードをリファクタリングし、システムオブジェクトを調整し、完了するまでこれを続ける。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 1359 | 国土交通省 ネガティブ情報等検索サイト | www.mlit.go.jp |
| 1087 | ゲームを趣味にしている人の割合が多いのはどのくらいの収入の人たちなのか調べてみた - nonameのノート | noname774300.hatenablog.com |
| 854 | マシュマロ！｜高河ゆん｜pixivFANBOX | kouga-yun.fanbox.cc |
| 850 | トコジラミ根絶方法 ｜害虫・害鳥獣を安全に対策します｜株式会社 オオヨドコーポレーション Ｐテックス社 | oyodo-pmp.com |
| 847 | ラマヌジャンは本当に何も知らなかったのか | mathlog.info |
| 774 | 裏紅白歌合戦2023 | jiyujoho.a.la9.jp |
| 679 | 水は変わった物質 | vitroid.github.io |
| 671 | しずかなインターネット | sizu.me |
| 606 | 日米でエンジニアの育成戦略が正反対だと気付いた話 -メソッド屋のブログ | simplearchitect.hatenablog.com |
| 498 | 『ゼルダの伝説 ブレスオブザワイルド』が品質を高めてくれた。売上10万本超え、R18インディーゲーム『洗脳アプリで高慢なお嬢様を好き放題するシミュレーション』開発者インタビュー -AZ-LINE あずらいん！ | az-line.jp |
| 484 | ChatGPTに社内文書に基づいた回答を生成させる仕組みを構築しました -コネヒト開発者ブログ | tech.connehito.com |
| 475 | 超映画批評『ゴジラ-1.0』90点（100点満点中） | movie.maeda-y.com |
| 465 | メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou | sizu.me |
| 454 | 「直接会って話したほうがはやい」は速いだけ｜araya | sizu.me |
| 438 | ベンダが提供していない決済モジュールの不具合による情報漏洩事故 東京地判令2.10.13（平28ワ10775） -IT・システム判例メモ | itlaw.hatenablog.com |
| 436 | Othellois Solved | arxiv.org |
| 435 | 池田大作氏の御逝去の報に接し | kishida.gr.jp |
| 424 | https://ip.guide/ | ip.guide |
| 421 | ナポリタンが究極の味になる！ほんのひと手間に「やって大正解」「今度からこうする」 - macaroni | macaro-ni.jp |
| 421 | 大麻、少年の性被害、男らしさの病（松本俊彦）[第12回] 酒をやめられない文学研究者とタバコがやめられない精神科医の往復書簡 | ohtabookstand.com |
| 407 | 変なドメイン取るな.net | www.henna-domain-toruna.net |
| 401 | ｍＲＮＡのひみつ ｜ まんがひみつ文庫 ｜ まんがでよくわかるシリーズ ｜学研キッズネット | kids.gakken.co.jp |
| 377 | 【雑記】セキュリティガイドライン類 約300時間 読み漁ってみた - 2LoD.sec | nikinusu.hatenablog.com |
| 374 | 弊社元幹部社員の不正について/日本海テレビ | www.nkt-tv.co.jp |
| 368 | t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました -DeNA TestingBlog | swet.dena.com |
| 361 | コラム・寄稿「なぜドイツ人にできることが日本人にできないのか」 | www.rieti.go.jp |
| 360 | 令和時代の個人サイトの作り方：suama works | techbookfest.org |
| 356 | 【楽天市場】SPUの特典内容変更について｜SPU（スーパーポイントアッププログラム） | event.rakuten.co.jp |
| 345 | 国産プレミアムウイスキー 一部商品の価格改定について | www.suntory.co.jp |
| 335 | Mini vMac | lrusso.github.io |
