テストプロセスを詳細化した話 - レビュー・テスト分析 - Qiita
以前、シフトレフトのために静的テスト、動的テストの2つのアプローチからどんなアクションを取れるかを記事にしました。 上記記事で書いたように、以前までのwith QAチームではテスト設計以降の作業を重視せざるをえず、上流工程でのテスト活動を明文化できていませんでした。しかし、メンバーの増強とユニット制への体制移行により、より上流工程から積極的にQAが関わっていけるようになりました。 その中でQAとして何ができるとよいのかを考えた結果、より積極的にテスト活動が行えるようテストプロセスを詳細化することにしました。具体的にはwith QAチームでは新たにレビューとテスト分析をテストプロセスとして明示することになりました。1 今回は、このレビューとテスト分析を中心に、実際に何が変わったのかを書いていきます。 前提の確認 本題に入る前に、レビューとテスト分析とは何かという確認から行います。 「レビュー
設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
はじめにTIG真野です。 秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
なぜシステム会社の見積りが「ボッタクリ」に見えるのかを、きちんと説明する。
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開） ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
硬直しきったプロジェクトで働いた思い出 - tehepero note(・ω<)
2015-04-29 硬直しきったプロジェクトで働いた思い出 ふと昔いたプロジェクトについて思い出したので書く。 経歴 2006-2009 中小SIer 2009-2012 フリーランス 2012-現在 サイバーエージェント 今日の話は中小SIer時代のこと。本エントリでは所属会社と呼ばせてもらう。 所属会社について 社員30名くらいで、当時で設立8年目くらい。 自称ベンチャー企業 自社製品もあったが、基本客先に常駐するスタイル。いわゆるSES契約というやつ。月に一度、帰社日というやつがある。 プロジェクトジョインの経緯 2008年当時、体力の無い所属会社はリーマン・ショックの影響で火の車。1・2年目社員の多くが社内失業者に。 会社としては、社内失業者を何とか現場に出したい。3年目以降で会社の主力メンバーと共に、社内失業者がバーターでジョインできる現場が優先された。 所属会社の1年目若手（
Yahoo!ニュース“Buzz”はなぜ「失敗」したのか～エンジニアに「解」を与えた編集者の存在
普段Yahoo!ニュースをご利用いただいている方の中にはお気づきの方もいらっしゃると思いますが、3月31日、Yahoo!ニュースから「Buzz」コーナーが姿を消しました。 時を同じくして、「Buzz」のリニューアルという形で「テーマ」機能をリリースしました。 ブラウザ版はテストリリース期間中のため現在は3％のユーザーに表示される仕組みとなっていますが（100％リリースは5月完了を予定）、Yahoo!ニュースアプリの最新ver.では全てのユーザーの皆様がご利用可能です（画像参照。テーマの機能やアプリの詳細についてはこちら）。 Yahoo!ニュースの「Buzz」は、2013年7月のリリース（ブラウザ版リリースは翌月）からわずか1年8カ月でその役目を終えました。 Buzzの機能や狙いなどについて書かれた当時の記事を振り返ってみると、当時の狙いは以下のようなものでした。 世の中の大きな動きとしてソ
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1
「何を使って設計書を書いていますか？」と尋ねよう: 設計者の発言
業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール（システム開発用の設計情報管理ツール）を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。 専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙（細かい方眼紙状に設定されたExcelシート）で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダー
git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
DevOpsなんてくそくらえ - razokulover publog
先日こんなことを言われた。 「テストを書いた成果を見せよ」 と。 ショッキングだった。 経緯 わたしはいまレガシーなコードに囲まれている。 もちろんテストもほとんどないピカピカのレガシーちゃんである。 レガシーちゃんは「Ctrl+F5 & tail -f 駆動開発」により開発が進められており、日々進化している。 このまま進化をつづけるといつかモンスターになり(もう軽く怪獣っぽいが)、開発スピードがどんどん遅くなり、メンテナンスやバグつぶしでエンハンスとなるような開発ができなくなる。このままじゃマズい...。 こういった事態を一新すべく、手探りながら私含め数人の先輩たちで「DevOps」に取りかかることになった。 バズワードにもなっているが「DevOps」とは、 従来型のシステム管理や調達（ITILを含む）といった、保守的でプロセスを中心に据えた運用からよ>り戦略的でアジャイルな、そして自動
罪と罰（11） 変革への序章：Press Enter■：エンジニアライフ
ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 五十嵐さんがイニシアティブを設立した背景を知ったことが原因だったのか、Aチームメンバーの意識は目に見えて変わっていった。元々、五十嵐さんの登場によって変化の兆しはあったものの、それがさらに加速された形だ。 1つの例としては、3バカトリオが繰り広げていたネバーエンディングな議論が、皆無にはならなかったものの激減したことだ。おそらく、プロジェクトAを何としても成功に導かなければならない、という五十嵐さんの強い思いが伝わったこともあったのだろうが、単純にやるタスクが増えて、議論に費やしている時間がなくなったことも大きいだろう。やる気の出る目標を与えると、若手エンジニアのモチベーションは劇的にアップするものだ。 以前なら、1日に1回は、デザインパターンがどうの、リファクタリングがどうのと
コンピュータシステムを「ビジネスとしての系(システム)の一部」として見ることが出来るかどうか - がるの健忘録
相変わらず「金の話とエンジニアの話の真ん中くらい」をふらりぶらりしているおいちゃんでございます。 ふと、偶然ではあるのですが。 ちょいとばっかり「壮絶な」ものを拝見したのと、そこに起因して随分といろいろ、考察できるネタがあったので。 その辺の考察の…途中経過、程度のものを、Blogにて。 とりあえず今回俎上に挙げるのは２タイプ。どちらにも共通しているのは「DRYなにそれ？ レッツコピペ駆動開発！！」な行動原理。 A)複数個所のテストだろうがどんだけ単純作業の連打だろうが「僕は」黙々と丁寧に根気よく続けます B)テスト？ なにそれおいしい？ 理想論として耳にしたことはあるけど、現実、テストなんてやってらんないよ？ Aは、割と典型的な「無能で勤勉な人間」。 http://d.hatena.ne.jp/gallu/20081114/p1 の話を思い出すのであれば、彼らは速やかに[除隊 | 馘首
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
“素人集団”が強みに 基幹システムを自社開発するハンズラボ
2013年4月に設立したハンズラボは、一見すると“非常識”と思われるような取り組みによって事業の拡大を図っている。 東急ハンズのIT子会社であるハンズラボが、基幹系など自社開発したシステムをクラウドサービスに移行する作業に取り掛かっている。年内に作業を完了するとともに、自社開発の経験を生かして外販に乗り出す。最大の売りは、オーダーメイド型システムを早く、安く作り上げること。得意とする小売業にアプローチする。 業務に精通するITメンバーたち 2013年4月に設立したばかりのハンズラボには、約30人のエンジニアらがいる。多くは、東急ハンズ社内の公募によって、前身のIT部門に異動してきた20代から60代の社員。彼ら、彼女らは業務に精通するが、ITの専門家ではない。そんなITの素人集団で、2008年からシステムの自社開発を始めた。（関連記事：東急ハンズ、ITソリューション会社「ハンズラボ」設立 ク
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/sotarok/status/1779070109577019789
まとめよう、あつまろう - Togetter
はてなブログチームの開発フローとGitHub
