はてなキーワード: プログラミング言語とは
IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。
SESを脱退し、そこそこ大手のIT企業の正社員になれた。しかし、そこはこれまでのSESで客先常駐していたような企業とは違い、あまり体制的には良くはなかった。
工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。
1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。
工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計、実装/単体テスト、結合テスト、総合テスト、などのサブ番号に分割して、工数を登録することである。
さらにセキュリティ教育などは個々の案件と無関係なことが多いので、維持管理用の工数番号が振られていることもある。
リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。
さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業したかを15分単位などで記載する。
工数管理のいいところは、作業をサボりにくくなることだ。作業効率が客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。
工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベルで工数を消費する。あとトイレなどにつける工数などもない。
しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。
その形式上すら煩わしいらしく、若手の意見をバリバリ言う人から、
・工数管理は全く意味がない。適当な工数を入力していても誰もチェックしていないのか、何も言ってこない。
・工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システムは不要である。工数管理システムと勤怠システムを一本化すべきだ。
などの意見が出ていた。
そりゃあ工数管理が根付いてない企業に工数管理を行えばそうなるでしょう。
工数管理は業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。
結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。
つまり、当社はよく言えば従業員の意見が通りやすい、悪く言えば従業員のわがままが通ってしまう企業なのだ。
従業員の意見を尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務は改善できない。
これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。
工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員のわがままが通ってしまうのだ。
(まあ当社の工数管理はテキトーだからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的に業務は改善していたと思うが。)
PDCAはPlan, Do, Check, Actionの頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。
実行した後は必ず振り返り(Check)を行いなさい。
当社もPDCAの概念はあるし、週報という形でそれを実現している。
しかしその概念は根付いておらず、週報以外ではPDCAは無視している。
つまり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。
振り返りも当然実施しない。実行のみがある。Do, Do, Doである。
これは作業者レベルでそうであるし、案件レベルでもそうだ。案件はたしかに最後には振り返りの資料を作成する必要がある。しかし、これは単に作成しなきゃいけないから作成してるだけで、綺麗事をまとめた振り返りである。
本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去をグダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽な対策が記載される。
当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。
私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの?」と詰められて終わりだ。指摘するなら十分な資料の作成と具体的な対応策の準備、そして責任と人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。
と書かれていた。
本来は、業務改善は個々のチームだけの問題ではないので、上層部でマニュアル化してルール化すべきではないのか?
アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか?
それをなぜ、個々のチームに依頼する?
業務改善といえばマニュアルの作成や設計書フォーマットの作成だ。
それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである。
しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。
フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。
当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。
これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者に相談しやすくもなる。
こういった業務改善は本来は上層部が率先して枠組みを作るべきだ。しかしやらない。
上層部に知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。
当社はとにかく従業員の声が大きい。強い。
業務改善などの施策を出しても、従業員が納得しないと続かない。
そういう文化を変えるのは並大抵のことでは出来ない。
環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。
仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。
仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。
2024/05/15 10:48
工数管理すべきなのは、成果物ではなくサービスを提供する人なのかもしれない。例えばPMなど。
当社の開発チームは、開発者やPM以外にも、君必要なの?何やってる人なの?打ち合わせには参加してるけど、ただの工数食い虫じゃね?みたいな人もいるのです。
なるほど確かにその通りですね。
意固地になって謝罪を固辞し続けて大変申し訳ございませんでした。
僭越ながらわたくしめがフェミニストを代表して土下座で謝罪させていただきます。
その方法として古代中国より伝わる「三跪九叩頭の礼」で謝意を表させていただきます。
なお、冗長した記述を避けるためにプログラミング言語「COBOL」を用いることを予めご了承ください。
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MAIN.
PERFORM 3 TIMES
DISPLAY "GUI"
PERFORM 3 TIMES
DISPLAY DOGEZA-CNT "KOUTOU"
DISPLAY "CHI"
END PERFORM.
DISPLAY "CHIRAI"
END PERFORM.
STOP RUN.
END PROGRAM SANGUIKIUKOUTOU.
御清聴ありがとうございました。
大変申し訳ございませんでした。
フェミニストの皆様の名誉を毀損したこと、誠に申し訳ございません。
その方法は、中国より古来から伝わる「三跪九叩頭の礼」をもってして深き謝意を表させて頂きます。
なお、表記を簡潔にするためにプログラミング言語で記述させていただきます。
The Prostration and Obeisance
Act I: The Ritual.
Scene I: The Preparation.
[Enter The Counter and The Inner Counter]
The Counter:
You are as brave as the sum of your fat little stuffed misused dusty old rotten codpiece and a beautiful fair warm peaceful sunny summer's day. You are as healthy as the difference between the sum of the sweetest reddest rose and my father and yourself! You are as cowardly as the sum of yourself and the difference between a big mighty proud kingdom and a horse. Speak your mind!
[Exit The Inner Counter]
Scene II: The First Prostration.
The Counter:
You are as brave as the sum of your fat little stuffed misused dusty old rotten codpiece and a beautiful fair warm peaceful sunny summer's day. You are as healthy as the difference between the sum of the sweetest reddest rose and my father and yourself! You are as cowardly as the sum of yourself and the difference between a big mighty proud kingdom and a horse. Speak your mind!
Let us return to Scene II.
[Enter The Inner Counter]
The Inner Counter:
You are as vile as the sum of a cursed old rotten buried smelly half-faced plague-infested contaminated toad and a beautiful healthy honest trustworthy noble golden-hearted angel. Speak your mind!
You are as cowardly as the sum of yourself and a pig. Speak your mind!
You are as vile as the sum of a stinking foul infected curse and a beautiful healthy honest trustworthy noble golden-hearted angel. Speak your mind!
Let us return to Scene II.
[Exit The Inner Counter]
Let us return to Scene II.
Scene III: The Second Prostration.
[Repeat Scene II, replacing "First" with "Second"]
Scene IV: The Third Prostration.
[Repeat Scene II, replacing "First" with "Third"]
Scene V: The Rising.
The Counter:
You are as good as the sum of a happy brave sweet gentle peaceful honest trustworthy noble golden-hearted king and a rose. Speak your mind!
[Exeunt]
御清聴の程有難く存じます。
はい、JavaScriptによるコーディングはコンピュータサイエンスの一部と見なすことができます。コンピュータサイエンスは、情報とその処理に関する学問であり、プログラミングはその重要な要素です。JavaScriptは、ウェブページを動的にするための主要な言語の1つであり、ウェブ開発の分野で広く使用されています。したがって、JavaScriptを学び、それを使用してコードを書くことは、コンピュータサイエンスの実践的な応用の一部と言えます。しかし、コンピュータサイエンスはプログラミングだけではなく、アルゴリズム、データ構造、ネットワーク、データベース、人工知能など、より広範なトピックをカバーしています。それぞれが特定のプログラミング言語やツールを使用して探求されることがあります。JavaScriptはその一部であり、特定の問題を解決するためのツールとして使用されます。それはコンピュータサイエンスの一部であり、その全体ではありません。それでも、JavaScriptをマスターすることは、コンピュータサイエンスの重要なスキルを習得するための素晴らしいステップです。それはあなたが複雑な問題を解決するためのロジックとアルゴリズムを理解するのを助け、あなたの思考を開発するのを助けます。それはまた、あなたがウェブ開発の世界に足を踏み入れ、あなた自身のウェブサイトやアプリケーションを作成するのを助けます。だから、はい、JavaScriptによるコーディングは確かにコンピュータサイエンスの一部です!
はい、ブラウザの実装は確かに**コンピュータサイエンス**の一部です。以下に、その理由をいくつか挙げてみます:
1. **アルゴリズムとデータ構造**:ブラウザは、効率的な検索、ソート、データの格納と取得など、多くのアルゴリズムとデータ構造を使用します。
2. **ネットワーキング**:ブラウザは、HTTPやHTTPSなどのプロトコルを通じてインターネットと通信します。これらのプロトコルの理解と実装は、コンピュータサイエンスのネットワーキングの分野に直接関連しています。
3. **レンダリングエンジン**:ブラウザのレンダリングエンジンは、HTML、CSS、JavaScriptなどのコードを解析し、それをユーザーが見ることができる視覚的なウェブページに変換します。このプロセスは、計算理論、グラフィックス、プログラミング言語の理解を必要とします。
4. **セキュリティ**:ブラウザは、ユーザーのデータを保護するために、さまざまなセキュリティメカニズムを実装します。これには、暗号化、サンドボックス化、同一生成元ポリシーなどが含まれます。
これらすべての要素は、コンピュータサイエンスの基本的な概念に基づいています。したがって、ブラウザの実装は、その「サイエンス」の部分を明確に示しています。ブラウザの設計と実装は、これらの理論を実際の製品に適用するための実践的なフレームワークを提供します。それらは、問題解決、効率的な設計、そして最終的にはユーザーに価値を提供するための方法を探求します。これが、ブラウザの実装がコンピュータサイエンスである理由です。
とある雑記ブログを7年ほど前に見つけて、年に数回ほど訪れている
役に立つとか面白いなんてのは一切ない
あまりにも拙い内容なので俺しか読者がいないから不憫に思っているだけだ
そのブログは「ポケストは任天堂関連だから京都に多い」という意味不明な解釈を垂れ流して炎上していた
リリース直後だとしてもお粗末すぎる記事なので当時話題になっていたと思う
その後も知能指数が低いこたつ記事を連発したり、アンチや社会への不満を似たような文面で何回も投稿するなど、ちょっと不憫にも思えるくらい情けない記事ばかり書いてる
カテゴリーもその時の瞬間的な流行に乗っているだけにすぎず、特に深いものはない
唯一読まれていたのは遊戯王の記事だったらしいが、それも飽きてやめてしまっている
それなのにブログ自体は今年で9年目となり月1投稿は欠かしていない
そこは素直に良い点だと思う
問題は筆者の能力が著しく低く、せいぜい炎上記事でしかPVを伸ばせないことだ
びっくりするがあの文章力で短編小説家を目指しているといまだに言っている
何が目標かテーマは何か何ができるのか一切わからない、本当に謎なブログと筆者だ
どういう内容書くつもりだよ
改行する
<br>
右から左に動かす
おいHTML構文かよ
どこかの記事のコピペをしないだけましだけど、それでもプログラミングと題してHTMLなんだよ
今日日、小学生が授業で習うような超初歩的なことしかないていないし、しかも内容が超絶古い
しかもmarqueeって俺も知らんぞってググッたらとっくに非推奨扱いの化石じゃねーか
なんで古の手打ち掲示板でしか通用しなさそうなことをこの令和に?
炎上狙いだとしても、もっとこうさ、ちょっとバズりそうな要素を含ませるとかしようぜ
これがある程度PV稼いでいるブログに書いた珍記事だったら面白いけど、おまえのところの読者なんて俺くらいしかいないだろーが
センスのかけらを獄門疆に封印してきたような君がいくらやってもPV伸びんわ
かつてのポケゴーは題材がビッグネームだったからバズっただけで、プログラミングなんてものでどうにかなるもんじゃねーよ
「AIを使えばやりたいプログラミング言語のコーチがタダでしてもらえるんだぜ!」
くだらん。
昔のグーグルだったら「[プログラミング言語名] 勉強 やり方」でググったら最高にイカしたページにたどり着いた。
作りたいシステムがあっても「[言語名] [やりたいこと] コード」でググれば欲しかった情報がドンピシャでガッポガポ。
そんな黄金時代があった。
ADSLが世界をつなぎ始めた世界、ネットの海が光速で流れていなかった穏やかな時間。
あの頃、ネットの海から求めていた知恵を引き上げるのは今よりずっと簡単だった。
今のネットは汚れきったヘドロの塊であり素のまま飲めば猛毒となる巨大な汚水、まるで東京湾だ。
AIがやっていることはネット上に溢れた有象無象を濾し取って、少しだけ昔のインターネットに近づけるだけの作業でしかない。
昔はほんのちょっとした言葉の組み合わせでたどり着けた知識が、今や何百文字ものプロンプトを指定してようやくたどり着けるようになった。
「AIは賢いものとそうでないものの格差を広げるだろう」と語るものは物事の一面しか見えていない。
正解は「かつて、インターネットという空間は誰しもに開かれた無限の智慧が内包されていた。その知恵が一部の人間に独占される時代がやってきた」だ。
誰しもが賢く慣れる世界の方がいいに決まっている。
生まれついたIQの高低を義務教育を終えて十年二十年それ以上経ってもいつまでも擦り続けるような哀れな者達の戯言のなんと醜く濁ったことだろう、まるで東京湾だ。
fx趣味なもんでpinescriptとMQL4っていうプログラミング言語は分かるんやが、こいつらとは勝手が違いすぎて諦めた。いずれにせよ、英語は分かってた方がスムーズに打てて良い。
プログラミング言語で動的言語を嫌って静的言語こそ至高みたいな主張の人って結構みかけるんだけど、なんでみんな偉そうでマウント取ろうとしてるの?
パフォーマンス面での優位ならまだわかるけど主張は基本型がないことをディスってる
頭が良ければ脳内で整合性の取れるコードを書けるわけだから、コンパイラのサポートがなくても書けるほうが優秀なのは自明のはず
コンパイラにサポートしてもらわないとまともなもの書けないよというほうが能力としては劣ってる
劣っててコンパイラのサポートがほしいならそれでもいいんだけど、なぜ自分が無能だということを偉そうにアピールできるのかがわからない
自分頭悪いので静的言語じゃないと書けないんですーとか言われたらじゃあそういう言語使うかとなるけど、
動的言語とかゴミ使う価値ないとか、◯◯言語は消えるべき、とか言われたらお前の頭が悪いだけなのになぜそれに合わせる必要があるの?としか思えない
コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果
ボケ&ツッコミ「お願いしますー ありがとうございますー」
ツッコミ「あー ありがとうございますー ねっ 今Githubでスターをいただきましたけどもね」
ボケ&ツッコミ「ありがとうございますー」
ツッコミ「ねー 有り難いですよ ほんとにね」
ボケ「入れておきましょう」
ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」
ツッコミ「プログラミング言語の名前忘れてもうて どうなってんねそれ」
ツッコミ「分からへんの? いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」
ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」
ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」
ツッコミ「すぐ分かったやん こんなんもー」
ツッコミ「いやそうやろ?」
ボケ「オカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」
ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」
ボケ「そやねん」
ツッコミ「HaskellはOSを作るのには向いてへんからなぁ」
ボケ「そやねんな」
ツッコミ「な? Haskell側もOS開発に任命されたら荷が重いよあれ」
ボケ「そやねんそやねん」
ツッコミ「Haskellってそういうもんやから ほなHaskellちゃうがなこれ」
ボケ「そやねん」
ツッコミ「あれほなもう一度詳しく教えてくれる?」
ツッコミ「Haskellやないかい モナドは確かに難しいねんHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」
ボケ「まあねー」
ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードがスッキリするねん 俺は何でもお見通しやねんから Haskellのモナドなんて」
ツッコミ「そうやろ」
ボケ「オカンが言うには プロダクションで使うにはまだ早いって言うねんな」
ツッコミ「ほなHaskellちゃうやないかい プロダクションでHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」
ボケ「そやねんそやねん」
ツッコミ「な? Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」
ボケ「そやねんそやねん」
ボケ「そやねんな」
ツッコミ「Haskellちゃうがな ほな もうちょっとなんか言ってなかった?」
ボケ「学生の頃 なんでみんな憧れるんか分からんかったらしいねん」
ツッコミ「Haskellやないかい 学生の頃はHaskellとOCamlとLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」
ツッコミ「そうやろ」
ボケ「オカンが言うには 関数型プログラミングの教科書に必ず載ってるっていうねん」
ツッコミ「ほなHaskellやないかい 教科書のサンプルコードにHaskellのコードが出てこんわけないやん」
ツッコミ「Haskellはね 関数型プログラミングの王道中の王道やねん」
ツッコミ「Haskellや絶対 ほな ほなもうちょっとなんかゆうてなかったか?」
ツッコミ「Haskellやないかい Yesodとかあるやろ な? RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskellや絶対」
ツッコミ「そうやて」
ボケ「オカンが言うには ジャンルでいうたら数学やっていうねん」
ツッコミ「ほなHaskellやないかい ジャンルで数学言うたらHaskellしかあらへんやん な? Haskellは数学の理論がベースになってるんやで ラムダ計算とか圏論とかな」
ボケ「そやねんそやねん」
ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった?」
ツッコミ「Haskellやないかい Haskellは変数が不変やから 変数に感謝するのは当然やねん ね? 状態変更せんと安心して使えるからな」
ボケ「そやねんそやねん」
ツッコミ「Javaとかの変数は裏切るからアカンねん Haskellの変数は一生そばにおってくれるから最高やで」
ボケ「でも分かれへんねん」
ツッコミ「分からへんことない おかんの好きなプログラミング言語はHaskell もぉ」
ボケ「でもオカンが言うには Haskellではないって言うねん」
ツッコミ「ほなHaskellちゃうやないかい オカンがHaskellではないと言うんやから Haskellちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン?」
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて(キラキラ)」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
3行でまとめます。
〇 エクセルシートはユーザーインターフェース(インプット)か出力結果(アウトプット)のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列(連想配列)に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
(もちろん、ユーザーインターフェースの別の欄(セル)に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。)
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
(これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…)
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
1.元となるcsvファイルをエクセルに読み出してシートに格納
2.そのデータは日付が数値型になっているので、日付(数値型)の入った列を文字列に変換した日付(文字列型)列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず(あるいはエクセルのセルオブジェクトを変数のように扱い)、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか?。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列(連想配列)と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
(逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・)
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列(連想配列)で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
(参考)【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
(参考)Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ(VBA)から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列(連想配列)のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある(ローカルウィンドウやDebug.printを使うなど)ので、リハビリに取り組んでほしいです。
(参考)VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
(最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。)
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用(加工用)のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ(VBA)は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
(あと、コマンドプロンプトの真っ黒な画面が怖かった)
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
(そのやさしさが上述したとおり悪魔の罠なわけですが。)
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
数学の必然性は実は人間の言語分析能力によるものなので、言語能力が異なる宇宙人とは、数学的語彙が共有できない可能性があるんですよね~
なぜ数学と言語能力が関係するんだ?と思う人は、以下のノーム・チョムスキーの有名な、無意味な二種の文を見ればわかってもらえるかもしれませんね~
・“Colorless green ideas sleep furiously.”(「無色の緑の考えが猛烈に眠る。」)
・“Furiously sleep ideas green colorless”(「猛烈に」「眠る」「アイデア」「緑色」「無色」)
前者は文法的には正しいが意味が無い文で、後者は文法的に正しくないから意味がない文、ということはわかっていただけるかと思います。
しかし、上記二種の文は、両方とも経験的には何も想起させないがゆえに、経験的には同様に意味の無い文です。
ということは、経験こそが認識の基礎、基底であると考える人にとっては、二種の文の違いを説明することができないのですよね~。
なぜならそのどちらも経験することができず、経験による理解が基底であると主張するのだから、経験的基底において違いのない(意味のなさ、指示対象が存在しないという点において同質という意味)上記二種の文の本質的差異(基底的差異)を指摘することができないのですね~
現代の言語哲学、そして現代論理学の基礎を作ってきた哲学者たちは、数学の必然性がどこから来るのかという問題について、
文の経験的理解よりも前に、文の文法的分析が先に行われる(そして数学的必然性は、文法分析に基づく理解そのものから正当化可能である)ことを示すことによって、
前経験的(アプリオリ)に論理や数学の必然性の正当化が可能であることを証明してきたんですね~
例えば上記二種の前者の文でいえば、経験できないにもかかわらず文法的に正しいことが理解できるのは、まず文法分析が先に行われ、その後意味の解釈に失敗するから無意味なのであって、その逆ではないのですね~
そして数学で扱われる文、例えば2+2=4は、なんらかの経験を前提せずとも、形式的な理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね~
そして例えば上記二種の文とは別の有意味である文「無職の緑色のジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね~
プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス的分析が行われますよね~
だから、数学の必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能性ももしかしたらあるのかもしれませんね~
なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね~