「単体テスト」を含む日記 RSS

はてなキーワード: 単体テストとは

2020-10-30

お願いだからセンスの無い人はプログラマにならないで下さい

プログラミングセンスです。センスの無い人がプログラマになると、他のすべての人に迷惑がかかります。だからセンスの無い人は絶対プログラマにならないで下さい。

プログラミングセンスが無い人や、プログラミングをやったことの無い人は、知識を得たり経験を積んだりすれば、誰でも「良いプログラマ」になれると思っているようですが、無理です。

というのも、センスの無いプログラマ問題は、知識経験の不足ではないからです。センスの無いプログラマの救いようの無い問題は「頭がおかしいこと」なのです。

題材は何でもいいのですが、具体的なコードを見た方がイメージがつきやすいと思いますので、とりあえず以下の問題を考えます

問題

住民リストが与えられるので、背の低い順に男女ペアにしたリストを作って下さい。ただし、男女の数は同数であるします。

コード

ふつうの人は、難しく考えずに以下のようなコードを書きます

const makePair = (persons) => {
  const males = persons.filter(person => person.sex === MALE)
  const females = persons.filter(person => person.sex === FEMALE)
  const compareHeight = (a, b) => a.height - b.height
  males.sort(compareHeight)
  females.sort(compareHeight)
  return males.map((male, idx) => [male, females[idx]]) // 男女の数は同数
}

この例はJavaScriptなので高階関数を使っていますが、仮にそういう機能が無かったとしても、

というコード構成は大きく変わらないでしょう。

一方、センスの無いゴミプログラマは、以下のような名状しがたきコードを書いてきます

function pair(psns) {
  var i = -1;
  var cnt = 0;
  var flg = psns[0] && psns[0].sex;
  var j = -1;
  var tmp = null;
  for(i = 0; i < psns.length; i++) {
    //console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
    //console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
    if(psns[i].sex == flg) {
      //console.log('cnt: ' + cnt + '->' + (cnt+1));
      cnt++;
    } else {
      j = i - cnt + 1;
      //console.log('swap ' + i + '<-->' + j);
      tmp = psns[j];
      psns[j] = psns[i];
      psns[i] = tmp;
      i = j - 1; // <- 理由は分からないが、i = jだと上手くいかない(by XXXX)。
      cnt = 0;
      flg = flg == MALE ? FEMALE : MALE;
      while(j > 1) {
        if(psns[j].height < psns[j-2].height) {
          //console.log('swap ' + j + '<-->' + (j-2));
          tmp = psns[j-2];
          psns[j-2] = psns[j];
          psns[j] = tmp;
        }
        j -= 2;
      }
    }
    //console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
    //console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
    //console.log('')
  }
  for(i = 0; i < psns.length; i++) {
    //console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
    j = Math.floor(i / 2);
    //console.log(psns, 'i=' + i, 'j=' + j);
    tmp = psns[i];
    if(!(i % 2)) {
      psns[j] = [null, null];
    }
    if(tmp.sex == MALE) {
      psns[j][0] = tmp;
      psns[j][1] = psns[i+1];
    } else {
      psns[j][0] = psns[i+1];
      psns[j][1] = tmp;
    }
    i++;
    //console.log(psns, 'i=' + i, 'j=' + j);
    //console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
  }
  psns.splice(psns.length / 2, psns.length);
}

こんなコードメンテナンスは御免被りたいです。一見して配列の要素を入れ替えていることが分かるだけで、実装を全て読まなければ(いや読んでも)処理の意図が全く分かりません。また、たとえば「i = j - 1」が間違って「i = j」などと書かれていてバグを起こしたとしても、原因を突き止めるのは困難を極めます

さて、このコードは具体的に何がいけないのでしょうか。長すぎることがいけないのしょうか。変数名が分かりにくいのがいけないのでしょうか。引数破壊的に変更しているのがいけないのでしょうか。不要コメントが残っているのがいけないのでしょうか。よく見ると、ソート処理で車輪の再発明をしていたり、「j」や「tmp」などが場所によって意味が違うカメレオン変数になっていたりしますが、それがいけないのでしょうか。どれも正しいですが、それらを逐一直したところで、本質的解決にはならないでしょう。

後者コードはもはや「ここを直したら良くなる」とかいレベルを超えています。たしかに、問題を具体的に挙げることはできます。このコードの致命的な問題が、凝集度の低さと、単一責任原則(SRP)違反にあるのは間違いありません。しかし、後者コードを書いてくる人に、

住民リストを男女に分ける処理や、リストソートをする処理、2つのリストをまとめる処理は、この問題とは独立して意味のある操作から、別の関数として抽出しましょう。その方がコードの見通しがよくなるし、一部の処理を修正したときの影響も小さくなるし、単体テストも書きやすくなります

なんて言ったって聞く耳を持たないでしょう。

そもそも、こういうコードを書く人は、この処理自体を「pair」なんて関数抽出すらしません。まだこの問題では入出力のフォーマットが明確に定義されているので、他人が1から書き直せますが、実際のプロダクトでは、無数の副作用を起こす数千行のコード迷路を彼の脳内フォーマットデータが通るわけです。もちろん、テストコードなんてありません。

まり、指摘をしても絶対に直らないのです。いくら言語の優れた機能ベストプラクティスを紹介しても、馬の耳に念仏。それらの利点を理解できるだけの脳みそが足りていないのです。

どうして、同じ処理を実装するのに、ここまでの違いが生じるのでしょうか。

これは、プログラミング技術問題ではありません。既に述べた通り、ふつうの人なら、特定機能の有無とか知識の程度にかかわらず、ふつうコードを書くのです。なぜなら、ふつうの人にはそちらの方が楽だからです。つまり、前者のコード別に何か卓越した技術を身につけた結果書けるようになるものではなく、まともな感覚さえ持っていれば、プログラミング初心者にとっても前者のコードの方が書きやすいのです。

まり後者のようなコードを書いてくる奴というのは、現実世界の捉え方が常人とは著しくずれているのです。要するに、「頭がおかしい」のです。この病気はもう直りません。だからセンスの無い人は絶対プログラマにはならないで下さい。

2020-07-29

本当の本当の本当に無理

単体テスト締め切り間近に設計書加筆とか頭悪すぎる

昨日残業しないで帰った癖になんであれもこれも未着手なんだよ

お前の尻拭いでみんな残業してるのに

何が未着手なのかぐらメモに取っとけよ

全部下から「あれやりましたか?これやりましたか?」って聞かなきゃいけないの?

本当に無理

なんでそんなに頭が悪いのよ

2020-02-02

anond:20200202210337

そりゃ細かく言ったら単体テストしてカバレッジ取って、Excel記述意味不明だったらQA投げてとかあるだろ。

そんなの些細な話だけどな。

2020-01-23

ベンダからシステムが一次納品されて受入試験してるんだが品質が低すぎるというか一度も総合テストしてないっぽいレベルで低い

機能によっては単体テストすらしてないんじゃと疑う箇所もある

なんなんだコレwww

2020-01-14

ソート関数説明は大体した。

バブルソートバケツソートであってもN=1,Bigの時には異なる数値を出すことがある。

ましていわんやその他のソート

当然何でこれだけの数のソートアルゴリズムがあるか?といえば条件に応じて変えるため

あるいみ、バケツソートで書かれていましたN=Bigでないとして

相手プロプログラマー

そりゃ、標準ライブラリにあるようなソートには変えてくることは予想ができる。

しかし、デバッグ時にはバケツソートになっていることもある。簡単だしデータ少なく入れるから

これもバケツソートの使い方。いわゆる単体テストじゃないけど、テスト中はバグが出にくいものにかえてあることがある。

 

これは現場で知っておくべきこと。標準的ライブラリにあるものがわざわざコードが書いてある。

そりゃなんかのいみがある。

2019-11-23

Julia (プログラミング言語)なぜ僕らはJuliaを作ったか

それでも、pythonは非明示的な動的型付き言語であり、記述時のチェックも少ないので、文法さえ合っていれば、結構自由に書ける。クラスインスタンスや、数値などではなく、(その場の変数値込みの)関数なんかもただのオブジェクトに見えるので、どんどん関数引数変数に入れられる。戻り値しかり。演算子オーバーロードなどもできて、直感的な記述可能。ということで、使う側の直感に合うような運用可能になっているがゆえに、受け入れられているのだろう。

しかし、それは運用単体テストに支えられているものであって、ひとたびその集中力が途切れたりうっかり見落としていたりすると、それがどこにあるのか、というのは、それなりにレアなケースだと、発覚するのがだいぶ先になって、その解析、分析も大変になるという恐怖は常に隣り合わせである

もしかして、そういう状況がいやだったから、掲題のコンピュータ言語を開発しようとしたのか。

http://marui.hatenablog.com/entry/20120221/1329823079

ここに、原作者ブログの日本語意訳がのっていた。もう6年も前になっている。

(原文:Why We Created Julia)

2012年2月14日(火) | Viral Shah, Jeff Bezanson, Stefan Karpinski, Alan Edelman

端的に言えば、僕らは欲張りだからだ。

僕らはMatlabのパワーユーザーだ。LispハッカーPython使いやRuby使いもPythonハッカーもいる。髭が生える前からMathematicaを使っていたのもいるし、未だに髭が生えてない仲間もいる。常識的な人にはオススメしないくらい多くのグラフR言語で描いてきた。そしてC言語は僕らのユートピアだ。

いま挙げた言語は大好きだ。どれも素晴らしいしパワフルだけど、科学計算機械学習データマイニング、大規模な線形代数演算分散・並行コンピューティング、といった僕らがやるようなものにはどれも一長一短で、仕事完璧にはまる機能もあれば何とも使い物にならないものもある。どれもトレードオフなんだ。

僕らは欲張りだ。これじゃ十分じゃない。

僕らが欲しい言語はこんな感じだ。まず、ゆるいライセンスオープンソースで、Cの速度とRubyの動的さが欲しい。Lispのような真のマクロが使える同図象性のある言語で、Matlabのように分かりやす数学記述をしたい。Pythonのように汎用的に使いたいし、Rの統計処理Perl文字列処理、Matlab線形代数計算も要る。シェルのように簡単にいくつかのパーツをつなぎ合わせたい。チョー簡単に習えて、超上級ハッカーも満足する言語インタラクティブに使えて、かつコンパイルできる言語が欲しい。

(そういえば、C言語の実行速度が必要だってのは言ったっけ?)

こんなにもワガママを言った上だけど、Hadoopみたいな大規模分散コンピューティングもやりたい。もちろん、JavaXMLで何キロバイト常套句を書きたくないし、数千台のマシン分散した何ギガバイトものログファイルを読んでデバッグするなんて論外だ。幾層にも重なった複雑さを押しつけられるようなことなく、純粋なパワーが欲しい。単純なスカラーループを書いたら、一台のCPUレジスターだけをブン回す機械語コードが生成されて欲しい。A*Bと書くだけで千の計算をそれぞれ千のマシン分散して実行して、巨大な行列の積をポンと計算してもらいたい。

だって必要ないなら指定したくない。もしポリモーフィック関数必要な時には、ジェネリックプログラミングを使ってアルゴリズムを一度だけ書いて、あとは全ての型に使いたい。引数の型とかから自動的メソッド選択してくれる多重ディスパッチがあって、共通機能がまったく違った型にも提供できるようにして欲しい。これだけのパワーがありながらも、言語としてシンプルクリーンものがいい。

これって、多くを望みすぎてるとは思わないよね?

僕らがごまかしようのないほど欲張りなのは分かってるけど、それでもぜんぶ欲しいんだ。二年半ほど前、この欲にまみれた言語を作り始めた。まだ完成してないけど、そろそろ1.0のリリースの時期だ。僕らが作った言語名前はJulia。すでに僕らの無礼要求に9割方は応えてくれてるけど、ちゃんとした形になるためには僕ら以外の要求も聞かないといけない。だから、君がもし欲張りで理不尽わがままプログラマなら、ちょいとこいつを試してもらいたいんだ。

我儘な開発者を満足させるための原語、というのはなんとも意欲的な目標だろう。

そして、その我儘を言う開発者が、今はやりの機械学習でも使いやすいだろう mathematica や R の行列演算統計計算世界を使いまくった連中が入っているところが今風の要求となっているようにも思う。

ちょろっと名前を聞いただけなので、これからなのだが、開発者としては、品質生産の加速がpython の一歩先を行くような世界であればそれは大歓迎だろう。

julia 何て名前を付けているから、検索すると AV女優の方が目立って出てきてしまうのである

https://qiita.com/sadayuki-matsuno/items/fc5e9ec3894a4b7bfbfb

ここからプログラムコードの断片をもってこようかとおもったが、

そのままコピーしても、今一歩な感じ。

ほらほら、

数式が数学で習った感じで書けるよね。

行列もほいほいかけるよね。

とかそういう小技が書かれているような気がした。

このあたりは、python限界を超えているので、見栄えはよいかもしれない。

2019-11-02

[]2019年10月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

441あとで/2227users 未経験でも1カ月で即戦力クラス知識が身に付く『webデザインドリル』公開 | knowledge / baigie

319あとで/2886users 賃貸住宅の退去費用として13万円請求された時の対応方法をまとめます|犬笛|note

305あとで/1662users 非デザイナーの僕がデザインぽいことをする時に使う便利なツール18選|かずたか@プログラミング独学して起業した人|note

260あとで/2214users 【朗報Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしま・・・これには金融マンも真っ青 | ライフハックちゃんねる弐式

228あとで/1529users 研修資料まとめ.md · GitHub

214あとで/1017users 技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog

191あとで/1517users 社会人の不幸の8割は合意のない期待から田中邦裕|note

185あとで/1788users この法律日本を「生産性が低すぎる国」にした | 国内経済 | 東洋経済オンライン | 経済ニュース新基準

182あとで/1222users 科学的で現代的な「人を動かす」──『事実はなぜ人の意見を変えられないのか-説得力と影響力の科学』 - 基本読書

180あとで/970users 3年かけてたどり着いた英語記事を読むための方法 - Qiita

172あとで/796users 文系大学生機械学習を0から始めて9か月でKaggle銀メダルを獲得するまで - Qiita

170あとで/669users いま知っておきたいLinuxWebアプリOSプロセスとしてどのように見えるか? を運用に生かす - エンジニアHub|若手Webエンジニアキャリアを考える!

170あとで/1344users 機械の立体図をフリーハンドでとんでもなく上手に描く人が製図のテクニック解説「恐ろしいレベル」「弊社に欲しい」 - Togetter

169あとで/2472users 食べログ3.8問題検証 - クイックノー

168あとで/1146users 質問が出ないのは話し手責任が8割。だから質問が出る」ようにルールを決めたら、大成功した話。 | Books&Apps

166あとで/898users 貧困を減らす実験アプローチ安田 洋祐|note

165あとで/679users 社内勉強会で作ったDocker/Kubernetes入門の資料公開しました - inductor's blog

164あとで/695users データサイエンス機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball

157あとで/1090users 20年の営業マン生活でわかってきた「仕事本質」を全部話す。 - Everything you've ever Dreamed

154あとで/953users 【インスタ、エアビーSlack等】人気サービスの初期ユーザー獲得方法

153あとで/1292users 【四川料理のスゴい人】家庭のキッチンの火力で「プロ並みのチャーハン」をつくる方法 - メシ通 | ホットペッパーグルメ

151あとで/1150users 0から100万円貯める、節約サバイバルガイド 

149あとで/1972users 巨乳炎上に見る進化文化ミスマッチ - 本しゃぶり

148あとで/637users WebサービスのA/Bテスト機械学習でよく使う「確率分布」18種を解説 - paiza開発日誌

147あとで/1149users フライドポテトチェーン店別徹底比較 :: デイリーポータルZ

143あとで/598users プログラミング命名規則ガイドラインを規定するオープンソースプロジェクト「NamingC - エンジニアプログラマのソーシャルITメディア

143あとで/661users ワークフロービルダーが新登場 : Slack簡単タスク合理化 | The Official Slack Blog

142あとで/564users 「単体テスト」再入門! 開発の現場バグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub|若手Webエンジニアキャリアを考える!

140あとで/1334users 13歳から43年間野宿していた「洞窟オジさん」はかつての住処でナニを食べていたのか?【極限メシ】 - メシ通 | ホットペッパーグルメ

138あとで/963users 自称IT企業があまりITを使わずに嫌になって野に下った俺が紹介するWindows自動化方法 - Qiita

138あとで/1513users あまりに多い嘘。探偵調査で見抜いた高知小2水難事故深い闇 - まぐまぐニュース

2019-09-24

プロはやっぱり業務で使えない

職業プログラマシステムの開発保守をやってるんだけど、色んな人が競技プログラミングにハマっているのをみてatcoderを始めてみて一ヶ月が経った。未だにF問題が解けなくて実力の無さを痛感してるけど、これ、たしかめっちゃ面白いアルゴリズム考える力もつくし、これからも続けようと思う。

それと同時に、やはり競プロ業務では使えないって思いが強くなった。「アプリを作るのが好きで、趣味で競プロもやってます」って人であれば面接で速攻でとると思う。問題となるのは「競プロ青色なので、プログラミングは得意です」という言い方をする人。その時点で俺なら落とす。

普段仕事プログラムを書いていると可読性とか保守をどうするとか、ほとんどの時間はそういうことを考えてコードを書いている。幸いそのお陰で、自分の関わるシステムは5年以上開発を続けても苦もなく保守できる状態が保たれている。しかし、atcoderに参加してみて、競プロ中は普段と全く関係のない知識を使っていることに気がついた。いや、使っているではない、使わざるを得ないのだ。

例えば、普段の開発では単体テストを必ず書くが、atcoderでは提出時間が早いほうが有利なため、簡単問題では単体テストが完全に無駄だという思いが脳裏に浮かんだ。システムを作るときには絶対にあってはいけない発想だ。回答を通す、という目的けがはっきりしているのも問題だ。参加中は可読性を上げるために変数名をつける、読みやすいようにリファクタリングする、などの行為がすべて無駄と感じられてしまった。回答を通すためだけに、 ad-hoc な if 文がどんどん付け足されていく。そして、回答が通った時点ですごく達成感が出てしまい、完成したコードにはまったく興味がなくなってしまった。atcoderに参加しただけで、普段システム開発をしている自分の頭がそのような発想に至ることがあるなんて全く想像していなかったので、恐ろしくもあり、競プロマインドシステム開発とは全く違うと痛感させられる経験だった。

こんなマインドプログラミングを覚えた人間は、絶対にまともな開発はできない。ひどい手癖が染み込んでいる上に、そこに自信を持ってしまっているのが非常に恐ろしい。ずぶの初心者よりももっと悪いと思う。

2019-08-17

考え方を変えたほうが幸せになれる。

エンジニアをしているが、

テスト仕様書を書きますねって言ってくれるディレクターがいる。

インフラからアプリケーションまで一人でやっているからか、自分仕事を奪われたようでちょっと悔しくなった。

これではシステム屋ではなくて、ただのプログラマーでは無いか…。

そこまで手が回らないって情けなくなってしまう。

ただ、

ディレクターがやってくれるのはあくま総合テストの事であって、

単体テスト結合テストエンジニアがしなければいけない。

それに、時間がないから「実際に使ってみて変な所があったら教えて?」

って言うつもりだったのを前もって準備してくれるのだから想定どおりでありがたいこと。

自分だってディレクターをした時は、エンジニアの為に色々補助や書類周りの作成してたっけ…。

そこで優越をつけてもしょうがないし、

素直にありがとうって言ってもいいよね。

自分嫉妬深さが嫌になる。

2019-03-18

anond:20190318185938

追記 0号相当は単体テスト用非動作機だったりメーカー通し(〇〇社試作第10031など)だったりして確かに現実には少ないかもしれない。

試行錯誤で出来た原型機がある場合は0になり得るが、ない場合には上に書いたような1番始まりの試作シリアルと量産シリアル体系がそれぞれ用意されるケースもある。

例えばボーイング787は試作機がMSN 40690/LN 1(ZA001)からMSN 40695/LN 6(ZA006)まであって、次の量産機が巻き戻ってMSN 34485/LN 7, MSN 34488/LN 8らしい。MSNとLNというのはボーイング通しの製造業者製造番号と787のラインナンバーだそうだ。

このケースでは試作と量産は同じシリアル体系のうち40kと34kという範囲違いだな。

F-15場合米空軍シリアル71-0280から71-0291が試作機として存在している。0280は0号機と言えるかもしれない。空自F-15DJの一号機二号機は02-8801と02-8802で、次の8機が飛んで12-8803から22-8810らしい。このNN-NNNNという体系は米空軍では共通のもの。頭二桁は初年度の会計年度かな。

ブコメで言われてる心神がX-2だかX-3だかいうのは米のXプレーンを真似たもので、F-15C-135などと同じように「X-2」までが機種名になる。

2019-02-20

メーカーSIer要求する単体テストが酷すぎる

メーカーSIer(仮にF社とする)のプロジェクトのもとで単体テスト工程に参画しているんだけど、非常につらいものがある。

テスト仕様書がつらい

エビデンスがつらい

障害報告がつらい


まとめ

この状況でテストする身にもなってくれよ...。

もう疲れた

2018-12-29

現場の他社の人たち、みんな口が達者で

さすがお客さんの会社系列だけあって、教育もしっかりしてんだろうな〜とか関心してた

けど、バグをけっこう出してた

バグ自体はまぁ、テストで出るものだとは思うが

プログラムコメントデバッグログ出力もきれいに削ったものだった

DB周りの処理やら他機能連携やら、異常としかさな

複雑な機能なのにこれでよく単体テストやれたなと思った

設計書で求められているログは出力している、とは言っていたが

そう思うとうちの会社の同僚はインターフェース周りの文書の食い違いに実装前に気づいて確認取ってたり

DB周りのエラーログを出力するようフレームワークに組み込んでたりと

実装周りではい仕事してるなと思った

トークはうまくない人が多いけど

2018-12-20

Clean Architectureから削ぎ落とせるものは何か

Clean Architecture良いねと言いつつ、みんな実務で採用しても何か削ぎ落として軽量化している。

そっちのほうが楽だからだ。

単体テストそんな書かないしね。

いや書いてるんだけど必要なところだけとか。

カバレッジ100%目指すわけじゃないんすよみたいな。

では一体、なにを削ぎ落としてるのか。

僕にはわからない。原理主義者が僕をイジメるのが怖いから。

2018-11-27

anond:20181127140718

単体テスト結果提出させないの?

ってか単体テスト項目を一緒に作らないの?

2018-08-11

http://blogos.com/article/317015/

例えば次の一文を取ってもこの人がシステムというものを何も理解できていないことが分かる。

コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。」

テスト実施には、時間費用人材などのリソース必要だ。

リソース無限にあるなら「考え得る限りの状況をテスト」することが可能だが、実際のリソースは有限だ。

極論すれば、1万年後、10万年後までのテストをするのか、考えてみるとよい。

また、テストには局面というものがある。

「日時を扱う」処理はライブラリにするのが普通だ。

ライブラリ単体テストでは、「2100年に2月29日はあるか」というテストを行うかもしれない。

しかし、結合テストシステムテストテスト局面が進むたびに、いちいち「2100年に2月29日はあるか」というテストを行うと、テストケースが爆発的に増えてしまい、これも現実的ではない。

「2100年に2月29日はあるか」というケースは、ライブラリ単位では保証されるかもしれないが、システム全体として保証されることはまずありえない。

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-04-28

ステップ

数年前に開発会社から全く別業界システム部門に入り、受注者から発注者立場が変わったので良い発注者になろうと頑張ってきたつもりなんだけど

日中途で入ってきた同僚が、長く付き合いのある開発会社に「改修案件の見積もり根拠が分からないので改修対象ステップ数とソース数を出せ」とか言い出して、それを止めようとした自分喧嘩になった、しかも「改修見積もりをしたのならステップ数は当然すぐに出せるはずだ」と言いながら

そいつは以前にも「単体テストの結果も全て説明付きの画面キャプチャエビデンスとしてつけろ。これは当然の事で、テストをしたのなら作っているはず。だから追加工数も払わない」と言い出してこれも喧嘩になった


残念ながらうちのシステム部門は専門の人材がいない為、こいつの言うことのおかしさを理解してもらえない

「規模を知るためにソース数を貰うのは当然の事です」とか言い出して、それをまわりが真に受けてしま

いくら自分反論しても1対1の話なので「やり方は色々あるからね」と窘められてしま

さらに本人には少し反論すると絶対に認めずかなり攻撃的に返されるという厄介さ

感じた事の無いレベルストレスを感じています。助けて…

良かったら対処案とか下さい…連休けが憂鬱だ…

2018-03-13

ひたすら単体テストをするにはどうしたらいいのか、単体テストをするようにコードを変更した後、その旨を安心して確認するにはどうしたらいいのか、

みたいなことを考えている(まぁ、こういうの好きやし、前のチームとタスク的に差がないからありがたいんやけど)

2018-02-14

anond:20180214191853

外注が「単体テスト自動化してますんで」って言うから意識高いな」って思ったんだが

納品物見たら、テストフレームワーク独自で、テストレポートカバレージも出ないし、テストコード中に「何をテストしているのか」のコメントも無いし、ほんとクソだな、と思ったことがある。

プログラマとして「あっ俺コイツに負けたわ」と思う瞬間

単体テストをちゃんと書いてるコードを見た時

2018-01-19

事業会社データサイエンティスト 会社退職しました

元々コンサル会社から事業会社のほうでデータサイエンティストをやるようになって1年経つが辞める。そのきつかったことを匿名という場所卑怯ながらも話したいと思う。

元々私は大学院でそこそこ統計をやってきてからコンサル会社に行きデータサイエンティストとして事業会社へ移った口だ。

根本的にデータサイエンティストとしての資質としてざっくりいうと以下の3つが必要だと思われる。

1. 統計能力関係及びそのプログラミング可視化能力

2. KPI設計及び事業からKPIへの落とし込みからそのKPIからどう事業繋がるかというビジネス設計能力

3. 上を基にしたコンサル能力

能力的には1がやや強く、その次に2がまぁまぁそして3はまだまだといった所で事業会社データサイエンティストとして孤軍奮闘をすることになった。

 入社理由

データはあるが、なかなか活用できていないこともあり、分析から企画から関われるという事で入社しようと思った。

後そこそこ大きな会社で働くのも良い経験と思い入社を決意した。ニッチな分野ではあるが、この分野ではTopカンパニーである

 実際の業務

最初の4日ぐらいは会社研修とかで潰れるのは仕方ないもので、それが終わり早速の業務を行う事になった。

まずはデータ各部門に依頼してから頂くのだが・・・

貰えない。

許可申請関係で3週間程かかってからまず最初データを頂けるようになった。この時点でやる気を削がれた。

更にデータ確認という事で事業へのヒアリングを進めるだけで・・・6週間程かかった。更にやる気を削がれた。

この辺りで気付いた事だが、コンサル会社でいたときは、データ確認がスピィーディーだったのに何故こんな遅い作業なったかというと

日本企業部署跨ぐというのはとても大変で、コンサルとしてやっていたときは単価も高いし、期間内でやらないといけないという事で

いろいろと調整がスムーズに進んでいたという事がこの時に分かった。コンサルとして外から見ているとやはり分からない事は多い物である

分析ツールエクセルだけ

データ確認も終わり、分析をし、改善を行うテーマを決めて進める事になった。この時点で2カ月ぐらい過ぎていた気がする。R/Python自分パソコンへの許可申請を出すが、降りない・・・会社的にはCならばOKだと言われる。でもCの追加ライブラリー関係ダメらしく・・・悩んだ結果エクセルを基に分析をする事になった。現状把握のために基礎集計をするが、エクセルSQLで言うGroup_byやら違うデータ同士をくっつけるためのJoinを32 bit エクセル関数ベースでやると何度も落ちる・・・。この時点でやる気は地の底へと落ちていた。

この辺りでCベースでもう書き直そうかと悩むが、流石にCのライブラリーがない所でフルスクラッチ調に書くのは工数的にかかると考えたのでvbaを用いていた。

エクセルベースでの可視化から上司関係者にデータ分析の結果を見せていく。この辺りでデータ分析から改善策はまとまっていた。しかしこの辺りでやる気をマイナスにして頂ける言葉を伺う。

私がVBAを書いているのをちらっと見て

プログラミング何かやっていても仕方ないし、プログラマーではねぇ・・・。今後会社ではプログラマーなんていらないか企画できるようにならないと」

勿論これは直属の上司からのお言葉ではないが・・・正確には同期である・・・もはや殺意すら覚える。因みにこの人の既存サービスの改良プロジェクトが回った時のデータ収集したら分析する事になっていたが、プロジェクトスケジュール感を見ると

要件定義 2週間

画面設計及び機能設計 3カ月

開発 4カ月

単体テスト・移行テスト 5カ月

運用以降

みたいな形でうん?何か少なくないか?と思ったら既存サービスに関してのギャップ分析無しに既存サービスの改良を進めているらしい

・・・その上取れるデータは〇〇〇で〇〇〇は無いらしい。あっそんなん改善出来んやん・・・。一応私はアリバイ工作のためにメール会議にて発言する

・・・空気を読めないと言われ会議呼ばれなくなってしまう(因みにこのプロジェクト要件定義から運用以降まで外注である)。

最早これは逃亡しかないだろうと心に固く決めてしまう。

私のコンサル的な能力がなかったと言えば確かにその通りである。でもいやうん日本企業の中で、分析をやっていくのは本当に難しいというのがよくわかる。

一人だったというのもある・・・でも殆ど基礎集計レベルで難しい用語を使わず改善を行おうとしたいやでもこの日本企業では無理だった。そしてやりたいと思わなかった。

たまに日本企業でのエンジニアの不遇差を嘆く記事を見かけるが、割と同じようなパターン臭いがする。

追記

新規リニューアルは当然のごとくつぶれ、また私がよくわからない事にawsへの移行だけは上手くいき(?)

200万pvの会員サイトAmazon aws料金を月々リザーブインスタンスで80万ぐらい払っていてクラウド安くないと社内的に炎上しているらしい。どんな設計したのかは

もはや手をつっこみたくないレベル

2017-04-21

単体テスト盲信してる皆様へ

そもそも意味あるのかちゃんと考えてる?

単体テストを書けばバグが減ります!」

単体テストのお陰で精神的安定を保てます!」

馬鹿じゃねーのかw?

テストコードメンテなんてデバッグの手順書メンテしてるのと大して変わらねーよw

その単体テストが本番と同一の動作テストできてる保証はねーって気づけボケ

本番と同じ動作テストたかったらデバッグしろ

なんで別のコード書き始めちゃうの?無駄じゃん馬鹿じゃん

それと「テストコードがあるから安全です」なんて寝言まだ言ってるの?

プロジェクトが進むにつれソース依存ライブラリも変化する以上

いつも同じ結果になるわけじゃねーだろが、(保守しないって選択はあるけど金入ってこないだろ)

本番でもテストコード動かしますってやつら以外無理して単体テスト書く必要ないんじゃねーか?

お前らが欲しいのは軽いデバッグモードであって単体テストじゃねーだろ?

工数削って単体テストを書いてソースが変わったらエラーになるからテスト書き直して・・・ってどう考えてもお前らが望む世界じゃないんじゃねーか?

流行りのTDDするくらいなら新人デバッグやらせた方がよっぽど筋がいい

というわけでよく考えなおせ

みんなが単体テスト言ってるから無理やり使うって運用やめろ

http://anond.hatelabo.jp/20170309040708

追記: 元ネタを茶化したジョークです

2017-03-23

わたしはしごとがあんまりできない。

具体的に言うと、

日本語での説明あんまりうまくできない。今日も後輩にJVMってなんですか、Staticってなんですかって聞かれたけど、なんかうまく説明できなかった。

あーなってこうなってっ説明しても、相手は「???」みたいな顔をしている…。

・深く考えられない。相手から意見言われと、思考が停止して「それが正しいまさに正解だ」という気持ちになってしまう。

たぶん他人から「1+1は3だよ」って言われたら、「えっ!?そうなの?そうなのか…」みたいな気持ちになって、最終的に納得してしまう。そんなレベル

不適切な場面で万能感が湧き上がることがある。「なんかできる気がする!!!スイッチが突然入る。

ただ、それは大体「気がする」止まりで、最終的に痛い目をみることが多い。

今日JVM説明するとき説明筋道考えてる最中に突然「なんかできる気がする!!!スイッチONになってしまい、

その勢いのまま説明を始めてしまった。結局、私の口からはぐしゃぐしゃした言葉しか出てこなかった。

単体テスト仕様書を作ると、割りとテストケースが足りてない。しかもそれは難しい観点のケースじゃないんだ。

自分の中で、もはや当たり前になってた観点なのに、ときどきボロンと抜け落ちる。

・誤字脱字などのケアレスミスも多い。印字切れとかもよくやる。

主体性がない。責任感がない。当事者意識がない。進んであれやりますこれやりますって、言ったことないなあ。


…もし上記を読んで「あーああいタイプ人間ね」みたいに想像ついた方いらっしゃったら、

恐れ入りますが現状を改善するためのアドバイスいただきたいです…。

上司に「そのままのキャラでいいよ」といじられるけど、本音は"もう諦めてる"なのかなあ。

ちゃんとした人間になりたいよ。

ログイン ユーザー登録
ようこそ ゲスト さん