「TDD」を含む日記 RSS

はてなキーワード: TDDとは

2020-06-25

テストコードが書けない

正確には一通り実装してからじゃないと書けない

なんで実装する前からテスト書けるのかがわからない

みんなt_wadaのこと盲信してるけど無理じゃね?

テスト書きづらいなと思ったら実装直すこともあるけど

最初テスト書けるってどんな脳味噌してんの?

TDDとかそれっぽいこと言ってるけどt_wadaの飯の種にしか聞こえん

プログラマ意識高いからこんなこと言わないけど

腹の中では同じこと思ってるだろ?

2019-12-05

滋賀県公式サイトリニューアルの件のアレについて(議会編)

http://b.hatena.ne.jp/entry/s/headlines.yahoo.co.jp/hl?a=20190729-00000074-mai-sctch

このニュースがバズった後、ニュースにも出ていない問題議会で追及されていたので、滋賀県議会のページ(令和元年9月定例会議(第9号~第15号)-09月30日-04号)をもとに、一部読みやす編集してみた。

ウェブアクセシビリティ試験結果と公表

議員
8月1日新聞報道で、滋賀県ホームページ総務省各自治体に対応を求めているウェブアクセシビリティ試験結果が公表されていないとの指摘があり、専門家から検査結果が公表されていないのは目標クリアできていないからではないかとの疑問の声が上がっている、との報道がありました。これを受けて、県は3月28日リニューアルから5カ月おくれとなる8月28日に、ようやくアクセシビリティ試験結果をホームページ上に公開しました。(中略)このウェブアクセシビリティ試験について、これはい実施されましたか
知事室長
アクセシビリティ試験につきましては3月11日に開始をし、6月5日完了いたしております。まず公開する前の内部環境におきまして、つまり3月の時点で、対象とするページデータ抽出し、アクセシビリティ試験実施をいたしております。その際には、対象40ページ・全体4万件余りの項目のうち、一部の項目につきまして不適合となったため、改善を重ね、公開後も検査継続し、最終的には全て適合となったということで検査完了した。それが6月5日でございます
議員
(中略)3月31日にホームページの再構築の完了報告書受託業者から提出されております作業完了とあわせて、納品物・成果物としてこのウェブアクセシビリティ試験結果もあわせて提出する必要性があります。(中略)3月31日にウェブアクセシビリティ試験結果というものは出されていたんでしょうか。
知事室長
提出をされております3月31日に委託業者から成果物として試験結果を報告を受けた時点では、先ほども少し申し上げましたが、試験対象とした40ページの試験項目約4万件余りのうち、98.1%が適合、残りの1.9%が不適合という状況になってございます。その1.9%の不適合の内容といたしましては、注意書きの漏れでありますとか、あるいは添付ファイルグループ化することが望ましいという指摘などでありましたので、仕様書に基づきまして、見やすさなどを考慮し、一定の水準に達していると判断し、検収を行っているものでございます。その後、改善の上、継続して検査を行い、全ての項目で検査クリアしているということでございます
議員
ちょっと幾つかわからない点があるんですが。では、3月31日に提出されたものは、この(6月5日の)検査証明書とはまた異なるものを出されたということですか。
知事室長
3月31日に提出されておりますのはそれ(6月5日検査証明書)とは別のもので、委託業者から検査結果の報告という形で受けてございます。その後検査証明書につきましては、6月の時点で全部が適合した状態ときに改めて提出を受けているという状況でございます
議員
これとは別のものが提出されているというのもよくわからないんですが、であるならば、3月31日に出されたウェブアクセシビリティ試験結果をインターネットに公開するべきではないんですか。
知事室長
お答え申し上げます。今ほど申し上げました経過等につきまして、わかりやすいように、ホームページでの公開につきましては考えてまいりたいというふうに思います
議員
であるならば、この(6月5日の)検査証明書はいろいろ問題があるんですが。まず「検査実施期間:2019年3月1日〜2019年3月31日」と書いてあります。でも、今おっしゃったのは3月31日ではなく6月5日ですよね。(中略)また、それぞれ検査日時書いておりますけれども、(中略)ホームページというのは日々内容が更新されますので、どの時点でのページを検査対象としているのかというのを明確にするために、「Libra」というソフト抽出時点のソースコードを記録して、それがサーバーに保存されています。その内容を複数検査員で目視それからプログラム検査しながらそのページを検査しているんですが、(中略)実はこの(検査対象ページのURLとして記載された)「https:」、いわゆるSSL対応というのが3月28日時点では行われていませんでした。いつできたのかというと4月3日なんです。(中略)6月5日に県が受理しながら、3月31日に検査期間終了したかのような形に書いてますけど、この検査報告書でそのまま県は受理しているんですね。私もいろんな書類を県に提出しますけど、日付が間違ってたらチェックして返されます。でもこの間違った検査証明書を県はこのまま受理して、しかもこれが今ホームページ掲載されてます。「2018年度の検査結果、つまり3月31日までに検査を行いました、検査結果はAAでした」という形で。県もそのことをわかった上で意図的2018年のものとして掲載されている。(中略)矛盾するんですが、公室長、御説明をお願いいたします。
知事室長
業者から3月末の時点で一旦提出をされ、その後改善を重ね、全て適合した形で6月の時点でその証明書が発行され、そしてそれを県がホームページ掲載したというものでございます。この御質問検査証明書につきましては、検査機関により発行されたものでありますので、改めて確認をさせていただきました。その検査証明書検査実施期間につきましては、昨年度の再構築事業におきまして当初に検査を予定していた期間を掲載をしている。そして検査日時については、検査を開始した日時を記載をしたものであるということを確認しております
議員
はい、私も確認させていただきました。ここの検査責任者に直接確認をさせていただきました。「当初予定していた検査期間に作業が終わらなかった。結局完了したのは6月5日までかかってしまった」と。これ、(3月31日に検収された)ホームページの再構築業務に含まれ業務の一部です。見積もり額でいきますと80万円です。3月31日までに完了させなければならない業務完了していなかった。加えて言いますと、検査するだけでなしに、(中略)先ほど仰いました98.1%以外の部分の修正作業というのはそれ以降行っておられますが、それも本来3月31日までに完了しなければならない業務が、結果、完了していなかったということの裏づけとなるこの検査証明書だと思うんですが、公室長いかがですか。
知事室長
先ほど申し上げましたように、全体の項目のうち98.1%が適合、1.9%が不適合という状況でございました。この状況を受けまして、仕様書に基づき見やすさなどを考慮し、一定の水準に達しているもの判断し、検収を行っているというところでございます。その後におきましては、保守業務の中で改善をし、その上で検査を受け、全ての項目がクリアをされたということでございます
議員
議論が前へ進みませんので次行きますけど。(中略)前のホームページとき検査結果が以前はありましたが、リニューアルに伴いなくなってしまいました。これ、勝手に消してしまっていいんでしょうか。検査結果に限らず、今回リニューアルによって、この公文書とも言えるデジタルアーカイブ勝手に消されている部分がたくさんあるんですが、公室長、そのあたりの見解を伺います
知事室長
過去のものでありましても、やはりしっかりと公開すべきものというのはあるかというふうに存じますので、他の都道府県の事例なども参考にしながら、望ましい公開の仕方につきまして考えてまいりたいと存じます

CMSライセンス契約ライセンス料の支払

議員
県が行った座談会の中で、CMSライセンスについての質問が出たと聞いております。今回導入されたCMSライセンス契約はどのようになっているのか伺います
知事室長
CMSライセンスにつきましては、昨年度は再構築等業務委託契約、今年度は保守契約に基づきまして、委託業者から滋賀県提供するように定められているところでございます。このCMS著作権はもともと徳島県帰属しております現在ライセンス供与方法やそのライセンスを使ってCMSの利用・改修を行うことにつきまして、問題がないことを直接確認をいたしております
議員
それを書いた書面等は存在しませんか。
知事室長
ちょっと私の手元にはございません。あるのかないのかも少し私の段階ではわかりませんので、改めて確認をさせていただきます
議員
私が確認しました範囲では、ライセンス契約書という書類存在しないと聞いております。今公室長は「昨年度は再構築の中で、今年度は保守契約の中でライセンス契約を行っている」と仰いましたけれども、CMSに関するライセンス記述というのはどこにもございません。再度説明を求めます
知事室長
今、契約書・仕様書の中につきまして詳らかに全てを理解しているわけではございませんが、構築業務におきましてはCMS一般的に開発業務の中に含まれもの理解をしておりますし、保守業務見積もりの中にそのことは明記していると承知をしております
議員
私、確認しましたが、保守業務の中にも明記はされておりませんし、ソフトウェアに関しては明記されておりますけれども、そもそも過去の打ち合わせの段階の議事録を見ましても、ライセンスの話はどこにも出てこないんですね。先般の座談会で(話題に)出てきて、慌てて調べたらこライセンスの話が出てきた。じゃあ、これ一体ライセンス料って幾らなんですか。
知事室長
ライセンス料が幾らかということにつきましては、直接幾らと示すようなものはございません。先ほど申し上げましたように、業者徳島県との間で話がされているものでございます
議員
まり、本県においてそれは保守に含まれる、昨年度における再構築の金額に含まれるということなんですが、(中略)そういう状況であれば、これまでの打ち合わせ書類の中ですとか見積もりの中に、このライセンスというものが明確に書かれるべきなんですが、実態としては書いた書面も何も存在しない。業者との委託契約だけ。業者がいなくなれば、滋賀県ライセンス権利をどうやって主張するんですか。
知事室長
現在ライセンス活用方法等につきまして、先ほど申し上げましたように、著作権を有している徳島県に直接確認をし、問題ないということを確認をしておりますが、今ご指摘いただきましたような事態が生じたときにどうすべきであるかにつきましては、十分研究することが必要かというふうに存じます。しっかり研究してまいりたいと存じます
議員
契約プロセスもそうですし、その後のやりとりに関してもそうなんですが、非常に不透明な部分ですとか詰めの甘い部分ですとか納得のいかない部分、この(アクセシビリティ検査証明書に至っては全く意味がわかりませんし、今もこの状態ホームページ掲載されているんです。どういうつもりか知りませんけれども。

今後の対応

議員
今後の対応について、どのように考えているのか伺います
知事室長
県民の皆様からお寄せいただきました御意見専門家の助言を踏まえまして、まずは今年度におきまして、制度概要や各種申請などのいわゆるストック情報につきまして、時系列以外のよりわかりやすい表示方法検討するとともに、タイトルのつけ方や記事掲載場所掲載期間の設定などが統一されるよう、庁内で協議を進め、掲載に関するルールを定めてまいりたいと存じます。その上で、来年度にはストック情報等について時系列以外でのわかりやすい表示に改め、情報の探しやすさを向上させてまいります。また、スマートフォンでの閲覧、操作利便性を一層高めていくため、文字の大きさや行間の設定、メニューの配置など、ページのデザインをより見やすく、使いやすものにしてまいりたいと考えております
議員
今、大きく2つの要素があったと思います。まず前半部分で述べていただいたのは運用面で工夫しながら改善できる部分、後段の部分スマホ対応等々つきましてはシステムをさわると、そういった解釈をさせていただきました。ただ、いずれにしましても今仰った対応では、今後の対応改善できる部分と、なおかつ改善できずに課題が残り続ける部分それぞれ存在すると思いますが、その部分どう考えておられますか。
知事室長
現在の県のホームページをできる限りよりよいものにしていくため、今ほど申し上げましたように、今年度から来年度にかけまして、さら改善を図っていきたいと考えているところでございます。そのほかにも、もっと詳細な分析に基づく利用者目線に立った動線設定でありますとか、メニュー分類などに関する御意見があることは認識をしておりますし、この議会でもさまざまな観点で御指摘をいただいております。昨年度から進めました今回のリニューアルに際していただきましたさまざまな御意見をしっかりと受けとめ、先を見据えながら、ホームページの利用状況や世代ごとの情報入手動向等を可能な限り分析し、今後の再構築業務に生かしてまいりたいと存じます
議員
幾ら今のシステムを頑張っていじっていっても、解決しない問題解決しません。やっぱり構造上に欠陥がありますので、そこは努力で、あるいはお金を積んだところで改善できる話ではありません。(中略)今から新しいものをつくるとしても、1〜2年でできる話でもありませんし、かといって今のシステムは今後5Gがやってくる中で1020年使うシステムでもありません。であるならば(中略)今後の改善に向けて、明確なロードマップというものをお示しをいただきたいと思いますが、そのあたり、知事質問いたします。
知事
今の時点でロードマップを全てお示しすることはできません。まずは今年度から来年度にかけて改善をしっかり行います。その先に、今も議員から言葉として入れていただきましたが、5Gの時代の到来を見越して、より広報広聴のプラットフォームとして、例えば双方向通信をどのように可能にするのかといったようなことでありますとか、大体ホームページは5年に一度のペースで改修・改善をしてきているということもございますので、その先を見通した体制なり、また課題の整理をする必要があると考えております。そのため、庁内におきましても検討を行う仕組みを整え、専門家の方々の知恵等もおかりしながら、今回いただいた課題等もしっかりと議論を行いながら、入念に次に向けた準備を進めてまいりたいと存じます
議員
(中略)今、これ中途半端になっていますけど、この検査証明書の日付がおかし問題とか、まだこの場でクリアできてません。知事との政策協議会でほかの会派からも出てましたけれども、やはりわかった人を入れて第三者検証委員会なり立ち上げてしないと、非常に不透明な処理、不可解な処理が調べれば調べるほどたくさん出てまいります。(中略)そのあたりのお考えがあるのかどうか、再度、知事質問いたします。
知事
いただいたさまざまな課題等につきましては課題として受けとめて、改善のために取り組んでいきたいと思います

2019-05-28

ニート脱出のため、プログラミングを独学するも仕事が見つりません

現役のプログラマweb制作ソフトウェアに関連する産業従事される方々のアドバイスを頂きたいです。また、ニートから社会復帰された方のアドバイスも頂きたいです。

注意: いわゆる特定を恐れてかなりぼかした表記をしているのですが、ぼかしすぎとの指摘をいただければ可能な限り追記いたします。ただし、GitHubプロフィール/WebアプリURLについては、就職活動のための個人情報が含まれている可能性があること、宣伝すべきでないことから、ここで公開をすることはありません。

自身について
プログラマとして

素人同然かもしれませんが、適切なアドバイスを頂くために必要だと思うので、書かせていただきます

成果物について

Webアプリ概要: 複数の外部APIを組み合わせて定期的にデータ更新される(現時点で数百万程度のレコード数)、ユーザ操作リソース更新されることはない(すべてのendpointが認証なし、GETのみ)

面接に間に合わせるように作ったのですが、残念ながら一度も面接官/採用担当者の方にご覧いただく機会がありませんでした。(そもそもGitHubについてご存知の面接官の方がいらっしゃらなかった…)

内容としては、モダンWeb開発の基礎を一通り踏まえた構成になっていると考えています

応募資格の壁・いざ面接

ソフトウェアエンジニアの取扱いが多い求人サイト(Find Job・GreenWantedly)、一般的大手求人サイト派遣会社ハロワ、横断検索サイト(Indeedなど)、Google検索

インターネット上で公開されている、通勤できる距離求人情報は片っ端からクリックしました。(Google検索site: ... ※実際には求人サイトドメイン結構効果的でした)

良さそうな会社はたくさんあったものの、応募資格の時点でほとんど諦めることになりました。(実務経験以外なら必須でない条件を含めて満たす求人もありましたが、必須条件を満たさないために応募をすることはありませんでした。)

社会経験」「実務経験」を必要としない寛大な会社は、ほぼSESしか存在しないようです。

「1年以上の実務経験」を必須とする、時給1000円のアルバイトはたくさん見つかりました。(ZOZOアルバイトが1300円で話題になりましたが、1000円のアルバイトでもそこまで求められるのかと思ってしまいました…)

視野を広げてWebデザイナーやHTMLコーダーを見てみると、実務経験に加え、「Adobe製品使用経験」(料金が払えない…)「Wordpressサイト運用経験」「ポートフォリオサイトを持っていること」が必要会社ほとんどでした。

VPSWordPress+nginx+SSL(Let's encrypt)で構築したことはありますが、1人で更新する分には静的サイトジェネレータを使ったほうが簡単で、GitHub Pagesなどで無料で公開できるので、実際の運用には至りませんでした。

やはり、自分デザイン系の会社が求める人材ではないと思います

応募資格の時点でほぼ応募できる会社存在しない中、応募資格を満たす会社に片っ端から応募して、数社面接までたどり着きました。SES以外面接落ち、SES会社は一次面接通過後に辞退させていただきました。

面接で基礎的なコンピュータサイエンス/アルゴリズム知識を問われる可能性を考えて、それらの基礎も学習しましたが、これもまた面接使用する機会がありませんでした。(それ自体無駄ではなく、むしろ自分のためになるものでした)。

どうすればいいのか

以下の選択肢は現時点の自分にとって現実的ではありません。


私の文章力が低く、読みにくい文章であったとすれば、申し訳ございませんでした。これでも下書きを一度破棄し、表現に気をつけながら、書きあげるのに数日を要しました。これが私にとって初めての増田での投稿で、「この内容を登録する」ボタンを押すのにも勇気必要でした。

厳しいご意見を含めた、皆様の返信・ブコメをお待ちしております最後までお読みいただきありがとうございました。

2019-04-27

俺のヒプノシスマイクは死んだ

ヒプノシスマイクにとても夢を見ていた 女尊男卑面白いラップミュージック面白い音楽言葉で左右される世界、なんて面白いんだろう!ジェンダー論に興味があるしラップミュージックが好きだ 二次元女性向けとされたジャンルでどう展開されてゆくのか、楽しみで仕方なかった

しばらく経って まず、コミカライズ女尊男卑設定がガバガバの浅慮なものだと知った 幻滅した ラップミュージック代替わりしただけの「兵器」だと知った 心底、幻滅した なにもワクワクしなかった 絶望さえした シナリオライターは、きっとジェンダー論に興味も無ければ、ラップミュージックも好きではないと思った

ならば、ならば愛した男たちの、そのコンテクストバックグラウンドはどうだろう?最も焦がれた男は、母親父親を殺して自殺したという悲惨環境にも関わらず、よく笑い、妹の誕生日にはフルコース手料理し、珈琲の淹れ方に拘り、タワーマンションで暮らす男だった

心底、幻滅した 殺してやりたいとさえ思った

プロジェクト始動時に公開された、あの殺意に満ちた声色はどうした?もう背水の陣だと言わんばかりの、鬼気迫る台詞回しはどうした?おい、その目の前の男は、心底執着して、憎んで、殺してやりたいほど、何も、微塵も、譲れない、宿敵なんじゃないのか?どうして、そんな他愛ない言い争いをしている?

じゃあ、もういい わかった 賢い消費者なので、手にする商品を選ぶことができる 大丈夫 見たくないものは見ないし、要らないものは手に取らない それでいい 楽曲は、歌は、言葉だけは正しいだろ それだけがわたしの中のほんとうであって、正義大丈夫 そうして、4/24を待った

終わった そう思った 俺のヒプノシスマイクは終わった、死んだ!

正直TDD楽曲の時から引っかかりは感じていた 作曲者アニソン畑の人間なこと、伝説グループ代表曲だというには、少しばかりポップなチューンだということ いや、それもただ、ささいなこと、ささいなことだった 目を瞑れた Hoodstarのサビが急にブロードウェイになるのも構わなかった 目を瞑れた

TLでstellaの感想を読んだ!心底、心待ちにした トレーラーすら聞かなかった 全ての楽曲の中で、最もPCCSが好きだ、愛している!世界もっと面白いはずだと、そう親愛なる共犯者が言ったので!だったら彼らの作る曲は、歌は、紡ぐ言葉は、いつだって奮い立たせると 本気でそう思った

絶望した これが絶望というものだとわかった

まず語りから入るのがダメだった ポエトリーラップですらない、ただのキャラクターとしてのセリフ ダメだった だってそれはラップミュージックというか、アートというか、キャラクターソングであって、それは、音楽というか、キャラクターセリフではないか

うその時点で興味は八割失せていた 彼らのなにを聞いてもダメだった 心が、受け付けなかった もうこれは、ダメものだと そう思ってしまった

それでもTLの親愛なる彼らは楽曲を絶賛した Stellaは最高!やっぱり楽曲は信じられる!アルバム、ハズレ曲なんて一つもない! 目を疑った 嘘だろ、わたしにとっては、どれも当たってない

ああ、終わった もう本当に、「呼ばれていない」 そう思った

以前から度々友人と話していたことには、わたしらは「呼ばれていない」のだと 客層ではない ヒプノシスマイクビジネスだ 彼らの求める顧客層というのは、掛け軸を五万で買う人間であり、バトルとなれば何十万と金を掛けて票を投じる人間であるのだ

そもそも論アーティストとして彼らを見ている姿勢こそが、楽曲アート性を求めることそのものが、わたしが、ダメなのだ、呼ばれていないのだ、わたしは、ヒプノシスマイクの客に、なれなかった

悲しい 悲しいなあ だってよかったじゃん、楽曲 なんだよ 今更そんな、そんなことする?なんで、なんでキャラクターにするんだ なんで だってチグリジアだって、PCCSだってBBBだって、デスリスペクトだって、よかったじゃあないか、なんで、なんでだよ、あんな良い曲だったのに、なんで、なんでだ、

でも、あのね、これは「女性向け二次元コンテンツ」なんだよ、アーティスト視することそのものが間違いなんだよ、わかるだろ、キャラクターソングじゃないか!と憤ることが、嘆くことが、それこそがそもそも間違いなんだよ、わかるだろ、顔と声の付属品なんだよ、曲は なあそうだろ?

なんかもう、脱力だよ もう何もいいや あーあ

2019-03-01

プログラミング、三大胡臭い開発手法

自動テスト

ペアプログラミング

 

あとは何だろ

アジャイル胡散臭いんだけど、メリットデメリット理解やすい方だと思う

 

追記:語弊があるな、自動テスト重要だ。TDDXP界隈と言ったほうがいいか

 

追記胡散臭いのと、不要ってのはちょい違う。必要でも胡散臭さは放てる。過大評価が近い。あと、複数人でやる方法論で胡散臭さが出がち。

2019-02-06

例えばDDDが好きじゃないとか、TDDが好きじゃないとか言うと、エンジニアはギョッとした顔で僕のことを見てくる。

まぁ実際スクラム必要ないみたいな話を聞いて、私もギョッとした顔をしてしまたことがある。

TDDDDDスクラム、型宣言オブジェクト指向原則デザインパターン、、、、

ソフトウェアエンジニアリングに於いて数えきれない聖書みたいなものがある。これらの聖書はすべての宗教聖書に一読の価値があるように、いいエッセンスが詰め込められている。

ただ、全てを一度引き出しにしまって、まずはコードを書くべきだ。

もちろんテストを書いてはいけないとも、クラス図を書いてはいけないとも、言ってはいない。

あなたソフトウェア判断に迷った時に聖書金言と見比べよう。

もし聖書には今のあなたの状況にあった教義が見つからなかった場合は、他の聖書に手を取ってみよう。

聖書の内容を頭に入れることは常に次のことより劣後すべきだ。

コードを書くこと

コードを読むこと

仕様を考えること

顧客と話すこと

他のエンジニア相談すること

2019-02-01

ヒプノシスマイクは何がしたくてどこにいくんだオタクは泣いているぞ

男性声優×ラップヒプノシスマイク女性キャラクター立ち絵を公開した件でまた炎上している。私調べで1週間ぶり5回目の炎上燃えすぎ。もはや燃えカスになっているのではないかと思いきや、まだ燃えてる。すっごい。

かくいう私も1週間くらい前、新しいドラマトラックの公開を機にヒプノシスマイクを降りた。コミカライズ1話を読んだ時から降りるか降りないかウジウジ悩んでたんだけど新しいドラマトラックが酷すぎて秒で降りることを決意した。ちなみにヨコハマ推しだった。

降りた後は、一応かなり思い入れのあるジャンルだったので、RADWIMPSの「もしも」の「もしも時が戻るならば純粋のものだった君にまた出会いたい もしも時が戻らぬなら素晴らしかった君に恋してた僕のままで」という歌詞自分とヒプマイを重ねてシクシク泣いたりした。完全に彼氏と別れた後みたいな感じだった。


だって過去のヒプマイは本当に素晴らしかったのだ。こう言うと何だか古参面してるみたいでイヤらしいが本当に割と古参だったので許してほしい。

そもそも2017年の秋に始まったプロジェクトなので古参新参もクソもない気もするけど。でもヒプノシスマイクというジャンルを新と旧の大きく二つにわけると、その分かれ目はあのめちゃくちゃバズったバトルアンセム(全員が歌ってるやつの二曲目)が公開された頃ということにはなると思う。むちゃくちゃかっこいい曲だったよね。かっこよすぎて、初めて聴いたとき「こんな幸せでいいの?」って泣いたし。

あの曲のおかげでヒプノシスマイクというジャンルが本格的に世間認知されるようになったのかなと思う。し、同じように思ってる人も多いはず。

さてそのようにして2018年夏頃人気を爆発させたヒプノシスマイクだったが、この後から雲行きが怪しくなり始める。仕上がっていない声優のいるライブ。まったく出ない円盤(でも映像はあるらしい)。音ゲー化決定。歩数計バトル(これは面白かったけど)。バトルの勝者に贈られる賞品(これは賛否両論あるけど、物議は醸した)。

そしてCDについているドラマトラックの、脚本。これに関してはかなり早い段階からおかしくなり始めてはいたのだ。というかそもそも最初からおかしくはあった。でもそのおかしさがなんか面白かったしウケていた。ように思う。

声だけで展開されるので、多少キャラクターがブレていてもトンチキな言動をしていても私たちはそれをスルーというか、見て見ぬ振りをしていた。もしくはなんかいい感じの妄想で補って脳内でいい感じの方に持っていっていた。

私は入間銃兎推しだったけど、ドラマトラックで彼が中高生喧嘩を売り始めた時点で「ん?」とはなっていた。でもそんな気にしてなかった。

もう一回言う。そんな気にしてなかった。というか気にしないようにしていた。なぜならヒプノシスマイクにおいて最重要なのは楽曲であり、ラップバトルだったから。曲とラップむちゃくちゃ楽しかったのでストーリーはまあそんなに気にしなくていいかな、て感じだった。


しかしそのようなスタンスだった私のような者に致命傷を与える事件が起こる。

コミカライズ

これに関しても、最初は「へー!コミカライズ立ち絵数枚の推しがついに……」みたいな感じだった。だってコミカライズって、"スピンオフ"でしょ?って感じだったかである

インターネットの奥地でこんな愚痴を読んでいる人は全員知っていると思うけど、知らない人もいるかもしれないので説明する。ヒプノシスマイクキングレコード内のレーベルが手がける「男性声優×ラップソング」のプロジェクトである

その言葉の通りオタクコンテンツヒップホップガチ曲を男性声優が正々堂々と歌う。そしてファンが得られる情報公式HP立ち絵キャラ紹介と楽曲CDに収録されているドラマトラックのみ。完全に"音"がメインで展開されていくジャンル

一体誰が、そういった音楽がメインのジャンルで、突然コミカライズストーリーの本筋を描き始めると思うだろうか?

誰も思わん。私も思わなかった。周りのみんなも思ってなかった。不意打ちだった。

別にドラマトラックをなぞるだけならいい。それならあくまでメインは、ドラマトラックであり、耳から入る情報から。けれど三つある(なんで三つもあんの?)コミカライズのうち一つは、作中で伝説とされているグループTDDの結成から解散までを描く前日譚だった。それだけならまだいいよ。本編の補完って感じなら、別にいいよ。

でも、世界観重要な設定とか、今後のストーリーに絡んでいく新キャラとかをコミカライズで出すのは流石に違う。

違うでしょ。違うよな?私の感覚おかしいのかな?そんなわけないよね?だって実際かなり燃えたし。

今まで"音"がメインだったわけですよ。楽曲ドラマトラックのみでストーリーが展開されていくっていうワクワク感が私は好きだったわけ。わかるか?わかってくれるよね この気持ち

それにドラマトラックをなぞるだけならまだいいってさっき言ったけど、音声だけならスルーできていたキャラのトンチキな言動とか、ちょっと現実離れした設定とか、視覚化されたら、もう見て見ぬ振りできんのですわ。もう見逃してあげられない。嫌でも目に入ってくる。圧倒的違和感

と、いうわけで冒頭に書いたみたいにコミカライズ1話を読んだ私はかなり悩んだ。理由は上に記したことと、もう一つ。ストーリーがすんごいつまんなかったから。もう話が矛盾してるとか破綻してるとか世界観あやふやすぎるとかこのご時世にジェンダーに関わる話にするならもっと考えなよとか色々全部ひっくるめて、「つまんなかった」で表現してもいいか?いいよ

それでも過去ヒプノシスマイクむちゃくちゃ楽しいジャンルだった(お正月remixとか)ということや、仲の良いフォロワーがいることなどを考えるとなかなか離れる踏ん切りがつかなかった。

しかしたらコミカライズはこれから面白くなるのかも。話も辻褄があうのかも。もしくは、コミカライズは読まないでCDだけ聴けばいいんじゃないか?今までだってCDドラマトラックだけでこのジャンルは成立していたんだし。ね?

コミカライズ読まなければいいんじゃない楽曲を楽しんで、ドラマトラックだけ聴けば話がわかるんじゃない?ね?

だってCDが、楽曲が、ドラマトラックがメインの原作でしょ?だよね?ね?ね?そうだよね?ね?



違った。1週間くらい前にyoutubeで先行公開された、次のCDに収録予定のドラマトラック(てか30分全部公開とか、CD売らん気か?)。コミカライズに登場した新キャラたちの名前が当然のように出てきた。

つーか名前キラキラネームすぎて目で受け取った情報と耳で聞いた音とがイマイチ合致しないけど、当然のように名前出てきた。あとキャラクターの1人の口調が変わってた。そんなのありかよ

コミカライズを読んでいない人は、確実に話についていけないだろう。

というか読んだ私も話についていけなかった。

全員別の人みたいだった。

そこで私はようやく、私の知っているヒプノシスマイクが全く別の、私の知らないヒプノシスマイクにいつのまにかすり替わっていることに気がついたのだ。

こうして私はもうこのジャンルについていくことは無理で、私とヒプノシスマイクは完全に志を違えてしまったのだという実感を得てRADWIMPSを聴いて泣くことになる。


以上、ジャンルから離れて微妙に日数経ってるのに、オトメイトが関わっているジャンル既存キャライラストも数枚しかない状態女性キャラ新規絵を出したヒプノシスマイク面白すぎて我慢できなくてこんなん書いてしまいました。

コミカライズが無理で、ストーリーが無理で、新しいドラマトラックが無理で、と言うと必ず「脚本家はずっと一緒の人なのになんで急に無理になったの?」という疑問をぶつけられますが、それはつまり、こういうことなのです。

見て見ぬ振りしてきたところを、見て見ぬ振りできなくなったから。

そして見て見ぬ振りできなくなるような売り方に変えたのは公式です。いやまじで公式に恨み言とか言いたくないし、私ヒプノシスマイクのこと大好きだったから、本当に、別れるのは辛い。横浜とかなんかもう元カレとの思い出の場所みたいになった。

だって出来ることならずっとヒプノシスマイク応援たかったし推しのことを好きでいたかった。でも無理になった。公式の売り方のせいで。


変わったのは私じゃない。ヒプノシスマイクだ。そしてそれに怒るのは絶対に悪いことじゃない(すごく攻撃的になるのは違うけど)。私は自分勝手なので、これだけは言いたかったんです

2018-12-18

anond:20180720024344

このエントリを書いて半年ほど経った。読み直すと論旨が二転三転していたり、啓蒙を気取った書き方だったりして恥ずかしいけれど、そう指摘してもらえて冷静になったののあり、以来、ちょっと離れてなんとなく見守ることにしていた。シンジュクが勝ちましたね。アルタ前の人混みの写真を見て、大当たりで大人気でよかったじゃん、と思えるくらいには、心の距離が取れていたんですが。

ヒプノシスマイクTDDコミカライズを読んで、解釈違いで検索に引っかかるツイートを眺めて、このコンテンツに対する失望がどんどん強くなった。

ヒプノシスマイク怖い話で私がジェンダー意識的にどうなの、と取り上げたのは(取り上げたかったのは)、

○女だけが覇権を握る世の中→女全体を憎むような描写(具体的には左馬刻の「クソ女ども」発言)

○の割には壁の外では男女は平等(?)に働いている様子(具体的には一二三が独歩の職場ナンパ→それでクビにならないくらいの距離感)

○壁の中でもさほど虐げられたり侮蔑される訳では無い様子(具体的には三郎がレストラン店員女性生意気な口を訊いても追い出されなかったこと)

この辺りだった。

まり憎むべき敵=独裁政権を「あの言の葉党とかいう奴らめ」ではなく、「あの女たちめ」という括りにしてしまうのが雑ではないか?ということ。

それに加え中王区で娯楽的に男達のラップバトルを消費する女たち、にファンを重ねるような投票システム

この2点が重なっていることを不愉快に思ったのだった。

(投票システムについてはどんどん自分が中王区の女と重なっていくのが楽しい、という意見を見て、なるほどそういうこともあるのか、と思ったので、今はさほど危険視していません。)

で、今回のコミカライズ

女性政権側の東方天乙統女が愚かな男と煽るような発言を繰り返していたのもあり、少なくとも「男全員お上喧嘩売られてる」状況なのは理解した。そして逆上したモブキャラの男たちが「女なんて所詮男の道具なんだよ」と言い放ってしまうくらいには「愚か」な、なるほどこれくらいの性認識なのか。

自分だってあの世界の男ならクソババア!くらいは言うかもしれない。ああいう言い方をする乙統女は少なくとも男女の間に壁を作り対立させようとしているように感じるから

けれど正直なところ、2年後の世界で目論見通り性別で分断できている様子や、性別で分断する意味があったと感じる描写はまったくない。もしかしたらTDDが動きを起こし、ドラマパート程度まで動きを落ち着けたのかもしれないな、とは思った。

これは一読者の体感だが、やっぱりこの程度のシナリオだと、女性独裁政権!というセンセーションナルさのために無邪気に作られた設定としか思えないのだ。なぜなら行間に見える日常生活で、男女の扱いの差がほとんどないから。その甘さがやっぱりどうしても気になってしまう。

左馬刻の妹が巨乳から炎上、という外部野次には笑ってしまったけど、かわいくてスタイルがいい、食事の準備をしてくれる妹というキャラクター像に対してコテコテ理想女の子らしさを感じたのは事実だ。それもガッカリ感に輪をかけた。

結局自分はこのコンテンツの作り込みに満足できないのかもしれない。楽曲レベルの高さで勝手に期待して、それならシナリオもきっと沢山考え込まれている、そのはずならここやここは不躾すぎる、そういうふうに思って私はエントリを書いたから。

今回のコミカライズは傷ついた、というよりは「なんだったんだよ」と力が抜けて笑ってしまうような話だった。もう積極的に買って読むことはしないと思う。感想が結局アンチみたいになってしまったのが、展開を楽しみにしていたファンとしては残念で、こうやって未練がましく長文を書いていること自体ファンダムへの砂かけと取られかねない。

でもまだ第一話、全三本の並行連載だし、どんどん良くなっていくのならこれ以上のことは無い。そうだといいな。

2018-11-30

anond:20181130160338

スクショとるってのは、UIテストであって、ブラウザ自動操縦なりしてテストすると思うんだけど、それってTDD(先にテスト作る)成り立つの

2018-06-06

anond:20180604223911

DDDTDDに置き換えて、全く同じこと言いそう

2017-12-04

待ち合わせの約束をすっぽかされることが多い

相手勘違いや、単純に忘れた等で、すっぽかされて、その場で時間が過ぎてから連絡を取って、しょんぼりすることが多い。

私自身がすっぽかしたことは、人生で一度もない。

直前のドタキャンはまだともかく、連絡すらなくてこちからするって相当でしょう?

つい先程も、習い事約束をすっぽかされてしまった。

隔週で回数がことなるため、勘違いしてしまったらしい。

相手必死に謝っており、1年弱の付き合いで普段はこんなことな相手だとしっているので、こちらとしては、

いえ、いいんですよ、それでは明日会いましょう

くらいの感じで対応した。

これとは別の話として、友人と遊ぶときや、異性を食事に誘ったようなときも、すっぽかされたことがちょいちょいある。

それぞれに事情は聞いているのだけれど、事情真相がなんであれ、

個別事象はともかくとしても、人生においてこういうことに遭遇することが多いというのは、

私は平均的に他人から舐められてるんだろうなって思う。

今日必死謝罪する相手言葉電話越しに聴きながら、そんなふうに目の前の問題とはちょっと違うところで少し落ち込んだ。

私の容姿フランシス・ガヌーみたいだったら、きっと違ったはずだ。

ヌー来年UFCヘビー級チャンピオンになります

ヌーグラウンドに穴があるんじゃないかという意見がたまに見られますが、

カーティスブレイズとの試合を見ればわかるように、意外とTDDは良い動きをしており、TDされてしまった展開でも、すぐ立ててました。

また、この試合での2Rまでの動きを見ている限りでは、スタミナがまるでないタイプではないのも明らかです。

以前の試合では、スタンドキムラをセットしてのサブミッション勝利という、意外な程の対応力も見せており、その上で彼のスタンドは恐ろしいの一言

証明されていないものがあるとすれば、グラウンドでの柔術への対応でしょうけど、

あの程度のレスリング対応力と馬鹿力があれば、穴があったとしても、ヘビーでは大抵の相手にはなんとかなるのでは。

先日の試合ノーダメージでしょうし、来年早々にはミオシッチとのタイトルマッチが見たいな。

2017-04-21

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

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

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

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

馬鹿じゃねーのかw?

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

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

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

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

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

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

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

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

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

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

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

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

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

http://anond.hatelabo.jp/20170309040708

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

2014-11-10

http://anond.hatelabo.jp/20141110015137

そうなんよね。金がありあまっててミッションクリティカル携帯キャリアならではって感じではあったのでちょっと記事アドバイスとしては適切じゃなかったかも。

記事で言ってたように根幹のチェックして検収OKでもいいとおもった。そのシステムトレードオフどれくらい許容出来るかって感じで割り切りでいいと思う。

 

まるぱくりだけどKent beckトレードオフの制約を貼っとく(TDD議論で出てたものだけど受け入れテストにも適用できるとおもう)。

 

■ 頻度:どれくらいの頻度でフィードバックをもらいたいか?

■ 精度:レッド/グリーンシグナルに求める精度はどれくらいか?

オーバーヘッド:どれくらいのコストを費やせるか?

寿命:存続の見込みと期間の両方を考慮したソフトウェア寿命はどれくらいか?

2014-10-11

アプリ屋がRailsを初めて触ってみて感じた事

Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。

発想が古臭い

モバイルファーストAPIファースト文脈ハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLゴリゴリ生成するなんてよほど特殊最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLメタプログラミング等のテクニカル技法宝石のように鏤められている様はまるでエジプト時代骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。

モデルMVC

Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsクラスディレクトリという特定実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナル概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。

レールから外れる辛さ

Rails界隈の人がよく「Rails流儀」や「正しい"MVC"」というのを口角泡を飛ばし議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRails世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインサービスレイヤ名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別名前役割を与えられても正直しんどいので、皆が皆libゴミを放り込んでいく様子にも納得がいきました。

レイヤ?何それおいしいの

RailsAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsリファクタ手法と称されているものクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときセットポジションDDD青本を投げつける必要が有るなと思いました。

TDDやれんのか

ビューとコントローラを結合させた場合結合テストはCapybaraとかのBDDマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。

分業とか出来るんだろうか

ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーRubyバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。

RESTとかきついです

RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思いますGETbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTあくまリソース抽象化する美しい概念なので、アクション副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間しか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計拝借することはよしとしても、「○○はRESTでは無い故云々~」みたいな注文はやめて頂きたいものです。

そんなに嫌なら他に行けば

とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまサーバーサイド初心者感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います

だってRuby楽しいんだもの

2014-05-11

プログラマってさ

クリエイティブ仕事に憧れてたけど、絵も描けず、楽器もできず、文章も書けないみたいなワナビーこじらせた人間たちの最後の逃げ場って感じがするよね。

RailsjQuery作った人間はすごいけど、それを使うあなた全然すごくないじゃん。ただの消費者じゃん。

でも絵や音楽と違って供給者と消費者の境目が一見曖昧からなんかすごいように他人も自分錯覚するんだよね。

それもワナビーを呼び込む理由なんだろうけど。

TDDとかも、それを導入したら現場効率が上がるとか本当はどうでもよくて「TDDやってる俺かっこいい」なんでしょ?

ワナビーとしての充足願望が満たされるんでしょ?

それで「会社TDDを導入するにはどうしたらいいか」みたいなブログ書いたらはてぶで「こいつはわかってるヤツ」みたいなコメントもらえて嬉しいんでしょ?

そりゃ教条主義に陥るわな。反原発Twitterでつぶやいて仮初の賞賛を集めるニートと同じだわ。

まあ「銀の弾丸は無い」って言ってるヤツも「銀の弾丸は無いって言える俺かっこいい」だから本質的には同じなんだけどね。


以上、ワナビー自己紹介でした。

2014-05-08

Google先生TDDテスト駆動開発)の評価を尋ねてみたよ

検索窓にふと tdd is って打って出た候補にワロタwwww

容赦なさすぎやろw

さらに、"tdd is a-z"の結果な。

tdd is a
tdd is a waste of timeTDD時間無駄
tdd is b
tdd is bullshit(TDDはたわ言)/tdd is bad(TDDは悪い)
tdd is c
tdd is crap(TDDは糞)
tdd id d
tdd is deadTDDは死んだ)
tdd is h
tdd is hard(TDDは難しい)
tdd is n
tdd is not a silver bullet(TDD銀の弾丸ではない)
tdd is o
tdd is overrated(TDD過大評価されている)
tdd is p
tdd is pointless(TDD無意味
tdd is s
tdd is stupidTDDは愚か)/tdd is slow(TDDは遅い)/is tdd still used(TDDはまだ使われているの)
tdd is u
tdd is useless(TDDは役に立たない)
tdd is w
tdd is a waste of timeTDD時間無駄

肯定的な文句がまったく出てきませんでした。事実はともかくとして、このように思われているということでしょうね。啓蒙は難しそうですね。大変ですね。

こちらからは以上です。

2014-02-25

初音ミクオンラインかるたゲーム「ミクミクかるた」を作ってみた

初音ミクオンラインかるたゲーム「ミクミクかるた」をリリースしました

http://mikumikuplay.com/karuta/

個人で開発して、開発期間は3週間くらいです。

■紹介動画URL

http://www.nicovideo.jp/watch/sm22964822

リリースしたものの過疎ってるので、増田宣伝をさせてくださいなと!

「ミクミクかるた」はブラウザで簡単に遊べるオンラインかるたゲームです。ゲームルールは簡単で、ボカロ曲が流れたら、歌詞の先頭文字の札をクリックするだけです。「みっくみ~くにし~てあげる♪」と流れたら「み」の札を取りますかるたの札の読み上げの代わりにボカロ曲が流れるというシステムです。オンライン対戦することも出来ますボカロ好きな人たちが集まって遊べる場になればと思っています

ゲームで使わせて頂いた曲はpiapro(ピアプロ)でお借りしました。改めて素晴らしい曲がたくさんあることを知り感動しました。このゲームによって素晴らしい曲が、より多くの人に聴かれることを願っています

実はこのゲーム開発者である私もボカロPをちょびっとやっています。私の場合、曲を作ってニコニコ動画にアップしても2日も経てば再生数の伸びが止まってしまます毎日すごい数の曲がアップされている為、すぐに埋もれてしまうのでしょう。私の曲は大したことがないのでいいのですが、中にはすごく良い曲でも再生数が少ないものが多々見られます。このゲームによって埋もれている隠れた名曲に、光を当てられたらと思っています

以前、「ミクミクすごろく」というオンラインすごろくゲーム(http://mikumikuplay.com/sugoroku/)を作り、ユーザーイラストと文章を作ることによってゲームコンテンツ拡張していくことが出来るCGG(Consumer Generated Game)の仕組みを作りました。CGGはブログなどでおなじみのCGM(Consumer Generated Media)のゲーム版に当たります

今回開発した「ミクミクかるた」では、開発作業をニコニコ生放送で配信していました。すると視聴者の方がゲーム機能デザインについてのアイデアコメントしてくれました。コメントしてくれたアイデアほとんどを採用しています。言わば、生放送駆動開発(Live Driven Development)と言えるのではないでしょうか?まぁ、これは悪乗りですが・・・

最近流行している開発手法としてテスト駆動開発(Test Driven Developement→略してTDD)というものがありますTDDをするとテストやすインターフェースモジュール設計が出来るようになりますが、この生放送駆動開発すると、ユーザーが望んでいる設計が出来るのではないかと思います。新たな開発手法発見することが出来ました。

■特徴一覧

ボカロ曲歌詞の先頭文字の札を取るかるたゲーム

ニコニコ動画等で埋もれてしまっている隠れた名曲に光を当てるシステム

Webブラウザのみ、ユーザー登録なしでプレイ可能

・開発作業を生放送で配信して視聴者から貰った意見を反映

HTML5Node.jsによりWebブラウザゲームにおけるリアルタイム処理を実現

ユーザー登録なしで簡単に遊べるのでぜひPlayしていただいて感想とかダメ出しとかしてくれると嬉しいです!よろしくです!

2014-02-12

何でソフトウェア開発の手法って上手くいかないの?

私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールシリコンバレー会社でも働いたことがある。私は12種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。

( 注:ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法プログラミング工学風のプロセス提供してくれる。しかし、上記の理由でそれだけでは不十分だ )

ソフトウェア開発手法が上手くいってる」っていつ言うことが出来るの?

チーム生産性幸福度メンバーのつながり・1日あたりのコード量・人月コード品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか?

もちろんどんな手法だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題  ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。

上記は私の経験則だけど、僕の知ってる殆どプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」

こんな思考実験をしてみよう、

つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。

この思考実験にはもちろん意味がない。メンバー一人ひとりのスキル性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。

アリスター・コッバーンが2003年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。

" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "

私達の最大の敵

私がプログラミングを始めた1970年当時、開発体制プロジェクトマネージャービジネスアナリストシニアプログラマと言った階層構造ガッチリ管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。

今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマ監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。

ガントチャートスケジュールドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルコーディングを放っておいてるのに、彼らは自分好きな手法適用するか作るかさせて、1980年代以上に決め事・儀式だらけだ。 

実際、今のプログラマは1970年代COBOL現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。

プログラミングチームが手法論を採用する(多くの場合チームの数名か、一人のいじめっ子が決めるのだが)と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジー生産性を高めるより早く、チームの生産性を下げてしまう。

で、何がうまくいくの?

私の経験から言わせると、アリスター・コッバーン論文やフレデリックブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクト成功させるにはチームメンバーが共通のビジョンを共有する事(その本では「コンセプトの統合」と呼ばれている)が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了ボタンクリックするだけのチームで働いことがあるが、何故か分からないがBDUFアナリスト監査の元で働いていた昔よりも気分が悪いものだった。

私はプログラマ様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマ手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。(私は必ずしもそうだと思っていないが。)でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。

これの翻訳です。

http://typicalprogrammer.com/why-dont-software-development-methodologies-work/

注1 '14/02/11 まだ半分しか翻訳してません。(明日完成予定)

注2 '14/02/12 翻訳完了しました。コメントの指摘に対応して文章を一部直しました。ありがとうございます

2014-01-23

テストファーストなんて幻想だ。TDDなんて空想だ。

理想

 テスト書く

 ↓

 テストコードレビュー

 ↓

 コード書く

 ↓

 コードレビュー

実際

 コード書く

 ↓

 コードレビュー

 ↓

 テスト書く

 ↓

 コードレビュー

になってるんだけどさ

これ、テストコード書く意味あんの?

2014-01-15

プログラマ会社的には

プログラマと呼べるようなスペシャリストが不在で、

多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社

そんな会社だと、プログラムでなるべく解決する(コードが業務プロセスを頑張っちゃう)ために頑張るよりも、

業務プロセス開発プロセス全体で最適化するよう頑張った方が、

たいていはハッピーであることに気づいた。

プログラムで頑張ろうとすると、

学習コストがかかりすぎるか、

外注するのに設計しようにも結局学習コストがかかりすぎるとか、

外注とのスムーズな協力関係無駄に気を使うとか、

外注が逃げるとか、

引き継ぎ先がいなくて死ぬとか、

そんな余計なことが多かった。

反復性・正確性が求められるものプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。

プログラムによる生産物を主要な糧にして事業をやっていると、

ともすればプログラムスペシャリストでないことに大きなコンプレックスを抱くけど、

生産物割合ライト公共性も低い(例えばエンタメスマホアプリ)だったら、

無理にスペシャリスト風にやる必要はない。

身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。

オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して

ライトフレームワークを選択して、ライト開発プロセスでやる選択がもっと歓迎されていいと思う。

そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からボトムアップ的な思想やツールでなく、

マネジメント視点経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。

プログラマ経営層になっての話は近年よく聞くけど、非プログラマ経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。

こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。

暇ができたらまとめたいなあ。。

その前に売上UP(白目)

2013-12-27

カバレッジ厨は消えろ

テストコードカバレッジ100%とか何バカなこと言ってんの?

お前がカバレッジ100%だと思ってるそのテスト全然スカスカですから

カバレッジ厨がTDDBDDだ、UnitTestRSpecだと騒いだところでバグは一向に無くなりませんから!!!!!

2012-09-04

最近意識高いエンジニア達に感じる違和感

勉強会っていうかOFF会だよね

勉強会のつもりで行ったらただのOFF会であまり勉強にならない、という事が多い。

(OFF会的な側面がメインなら、そう銘打って欲しい)

何そのLT信仰

アウトプットは大切だけど、LT銀の弾丸ではないので万能のように言うのいくない

何そのTDD信仰

テストファースト有効な場面が多いけど、TDD銀の弾丸ではないので万能のように言うのいくない

何そのアジャイル信仰

アジャイル理念は素晴らしいけど、アジャイル銀の弾丸ではないので万能のように言うのいくない

何その特定言語信仰

全ての言語銀の弾丸ではないので、万能のように言うのいくない

Twitterセキュリティのあれこれしているの、何か秘密警察みたいでアレ

アレ。。。

いじょー。

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