  |
はてなキーワード: ウォーターフォールとは
https://logmi.jp/tech/articles/326896
これ見て吐き気を催したんだけど
なんで日本ってインフラ屋がすげー偉いみたいな扱いになってるのよ
KDDIも障害起こしたくせに「社長が凄い」「現場は頑張ってる」とか言う人多くて理解不能
インフラ屋は道路を作る人であってそれはそれでとても尊敬はするけれど
やっぱり表舞台に出て欲しいのはその上で走る車を作る人たちなんだよ
カッコイイ車を作る人に憧れて欲しいし、ブルジョアにはスーパーカーに乗って欲しいわけよ
日本で凄いフロントエンドのソフトウェア作ってる人っていっぱいいるし
特にゲーム業界なんてとんでもなく凄い人達ばっかりなのに全然フィーチャーされない
そのせいでドコモを始めとしたインフラ屋はフロントエンドを軽視するから未だにウォーターフォール開発ずっと続けてて
PDCAを3年周期で回して自己満足してるような連中ばっかが社内に残ってるわけでしょ
世間で持て囃されて高収入を得るような人はフロントエンドに立って欲しいんだけど
前職と比較すると平均技術レベルはマジで変わったように感じる。
前職だとクリーンアーキテクチャやらCI/CDやらは言葉の意味すら知らない人も多かったけど、
今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。
FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、
凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値もめっちゃ上がるんだろうなって感じもある
コードの品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル。
命名として若干ニュアンスに違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し！」みたいなのは容赦なく潰される。
ペアプロ・モブプロはしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。
会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらいはいる。
開発手法もアジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんとセオリーに則ってる形で管理されている。
ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね？」っていうのもまた感じた。
そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算で10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値を提供できてんのかなこのサービス？っていう感じというか……
前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。
動いてるものが同じなら採用技術がオンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、
NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん？
難易度の高いイケてる技術スタックを使う＝必然的にエンジニアのお賃金が高くなるってことだから、経営者視点から見てもこういう選択って果たして正しいのかなぁって。
なんならエンジニアの賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。
どう思うよ。
楽しむだけならそれで良いので終わりです
どんどんアイデアを練って楽しみましょう
でももしあなたがそのアイデアを形にしたいと思ったならば、押さえておくべきポイントがあります
まずあなたのアイデア形にするためにやるべきことを決めなければいけません
それを検討するための情報は貴方のアイデアに過不足なく記述されていますか？
やるべきことが現実的でない場合、どうすれば現実的にできるかアイデアを練る段階に戻って修正しましょう
やるべきことが決まったら、やってみましょう
うまくやれなかったら、やるべきことを見直して修正しましょう。アイデアも修正してかまいません
やるべきことをやったなら、結果を確認してみましょう
その結果を受け入れる or 次にやるべきことが見えたのでそれを決めてやる
でもめんどくさいですね
DBを設計する場合、パスワードのカラムを何文字にするか決めなければならない
これを最大2万文字とかにできなくもないが、DB容量を圧迫するといった理由で8文字や10文字に限定していてもおかしくはない
MongoDBのようなオブジェクトDBなら別だがSQL系のDBならこの理由が最もあてはまりそうに思う
同様の理由で文字種にも制限をかけてそう（UTF-8とか送られたら面倒）
境界値テストとしては最大文字数を試さないといけないが無制限だとそれができなくなる
100文字でテストするとなると、仕様としては100文字が限界ということになって文字数制限をかけることになる
ただ、それなら8文字とかで制限している理由として弱い気がする
無制限ということは極端に言うと1GBのパスワードを受け付ける、ということになる
1GBのハッシュ値を計算するのはブラウザ側になるのだが、1GBのハッシュ値計算が重くて使えない、という苦情が来るかも知れない
ただ、これも1000文字とかにしてしまえば良くて、8文字にしている理由にはならない
ウォーターフォールで実装する場合に上位レイヤでの仕様を決めるのはプログラマーでない場合が多く
定型のエクセル仕様書に「パスワードの最大文字数」というセルがあって、そこにデフォルトで8という数字が入っている
上位レイヤで仮にそこに100とか1000とかの数字を入れたとき、下位レイヤで何が起こるかわからない
つまりそこに8と書いた人が現代にいるのではなく、誰も決定していないから文字数制限が起きている
下位レイヤでの実装側は平文保存の危険性を十分に理解しているのでハッシュ値（とソルトなど）を格納する
多分、仮説４だと思うが、仮説１でないことを信じたい。
仮にそうするならおとなしく業務委託すればいいのに
「技術を蓄積するんだ」
って感じでGitHub, Dropbox, MS365とか軒並み禁止
Notionとか、そもそも何それ？っていう対応でとにかく禁止
元々入っていたシステムとかもサポート切れになったタイミングでExcel管理に移行
一部は新しいシステムに置き換わったけど素人が発注してるから既存のDBにCRUDするUIが付いてるだけ、っていうシステムになってて
意味不明な「なんたらコード」を入れたりしないといけない部分はExcelファイルからコードを探し出してきて手入力
前はあった情報共有のWikiとかもセキュリティを名目に閉鎖されて代わりに見た目はおしゃれなFAQサイトが開設
情報は適宜アップデート、ということで最新情報は載ってないし更新もできない
アジャイルとかウォーターフォールの問題じゃ無くて、発注者側がアホだとどうしようもないってことが良く分かった
いくら苦情を言っても
「どうせ後１年ちょっとで異動だし」
っていう感じでノラリクラリの対応されるから何にも変わらないし
って言ってるんだけど全然届かないし幹部連中も素人なので「そんなもん」と思ってるみたい
腹が立って仕方が無い
なんかいっぱいはてブコメントとトラバきた！！ありがとう！！おかげ様で有意義になりそうだ！！2月末にやったことのまとめうｐするね！！！
歯医者→予約した！！
日数足りない→ほんとだよ！人生足りない
サウンド・オブ・ミュージック他→観て見ようかな！！
FF14→ドラクエ派なの！ごめんなさい！！MMOだよね？ちょっと苦手なの！！ソロでやりたい！！
なんだかんだだらだら過ごしちゃう→あるある、それもまた至高！
検査項目が多い人間ドッグ→天才だ！そうだ、これはいいね！！たしか至れり尽くせりだったような気がする！！
海外旅行→いけねぇ！ｗｗてか生まれ外国だけど日本はいいよ！！
元気があって羨ましい→アキレス腱断裂して半年きつかったけど、歩けるってすごい！！元気は大事！！
何もかもが私と違う→みんなちがってみんなどうでもいい！！そんな感じだよね！！
筋トレ→しばらくしてなかったけど再開しよう！！レッグレイズ大好き！！
すべてのトラバに返答してるのすごい→なんでわかるの！？匿名だよね！？
興奮を抑えて→そうだね！！おちっちっちちつつ落ち着！！く！！
＿＿＿＿＿＿
東京済40歳バツイチ子持ち、転職に伴い2月の中旬から有休全開放で休める！！
※子供は大きいので一人で過ごせる＆預けられるので1泊くらい可
※遠出なし
何しよう！！なんかアイデアくれ！！ちなみに前の転職で1ヶ月休んだが本当に休みが足りない。頑張りと会社・社会貢献に対して休暇が足りなさすぎる。1年くらい休みたいし湯水のように金欲しい！！
あと2月ってなんかやだね、寒いし、空どんよりしてるし、いい景色なところいっても寂しい景色しかなくない？気のせい？
ひとまずやることを書くぞい！！！コロナもあるし！！一人でできることがいいよね１１１！！
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
https://qiita.com/mskmiki/items/544149987475719e417b
SEのAさんが作ったデザインがまさに良くあるエンジニアデザイン
別にこれがベストではないだろうけどここから意見を貰いつつ変えていけば良い
少なくともAさんのよりは断然良い
ところがこれについてるブコメがひどい
delta-ja さらっと流されてるけどBさんの手順1が死ぬほど重いステップで年単位で中にいる人かそういう人への入念なヒアリングが必要。勝手な想像でBを作ると大炎上するよ。Aは使いにくいけど安牌なことが多い。
入念なヒアリングなんかいらんけど？せいぜい30分ぐらい話聞けば作れるだろ？
しかもヒアリングしたって相手も答え持ってないよ。だってまだ無いんだもの。
もしかしてウォーターフォール的に一気に納品して終わるような開発しかしたことないの？
あと、Aが安牌って何？そもそも役なしなんだけど？
hatest AがいいかBがいいかはお客さん（使う人）に聞かないとわかんないよね。一画面で一覧化したAのほうが使いやすいってお客さんもいるのよ。作る側の思い込みでカッコイイのがいいってのは違うと思う
はい「そういうお客さんもいる」頂きました。
あとデザイン＝かっこいいだと思ってる人もいました。
デザインは日本語にすると設計ですからね。これだけでも覚えていってね。
atcgouch ダサいという言葉で一本釣りだな。Bは情報の少なさが適切でいわゆる顧客向けでAは管理画面等の関係者向けデザイン。何回も管理画面を開く人にB見せたら「不必要にスタイリッシュなのやめません？」って言われるよ
管理する人ほど多くの情報が必要って、どういう仕事してるんですかね？
子供の成績順に並べるとかですかね？それなら表ベースで他のこと考えますよね。
デカいスクリーンに全会員情報を表示するようなイカゲーム的なデザインでも注目すべきところを赤くするとかやりますよね。
というかスタイリッシュってなんですかね。そもそもBはそんなにスタイリッシュですかね？
上から適当に並べたけど他のも根本的に分かってない奴らばっかが偉そうに釈迦に説法してそこにスター付けてる
こういう自称エンジニアって仕様書眺めて機能を並べるだけのいわゆるコーダー屋さんなんだよね
だからデザインが何を意味しているかを分かってないし、「オシャレにする行為」ぐらいにしか思ってない
しかも窓側を向いて立つんだから進行方向と垂直に向ける方が持ちやすいだろ？
同じようにデザインするときは全てに意味があるし、それが正しい意味でのデザインであり設計なのよ
UIをデザインするときに内部の設計や情報を自慢げに面に出すのはV12エンジンむき出しで走る自動車みたいなもの
とにかくいろんな機能があるから全部見せたいっていう重いが強すぎて空力や剛性を無視してしまってる
お前らが頑張ったのはよく分かったから別にいちいち見せつけてくるな
