  |
はてなキーワード: 非エンジニアとは
先輩が退職するらしい
今いる開発チームは実質2人で、わたしは新卒で入社して3年目の若造である
先輩が辞めそうなことは1年前くらいから薄々は勘づいていて、あぁこの先輩そろそろなんだろうなあとは思っていた
冷静に考えてみたら
なによりコードレビューとか新規開発物のアーキ選定とかは基本先輩に頼りきりだったので
勘づいてから今までの1年弱はそれまでにも増してなんでもできるようになろうと思って頑張っていたし、
先輩に依存してしまっていた部分は自分もできるようにならねばと思って率先して手を出したりしていた
結果1年間で守備範囲も広がって、最低限の部分は自信を持ってできるようになっていた
だからまぁ今回先輩が辞めますって聞いた時はそれ自体はそんなショックでもなくｱｯﾊｲってくらいだった
自分的にはやれることは全部やっていたし、
客観的にみてもそこそこ変わったように見えている自信があった
先輩が辞めるとなって言われたのは「お前1人になったら無理だな」「わからないところはどこだ、お前にできないことがそんなに少ないわけはないもっとちゃんと考えろ」だった
先輩がいついなくなっても大丈夫なように必死でやってきた今までをなにも見ていなかったのか？
なんでわたしはこんななにもみてない人間、しかも非エンジニアに評価をされなくてはいけないのか
わたしが半年間1人で必死に回してきた案件も「お前1人でリリースさせるのは怖い」という理由でリリースできなくなりそうである
リソース面は1人じゃどう頑張ってもすぐに限界が来るなと思って半年前からベンダー探しもしているし、
新卒配属枠がなかったところを無理に作ってもらって受け入れて育成もしている
そりゃ先輩いた方が安心に決まってるし、若造に全て任せて信じてくださいとは言えないけど、そこまで無能ではないと思っていて欲しかった
見てくれていなかったことを責めるのは間違いで、見てもらえるように、伝わるようにできていなかった自分が悪いこともわかっているけど、
なんかすごく、なんとも言えないもやっとした感情が湧いてきた
俺が新社会人に言うなら。 一つ、時間は無駄にしてもいい。ちゃんと心を休めろ。 二つ、お前はジョブスじゃないし、多分孫正義や三木谷ですらない。 三つ、誰かの(例えば上司や家族でも)期待に応えるためだけに働くな - id:moons
データとして使えるようにしろ、見映えのためにデータを壊すな。これは仕事の基本に据えたい - id:robo_pitcher
ブコメページ - お役所「Excel」の改善案が公開 ～あかんヤツ→ええヤツの例がわかりやすく、一般市民にも結構参考になる - やじうまの杜 - 窓の杜
多くの非エンジニアが勘違いしてるんだが、上手く行かないのには理由があるが、上手くゆくのには理由はないんだ。たまたま事故が発生してないだけ。全ての既知と予想問題を潰した後でも もぐらたたきなんだよ。 - id:mangakoji
ITエンジニアが教訓とすべきは、間違って外部に出る可能性があるから、開発やテストでも変な言葉を使うな、ということ。詳しくはプログラマが知るべきこと97のその25「見られて恥ずかしいデータは使わないこと」 - id:bohemian916
ブコメページ - 「もう帰ってこなくていいです」母親にカスタムメイドのスクショを誤送信した結果…心抉る返信に思わず涙 - Togetter
マネジメントの基本は、「やることを決める」のではなく、「やらないことを決める」 - id:dazz_2001
ブコメページ - 地方は儲からない｢イベント地獄｣で疲弊する | 地方創生のリアル | 東洋経済オンライン | 経済ニュースの新基準
「若い人がやるような仕事」というのがそもそも年功序列の思考であって、適材適所の考え方からすれば年齢など関係ない。 - id:ounce
これに抵抗がある人は、マーケティング軽視のものづくり真理教にハマってる。人目に触れなければ存在は無いに等しい。いいモノは自然に売れるのではなく、そもそも人に認識されないモノは存在しないのと同じなの。 - id:u4k
ブコメページ - メルカリで3ヶ月以上売れなかった洋書が一瞬で売れた！手間のかからないひと工夫が天才的と話題に「発想の転換すごい」「早速実行した」 - Togetter
俺はITエンジニアをしていて、ベンチャーやSIerなどで自社、顧客企業を問わず今まで多くのWebシステムを作る案件に関わってきた。
プロダクトが上手くいくもいかないも、プロダクトオーナーが全てだ。
特にWebサービスの場合、ビジネスサイド、ITエンジニア、デザイナーという3つの職種がチームを作ってプロダクトを開発していくことになる。
その場合はプロダクトオーナーはビジネスサイドが務め、テックリードがPdM補佐のような形になるだろう。
SIerの場合は、顧客企業の窓口となる人がPOを努め、開発会社のマネージャーがテクノロジーを統括することになる。
そして大抵の場合、ビジネスサイドの人間がPOを務めると、「声のデカいステークホルダー」となり、チームを引っ掻き回し、プロダクトを迷走させ、モチベーションを下げさせるのだ。
だってそうでしょう！？プログラミングも、DBでのデータの持ち方も、他社のAPIの使い方も、UIデザインも、いくつかあるUIの選択肢とそれを実現する工数も、何も分かってないんだから。そんな人間が最終意思決定者をやるんだから、上手くいくはずない。
だいたいMVPにはふさわしくないリッチなUIを要求してきたり、難しい実装や工数のかかる機能を要求してくるのだ。そしてその実装に工数がかかるのは、エンジニアの怠慢、スキル不足だと考えている。
本来であれば、機能の過不足については、ユーザーがやりたいこと、こちらがやらせたいことが実現できているかどうかだけを考えるべきなのだ。それがどういう形のUIで提供されているか。別ページなのか、モーダルなのか。ボタン押下で動作するのか、JavaScriptでインタラクティブな操作ができるようにするのか、ビジネスサイドがこだわり主張するべき所ではない。
そもそもエンジニアは1+1=2になる世界で生きているが、営業というのは顧客を口説いて意思変容させるのがミッションだ。現実を歪めるのが職務なのである。エンジニアはエンジニアの工数は変えられないものだと理解しているが、営業はそれも「なんとかできるはず」と考えてしまうのだ。
仕事には内部に向けるエネルギーと、外部に向けるエネルギーの2つがある。そして、外部に向けるエネルギーをどれだけ大きく出来るかがビジネスの成功に繋がる。
ビジネスサイドの何もシステムの専門知識の無い人間がPOをやると、思いつきで「あれはどうなの」「こうしたらどうなの」って言って、エンジニアやデザイナーという専門家が「それは難しいです。なぜなら技術的に…工数的に…タイミング的に…」という話をして、仕事に使えるエネルギーもモチベーションも時間も、POを説得するという「内部に向けるエネルギー」に消費してしまうことになるのだ。
色んな専門家が集まって、それぞれの専門領域を発揮し、お客様に価値を与えるプロダクトを作り、金を稼ぎたい。だからこの仕事をやっているのに、なんで何も分かってないPOが自分の存在意義を発揮するためのだけのオ◯ニープレイを説得することに毎日忙殺されているんだろう。馬鹿じゃないかしら。
そういうPOを補佐するために有能なPO補佐がいるんですよという話もあるが、どうせ人の話を聞かないんだからPO補佐がいたって意味ないです。
そしてそれができるバランス感覚と説得力を持った有能なPO補佐がいるんだったら、その人がPOをすべきだ。お前じゃない。
過去会ったことのあるPOには、エンジニア出身のダメなやつもいた。この現代において生PHPやStrutsの時代で止まった知識を振りかざし、自分は知識があると勘違いした痛いやつが。もっとも彼は元エンジニアであって、エンジニア辞めた後はかなりの年数を営業としてやっている人間だったが。
だから俺は、POは現役エンジニアがやるべきだと思う。技術オタクのCTOというよりは、VPoEの立場の人がやるのが一番いいかな。顧客を無視したエンジニアリングオ◯ニープレイをしない、ちゃんとカスタマーサクセスとUXへの費用対効果を考えられるエンジニアだ。
そして営業/マーケターはサービスを売りつつ、顧客の声を聞き、顧客の抱えてる課題を発見し、それをチームに伝えてくれたら良い。ソリューションはエンジニアとデザイナーが考えるので。
ある程度会社が大きければ、エンジニアをプロダクト開発のトップに据える、そういう責任移譲もできるだろう。
今日の名言飛び出しました
「プロダクトオーナーがしっかりとしないと、エンジニアがいても能力がある人がいても意味ない」
「ビジネスモデルは考えられるけどプロダクトモデルを考えられない人が増えてきている」#DxMiraiKaigi https://t.co/6VHrh1Ut3z— あれっくす@一番下手っぴでいい (@MHTcode_Alex) May 20, 2021
ベンチャーのあるあるとして、ビジネスモデルは考えられるけどプロダクトモデルを考えられない営業人間が起業して、「俺の考えたビジネスモデルを実現するに協力してくれるエンジニア募集！」とか言ってチームを作り、社長がPOを務めることが多い。
でもその社長に、POとしての職責が果たせるかどうか、スキルがあるかは別な話である。というか大抵の場合、無い。
声のデカいワンマン社長の言うことを聞いて、クソなものをクソだと思いながら作り、社長がVCにプレゼンして調達したお金を啜って生きていくのがベンチャーでのエンジニアライフである。オワリです。
ベンチャーで上手くいくのは、エンジニアでありながら希なプレゼン能力とコミュ力を持った、エンジニア社長がいる会社しか見込みがない。
これを読んでるあなたがもしビジネスサイド出身の社長さんであれば、あなたの仕事はプロダクト開発にズカズカと踏み込んでいって、思いつきで喋って、自分のこだわりを入れるように怒鳴り散らすことではありません。
課題は無いか耳を傾け、解決できそうな人を連れてきて、お金を出すだけに徹するように下さい。
それができないのであれば、あなたはWebシステムという無限の拡張性があるものからお金を得ることはできません。愚直な営業と手作業でバリューを出すという、労働集約型の仕事を一生全うしてください。
そしてこれを読んでるあなたがもしエンジニアであれば、ビジネスサイドにプロダクトの決定権を握られている状況ではエンジニアが幸せになれることは決して無いので、ビジネスの作り方やマーケティングを学んで、エンジニアがビジネスを握っていこう。プログラミングを修得するのに費やした時間と努力をビジネスサイドにも発揮すれば同じように身につけられるはずである。ビジネスサイドに顎で使われる存在から抜け出していこう。
星野リゾートではどのようにして旅館現場出身者をIT人材へ育成したのか？【デブサミ2021】 (1/3)：CodeZine（コードジン） https://codezine.jp/article/detail/14017
これはすごいですね。非エンジニア出身のPOでありながら、ちゃんとプロダクトを成功へ導いている。
ここでの例では2例あって、社内システムと、社外のお客様向けのシステムだ。
社内システムはノーコードを活用して、自分たちで作って自分たちで運用するようにした。いいですね。非エンジニアの思いつきをエンジニアに作らせる、という動きにはなっていない。自分の思いつきのケツはちゃんと自分で拭け、他人に迷惑をかけて対処しようとするな、ということだ。
社外向けのシステムを作るに当たっては、ちゃんと自分たちをIT人材に変化させていくための勉強をちゃんとしている。エンジニアと同じ目線に立って同じレベルで話ができるようになっている。これだといいですね。
やっぱり、Webシステムを作るPOは、営業出身ならめっちゃITのこと勉強すべきだし、それが嫌ならITで金儲けしようということからは降りるべき。
非エンジニア。資格が必要な事務をしている。ある会社で、初めはパートで募集してそれに則って応募したのに、なぜか採用時の雇用条件提示書では正社員になっており、そのことを指摘したらじゃあ今回はご縁がなかったですね😅となった。
パート求人なので、当然だと思うのだが求人の仕事内容A,B,CがあってA,B,は今までの経験から余裕で即戦力になれます。Cは経験ないですけど大体2週間のOJTでモノになります。時給1×00円〜で１日何時間労働、週何日でどうでっか？という交渉に臨んでいたつもりだったのに、向こうは面接で、将来的にD,E,Fという仕事をする気はあるか？とか、5年後のキャリアプランは？とか趣味を仕事に生かす気はないか？とか聞いてきて、挙げ句の果てには上記のような行動に出てくるわけで、そもそも会話が成り立っていない。意味不明。朝三暮四。羊頭狗肉。
その頭の悪い会社の求人はともかくとしても、スキルを有効活用しようとしても。どうしても「フルタイムの壁」に阻まれる。どんな会社であっても１日8時間〜週5でがっつりこき使おうとしてくる。
なぜこうまで採用側は「正社員」にこだわるのかというと、正社員は会社にとって定額使いたい放題プランみたいなモノだからだ。よく言われる通り、クソバカアホゴミジャップランド企業は、採用時にジョブディスクリプションを作らないので、入社したら求人票に書いて無い仕事までさせて、給料据え置きで「でもお前正社員なんだから我慢しろ、いい経験だろ」なんていうのが目に見えている。実際この条件下で、みなし残業制で契約してしまえば名実共に定額使い放題プランが完成する。
それの何が問題かというと、端的に言って生産性が低いまま長時間働かされる→スキルを身につける余裕も生まれず生産性が上がらないというスパイラルに陥る点がある。
俺自身、自分が専門とする仕事については、プログラムを組んでツールを作ったりして効率化を図ってきたし、在宅勤務が難しかった作業を在宅できるようにしたりした。実際このコロナ禍で内定をもらえたのはそういう点が評価されたのだ思う。そうは言っても、自分の専門外の雑用的作業まで効率化を図ったり改善提案するほど暇じゃないし、できるとも思わない。
これまでジャップランド企業は、そういう「非コア業務」、要はオフィスの中にあるマックジョブを「非正規雇用」という政治的に作られた下層階級に押し付けてきて、碌にITへ投資もせず、新卒はともかく中途へ教育もせず現場の運用だけでなんとかしようとしてきた。
もちろんこれは一つの要因に過ぎず、人事部が人材育成に対して定見がなく現場丸投げとか、解雇規制が強すぎるとか新卒一括採用とか色々な要因が絡み合っていることが原因だと思うが。
ここへきて、DXだのと最もらしいことを言っているがメンバーシップ雇用の「正社員」という定額使い放題プランにこだわる限り、いくら小手先でITツール導入したって何も変わんねえよと思った次第。
直接の原因は知らないので非エンジニア向けの戯言、はいはい嘘松程度に聞き流してくれ。
タイトルは釣りみたいなもんだ。データも客観的な観測もない。本当の理由なんて外部からわかるはずがない。
単に一個人が中の人らに酒を注がれつつグチられた内容の総集編だ。
前提として、社会インフラ系のIT基盤は設計や運用に企業体質が出やすい。
わかりやすいのはSuicaとかで、ハードウェアのFelicaこそソニーの技術だが、Suicaのシステムアーキテクチャは完全に鉄道屋のそれだ。
アプリやWebなんぞは使い勝手がイマイチだが、Suica自体のシステムダウンで首都圏の自動改札が全滅、復旧するまで使えませーん、なんて事態は聞いたことがないだろう。
安全が全てに優先する。
そういう作りにしてあるのだ。
じゃあみずほ銀行はどうなってるかというと、とりあえず止めない、安定運用できたら3社統合の負債を返そうとする、それだけで精一杯だ。
銀行屋のロジックで生きてるから、抜本的な改善はかなり難しい。
MHIR（みずほ情報総研）が大体開発にあたるわけだが、ここでの評価はほぼ銀行の出世と一緒。
入社前の面接の時点で出世コースを見出された賢い社員は、有力な派閥の上司の元で可愛がってもらい、成功すれば出世する小さな案件をあてがってもらう。
あまり大きい案件はリスクが大きい上、成功すると目をつけられる恐れがあるからだ。
そこで卒なくこなした奴が同期より少し上に行く。
年次にあわせて適切なサイズ・リスクの案件をもらい、統括し、出世する。
リスクの高い案件は技術知識だけで政治力のないはねっかえりにでもくれておけばいい。
こんな環境で誰が「抜本的な改善のため落ちにくい安定したシステムアーキテクチャを検討しましょう」なんて言う？
それで何のリターンが得られる？
「とりあえず動いてる」「止まったら運用のせい」「何日でも詰めさせて復旧すればいい」のに？
詰んでるんだよ。組織として。
中の奴らがどう思ってるか知ってるか？
下手な正義感振りかざしても何も変わらないからな。正しい学習性無気力だ。
そこそこ給料がいい分、このご時世では家族がいる奴はなおさらリスク取れないしな。
まあ、3社統合の時点でシステム屋が本体の建前と開発の実際との整合性が取れず、結果として歴史に残る大失敗から始まってるようなところだ。
マトモになるには時間がかかるだろう。
中の人やOBさんよ、「ホントのところ」をバレない程度にちょろっと教えてくれるの待ってるからな。
他社の中の人も「うちもひどい」「ここはまだマシ」とかあるだろ？
結構色々ついたな。
肩の力抜いてそのうち出てくる調査報告書でも読んどけよ。
まあ、ろくな人材がいないのは事実だから気持ちはわからないでもないが、その前に
そんなことする暇があるならGithubにコミット投げてどっかのエンジニアに「レビューしてもらえませんか？」ってリプライ飛ばす方がまだ健全だわ！！！！
君もこんなとこで長文垂れ流す暇があるならgihubにpushしてみたらいかが？
環境について
出社について
在宅について（ここは業種関係ないと思うが）
コミュニケーションについて
取引先について
ほとんどの参加者は、コンピュータサイエンスなどの学位を持っているわけではなく、国内のSIerなどでパソコン弄りをしてるだけのただのオタクです。
彼らの大半は、まともなコードが書けるわけでも、インフラ等の保守ができるわけでもありません。
非エンジニアの連中に到っては、流行りのIT用語を援用したポエムを作ってるだけであり、話を聴く価値はありません。一部の技術のある人たちも、そういう人たちに合わせて話をしています。
よく、「プログラマはつねに最新技術を学ばないといけない」などと言われます。
これはある意味正しいのですが、この主張が指している対象は、新しいツールやフレームワークの単なる「使い方」であって、根本理念ではないのです。
実際のところ、ソフトウェア技術なんてものは、コンピュータの黎明期から大して進歩していません。進歩しているのはほぼ全部ハードウェアの技術です。
例をあげれば、「オブジェクト指向」なんてものはC言語ができた時点で既に確立されており、有能なエンジニアはみんな知っていたのですが、90年代に入りJava等が普及すると同時に量産型のコード書きの間でにわかに流行りだしました。
エンジニアが第一義的に学ぶべきなのは、コンピュータサイエンス全般の基礎であり、それを欠いた人が流行りに飛びつくのは虚しいだけです。
