おつかれじぶん（╹◡╹）
やるおじはマジで帰ったほうがいいのでは…。
少々帰ったところで許されるのでは（というか許していきたい）
実際、本当に堅牢なサービス作ろうとすると果てしなく面倒よね……関わる人やデータの取り交わしくらいから何重もの手続きが必要になったりする。
このアカウントは、notestockで公開設定になっていません。
こういうニュースになって「おい、うちは大丈夫なのか！？」ってなる企業はまだ良くて、対岸の火事だとあぐらかいている企業がほとんどだろうし、「そこにお金と時間かけるくらいなら追加機能つくるわい」って言うガバ運営とか予算削られまくりサービスとかが山ほどあるんやろうなあと思ってます。
本当は「上流」とか「下流」とかで分けるのがそもそもナンセンスなんだと思う。
上流とか下流とかなくてまるっとで１つのプロジェクトだし、同じシステム作るメンバでしょ。
分けちゃう考え方って結局ウォーターフォールの悪癖だよね。
振り返りはまあチームで適切に出来れば越したことないけど、立て込んでるとなかなかむつかしいよなあ。
自分は個人だけでも振り返ればそれでいいと思う。稼働収支なんかは必ずつけてるはずだし、そうでなくても開発している際に無茶な仕様決めてきたら実装者がヒーヒー言ってるとかを見るだけでも経験につながるのかなあと。
その辺、上流からブラックボックスになってると気づかないままつぎの案件でも無茶やらかすんじゃなかろうか。
ばななさんの言ってる「一連の流れを知る経験」というのもこの辺のことなのかなあと。
貴方が決めてきた要件、設計はこのように下流に影響するんですよ、その結果見積もりとこんだけ差異が出ましたねっていうのをやって、その上で「プロジェクトの成功」について考えると上流経験だけの人でも何かとっかかりは掴めるんじゃないかなあ。
特にスコープ漏れなんかは肥大化した要件に耐えられなくなって、下流が地獄絵図になる。
上流にイエスマンがいると大体これ。
雰囲気ってわりと大事と思ってて、そういう時に「いやいや、それは出来ませんよ」と否定的な意見を言える空気が大切かな。それを受け入れられる空気も。
上に行けばいくほどどちらかというとこういう雰囲気作りとかみんなが同じ方向見てるか（見てない場合は向くようにする）とかのスキルのが重要な気がしてる。
一応チームだからね、総意は大事と思ってる。
忌憚ない意見を言えるチームの案件は抱える問題や課題も少なくなりますね。
スコープとか目的とか誰のために作るのか、みたいな部分は常に念頭においておくほうが良いかなって思います（進めているうちに迷走することも多々なので）
超クールなイマドキのダッシュボードのUIデザインまとめ | イリテク https://iritec.jp/web_service/13048/
