「イテレーション」を含む日記 RSS

はてなキーワード: イテレーションとは

2024-02-17

今後3年以内に起こることは「ミニコミ媒体の復活」なのではないか

①生成AIの影響で真偽が判断つかない情報や、無意味・無内容な情報が、加速度的にSNSなどに溢れかえる

➁もはや、オープンSNSインターネットはスカム情報で溢れかえりナンセンスで役に立たないものになる

オンライン/オフラインわずニッチフェイス2フェイスコミュニケーション流行

ニッチコミュニティを横断するミニコミ媒体需要が復活する

意味のある情報」が人の手に戻ってくる時代と考えると、インターネットがより身近になる、人間中心的テクノロジーになる契機なのかもしれないよね。もはや、「ただの情報」がスカム化して意味をなさなくなり、「人とのつながり」みたいなコンテクスト重要になる。

この話はなにも生成AI話題に出すまでもなく、そもそもインターネット広告モデルの持つ情報流通脆弱性の話なんだけどね。

まりインターネットはすべてをフリーにした。そういったアナーキー価値観草の根的に生まれ世界だった(cf.自由ソフトウェア運動)。だけど、それじゃビジネスは成り立たない。

そこで、インターネットがたどってきた道はこうだ。

アナーキストたちは採算度外視で(そもそもそういう商業主義否定するんだからそりゃそうだ)市場を壊していく。「無料アクセスできる」情報には誰も金を払いながらない。だって、値段をつけて売られてるものが、ネットならタダではいから

そのため、商業主義者たちは考えた。「つまりエンドユーザーには無料で届けなければ太刀打ちできない。なら、エンドユーザー商品にして、toBエンドユーザーを売ればいいんだ」。これが今日まで続く、インターネットで主流の「広告モデル」によるコンテンツ生産だ。

しかし、インターネットの「広告モデル」は、これまでのメディアのそれと大きく異なる。なぜならば、トラフィックのすべてが事細かに分析対象となり、しかもそれがリアルタイムで見えてしまうから。つまりウェブコンテンツは「この特定ページのこの部分にこのくらいの時間滞留する。だから、ここに広告を置けば見えやすい」ということが分かってしまう。

これは大問題だ。クリエイティブっていうのは、コミュニケーションっていうのはそういうもんじゃない。数字言葉に現れない絶妙な采配。そこにしかクリエイティブは宿らない。なのに、それが許されなくなってしまった。

そうなるともう、アテンション・エコノミー問題につながる。さらに注目を、さらに注目を、そんなことをしているうちに「何に注目したらいいか」をゆっくりと捉える時間がなくなり、「安易な刺激」に逃げるようになる。

タイパ」という言葉最近話題らしいが、あんものは嘘っぱちだ。「安易な刺激」のイテレーション周期をいくら速めたところで、そこに「意味」はない。TikTokを2時間見る時間があれば、映画館に行ったり、コンサートに行ったりして、「意味のある体験」をしたほうがよっぽどパフォーマンスはいいはずだ。

そして、「タイパ」という言葉流行さらに「生成AIによる情報のスカム化」は、いわばこの「無意味な加速」の極限であり、ピー状態である。つまり、このバブルはあっという間に弾ける。徐々にその加速が無意味であることに気が付き始める。(cf.寝そべり族、Doomer、だめライフ

からこれからは、「ミニコミ時代」だ。自分たち時間を大切に、自分たち価値を大切に、自分たちいのちの使い方を大切に決められるオルタナティブライフが求められる。そうした血の通ったネットワークが求められる。そこに必要なのは、内部の結束と、外部への発信としての「ミニコミ」なんだとおもう。

2023-12-10

技術負債を返済すること

コードを書いていて、2つの選択肢に襲われる。

一つは少し時間をかけて整理された読みやすコードを書くこと。

もう一つはすぐに仕事を終わらせるためにそれっぽいコードで終わらせること。

後者を選ぶと、どんどんと技術負債のしかかっていく。

開発のイテレーションの中では、過去コードリファクタリングする時間など無いことが多い。

から今、少し時間をかけるべきことが多い。

このような技術負債意図的負債と言われる。

意図しない負債というのは、きれいコードを書くようにしていても、問題領域のものが難しくて整理するのが難しくなってくることだ。この場合は、設計の方に重点を置くのが良い。

2022-06-08

Backlogの前にやるべきことは何か?

これ

家庭にBacklogを導入してタスク可視化しようとしたら大失敗した

https://anond.hatelabo.jp/20220607152713

 

会社でもよく見かける気がするんだけど、複合問題だと思うんだよな

 

やりたいこと:タスクをやってほしい

Backlog解決すること:タスクの整理、進捗管理

 

ここでずれてると思う

タスクやらせる」の解決策として「タスク管理ツールの導入」は間違いどころか逆効果かもしれない

元増田も気づいてるけど

 

タスク可視化会社において重要

会社では、予算計画を立てて、リソースを確保し、それを実効するというのが基本サイクルだから

タスクはだいたい明らかになっている

その全タスクが膨大だったとしても「やりたくないなあ」にはならない、仕事なんだから

金を稼ぐという目標があるからできる

 

じゃあ私生活でこれをやるとどうなるかというと

可視化されたらやることが膨大でやる気を無くす

リソースが限られている

・やっても金が稼げるわけでもない

から、当然やらない

これは家族間でやってもそうだし、自分でやってもそうだろうと思う

 

タスクやらせる」というのは、普通に親のようにガミガミ言ってやらせるか、もしくはゲーミフィケーションの導入が妥当だと思う

ものすごく平たく言うと「恐怖で支配する」か「褒めて伸ばす」か

つってもゲーミフィケーションも難しいし大変なんだけど

相手との関係性が(たとえ会社であっても)重要になってくる

夫婦間?無理に決まってる

 

ところでこの

可視化されたらやることが膨大でやる気を無くす

リソースが限られている

・やっても金が稼げるわけでもない

から、当然やらない

 

という状況はベンチャー企業の状況に似ている

彼らがよく言うやり方は「タスクの取捨選択」「イテレーションを回す(スクラム、かんばん)」だ

タスクを洗い出す、1週間でできることだけやることリストに入れ、実施し、振り返る

このフローだとよりうまくいくかもしれないが

これだってやる気が無いやつのケツを叩くだけのパワーはないので

スクラムマスターのような、いわゆるマネージメントをする存在は不可欠であり

マネージメントでできるのは上で言った「怒る」「褒める」程度のものなんだろうと思う(ここらへんは専門外なので詳しくない)

 

ちなみにBacklogはこのようなかんばん方式フォローしたらしいので使ってみるといい

https://backlog.com/ja/blog/backlog-update-2020-01-28-kanban-board/

 

あ、ヌーラボ上場おめでとう

長かったね

俺の記憶だとブームredmineBacklog→jiraと変遷したと思ってたけど着実に頑張ってたようだ

たまに使ってるよ

 

あ、ごめんタイトル全然違う話になってるわ

Backlogの前に、目的明確化をしたいね

それはほんとうにBacklogツール)で解決するのか?

 

ーーー

 

そうか、平たく言えば「人を動かす技術」か

確かそう言う本あったよね、詰んでるわ笑

2022-05-31

anond:20220531145117

システム開発でも、現場を知らない管理職連中が馬鹿げた仕様をたくさん詰め込んで、

いざ運用に回ると、現場からボロクソ言われるんだよな。

しかもたくさん詰め込んだ分密結合になってるから、改修コスト無駄にかかるっていうねw

住まいアジャイルみたいにイテレーションが回せたらいいなって思うよ。

2021-10-21

弊社のゴミみたいなアジャイル開発に名前を付けてほしい

(従来通りの俗に言うウォーターフォール的なプロジェクト計画だと)1年ぐらいのスケジュールを引くところ、

アジャイルで3カ月のイテレーションを 4回繰り返すと言って 開発をスタートさせておいて、

実際には やり直しができない。

最初の3カ月で作ったものを 仕切り直ししようとしても、認められない。

色々と説得を試みたが、鼻から 仕切り直しを認めるつもりなんてなかったことに今更気付いた。

1年規模のプロジェクトを3カ月で無理やりやらせただけ、エンジニア負担を強いる方便として

アジャイル開発が利用されている。そもそもお人良しすぎた俺が悪いのだ

2021-05-29

anond:20210529092037

そんなことはどうでもいいか

早く開発初めて

イテレーション回して

さっさとリリースしてね

わかった?

仕事遅いんだよ、まったくも〜

2020-06-24

リモートワーク

働き方は今後も変わる。

リモートワークでもパフォーマンス落とさないためにはスピードをあげることだ。

そうだ働き方を定義する。月曜にレビューしてやることを決める。残り4日で

タスク切って開発してリリースだ。これが新しい効率的な働き方だ!

とか言ってるの。世間知らずの上司ドヤ顔で。

開発イテレーションは2週タームでずっと稼働してるし、かなり先まで

スケジュール織り込んでる。企画案件にしたって開発要件情報設計

4日程度でやったところで、ザルだらけの精度低い事故誘発するような

アウトプットばかりで手戻りばっかり。

「あの会社はそうやってるんだ。うちもやるぞ」とか言ってるの。もうみてらんない。

サービスも開発環境リソーススキルセットも違う。そもそも対応するシステム

うちはレガシー大戦艦(それが良い事ではないと理解はしてる)だぞ。

なぜ利己的な馬鹿出世するのだろうか。

大企業の中で生き抜く能力はたしかに高い。が、なるほど、優秀だった先輩が

次々とドロップしていく理由がわかった。

2020-05-27

COBOL現場社会科見学してみたい

PHP使ってwebバックエンド開発をメインでやってきたけど

最近逆にレガシー仕事に興味が出てきた

ファイルに日付入れて管理したりそういうやつ

会議室みたいなところで長机を共有して貧弱PC仕事するんでしょ?

PC立ち上がるまでにタバコ吸おうかみたいな

あと多分ウォーターフォールで開発してるのかな?

かいイテレーションさないでどうやって人が使えるシステムが作れるのか興味ある

正直COBOLが何できるのかよく知らんけど

金融系で何かやってんだよね、あとNEC汎用機?(汎用機ってなんだろう?)

触ったことも見たこともないけどすげえ読みづらそう

あと、いかにもオタクって感じのおじいちゃんがたくさんいそう

一つ質問したらそれに回答しないで別の自分が話したいことをずっと話してそう

単価安いのにいつまでもその仕事にしがみついてるってどんな気分なんだろう

1日だけ体験してみたい、そしてネタにしたい

2020-05-22

anond:20200521225730

プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。

JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScript改名されたり、規格を話すときECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。

Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。

Javaは初期のころオートボクシング / アンボクシングもなく、ストイックオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコード簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である

PHPWebネイティブ言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能初期化していない変数最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列数字臨機応変に切り替える機能もあり(今もそうかは知らん)、数字文字比較比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。

C#Hello Worldくらいしかいたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。

C++黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーション腱鞘炎になることもない。PC Unixにも最初から環境インストールされているか簡単インストールできるので毛嫌いせず使うとよいと思う。

Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。

CSS...はプログラミング言語なのか?そうか。

TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。

Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるからカーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。

これ以下のランキングのもその気になったら書こうかな。

2020-04-17

anond:20200417082609

エクスペンシブ人材は切られてチープ人材で埋めるって戦略もあるだろ。そういう意味ではリクルートはサイクルドイテレーションだよ。

2020-03-28

アジャイルってなんだっけ?

システムの作り逃げはなぜ起こるのか - novtanの日常

アジャイルって「テストに通るだけのクソコード量産体制」じゃない? 

ウォーターフォールが良いとは言わんが、デザインパターンと、ドメイン単位での分離をやるには、ある程度の設計必要だよ。

アジャイルにせよプロトタイプにせよ本来時間効果お金で買う為の手法なのだが、

なぜかこれらの手法効果コストメリットがあるというアホな技術者発注者蔓延しているのが原因かと。

時間お金がほぼ全て

RFP以前に、そのシステムで何をしたいのか明確にできず「いい感じでやってくれ」としか言えないような組織

アジャイル? 安くて速い? それで行こ!」な経営では、企画失敗の連帯責任すら負わされる。逃げるべし。

細かくイテレーション回して検証していくのがアジャイルだと思ってけど違うの?

2019-08-08

anond:20190808004550

よーしじゃあ次は「何を作るべきかすら明確でない」という新規事業のための開発やってみようよ。

さなチームで高速にイテレーションさないと破綻するの。

2018-04-15

システム監査技術者2018/4/15メモ

覚えている内にメモ

■午後1

<大問2>

設問1:本番運用サーバに負荷を与え、予定や会議室登録などの従業員の通常業務に影響するリスク

設問2:申請者に、個人情報の利用目的・保管場所削除予定日を確認し、実際に削除されたことも確認すること

設問3:必要以上のサービスレベル提供する体制を用意することにより、コスト配分を最適化できないリスク

設問4:活用検討会の議事録を通期確認し、新規データおよび追加収集したデータの利用状況を確認する

設問5:会議開催実績表を通期確認し、情報共有を目的とする各部門の会議が減少していることを確認する。

<大問3>

設問1:a=新販売システムでの自動チェック

設問2:b=EDI取引契約

    c=受注伝票

設問3:e=1注文が10万円以下となるように分割発注されてしまう、

    f=受注責任者が、承認なしで処理したデータ一覧を日次で確認する

設問4:g=出荷完了リスト出力時に、当日出荷日のデータが出荷入力されていない場合に通知する機能があるか確認する

■午後2

<大問1>

難しそうだが選択者が少なく採点甘めになりそうだったこと、

H25午後1--問1がアジャイルに関するもので、イテレーション毎の反省会

要件スコープの逸脱に注意する点などが述べられていて、覚えていたためにこちらを選択した。

# TAC合格トレーニング本の解説もためになった。選んでよかった。

設問ア:

システム概要を述べる。インターネットシステムのほうがよさそう。

開発会社のPKG部分からの追加開発が多いこと、

要件不明瞭な点が多いこと、社会情勢によって本PJへのコスト配分を検討したいため、

などがアジャイル開発を採用した理由とした。

アジャイルの内容としては、イテレーション4週間で設計・開発・テスト・UATおよび内部分析したこと

開発環境に関しては、自動ビルドデプロイツールを利用したこと記述

設問イ:

2-1 体制スキルに関するリスクコントロール

 ①アジャイル経験者がないために、PJが進められないリスク

 ②アジャイル経験者がないために、Pスコープ外の顧客要件対応してしまリスク

 ③アジャイルにおける開発環境構築の経験者がいないために、テストが遅れ納期間に合わないリスク

これらのリスクに対するコントロールとして、PMPJ立上げ時に各経験者を参画させる必要がある。

また、開発が進んだ時には、1イテレーションの終わりに、当サイクルのプロセス分析し次サイクルに

改善点を生かしていくコントロール必要

2-2 開発環境整備に関するリスクコントロール

上述の③のようにスキルのある人材必要だが、実際の構築にあたり、

実はスキルが無く、進められないあるいは構築した環境品質がひくくなりテスト進捗が遅れるリスク

期待したメンバが、他タスクに埋もれ本来環境構築作業に着手が遅れテスト進捗が遅れるリスク、がある。

このコントロールとして、PMが構築時の進捗および品質を把握し管理する必要がある。

設問ウ:

3-1 体制スキルに対する監査手続

監査証拠  :PJ立上時のPJ計画

監査手続き :体制図の説明を査閲する。

監査ポイントアジャイルアジャイル用の開発環境構築のスキルを有していることをPM確認しているか

       またコレに関する上長承認を得ているか

監査証拠  :イテレーション毎の成果分析会の議事録

監査手続き :査閲する。

監査ポイント:終わったイテレーションプロセス反省・次への改善点に言及されているか

       次サイクルの同議事録で、その改善効果言及できているか

3-2 開発環境整備に対する監査手続

監査証拠  :構築フェーズにおけるPMPJ進捗報告書

監査手続き :査閲する。設計工程や構築工程フェーズアップ資料か。

監査ポイント環境構築の進捗が把握されていること。環境の構築品質について評価していること。

監査証拠  :実際に構築された開発環境

監査手続き :開発メンバあるいはテストメンバにヒアリングする。

監査ポイント:開発したモジュール自動デプロイされ当日あるいは翌日に当該機能テストができる状態か。

以上

2017-09-09

アイドルマスター シンデレラガールズ U149 はつまらないという話。

まず何も知らない人に簡潔に書くと、『アイドルマスター シンデレラガールズ U149』(以下適当に略す)とは『アイドルマスター シンデレラガールズ』(以下適略)というゲームコミカライズ作品の一つである

コミカライズとしては原作に対して忠実さ・リスペクトのある作品一定以上の品質もあるのでファンアイテムとしてはそれなりに良いものだ。一方で、原作を知らない人にとっては取るに足らない凡庸漫画ひとつに過ぎないという、よくあるコミカライズ作品である

Web漫画としてサイコミで連載されていて今なら最初から全部読めるので興味がある方は読んでみてもいい。

https://cycomi.com/title.php?title_id=46

こういう前置きをしている私は上記に当てはまらない、アイドルマスターシンデレラガールズ既存ファンである。それを前提にして本題に入る。以降の話は関連作品も含めてネタバレを有することを注意しておきたい。

本題

この作品は非常に退屈な物語である

コミカライズとしては及第点以上を取れていると思う。漫画に限ったことではないが、世の中には自己主張控え目な毒キノコのように見る者を誑かし食することで生命を脅かすように読んだ者の精神健康を害する作品があることを思えばよっぽど良い。そういうものに金を払った経験はいっそ高度な文明的行いのようだった。

さて、それでも私の周りで似たような意見を聞くのでそれを取りまとめておきたい。

作品問題に対する指摘はいくつかあるが、ここでは一つだけ取り上げる。

それは物語が繰り返しに過ぎないということ。

ただし、この言葉には二つの意味がある。既存ファンでなくても気付く点、既存ファンにだけ感じられる点の二点において、この物語は繰り返しである。前者を単調であるといい、後者を焼き直しと呼ぶ。この二点において少しだけ掘り下げる。

単調な物語の繰り返し

今ならタイトルページに全ての話が並んでいるのでそれを眺めれば、この漫画原作のことを知らない方でも各話のタイトルにはより小さな物語主題とその話の順の数字が割り振られていることに気付くし、そのすぐ後には最初を除いた全てがキャラクター名前であり、各話がそのキャラクターに焦点を合わせた内容であることを理解する。

これは単調な物語という問題が、表出しているのである。この作品はより小さな物語の3話毎の繰り返しであるのだ。

物語の主要キャラクターであるアイドル少女たちは9人いる。

この9人のプレティーンが自己存在意義をかけて衝突したり複雑な人間模様を描くということはない主題になっているアイドル以外は添え物で誰でもいい場合が多い。もちろん例外もあるが、せいぜい一対一の関係だ。ここにプロデューサーという『アイドルマスターシリーズで要となる役目を持つキャラクターを加えても何も変わらないことは一読すればわかるということも付け足しておこう。

このように個人に根差し問題解決を3話毎に繰り返している。この個人に根差し問題という指摘は後にも関係しているので覚えておいてほしい。

さて、3話というイテレーションが、序破急が、問題提起確認解決という流れが、如何なる読者にも理解できるのはある切実な悪影響を産む。読者の誰もが次の話を更新を待たなくてもどうなるのか、結末は果たして何処へ行こうとしているのか容易に想像できるし、その想像を超えてくることは絶対にない。個人に完結する問題バリエーションに変化を付けるのは難しい。特にこの作品は主要なキャラクターをプレティーンと限定しているのでそれが顕著に表れる。また、解決手法に目を惹くものがなくむしろただの会話で済んだりするので盛り上がりや起伏、それによる興奮がない。

読者の期待を煽ることは決してなく、要するにただただ単調なのだ

焼き直しの繰り返し

どのようなWeb漫画サイトも同様に、序文に書かれるあらすじを読めば誰でも物語全体の概要理解できるだろう。ここで同作品最後の文を引用する。

さなアイドル達と小さな新人プロデューサーが贈る、新しいシンデレラストーリーが開幕する。

しかし、既存ファンにとってこれは新しいシンデレラストーリーでは無かった。

前項で個人に根差し問題という指摘を行った。これがなぜこの作品既存ファンの心象に退屈さを塩傷口よろしく塗り込まれ現象となる理由は、それは原作ゲームがもう何年も更新され続けているゲームであり、かつアイドルとそのプロデューサーとして一対一の関係を描いているゲームからである

直截的に言えば、そのキャラクター個人の悩みなど従来のファンには既知の事柄であるし、改めて描かれても新鮮味が無いのだ。

また新鮮味という話であれば、最初橘ありすの「宣材写真撮影」に纏わる話は、『シンデレラガールズ』のアニメでもやってるし派生元でも別の派生先でもやってる定番である。その中で言えば解決方法も極めて平凡なのもファンの期待に応えているようで一層下回る。

この作品の最大の特長といえばこれまでフォーカスされなかったプレティーンのキャラクターやそれに見合う矮人族のプロデューサーがいることだ。しかし、如何せんどいつもこいつも真面目に波乱起こす気が無く、二度目になるが盛り上がらない。波乱があればいいとは言わない。しかし波乱が起きないということは、キャラクターという個性を持ち得ないのも同じではないか。ただ低身長の皮を被った誰かの物語に置き換えられる。ただ真摯優等生ソロプレイしか活躍できないキャラクターであるのなら、彼らは彼らである必要がなく、他の誰だっていいのだ。皮だけ派手にしたところで、平凡な物語は平凡だ。なぜ狂言回しと呼ばれるキャラクターが生まれるのか、我々は反面教師を以て理解してしまう。

物語は単調な起伏を繰り返すだけ。計画し尽くされた行程は作り手にとっては満足するものだが、受け手にとっては必ずしもそうとは限らない。我儘な顧客であることを承知で言えば、我々は見たことがないものが見たいのだ。アニメゲームも各々アイドルの成長を描く先駆者だったが故に満足した。そうではない点ももちろんあったが、概ね次の展開を予想できないものだった。しかし本作品はその後追いに過ぎなかった。

我々はこの物語を知っている。恐らく作者よりも。

まり深く内容に触れずともこの作品が読者を退屈にさせてきたことは説明できただろう。

現時点で19話。イテレーションは5回目で4人目の物語解決の途中である。連載10か月。プレティーンは全員で9人いるのでまだ残り半分残っている事実に戦慄しよう。

私は最新話の作者コメント第一話と同じだったことに慄いたが、今見たら差し替わっていたので深掘りしない。その第一話のコメント引用すると、

お待たせしました!いよいよ「U149」始まりますアイドル達の新たな一面をどんどん見せられればなと思ってますので、よろしくお願いいたします!

新たな一面など無かったということはさんざ書いた。

実のところ、我々が期待していたこハードルを超える作品では無かったと思う。それでもコミカライズという点では良評価を当たられる。新規の読者にとってはこれも新たな一面になるのだから

雑感

最新19話は良かった。賑やかしでも他のアイドルが出てくるのは良いことだ。ここで出てくるのは誰でもいいが上の主張とは誓って矛盾しない。賑やかしだけでもいいじゃん、という主張はよく見るがこうなると容易に首肯する。なけなしの起伏だって要らねえや。冗談だが一考する余地はある。

しか最後の見開き、見れば見るほど最終回みたい画だ。つづくって文字が誰かの悪い冗談しか思えない。

10か月やって最初ステージって、悠長過ぎだろう。アニメなんて一か月半でやってたじゃないか

アニメといえば…これでアニメ化してほしいという意見を稀によく見るが、冗談でも口にすることじゃあない。

2015-01-09

http://anond.hatelabo.jp/20150109192406

金は相対的なもんなので、貧乏人を排除したら金持ちのうち8割くらいが貧乏人になるだけ。

高々有限回のイテレーション人類は滅亡して終わり。

2014-12-22

http://anond.hatelabo.jp/20141222005720

それって単にイテレーションフロー収束先の話であるから収束性そのものとは別であると思うし、収束自体単一のイテレートに対して収束的な振る舞いが定義されているかどうかで決まる。

2014-03-24

アジャイルってそんなに大層なものでもないんじゃないの

http://d.hatena.ne.jp/megascus/20140323/1395533267

設計できなくて、失敗も許されなくて

それでアジャイルからずにスクラムやったら

普通に失敗して1,2イテレーション破綻する。

それでいいじゃん、って思う。

ウォーターフォールでだましだましやって

だいぶ時間が経過した後のテストで火を噴くよりよっぽどいい。

破綻した後でどうするか、が大事なわけで

そこで学べるなら学べばいいし

何も手を打てないなら何やっても無駄

アジャイルなんて大層なものでもなんでもなくて

要は早く失敗できるってだけなんだから

からないもの試行錯誤でやってみることこそ

変化を求めるアジャイルのあるべき姿で

から入ることを否定するのは

それこそアジャイルっぽくない気がする。

理解できなくてもとりあえずやってみるというのは

推奨されこそすれ批判されるものではないと思う。

自分スクラム嫌いだからやらないけど

形式的にスクラムやる人を責めるつもりはないな。

アジャイルでやったら失敗した!」

って言われたくないって話なのかもしれないけど

そういう時代はもう終わったと思ってる。

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