´Д｀)< AM 2:00 ～ 5:00 までは 18禁画像をリツイートしても良いという自分ルールを作るというのはどうか・・・と今考えている・・・ — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< これはどっちがいいか迷う — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< この辺についてはみんな同じように困っているから、それぞれにそれぞれの思いがあるんじゃないかとは思う・・・ — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

パワーワード祭り http://pic.twitter.com/mnw6J8AxPn — lorin (@shelter2_home) May 10, 2017

´Д｀)< あと設計レビューを通った後は、設計に関してはチェックしないようにする、とか。 ちょっと極端だけど。 — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

と、言いっぱなしになっていたんじゃないかな。 なんにせよ、リリース直前でチェックしても痛い手戻りが発生するだけでメリットは無さそうかなと思う。 問題が発生したときに修正ができるタイミングでの確認が必要かも。単体テスト直後とか。 — Takoyaki _um…

´Д｀)< そのタイミングで一度 repository に commit してもらって、リモートで設計書と合わせてコードを確認するとか…… 状況によるけど、指摘方法も「これは間違い」というのではなく、「こうすればいいのでは？」みたいにするとか…… — Takoyaki _umaaaaaa (…

´Д｀)< あとタイミング。 リリース前にレビューして、NG判定が出たときにリカバリする方法が考えられていなかったんじゃないかと思う。 レビューする側にスケジュールを伸ばす権限まであるなら問題ないかもしれないけど、 「リリースはさせません。スケジュ…

´Д｀)< 今回の記事にあるような「人が増える」場合は、増えた人が何か作業をするのは良いと思うんだけど。 元々作業していた側の作業を増やしてはいけないと思う。 だから「レビュー」という形を避けて「手伝う」という形の方がいいんじゃないかと考えた。 —…

´Д｀)< 本当に「作業を増やす」という方向はなんとしても避けなければならない。 問題に対して対策をするたびに作業が増えていったら、時間がいくらあっても足りなくなる。 毎日残業は増え、集中力を失い、ミスを犯し、それに対策するためにまた作業を増やし…

´Д｀)< 色々と、とても悲しい記事だった — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< 広報活動の部分は、ちょっと寂しいなあと思ったり。 最初に書かれていた『自分の事業部にいるエンジニアの雰囲気を変えたかった』という部分には効果はなかったのだろうか・・・ — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< 「レビューします」と言ってしまうと 「ああ、面倒な作業がまた増えた・・・」 になってしまうから、「手伝います」的なスタンスでいきたいところだよね・・・ — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< 例えば明確に「レビュー」という形を取らなくてもいいかもしれない。 ・設計レビューのときは、既存のレビューに同席する形を取る ・リリース前レビューは、作成済みの資料とソースで勝手にレビューを進める みたいな形にするとか。 — Takoyaki _umaa…

´Д｀)< 今まで何度も tweet しているんだけど。 問題に対する "再発防止策" を考えるときに、 "防止手順を追加する" ことで解決しようとしてはいけない。 今回「レビューする」という項目を追加したことは、「発生した問題に対するチェック」を増やしただけ…

´Д｀)< とはいえ「新規プロダクトメンバーの知識不足による検討漏れ」が問題原因だった場合はおいそれとは対応できない。 その場合は・・・うーん・・・どうしたものかな — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< はたしてこの記事に書かれている施策が、自分が体験した内容と同じものかどうかは分からないんだけどね。 もし、自分が体験したものと近い内容だったらという前提で、当時の対策について考えてみるといくつか思うことはある。 — Takoyaki _umaaaaaa (…

´Д｀)< やり方としてまずかったのではないかと思う箇所は下記2点かな ・業務フローに手順を「追加」したこと ・「追加」したタイミング — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< そしてレビューは形骸化していく。 準備する時間、実施する時間、まとめる時間を消費するだけの、無駄な作業に。 — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< そして、自分もこの記事に書かれている人のような感想を持っていた。 「厳しいスケジュールにさらに作業が増えた」 「レビューが通らなかったら土日出勤や毎日0時まで残業しなければならない」 — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< 設計レビューやリリース前レビューがどのような形で行われたのか、具体的な記載がなかったので想像でしかわからないけど……。 昔、自分が作業していた現場でも似たようなことがあった。 自分はレビューイとしてだけど。 — Takoyaki _umaaaaaa (@Takoya…

´Д｀)< まずはこの記事を書いてくれたこの人に感謝したい。 とても重要で有用な情報だと思う。 そして内容も、なるほど・・・と色々考えさせられた。 — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

“社内横断の技術組織を終わらせました - nottegra’s blog” https://t.co/CZp7LjbNem — ( ꒪⌓꒪) (@mattn_jp) May 13, 2017

´Д｀)< 個人的には、共通 DLL を使って API 等を実現している箇所をエミュレートして動作させるのではなく、ARM 版の DLL を用意しておいて差し替えている？のかなあと思ったんだけどどうなんだろう。 エミュレーションさせる部分をできるだけ少なくする感じ…

´Д｀)< あと x86 エミュレートも、全てをエミュレートするわけではないっぽい？ような表現だった。 DLL がどうこうとか書いてあったんだけど、詳細はよくわからなかった。 — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

´Д｀)< この記事で重要なのは、「単純に x86 をエミュレートしているわけではない」ということみたい。 ・WPF アプリは x86 エミュレートで動作 ・UWP アプリは ARM ネイティブで動作 というところが強調されていた。 — Takoyaki _umaaaaaa (@TakoyakiU) May…

ARM版Windows 10がx86版Windows 10とほぼ同じサクサク具合で快適に動くデモ公開、エミュレート用システム「CHPE」を技術者が解説 - GIGAZINE https://t.co/VYDuoiEW6s — きり㌠@Выбывать (@kirimemo) May 13, 2017

´Д｀)< 昨日もリツイートしたっけ？この記事。 — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017

http://pic.twitter.com/KK762jeaDK — 坂本みねぢ (@S_mineG) May 13, 2017

*´Д｀)< かっこいい — Takoyaki _umaaaaaa (@TakoyakiU) May 13, 2017