  |
はてなキーワード: 上流工程とは
パワハラって具体的に何なのかわかんないけど、力関係的に逆らいにくい人にプレッシャーかけられたので多分そうなのかなと思う。
どんな感じだったかというと
2.実装していくとどうすればいいかわからない部分が出てくるので、仕様を尋ねる
3.無視される
5.後々、仕様と違うことを詰められる
という感じだった。
詰められ方は
「バグが多すぎます、ちゃんと確認やテストを行ってください」とか
「この不具合はシステムの構造上致命的です、早急に修正してください」とか
いまチャットの履歴から引っ張ってきたけど、原文はもうちょっと高圧的だと思う
普通じゃんと思うかもしれないけど
だったりするので、小さなミスでも大きなミスとして圧をかけてくるのが辛かった。「そもそもそんな仕様だったことすらこっちは知らないよ！」っていうのでも責められるし。
そしてミスはミスだからこっちが悪いので言い返せないんだよね…
未経験からエンジニアになったというか、新卒→自営の流れを汲んだ人間で初社会人だったから「世の中こんなものなのかな？」とか思ってたけど
いわく下についた人を二桁近くやめさせてきた人間らしくて外れ引いたんだなって思った
今その会社の評価星1.2とか凄まじいことになってるんだけど、
昔は良かった的なコメントがついているのでもしかしたらこの人のせいで良いエンジニアがどんどんやめていってしまったのかなとか思ったりした。
技術力も低くて尊敬できる所一つもないんだけど、こういう人に限って社内政治が得意だったりするもんだから、上の方のポジションに居るんだよね
だから指示も抽象的で「いい感じに頼む」みたいになるし、GUIで状況がわかる段階になってから「こうじゃない！」とか言い出すから困る
一つだけ良かったこととしてはありとあらゆることが適当に投げられて後よろしくされてたので、急速に技術がついたこと。
DBもよくわからなかったし、SQLも書けなかったけど、半年ぐらいでフルスタックの開発を一から任せてもらえたりしたし、実際にどうやればいいか分かれた。
---
冒頭に戻るけど、SEは
・大まかな設計
・進捗管理
など、いわゆる上流工程のこと指して使ったけど、結局こういうポストに収まる人って社内政治得意マンが多いんだろうなって思った
社内政治が得意で技術力もあるっていう人は、仮にどちらもレア度10%だとしたら掛け合わせで1%なわけで、多くは社内政治だけ得意なことが多い
つまり技術力は対してないから具体的な指示が出せなくて、曖昧なところを『いい感じ実装』する羽目になる。技術力なかったら具体的な質問に的確な回答を返せないしね。
……正直そんなSE嫌われてる論とかどうでもよくて、
オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る － Publickey について思ったことをつらつらと。
log4shell と呼ばれる脆弱性が 2021 年 12 月にあった。これは Java というプログラミング言語でプログラムする際に、動作のログを記録するのに非常によく使われるライブラリ log4j にとても危険な脆弱性があった。なにがそんなに危険かっていうと
マインクラフトのサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんの Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。
そんなわけで即座に影響範囲、脆弱性のない新しいバージョンになっているか調べろ！って IT 関連企業はとてもバタバタしていた。
という背景の中、オープンソースのソフトウェアである cURL の作者にとても失礼な log4j の問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。
cURL (https://github.com/curl/curl]) はオープンソース(以下 OSS)の通信ライブラリとコマンドラインツール。 Linux などのサーバ上からファイルをダウンロードしたりするのにとてもよくつかわれるライブラリ。
C言語で書かれている。
ライセンス は MIT を参考にした独自ライセンス https://curl.se/docs/copyright.htm]
OSS は基本的に無保証で提供される。そのことはライセンスに明記されている。
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
そんな OSS に対して、
「あなたがこのメールを受け取ったのは、■■があなたが開発した製品を採用しているためです。私たちはこのメールをあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」
といった上から目線のメールを開発者に送るというのは、IT 企業として無知にもほどがあるといったところ。加えて log4shell 問題、名前のとおり log4j の脆弱性なので Java でかつ log4j を使ってなければ影響はないのに、C言語でかかれた cURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシーな名前つけてあそんでんじゃねーとも思う。)
なお cURL はどうやら開発者の Daniel Stenberg 氏が wolfSSL というところを通じて商用サポートを提供しているらしい。 https://curl.se/support.html]
ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通の対応。
そしてブログに書いてある2回目の返信で、David と名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。
こういうフローが事前に規定されていて CVE とか問題が検知されると発動する。このときに担当が大丈夫です！って回答するときにエビデンス（証拠）を求められるのだけど、クソな情セキは自社の担当の言葉を信用せず、開発会社からの言質をとれ！って命令するので、くそメールがスパムされるという背景があったりする。（担当が無知だったりイケイケだと、とにかく下請けにやらせればいいというパターンももちろんある）
そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。
加えて担当レベルになると大手は「そんなん下請けにやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。
もちろん担当者はピンキリだからこうとは限らないけど比較的多い印象。
ま、これ今回 Daniel Stenberg 氏が公表したからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的なムーブのようです。 LogJ4 Security Inquiry – Response Required | Hacker News
小さいところは
とかであんまり上から目線でこない感じはするけど、これはあくまで個人の資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。（個人の感想です）
この手のメールになんでカチンとくるのかって言えば
ということで、皆ちゃんと保守・サポート契約して、契約範囲で質問しような！
そして金払ってても相手は人間なんで、お互い敬意をもって接しような！
Public Key でこの件にからめて記載されている奴について
https://www.itmedia.co.jp/news/articles/2201/11/news160.html]
ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。
火事で財産失ってむしゃくしゃしてやったのかなんなのか。人気 OSS になったのに全然金にならんぜ！ってのが辛いのはわかる。が、OSS のライセンス的に支援を義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキームが必要だったのかもしれない。
あと個人開発で、善意でこれ便利だろ？って公開しているものに対して、辛辣な言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。
ブコメでフリーライドって書いている人が居るけど、MIT ライセンスでだしてんだから OSS の理念である自由なソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤなら MIT 以外のライセンスでだせばよい。古くは MySQL の Dual ライセンス、最近の Redis とか Mongo みたいに。
ただ、金欲しいとか大体 Donation 募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね？
じゃなきゃ GitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。
https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]
で、商用ライセンスの問題。これ今回のくそムーブの問題じゃないのここに並べられるのに非常に違和感がある。なんか OSS と大企業の対立を煽るようなミスリードを誘っているように感じてしまう。
大手クラウドベンダは OSS のライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。
オリジナルを開発した会社がリスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの？クラウドベンダも金払ってあげれば良いんじゃないの？とは思うよ。（2社は協業したけど）
ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。
Apache License 2.0 とかのライセンスの OSS として公表しているものの利用をフリーライドと表現するのも、それがなんか嫌儲で Evil ってのはちょっと判断できないかなぁ。
大手が自社でメンテできてしまう（できるようにする）というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦はちょっとなぁという感じ。
OSS の理念的に改修した分は元のソースにもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。
この辺は賛否両論色々あるので気になったら調べてみて。
以上。ご査収ください。
応募理由を聞かれて「上流工程に深く携わることでお客様により良い価値を提供するため」とか「御社の企業理念に共感したため」とか言う奴。
こっちだってそんなこと本気で考えてる奴いないってちゃんとわかってるからな。
こんなの「ネットに書いてる模範解答を暗記してきてる奴」以上の情報がこっちには伝わらないから実質何も言ってないのと一緒なんだよ。
「コロナでリモートワークの求人増えてホワイトで高給な企業に行きたくなったから」を失礼にならない感じの言い回しで言ってくれた方がまだ好印象。
新卒ならまだわかるんだよね、実績がないからテンプレートと大喜利力で勝負するしかないって。
中途でこれやる奴は正直割とマイナスだったりする。
技術パートで取り返せりゃいいんだけど、そこがダメなら口下手でも良くも悪くもエンジニアらしい人の方を優先して採用しちゃうわ。
まずはバグの原因を突き止めてそれが何故テストをすり抜けたかを調査
調べてみるとテスト中に出てくるエラーメッセージが微妙に違うけど気付かずにスルーしてしまったらしい
再発防止策としては社員のマインド醸成とか言い出しててアホかと
上流工程でもっと詳細な検討をするべきとかも言い出しててホントアホかと
報告書を上司の上司の上司まで報告し終わったらようやくバグ改修の予算が下りるらしい
そんでその予算を使って契約書作って上司の上司の上司まで承認を貰えたら修正開始
修正そのものは3行ぐらいなんだけど、もう一回テストやり直すんだって
多分だけどマインド醸成するための研修とかもやることになるんだろうね
この手の人達にアジャイルをいくら説いてもそりゃぁわからんよなぁ
要するにこの手の人達って骨の髄からミスが嫌いでこんなことになってるんだと思う
電車が遅延するとか、お釣りを2円間違えてるとか、書類の提出が1日遅れたとか
そういうのが大っ嫌いな国民性だからソフトウェアのバグも根本的に嫌いなんだと思う
「よく考えて作れば間違いは起こらないよね？」
「ちゃんとチェックしたの？」
とかそんなことばっかりやってる
とか平気で言ってくるんだもんな。どうかしてる
あと、心の底では機械を信頼していないっていうのもあると思う
コンバインで刈ったお米よりも手作業で刈ったお米の方が美味しいと思ってる
Excelが計算した数字よりも、自分で電卓叩いた方が正しいと思ってる
（電卓の中身は分かってないのだが、電卓はもはや自然の一部だと思ってる）
ちなみに本当にExcelは間違えることがあるのでタチが悪いのだけれど
そもそもExcelを使う利点は「入力すべき数字だけを入れれば、必要としている数値や情報が自動的に計算される」という点にあるんだけど
そこまでいくともう信用されない
なのでプログラミングみたいなことをやるときにも「信用できない」っていう前提で作るから
とにかく慎重に作るし、間違いが無いように丹精込めてじっくりゆっくり作る
人間が指さし確認でExcelの表を一つ一つ埋めていくし、それをダブルチェックする
誇張でもなんでもなくて、割とこういう開発は日本中で行われてる
結局彼らにアジャイルマインドを教えるのなんて天動説を信じてる人に地動説を教えるぐらい不毛な話なんだと思う。
天動説が廃れたのは、ただ天動説を信じてた人が死んでいったから、という話と同じで
この手のマインドの人達が定年して退場して頂くまでこれは続くんだろう
ただ、若手が彼らのマインドを引き継いでいる様子もあるので地獄しか待っていない気もしなくはないが・・・
ちなみにLog4jのことは昨日知ったらしくこれから対処予定らしい。
なぜ日本のIT業界はいわゆる上流工程（要件定義など）に集中し、実際のコーディングを重要視しないのですか？
日本のIT業界の多くは、サービスを売ってるから上流工程を大事にするのだと思ってます。なのでコーディングを重視しないように見えるのでは。
ここでのサービスとは、例えばプロバイダとして回線を売るとか、SIerとして、ある一品物のシステムを開発運用するとか、をサービスとして考えると、売ってるものはコーディングした結果のモノ、ではなく、接続サービスとか、システムを運用している意味での、サービスから金を得ていると考えられると思います。
もちろん、どこかはコーディングされているのは確かですが、重要なのは、ある程度機能することであって、サービスとして成り立っているかの方がはるかに重要なのは確かです。
ということで、サービスを主に売ってる会社は、どうしても自らの投資先もサービスを主に考えるのだと思います。自らがコーディングしたプログラムでも、どこからか持ってきたプログラムでも、結果として同じサービスが提供できるなら、どちらでもいいと考えるのではないでしょうか。
ただ、そうはいっても、そのサービスを阻害するほどにプログラムの品質が悪いとどうしようもなくなりますが、そこらへんは経営者の判断(実質上は担当者の判断)になりますが、サービス>コーディングの優先度になるのは変わらないのでしょう。
逆にIT業界でも、例えばアプライアンスを売るとか、コーディング物が製品の会社は、コーディングを重視する場合があります。全部ではないですがね、、
今の職場はitとは無縁のサービス業なんだけど、転職者の親父のITスキルが低すぎる。
俺はVBAの話をしたくてウキウキしてて、元本業はどういうコードを書いてどの辺の業務を自動化したり簡略化していくのかとても楽しみにしていたんだけど、VBAは使えないらしい。
それどころかExcelでIF関数の使い方もわからないみたいで、月の書類に使われてるIF関数で指定されたセルがひとつズレて表示にエラーを起こしていたのを彼が発見し、「エクセルよくわからないんで直してもらっていい？慣れてるよね？お任せします」と言われて空いた口が塞がらなかった。
先輩たちも「覇気があんまりないよね」「やる気なさそう」「モゾモゾしゃべってて何言ってんのかわかんねぇ」と愚痴をこぼすようになってきた。
制御文わからないようなITエンジニアって存在すんの？本人は上流工程を担当していて元フリーランスとか言ってんだけど、困惑しておる。
