  |
はてなキーワード: 変数とは
昨年子どもが生まれ、育休を3ヶ月取った。都内の上場スタートアップ勤務ということもあり、男性育休には寛容な環境で、同僚からはお祝いにおくるみもいただき、前向きに送り出してもらった。
当然だが、とてもハッピーな気持ちで育休に入った。出産に立ち会って自然と流れた涙は、これまでの人生で最も無垢で、言葉にならない嬉し涙だった。仕事と子育てを両立して、より一層充実した人生を送っていくぞと意気込んだ。
しかし、育休中に痛感したことがふたつある。
まず、育休中は仕事をしていないので、育休を取ったからと言って仕事と子育てを両立したとは思えなかった。数ヶ月程度の育休は「特に大変な新生児期を乗り切る手段」であって、「仕事と子育てを両立する手段」にはならないのが現実だ。
そして2つ目に、「両立」と勝手に言っているが、それは自分だけの問題なのかということ。子育ては夫婦の共同プロジェクトだ。義務教育までとしても15年を要する、一大プロジェクト。そのプロセスにおいて、当然、妻には妻の「両立」がある。
育休は子育てのほんのプロローグに過ぎず、その後が本番と言ってもいい。
3つそれぞれの満足度（納得度の方が適切かも）のバランスをどうやって保っていくか。中長期的にはこれが1番のテーマで、もはや、要素がふたつであることを前提にした「両立」という言葉で捉えること自体が、時代遅れに思えた。
妻はメーカー勤務で、仕事好きな人間だ。バリキャリ志向ではないが、自社商品を愛してやまないタイプで、今後もフルタイムでの仕事を望んでいる。彼女が仕事を通して充実感を得ることは、一緒に生きる私や子どもにとっても大切なことだ。
私は会社に働き方の相談をした。フレックスがなく、リモートにも回数制限があるため、せめて後者は緩和できないかと。しかし残念ながらその交渉は実らなかったため、転職を決めた。
次はリモートかつフルフレックスの環境で、幸いなことに年収も大きく上がるオファーをもらえたので、自分自身の問題は解決できたが、これだけ少子化が社会問題になる中でも、子育てと仕事の両立に優しくない現実を突きつけられたモヤモヤは消えていない。
経済合理性が伴う事由や、事業を左右するような外圧がなければ企業は変化しない。女性社員の活躍を進めて社会情勢に応じつつ、男性社員にはこれまで通り仕事にフルコミットさせたい。これが経営者の本音だろう。
しかし、その男性社員に子どもがいるとなれば、しわ寄せはパートナーの女性にいき、どこかで働くその人のキャリアを制限し、家庭の幸福度の総量も減らす。間接的に女性活躍を阻害しているわけだが、大半の企業は「知ったこっちゃない」と言うだろう。
だから思う、男性こそ子育てを理由に転職した方が良い。環境や制度を変えなくても男性社員が辞めないから、企業も変わらない。賃上げだってそうだろう。
厄介なことに、子育ては本当に千差万別。子の性格や体質、家庭の経済力、時間の柔軟性、幼稚園や保育園の環境、本人やパートナーの体力、実家の頼りやすさなど、いろんな変数で難易度が変わる。
カードに恵まれただけだったかもしれないことに想像が及ばず、n=1の個人的な体験談で断じてしまう人もいる。そういう人が上司や経営者の会社にいるなら、すぐに転職した方が良いと個人的には思う。
少子化と人手不足が課題の社会なのだから、共働きで子育てもしようという自分は多少わがままを言ってもいい。自分にそう言い聞かせることで、同僚に迷惑をかけることを頭から消して長めの育休を取り、転職も決めることが出来た。
仕事より家庭、という安直な二元論では捉えていないし、仕事ももちろん頑張っていくが、「仕事=今の職場」ではないはずだ。
繰り返すが、男性こそ子育てを理由に転職した方が良い。それが大きなうねりになれば、いろんな問題が少しずついい方向に向かうように思う。
標準的な経済理論で経済主体の行動を決定するのは、名目変数ではなく、実質変数である。
「賃金と物価の好循環」がなぜ好循環なのか。「デフレを抜け出したいでーす！ピロローン！」ぐらいの根拠しかない。
経済の実質値がインフレによって高まるということはあるのだろうか。
名目賃金と物価が同時に上昇する経済の方が、互いに凍結し合っている経済よりも好循環が起きやすい、という見方を100歩譲って認めるとしてみる。
家計が企業のように、物価・賃金の名目値が上昇する経済が、消費や住宅投資をより増やすかと言われれれば、それはかなり怪しい。
貨幣錯誤はあるかもしれないが、実質賃金が低下し、物価が高まれば消費は減る。当然である。
「賃金と物価の好循環」の正の効果が、他のリスク要因を上回るかというと、断定はできない。
経営者としてお答えしよう
ファック死ね
業務時間を割いてなにかやってるのは知っていが注意すると拗ねてモチベ下げるので黙っているが、管理職には絶対に上げないフラグを立ててるからな
持続可能性
頼むよ、これを意識してよ
仮に５秒短縮が当該業務担当５人、１０回／日だとして年間１６時間。。。
ん？わりとデカいな。
頑張れ
違う違うちがう
どうせ空いた時間は給湯室でくっちゃべってるだけだ
知るかボケ
あのな、頑張って勉強して業務効率化に寄与してくれるのはありがたいが、
オマエ死んだらどーすんの、連想配列が保守メンテできるスタッフ他にいる？
ワークシート上のセル式ならなんとか追いかけられますが、VBAでややこしいことやれたらわかりませーん、だよね？
VBAでゴチャゴチャやられるといざ業務拡大近代化の時に余計な工数もかかるの。
ワークシート上で処理完結してて適度にコメントも書いてくれてたらそれがそのまま要求仕様、ドキュメントになるの。
プログラム化されちゃうと要求仕様はそこから紐解かなきゃならない、そんだけ余分な工数がかかる。
残業して連想配列してるのは分かってるが、さっさと帰って婚活でもして、ブサイクな嫁とアホの子供でも作って、あぁもう迂闊に会社辞められねぇ、ってなってくれたほうが会社はありがたいの。
美しくない？
知るかボケ
どこにどれほどリソース割くべきか
こっちもアホでは無い、経営多変数パラメーターを加味して妥協し方向性と優先順位決めてるんだ
頼むから言う事聞いてよ
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、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などに切り替えていく、というプロセスがいいのではと個人的に思います。
数学の必然性は実は人間の言語分析能力によるものなので、言語能力が異なる宇宙人とは、数学的語彙が共有できない可能性があるんですよね～
なぜ数学と言語能力が関係するんだ？と思う人は、以下のノーム・チョムスキーの有名な、無意味な二種の文を見ればわかってもらえるかもしれませんね～
・“Colorless green ideas sleep furiously.”（「無色の緑の考えが猛烈に眠る。」）
・“Furiously sleep ideas green colorless”（「猛烈に」「眠る」「アイデア」「緑色」「無色」）
前者は文法的には正しいが意味が無い文で、後者は文法的に正しくないから意味がない文、ということはわかっていただけるかと思います。
しかし、上記二種の文は、両方とも経験的には何も想起させないがゆえに、経験的には同様に意味の無い文です。
ということは、経験こそが認識の基礎、基底であると考える人にとっては、二種の文の違いを説明することができないのですよね～。
なぜならそのどちらも経験することができず、経験による理解が基底であると主張するのだから、経験的基底において違いのない(意味のなさ、指示対象が存在しないという点において同質という意味)上記二種の文の本質的差異(基底的差異)を指摘することができないのですね～
現代の言語哲学、そして現代論理学の基礎を作ってきた哲学者たちは、数学の必然性がどこから来るのかという問題について、
文の経験的理解よりも前に、文の文法的分析が先に行われる(そして数学的必然性は、文法分析に基づく理解そのものから正当化可能である)ことを示すことによって、
前経験的(アプリオリ)に論理や数学の必然性の正当化が可能であることを証明してきたんですね～
例えば上記二種の前者の文でいえば、経験できないにもかかわらず文法的に正しいことが理解できるのは、まず文法分析が先に行われ、その後意味の解釈に失敗するから無意味なのであって、その逆ではないのですね～
そして数学で扱われる文、例えば2+2=4は、なんらかの経験を前提せずとも、形式的な理解(つまり文法的理解)から正当化可能であるがゆえに必然的(=非偶然的、または前経験的)なのですね～
そして例えば上記二種の文とは別の有意味である文「無職の緑色のジャージを着た男性が猛烈に眠る」であったとしても、まず文法的理解が先に行われたあと、その意味解釈を行うことができるがゆえに有意味なのですね～
プログラミング言語だって、まずどれが変数で、その変数に何が割り当てられているかといったセマンティクスよりも先に、シンタックス的分析が行われますよね～
だから、数学の必然性は実は人間の前経験的な言語分析能力によるものなので、言語能力が異なる地球外生命体と遭遇した時、数学的語彙が共有できない可能性ももしかしたらあるのかもしれませんね～
なぜなら我々の理解する必然性とは、我々の言語分析能力に基づくものであって、よそから来た宇宙人にそれが期待される理由がないからですね～
GitHub Copilotは変数名やメソッド名をちゃんと規則立てて付けてるとめちゃくちゃ優秀に機能する
boolean open
みたいに付けてると微妙なこともあるけど
boolean isDialogOpen
他にも、createDataDayっていうメソッドがあって似たようなcreateDataMonthとかが乱立してるときに実装を共有化したいって思ったときなんかは
function createDataBase
ぐらいまで打ち込むと共有部分だけ抽出してくれる
命名規則だけじゃなくて実装のアルゴリズムがちゃんと整理されて設計されているとこっちがやりたいことを把握して実装してくれる
この辺は例が難しいけれど、なんかCopilotがまともなことを返してこないな、と思う時はこっちの実装が微妙な場合が多い
整理しなおして分かりやすい状態にしておくと綺麗に動いてくれる
Copilot使えねーって言ってる人のソースはほぼ100%こういう最低限のことができてなくて
とか言ってる奴は50%ぐらいの品質の命名規則やアルゴリズムになってる
の具体的になんて本(ネットのpdfでもよい)の何ぺージあたりからが元増田の問いにとって核心なのって話よね
てか、ラムダ計算よりむしろ記号論理学のほうが学問としての領域が気持ち広くなってね？
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
(後略)
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
「Aかつ¬Aの証明を得ることができる」に対して、「いいや得られない。お前がそのように見せかけているだけだ」おれの計算(記号処理)手続きこそ推論規則に適っているし正しいと、反論されたら？
また、「そもそもここでいう『得る』とは」どういう意味か？と突っ込まれたら曖昧でなく『得る』ということが『得る結果の具体例ではなく』『どういうことか』記述できるのかという話です。
￢￢Ａ→Ａという規則に基づいた結果が
￢￢￢￢￢Ａ→￢￢￢(￢￢Ａ)→Ａ
なんだよ！と言い張られる。もちろん常識的にはおかしいと思えますが、いまは突き詰めたことを言っています。
一般には、￢￢￢￢￢Ａを書き換えるために、この記号列の一部分￢￢Ａに着目して、規則からＡと書き換えられるから、この結果を￢￢￢(￢￢Ａ)に代入？して、￢￢￢Ａに書き換えられる、という思考プロセスをとるでしょう。
しかしあくまでものとしては、ここで考えているのは￢￢Ａではなく￢￢￢￢￢Ａなわけです。
規則通りに書き換えられてない、言い換えるなら同じ規則を使っていないという主張に対して、そもそも同じ規則が適用できているということ、規則が同じとはどういうことか自体を定義や公理に組み込むことはできるのか。
矛盾や証明ということはまだその概念を記号列で示す余地があるが、規則が同じかどうかという定義もとい「規則」は厳密に定義可能かということです(無定義語として関係性の定義でもよい)。図形が合同か、みたいな合同の概念の定義など比べてもまたレイヤーが一段メタ的になっていて厄介というか。「違うのは自明じゃないか！」といっても、自明は説明できてこそ自明なのですが、ここでいう同じかそうでないかということについてはそれを根拠だてる定義は原理的に無理なんじゃないかと思えてしまいます。
さきほど『得る』という言葉に突っ込まれたら云々ということを言いました。
ブコメには「自然言語の曖昧さで数学をの厳密さ否定しようとしてるだけだ」というのがあります。
別に私は自然言語の曖昧さを問題にしていません。そこは問題の本質ではないです。
むしろこうした言葉は一般に疑いようなく明らかなものです。「左右」とか「これやあれ」みたいな近称や遠称の概念などもそう思われるでしょう。
しかしむしろこれらの概念には一切曖昧さはないという前提に立っても、これもごく単純な話で、曖昧でないからといって、いままでその概念を持ってなかった知性的存在に対して、「これ」や「左右」といった「概念」を、対面やジェスチャーを使えばいざしらず、記号列を用いて一意に定義できる保証はないよね、ということです。定義の厳密さを担保する必要条件が、記号論理学に基づくということにあるのなら、数学を厳密とのたまうかぎりにおいて、当然対面やジェスチャーではなく、これとか同じとかみたいなもっとも原始的な部類の言葉まで全て記号で一意に定義できることを示せなければならないでしょう。
あとあなたが↓のトラバと同一だと言ってくれたら以降↓の方のツリーに返信書いて一元化するのでそのつもりで
https://anond.hatelabo.jp/20240216215810
ちなみに関連しそうな話題として自分自身ラムダ式を勉強した経験があるけど
2. ラムダ項M, Nに対して (M N) はラムダ項。この形のラムダ項を適用（ラムダ適用）という。
という定義があるんだけど、これに基づけば(x x)というのもラムダ項じゃないのって思ってた。
でもラムダ式で(x x)なんて形のは見たことないし、違うんだろうなと。
でも論理的にはなぜ違うのか全く納得できてないので(納得感が正しさにとって問題じゃないとはいえあえて言うが)(x x)だってラムダ式でしょって胸を張って言い張れる。
分かってる人からみれば、そして俺にとっても￢￢￢￢￢Ａ→Aと同程度にバカげた主張なんだが、そのわかってる人にとっても「この規則ならこういうことが言えると思うのに、なんで正解とされてるのと自分が思ってることが違うの？」ってなることはあるはずで、それはこの世で一番数学ができる人であってもありえること。この世で一番数学ができる人さえ規則を正しく適用できていないらしいとき、そもそも正しい適用とはなんだってなりそうに思うんだが。
青年向け漫画の編集者をしていた。といっても若い頃の話だ。都内にある編集プロダクションを辞めて田舎に帰ったのが36の時だから、おじさんの入り口に立った頃か。今では完全なるおじさんである。
働いていた会社というのは、講談社とか小学館とか秋田書店とか、そういう大手出版社ではない。あくまで編集プロダクションである。出版社と編プロがどう違うのかって……ざっくり言うと元請けと下請けだ。出版社が出版事業（今回だと青少年向けの漫画作りや商業展開）の企画をして、漫画家が作品そのものを作って、編プロは雑誌本体を作って、その制作過程で印刷所やデザイン事務所といった専門集団と関係することになる。
イマイチな説明になってしまった。一般社会の例で説明する。民法でいうところの委託(準委任契約)に当たる。公共建築の分野でいうと、公共機関の建築技師が新しい建築物のマンガ絵を作り、建築事務所が基本設計～詳細(実施)設計をして、出てきた成果物を元に大手建設会社が施工監理し、地元にある中小事業者が実際の土木建築作業をする。
自分が勤めていたのは、この例でいうところの建築事務所だ。受益者(国民=漫画読者)の希望に応えたい組織があって、そこから依頼を受けて動いている関係会社のひとつ。そういうアナロジーだ。
出版社との役割分担は、そこまで分離しているわけでもない。漫画編集者といえば、昔の手塚治虫ほかの自伝みたいに、漫画家とアツいやり取りをしているイメージがある。ああいう、企画経営と制作現場の間にあるような仕事は、出版社の社員が直接することもあれば、編プロが出版社(編集部)のオフィスを間借りして行うこともある。
前者の例だと、マガジン、サンデー、チャンピオンなどだ。コンビニや書店にほぼ必ず置いてあるレベルの漫画誌。大手出版社に総合職コースで入社した人が、（編集、取材、制作、資材、宣伝、マーケティング、総務経理人事その他事務）といった多くの部門のひとつである漫画編集部に割り振られて其処に居る。
後者の例だと、大手出版社が出している漫画誌でも、あなたが聞いたことのないやつもけっこうあると思う。そういうのは、編プロが出版社(編集部)の仕事を丸ごと請けて実施していることが多い。自分は、そういう会社で働いていた。職場自体は大手出版社の中にあるが、いわゆる委託先の社員だった。別の言い方をすると、親雑誌に対する子雑誌の関係。
ほかの長文増田の記事を見るに、あまりたくさん書けない仕様のようである。何文字までかは知らないが、文字数制限があると思う。本当は何万字でも書きたいのだが、あくまで自分が書きたいだけであって、あなたが読みたいとは限らない。一万字以内になるよう心掛ける。以下に、自分が関わった漫画家を２人だけ紹介しよう。最後に所感を述べて終わりにする。
その２人(A先生とB先生。どちらも若手)と私は、分水嶺のような関係（追記；わかりにくい表現ですいません。ブクマカのBuchicatさんのコメントのとおりです）だった。ある日、私が担当していた漫画家のA先生が新作の企画提案に来ていて、同じタイミングで別の編集者のところに持ち込みをしたのがB先生だった。その別の編集者が不得手なジャンルだったこともあり、A先生との話が終わった後で、私も一緒にB先生の作品を読んだ。
その後、編集部の責任者を交えた会議で、私が引き続きA先生の新作の担当者に決まった。新人であるB先生の担当になる可能性もあったが、そうならなかったのは、今の漫画界の一界隈にとって幸運なことだった。
A先生は、雰囲気が暗めだった。人間性まで暗いというわけではなく、心を開くと明け透けになるタイプだった。モードに入ると饒舌になる。
弊誌では、読み切りを何度か掲載したことがあった。アシスタント経験あり。小さい賞を取ったことがある。ヒット作はないが、若き漫画家としてはキャリアがあった。
画力が抜群だった。小学校や中学校で、学習ノートにフシギダネの絵とかをソラでゲームパッケージそのまんまに描く子がいただろう。とにかく天賦の才を持っていた。最小限の画量で、それでいて迫力と感情に溢れた1枚1枚を描く。そういう人だった。
難点は、マジメすぎるところか。少し前にやっていたアニメだと、チェンソーマンに登場するアキくんか(少し前……？)。とにかくマジメだった。いや、やはり『直向き』に訂正する。
A先生は、少年誌に見合わない重たいテーマに挑むことがあった。今でもそうだ。彼のマンガには『緩さ』がない。それもいいところなのだが。私は好きだった。はっきりいって。が、読者の傾向に合っているかは微妙だった。
子どもの頃から漫画が好きだったらしい。中学生の頃のイラストを見せてもらうと、俄然キャラクターへの愛に溢れる作画を見ることができた。中学生らしい、プロには程遠いクオリティなのだが、しかし見ていて違和感がないというか、自然にくっきり入ってくる。
私という人間は、具体例で物事を説明する癖がある。上の「中学生らしいイラスト」を別の事例で表現すると……「うるせ～！！知らね～！！FINALFANT ASY」(短縮URL：https://x.gd/L5cc4)だろうか。以前、いつぞやかのid=pptppc2さんのブックマークコメントがきっかけで元ネタを知ることになった。
あの時のA先生のイラストは、ベルセルクのセルピコだったと思うが、力強い表現だったのを覚えている。セルピコがファルネーゼを抱きかかえて、
「申し訳ありません 道案内を頼まれまして 少し席を外していましたもので」
と言うシーンの模写だった。
さて、そんなA先生だったが、ある時これまた重量級のテーマで描きたいものがあるという。先ほどの、編集部での新企画提案の話だ。
その際、A先生からプロットをもらい、私のデスクで拝見させてもらったところ……うちの雑誌では持て余しそうだった。作品の質が低ければ普通に打ち切りになりそうで、作品の質が高くても――弊誌の売上規模だと会社グループ全体の機会損失になりそうだった。私の前でパイプ椅子にかけているA先生は、不安げな面持ちだった。
内部の話で悪いが、例えば「甲」という雑誌の亜流の「乙」という雑誌があるとする。ビッグコミック(オリジナル、スピリッツ、スペリオール)みたいな感じだ。この時、甲と乙に明確な上下関係があった場合、乙誌に掲載された漫画が甲誌に引き抜かれることがある。その際、甲誌の編集部から言われるのが、
「なぜうちの編集部に見せなかった？」
という意見だ。これは、ストレートに言われる場合もあれば、暗に言われる場合もある。だが、事前に上流の雑誌に見せていたとして、多くの場合は玉虫色の返事があるだけだったりする。
話を戻そう。この時の自分は、編集部の自分のデスクのあたりでA先生の次回作を見せてもらっている。確か缶コーヒーを飲んでいた。
自分としては、A先生のマンガを弊誌に載せたいと思っていたが、先ほど述べたとおり、後ろ髪を引かれる思いもあった。社会派の少年漫画というのは扱いが難しい。その作品が「あしたのジョー」の影響を受けているのは明白だった。「A先生であれば、きっと面白い作品にしてくれるのだろうな」という期待はあった。
うーん、大いに悩むところだ。どうしよう。思いあぐねていたところで、別の編集者から声がかかった。要約するとこんなところか。
「持ち込みに来た人がいる。私の専門じゃないので判断が難しい。門前払いにするレベルではないので、あなたの判断を仰ぎたい。上の人間は今出かけている」
要するに、自分の専門外なので判断できないよ、と言っている。ここも会社なので、編集者の上には当然上司がいる。その人達がいなければ同輩に相談するのが基本だ（余談だが私は後輩だった）。こういう原則は一般の会社と変わらない。
その『別の編集者』というのは、儚い感じの純文系が得意なタイプだった。一番わかりやすい喩えは……『はちみつとクローバー』みたいなやつだ。ああいうのが得意な人だった。
その時は、A先生との話が終わったら行くと告げた。それで、しばらくそのまま話を続けた。
「この作品はいい意味で重たいね。ちょっと考える時間がほしい」
と言って、その日は解散した。A先生は、「お願いします！」と言ってパイプ椅子を立ち、そのまま帰っていった。いつもだったら喫茶店でご飯をおごっている。
A先生は、『いい子』だった。あまり感情は出さないけれど、人間に対する愛を持っている。そういう子だった。私が当時、A先生にご飯を奢って、彼がおいしそうな表情で食べている時、私は幸せだった。A先生が幸福だと、自分も幸福だと思えた。A先生が漫画という手段で自らを表現している時、まるで自分もそれに劣らぬような喜びを得ていた。
ヘンな表現かもしれないが、例えば読者がA先生を褒めている時、自分とA先生との区別がなくなっているというか。彼のことが、自分のことみたいに嬉しかった。これは愛なのだろうか。
持ち込み部屋に行くと、別の編集者と、持ち込みに来た子が対面で座っていた（ちょこんと挨拶をしてくれた）。自分が座る席には作品が置いてあった。綴じられていない原稿用紙がある。ページ数にして30枚ほどだった。もっと多かったかもしれない。記憶があやしい。
実際、B先生の作品は面白かった。コテコテの学園ものかと思いきや、登場人物それぞれに適度な制約があって、キャラクターも立っていた。これまでのキャリアを聞き取ったところ、作品が雑誌に掲載されたことがあるようだ。アシスタント経験もある。
絵の方は、自分がこういうのも大変失礼だが、上手な方ではなかった。どちらかというと、脚本や設定、キャラ作りが得手のように映った。当人が情熱を注いでいる箇所はすぐにわかる。キャラ絵が有名漫画家の影響を受けているとか、キャラクターの台詞回しがハリウッド映画風とか、背景や小物を手を抜くことなく全部描いているとか、そんな具合に。
光るものがある作家だった。これを見抜けないようなのはモグリ――そんなレベルで輝いていた。
私は作品を読み終えた後で、「ちょっと待ってね」と自席に戻り、少し残っていた缶コーヒーを飲み干して、思案を重ねつつ持ち込み部屋に戻った（どうするのが最良かわからないケースだった……）。
それで、テーブルではこういうやりとりをした。
私「イイ作品だと思います。特に、セリフ回しにセンスを感じます。掲載ができるとかここでは言えないけど、話は通してみますね」
Ｂ「ありがとうございます」
私「それで、担当はね……縁なので。あなたがするのがいいのでは？」
編「私よりもほかの人がいいと思います。もっと才能を引き出せる人が……」※小さい声で
私「いや、でも恋愛描いてるよ。エンタメだけどいいんじゃない」（こいつ、作家の前でアホなこと抜かしよって）
編「難しいです」
私「でもこれ、縁だよ」（意識が低すぎる……）
編「ほかの作家さんも抱えてるので。いっぱいいっぱいです」
私「わかりました」（トラブル回避のため後で編集長に説明しとこう）
Ｂ「すいません。僕の作品はどうなるんですか？」
私「後日連絡しますね。必ずしますから、それまでは他誌への持ち込みは待っていただけますか」
Ｂ「あの、はい。できればですが、早めでお願いします。一週間くらいでなんとかなりますか」
私「なんとかしてみます」
作品そのものと、作家プロフィールと、付属資料のコピーを取らせてもらって、彼には外で缶コーヒーを奢った。ビルの入り口まで送ったところまではいい気分だったが、正直、身に余る事態だった。
持ち込み作家の才能がありすぎるのも考えものだ。嬉しい悲鳴というやつ。誰が担当に付くかで今後の雑誌の売り上げに影響がある。重大な意思決定ということになる。
最悪、『進撃の巨人』の時みたいに優れた作家を逃してしまう可能性がある。あれも、実際は諌山先生は門前払いではなく、週刊少年ジャンプの担当が付くか付かないかの微妙なラインだったらしい。それで、誰が担当になるかを押し付けあっている間に諌山先生が他雑誌に持ち込んでしまった、という話が業界団体の公的な飲み会で囁かれていた。
B先生についてだが、一週間後に担当編集が決まった。「別の編集者」でもなく私でもない。当時、若手のひとりだった20代の子が任されることになった。編集部のトップを交えてB先生の原稿のコピーを読んだのだが、「若い感性が光る。年齢が同じくらいの人と組ませる方がいいのでは？」という結論になった。
その20代の子は、上の組織からこっちに出向してきている子で、いわば武者修行の身だった。一流大学出で、本社のプロパー社員。いわゆる総合職である。
最初は、私に選択権があった。B先生の担当になる道もあった。だが当時の私は多忙であり、月に何度も会社に寝泊まりするレベルだった。新人は抱えるべきではない。しかし、才能のある子だから迷いがある。
A先生のこともあった。彼のあの作品を世に出してやりたい。もっと有名にしてあげたい。そんな想いがあった。
私が悩んでいるうちに、例の20代の子が手を挙げたのだ。私としても、彼のやる気と知性と直向きさは買っている。諸手を上げて賛成した。
今思えば、正しい選択だった。もし私がB先生の担当になっていたら、面白い恋愛エンタメを楽しめる読者の数は減っていただろう。これでよかったのだ。
以後のB先生は、例の持込漫画のブラッシュアップを続けた。翌年には、晴れて弊誌に第一話が掲載されることになった。さらに以後は、担当編集とともに二人三脚で躍進を続け、イケイケドンドンの勢いを保ったまま、一度も息切れすることなくスターダムに上り詰めた。今では漫画家として世に知られている。
上で挙げたA先生の意欲作は、読者層に合っていなかった。それでも、高い画力とシナリオ構成の上手さがあったのだろう。その意欲作は、連載期間を積み重ねる度にファンの数が増えていった（業界的には、Amazonの第一巻のレビュー数が人気の代替変数になることが知られている）。
今では、A先生は親雑誌で連載を勝ち取るまでになった。去年だったか。彼の作品をコンビニで立ち読みする機会があったのだが、やはり突き抜けた画力だった。週刊連載であそこまでの画力というのはまずない。
2024年現在、私は東京を離れて田舎で暮らしている。地元の町役場にUターン就職して、実家の農業を手伝いながらスローライフに近い生活を送っている。
実は、編集者だった当時、働きすぎて病気になった。ある日、下腹部の辺りに違和感を覚えて、血の塊のようなものが血管を這っている感覚があった。病院に行くと、「遅くても明日中に入院しなさい」という医者からの指導があった。
それなりに重い病気にかかってしまった。一応は死亡リスクもある。数か月ほど入院した後、どうしようかと考えて、考えて、考えて……編集部に復帰後は、労働を最小限にしつつ転職活動をスタートした。
A先生については、幸いだった。彼の意欲作とは最終回まで付き合うことができた。私が退院した後、無事完結を迎えることができた。あしたのジョーに比べればハッピーエンドだった。
入院中に、A先生とB先生がお見舞いに来てくれたのを覚えている。ほかの編集仲間も来てくれた。A先生は、テンションが低めで、何を考えているのかわからないこともあるのだが、人間への基本的な愛というか、思いやりがある人だった。
もう40才を過ぎている。はてなユーザーの中では平均的な年齢か。思えば齢を重ねたものだが、当時の日々は今でも夢の中に出てくる。
若い頃から編集者をやってきた。身体を壊さなければ続けていたのかというと、多分そうだろう。でも、今の生活も悪くないと感じている。自分語りはここまでにして、締めにしよう。
もしあなたが、Webでも紙媒体でもいい。気になる漫画作品を見つけたとする。面白いものを見つけたと感じたら、ひとまず買ってみるのがいい。Webだと１話単位で売っている。
ひとかどの漫画家というのは、自らが産み出すモノを本気で高めにいっている。あなたのフィーリングが合ったのなら、ひとまず１巻だけでも読んでみる方がQOLが高まると思う。ハズレを引くことはあるだろうが、アタリだってちゃんとある。人生は運試しである。
pythonコードの速度のボトルネックを見つけるにはline_profilerが使える。
だが一部の開発者は「速度に凝り過ぎるとコードが読みづらい」という。
これには異論がある。
大幅に速度を改善するようなコードの改善は、むしろコードをシンプルに保つ上でも重要な働きがある。
傾向としては、マルチプロセッシングなどを使わずに速度を改善した場合は、プログラムの長さは減少する。
速度を改善すれば、特定の出力をするコードの最小長(コルモゴロフ複雑性)に近づく。
速度改善によってわかりにくくなるという人は、数学ができないのかもしれない。
物理学では、変数を単一の文字で表すことが多いが、こういうのに慣れていると「シンプル」の概念に差が開く。
こういった科学的な「シンプルさ」を理解できない人に対して、意味を説明する形で変数名を決めても、結局コードは理解できないだろう。
確かに、ビジネスドメインに近いコードであれば変数名をドメイン語に合わせるのがわかりやすい。
しかし「ボトルネックを改善しなければシステムが要件通りの速度にならない」ようなケースでは、数学的なコードの方がわかりやすくなるのである。
1. **条件式の曖昧さ**：JavaScriptでは、`if (value)` は `value` が「truthy」（真と評価される値）である場合にのみ実行されます。しかし、このコードは明確ではありません。`value` が何を意味するのか、どのような値が期待されるのかがコードからは読み取れません。`null` でも `undefined` でもないことを確認するには、より明確な条件式（例：`value !== null && value !== undefined`）を使用する方が良いでしょう。
2. **ログメッセージの不明瞭さ**：ログメッセージ `'null でも undefined でもねーわ'` は、`value` が `null` または `undefined` でないことを示しているようですが、これはコードの実際の動作と一致していません。`value` が 0、空文字列（`''`）、または `false` の場合でも、この条件は偽（false）と評価されますが、これらは `null` または `undefined` ではありません。
3. **コードの可読性**：コメントやより記述的な変数名を使用することで、コードの意図や動作を明確にすることができます。現在の状態では、このコードの意図を理解するのが難しいかもしれません。
JavaScript でさあ
変数 value が null でも undefined でもない事を確認するのに
if (value) { console.log('null でも undefined でもねーわ'); }
これほんとやめろって。
おかげで value に 0 とかが入ってる時に、このコンディションが false になるわけだ。
色んな会社さんのコード見てきたけど、このタイプのバグ本当に多い。
昨年は、世界的にも有名な会社さんのフレームワークがこれでバグってた。
でももう既にシステムの一部は本番稼働しててフレームワークはいじれない。
仕方ないので value には一旦文字列の '0' を渡しておいて if (value) {～} の中の重要なロジックを動かして
(めっちゃ幸運な事に、数値 0 のかわりに文字列 '0' でも正しく動くような、型について緩いロジックだったから)
その後で改めて value に数値 0 を入れなおすという、きったないハックで誤魔化した事もある。
自分がお客様だったら怒るね。「いやいや、全部理想的なコードにしてちょうだいよ。お金払ってんだよ？」って。
ITエンジニア達がこぞってクソコードの話をしている。他人様が書いたコードにいちゃもんをつけて悦に入ってるのだ。
書いてあるコードの変数名にいちゃもんを付けたり設計にいちゃもんを付けたりするのが奴らの生業だ。
Xでは今その話題で持ちきりである。クソコードだと揶揄するのは構わないが、ところでお前らはちゃんと風呂に入っているのか？
他人様にいちゃもんを付けているのにまさか、風呂に入ってない奴なんていないよな？
リモートワークだからと胡座をかいて、稀にある出社日に洗ってない犬のような匂いとカビ臭い服の匂いをオフィス中にプンプン漂わせてないよな？
くせぇんだよ。せめて風呂入って洗濯した服を着て出社してくれ。
コードの重複があるわけでもない状況で、コードを関数ごとに分離するメリットデメリットを知りたいという話ですよね。
コードの重複がある場合に関数などに切り分けていないと、同じコードを何度も書くことになり、不具合があった時にコピーされたすべての個所に変更が必要となるというデメリットがあるので理由がわかりやすいですが、重複が無いとその点が不明確ですね。
画面に収まらないサイズのコードは複数の関数に分割するのが一般的だとは思います。
理由は元増田も書かれている通り、長いと理解の限度を超えるからです。
コードは意味があるまとまりで短ければ短いほど理解がしやすいと思います。
グローバル変数を使わないようにすると、入力・出力が関数を読むだけで明確にわかるので、さらに理解がしやすいです。
また、関数に分けておけば、関数が仕様通りに動くかの確認するユニットテストも簡単に書けます。
ユニットテストでは関数がさらにほかの関数を呼び出している場合、呼び出される関数の代わりにテストダブルを用意することもあります。
分割して、複数の関数を呼び出すようにすることのデメリットは、
下手糞が切り分けるとなんでそういう切り分けになったかわからないところで切り分けられてかえって可読性が損なわれるとか、
関数の機能が拡張してより多く・あるいは少なくの情報が必要な時に関数インタフェースの変更が必要になることとか、
関数を置いているファイル内の場所を変えたときにバージョン管理システムが追っかけてくれないことがあるとか
くらいでしょうか。
いずれにせよ、分割するメリットの方がデメリットを上回ることが大半なので、大抵は機能ごとに分割して小さい関数を作り、それをメインからは呼ぶようにすると思います。
まず、関数の名前をやっている工程を表すものにすることですね。
「データの取り込み」 とか 「データの突合せ」とかを明示すると、それを呼んでいるということはそういうことをしてくれると思うので。
また、関数が何をしてくれるのかも関数のコメントとしてつけておくとよいと思います。
例えば、
filename引数で指定されたファイルからデータを取り込み、JSONフォーマットで返す
返値: JSONフォーマットされた取り込まれたデータ。例: [{'employee name': '山田 太郎', 'employee id': 1}]
例外: filenameを開けない場合はFileOpenError、JSONにコンバートできなかった場合はConvertError
みたいなコメントをつけておくと何をする関数なのかわかるので、その機能を調べたいとき以外は読まないでいいかなと。
あと、コードを連続で読みたい場合、ソースを解析してタグジャンプをつけてくれるツールやらIDEやらを使うことが普通だと思います。
これはどういう意味でしょうか？同じものを表すのに関数ごとに別の変数名を付けているとか？
もしそうだとしたら、使っているプログラミング言語の制約やプログラミング規約によるものなのでしょうか？
ある関数のローカル変数が他の関数のローカル変数に影響を与えることは無いはずなので、ローカル変数は大抵適当な名前が付けられるイメージです。
今時のプログラミング言語なら変数のスコープが関数の中にとどまるような書き方ができると思うのですが。
関数インタフェースを定義し、そこにいちいち引数を書くのが面倒というなら...まあ、それは必要税って感じがします。
そこに引数を書いておくことでこの関数が何に影響されるのかわかるので。
参考までに。
