  |
はてなキーワード: 非エンジニアとは
意思疎通がうまくいかない＝エンジニア（IT）がわからない非エンジニア/カスエンジニアのせいという理論から誰ともうまくコミュニケーションがとれないエンジニアがいる
無茶苦茶な理論でゴネ、周りが議論を諦めて受け入れるしかない状態にしたことを論理的に思考できる僕が非エンジニアを論破し、カスエンジニアを導いたと勘違いしているので厄介
この無茶苦茶な理論というのがエンジニアリングとは直接関係がないことが多い
例えば、五千万の発注するのに稟議書を作らないといけないので資料作りを手伝って欲しいという要望に対して、そういう稟議書を出す文化がエンジニアリングを停滞させる！なんて古い会社なんだ！今すぐ発注！とキレられたことがある
会社のルール上それはできない、納得がいかないならやらなくていいと引き上げると僕が確認してない内容で稟議通すつもりですか？！他のエンジニアのレベルじゃできない仕事だ！とさらにキレた
エンジニアの論理的思考＝ビジネスにおける論理的思考と同等のものなので非エンジニアよりもビジネススキルがあると考えている節があり、エンジニアファーストな環境を作るために非エンジニアも導いてやると考えているようで、職責の範囲を超えた口出しをすることもしばしば
地方で一軒家建てられる金額を稟議なしで通せとキレてる時点でビジネススキルどころの問題ではない
その発言は経験の浅い若手のみが許されることであって、30後半の社会人が言うことではないと俺は思う
プロジェクトから外れてほしいがエンジニア人材が枯渇しすぎててこれ以上贅沢を言えない状況
つらい
非エンジニアフリーランスでもローンで買わせてくれた銀行はネ申。
（でも友人の漫画家は三井住友でローンを通した。ただし２年間も地獄のような保険料で苦しめられたとのこと）
今売っぱらえば最低3000万円ぐらい儲かるが、生活空間＋生活環境のために買ったんだから資産上昇なんかどうでもいい。
3LDKだがやや狭い（70㎡）。23区内・山手線なんだから我慢の範疇。
今は大体一馬力1000万。18年の最悪の時期だと700万ぐらい。でも維持はできるし、生活もできる。妻もいる。子供はいらん。犬も猫もいる。うさぎもいる。
もう買いたくて買ったんじゃなくて「買えるなら買わせてみろよ。買えたら両親引き取るから（笑）」と営業に来た不動産ディベロッパーと銀行と協議しながら買った。
まじでボトムで買えたので良かったね。
父を看取った後、母と妻の折り合いが悪くなって母を施設に。その母も去年亡くなった。両親を引き取らなければもっともっと余裕のある生活はあったが、買うと決めた前提が両親の引き取りなんだからそこまでだよ。
まぁ、オマエラの参考にならない買い方してるので、単に「自慢にならない自慢」なんだよね。
UnityもUnrealEngineも本格開発するなら大差はないんですけどね。
どのみちカスタマイズしないといけないというだけで、より短縮できるエンジンを選択しただけの内容ですよ。
が評価ポイントになりますが、ゲームによって不必要なものは削除したり先鋭化したりしますが、大元の開発者（UnityやEpic Games）との連携が不可欠になってしまいます。
大体の場合は海外はレスポンス非常に悪いので、自社でやれるなら自社でやったほうがカスタマイズしやすいし、何なら最新の描画処理なんていらない、ってなるんです。
もちろんUnity最高HDRPいいよね、とかはちょっと……となりますが、エンジンの性質を知ってる人であれば別にUnityだろうとUnrealEngineだろうと大差ないです。
スタンダードの状態での品質はもちろん大型タイトル作るならUnityは論外ですが、小規模〜中規模で制作するならUEだとBP管理がクソ面倒なので、Unityの方が良いです。
いやずっといるだろ。ツッコミきれないけど
とりあえず、下記の意味がわかっていただけたら幸い(でも謎理論で拒否するんだろうな)
ネタ抜きに社内で生成AI使ってもいですよ！ってやってるとこ入ればいいんじゃないですかね
大企業はだいたい入ってると思うけど、地方の場合はまだ社内生成AI無いかもだから、やはり在宅勤務をする
別の増田(ワイじゃない) ↓
非エンジニアだけどClaude3に増田ミュート作ってもらったよ
これを改善してってお願いした。何書いてあるかわからないけど動いたよ。
https://anond.hatelabo.jp/20240125203115
// ==UserScript== // @name 増田ミュート（白塗り版） // @namespace http://tampermonkey.net/ // @version 2024-06-26 // @description ミュートワードを含む最小限の範囲を白塗りにする // @author You // @match https://anond.hatelabo.jp/* // @icon https://www.google.com/s2/favicons?sz=64&domain=hatelabo.jp // @grant none // ==/UserScript== (function() { 'use strict'; const muteWords = [ "弱者男性", "弱男", "弱者", "婚活", "男", "女", "年収", "下方婚", "発達障害", "発達", "ハッタツ", "ハッタショ", "ﾊｯﾀｼｮ", "競プロ", "競技プログラミング", "AtCoder", ]; function whiteoutElement(element) { element.style.backgroundColor = 'white'; element.style.color = 'white'; element.style.textShadow = 'none'; element.style.cursor = 'default'; element.style.userSelect = 'none'; // テキスト選択を防止 element.style.borderBottom = '1px dashed #ccc'; // 枠線を追加してテキストがあることを示す // リンクの場合、クリックを無効化 if (element.tagName === 'A') { element.style.pointerEvents = 'none'; element.removeAttribute('href'); } // 子要素にも適用 Array.from(element.children).forEach(child => { child.style.backgroundColor = 'white'; child.style.color = 'white'; child.style.textShadow = 'none'; }); // ツールチップを追加 element.title = 'この内容にはミュートワードが含まれています'; } function shouldMute(text) { return muteWords.some(word => { const parts = word.split(''); const regex = new RegExp(parts.map(char => `${char}\\s*`).join(''), 'i'); return regex.test(text); }); } function findSmallestMuteableElement(element) { if (element.nodeType === Node.TEXT_NODE) { return shouldMute(element.textContent) ? element.parentElement : null; } if (element.tagName === 'PRE' || element.tagName === 'CODE') { return shouldMute(element.textContent) ? element : null; } for (let child of element.childNodes) { const result = findSmallestMuteableElement(child); if (result) return result; } return shouldMute(element.textContent) ? element : null; } function processElement(element) { const muteableElement = findSmallestMuteableElement(element); if (muteableElement) { whiteoutElement(muteableElement); } } function processAllElements(root = document.body) { const walker = document.createTreeWalker( root, NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT, null, false ); let node; while (node = walker.nextNode()) { if (node.nodeType === Node.ELEMENT_NODE) { processElement(node); } else if (node.nodeType === Node.TEXT_NODE && node.parentElement) { processElement(node.parentElement); } } } function handleClickEvent(event) { setTimeout(() => { processAllElements(event.target); }, 100); } // 初回実行 processAllElements(); // クリックイベントの監視 document.body.addEventListener('click', handleClickEvent); // DOM変更の監視 const observer = new MutationObserver(mutations => { mutations.forEach(mutation => { if (mutation.type === 'childList') { mutation.addedNodes.forEach(node => { if (node.nodeType === Node.ELEMENT_NODE) { processAllElements(node); } }); } else if (mutation.type === 'characterData') { processElement(mutation.target.parentNode); } }); }); observer.observe(document.body, { childList: true, subtree: true, characterData: true }); })();
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
当方非エンジニアですが、外部のapiをつかってGPTsでチャットボットが作れた。
わからない点は聞くと教えてくれて全部直してくれるしトライ＆エラーがとにかく早くてストレスがない。唯一GPT4の上限回数に達してしまって、その間何もできないところですが。
自分の作りたいものがイメージあるといちいちエンジニアに頼まなくていいのですごい楽だ。世の中にリリースする時は保守性とか色々考慮しないといけないのだろうけど、簡単なプロトタイプを作るくらいだったらデザイナーやディレクターでもできるようになるんだろうなぁ。エンジニアに怒られないし自分のペースでやれるからノンストレスだわ
作ってみて思ったのは、単にボットを作るだけだとだめで、どんなものをつくるのかの発想力・企画力と他のボットと差別化するためのオリジナルデータが必要ですね。
https://anond.hatelabo.jp/20230917223337
一般論として、40歳未経験エンジニアを雇ってくれる企業はほぼ存在しないと言っていい。
奇特な会社は雇ってくれるかもしれないが、22歳新卒をよちよちするのと40超えのおっさんをよちよちするのだったら100人中99人は22歳を選ぶ。
その上で、だ。40歳がプログラミングを学んで業務で価値を出しうる唯一と活路と言えるのが掲題の「手作業でちまちまやんなきゃいけないことをマクロで秒で終わらせられる事務職」なのである。
この話のポイントは、世の中には「どう考えても手入力させるには無駄極まりない」にも拘わらず「エンジニアの稼働費用と派遣社員の稼働費用を取ったら『エンジニアなら1時間で終わらせられる仕事』を『派遣社員に2日かけてやらせる』のが経済合理性がある」という現象があちこちに転がっているということだ。
これを書いてる増田は、非エンジニアだがPython、GAS、SQLくらいなら自分で書いて実行できる。だからわかるんだが、すっげえどうでもいい仕事なんだけど膨大だからマクロ組んだ方が早い、でも社内の責任問題なり工数なりの問題で「お前は派遣社員を管理する立場なのになんでそれ自分でやってるんだ、派遣社員にやらせろ（※自分でやれば1時間で終わるが派遣社員にやらせると4日かかる、手作業なので）」みたいな絶妙な仕事が、実はIT企業だとゴロゴロ転がっている。
マジでプログラミング未経験40歳がプログラミングで社会復帰目指すのであれば、この「本職エンジニアだと稼働工数かかりすぎて絶対任せられないが、手作業でやるにはマジでクソなので自動化したい」みたいな業務はあちこちにゴロゴロ転がっているので、そこを狙い目にするのがおそらく一番いい。
というか個人的には「プログラミングで自動化できる事務職の人」がいたら絶対雇いたいもん。別にGoogleの第一線級で戦える力なんてなくてもいい。世間の99%はPythonもSQLもJavaScriptも使えないんだよ。で、そういうのって本当に「人力で1営業日かかるしごとを1時間で終えられる」みたいな絶妙なブルーオーシャンがガンガン転がっている。
めっっっちゃくちゃプログラミング書ける必要はない。なんならウェブ上にあるインターネットのコードをいい感じにコピペしてあれこれできたらいい。
とにかく、「手作業でやるにはゴミな仕事をプログラミングで自動化できるスキル」があったら、事務職としてはかなり重宝されるし、そこからスキルアップできると思う。
あ、ただいくつかアドバイスしておくと、「①仕事進めるときはどんだけ言いづらくても同僚or上司に自分がやろうとしてることを伝えろ（伝えないと自分の責任問題になる）」「②本番データをいきなりいじろうとして失敗すると一発死亡だから『データを元に戻す方法』だけは常におさえておけ」くらいのところ。
大手メーカーのプロダクトについて手伝って欲しいってことで業務委託で入ったんだけど
見させてもらったんだけど、まぁクソコードでした
どれぐらいクソかっていうと{ apple: 100, banana: 200, orange: 300}ってなってる中からorangeの値を取ってくるときに
for文でkeyをループして一つ一つをイコール比較して見つけたらbreakするっていうコードが日常的に使われてるぐらいクソ
他にも数え上げたらキリが無いんだけど「難しくて読めない」じゃなくて「アホすぎて読む気が失せる」っていうコード
そんでそのクソコードに対して追加機能を入れてくれって言われたんだけど
こんなクソコードだとバグを引く可能性がめちゃくちゃ高いし作業効率化のためにリファクタリングしましょう、って提案
結果としてはこの半年ぐらいで想定の進捗の半分ぐらいしか行ってない
「最初は半年でコレぐらいができるって言ってたのに半分しか進んでないぞ！」
とか言ってくるんだけど
「だからリファクタリングしないと作業効率悪すぎて全然進めないですよ、まずはリファクタリングしないと無理ですよ」
ちなみにその人の実装スピードはこっちの3分の1ぐらいなので慣れたら早いとかそういう問題じゃ無い
非エンジニアでリファクタリングを理解してくれない人ってのはまだ分かるんだけど
