Jun Mukai

Jun Mukai:リクエストされたのでお答えしますが、そんなのどっちでもいいですよ。 もちろん、あなたのキャリアの方向性は変わることがあります。なんでもやる方が色んな経験を積んで技術も経験も積めるかもしれないけれど、一つの専門的な方向性を定めた方が自身の専門性の蓄積につながることもあります。でもそれのどっちがいいとか悪いとかは、ありません。どちらの場合でも結果的にいいキャリアにつながることもあればうまくいかないこともあります。今後のトレンドがどちらに転ぶかも事前に予測はつきません。 というわけなのでどちらがいいかなどで考えるのはやめた方がいいと思います。好きな方を選べば良いです。どちらか一方の方が性格的に向いている、という人はいるので、その場合は向いている方を選んだ方がいいですね。なのでご自分の性格がどうなのか次第ではないかと思います。 ついでに2点ほど補足させていただきたいと思います。 第一に、根本的にはそんな選択には大した意味はないんじゃないかと思っています。一年目に何をどうしようが、そこからの自分のキャリアの方向性がどうなろうが、途中でやっぱ違ったなと思えば方針転換すればいいんです。職業人生というのは何十年も続くものです。最初の選択は大事ということをいう人もいますが、そんなことに捉われる必要は全くありません。肩の力を抜いて、そんな程度のことはどっちでもいいしいつでも方向転換すればいい、というつもりでいてください。結果として選択を間違えることはありますが、間違えても別にいいんです。みんな間違えているし、私も右往左往しているし、みんなそうやって生きています。変に思い込んでこれしかないとか、選んだからにはこうするしかない、といって柔軟性を欠いてしまうのが一番危ないように思います。 第二に、あなたに選択肢があるかどうかはまた別の話です。会社やチームの現状、必要とされる仕事、あなたにやってもらおうと思っていたプロジェクトの方向性、そういったもので仕事の内容というものは決まったりするものです。なんでもやるか一つのことに集中するか、なんてことにあなたへの選択肢はなかったりします。実際に入社してみたところ仕事内容が思ってたのと違うこともあります。基本的には事前に想像でこういう決断をするのではなく、与えられた状況を確認し、その地点からできることに取り組んでいき、少しずつ前に進んでいくことをお勧めします。 もちろん向き不向きはあるので、割り振られた仕事が全く向いていなかったとか、自分のキャリアパスと違っていた、というときには何かをすることもあるかもしれません。上司などと相談して担当を変えてもらったり、あるいは異動をしたり、極論としては転職であったりもありえるかもしれません。いずれにせよ与えられた状況次第なので、そのときになってから色々考える、というので全然問題ないんじゃないかと思っています。

Jun Mukai:そうなんですか？　私自身はNLPの研究者ではないのですが、そういう視点ばかりではないですよね。たとえば、 https://www.reddit.com/r/MachineLearning/s/odmh97kkOC とか https://newsletter.ruder.io/p/nlp-research-in-the-era-of-llms のような内容を読んでみると、全く逆の視点の研究者が多いように思います。 もちろん人それぞれなので言い分もまた人それぞれではあるでしょう。どちらが多いかもわかりません。LLMの登場はNLPの分野においてものすごいブレイクスルーであるのは間違いありません。実際、ここから新しい可能性が広がっているという見方もできる一方で、これまでやられていた研究内容の中には全くやる意味がなくなってしまうようなものがあることは容易に想像されます。 人によってはこれまでとは全く異なるアプローチが要求される可能性もありますし、研究の方向性を見直す必要があるかもしれませんし、やろうと思っていた研究について今後の可能性が全く感じられなくなることもあるかもしれません。それは辛いことです。悲観論はそういうところから生まれるだろうと思います。 NLP分野にはこういう強烈なパラダイムシフトは何度か起こってきました。たとえば直近ですと、これまでの常識とは全く異なる機械学習ベースの機械翻訳が現実的になり、過去の機械翻訳の品質を遥かに超えてしまったということがありました。それでも研究分野自体は残っていますし、新しいパラダイムが切り拓いた方向に研究は進んでいくと思います。 LLMでも同様に、研究分野全体としては終わったとはいえないとは思います。でも今いるNLPの研究者全員にバラ色の未来がある分野というわけではないでしょう。

Jun Mukai:ある文脈においては一理あると思います。たださすがに誇大的な表現と思いますし、それはそれとしてソフトウェア技術の専門家は必要だろうと思います。 最近よくgithub copilotを使ってコーディング作業を補助してもらっています。copilotはかなり賢いですし、現状でもboilerplateのようなコードをさっと書くのには本当に向いています。すごく便利です。ただ現状ではそこまで賢いものではないので全く見当違いなコードを生成することも多いですし、なかなかいい線を行っていても細かい部分が間違っているというようなことばかりです。そのままでOKなことは自分の経験では皆無です。でも叩き台としては非常に便利で、それを元に細かい部分をちょこちょこ直したりとかで済むのであればコーディング自体の時間の短縮にはつながります。 現段階での技術はまだまだですが、これから数年経ってこの技術がさらに発展したり、現行のLLMたちの生成するコードの精度が上がって行ったりすると、ちょっとしたコードを書くのはもうそれでいい、みたいな状態になることは容易に想像されます。 それでいて同時に、自分のソフトウェア技術者としての仕事のコードをどこまで任せられるのか、あるいはソフトウェア技術者としての仕事をどこまで移譲できるか、と考えると、それは全然無理だなと思うことも多いです。 こうした近年のAI技術によって生成されるプログラムというものはそれ単体で完成するようなものが多いです。一方実際の仕事だともう少し違うことが求められることも多いでしょう。巨大なコードベースの中のどこに変更をするのが良いのか、全体的な設計や統一性などからどのような変更をすることが求められるのか、新しいコードが既存コードと同じような構造を持っているとき、何らかの抽象化を導入することが良いのかどうか、設計を見直す必要はあるのか、などなど……。実際の職業プログラマのコーディングというのは、そういう様々な制約条件を考慮した上で行うものでしょう。 そうした検討を人間の専門家が行った後で、実際のプログラムという文字列を人間が書くかAIに生成してもらうかでいうと、AIに生成してもらったほうが早くなるということはありうると思います。でもそうであってもソフトウェア開発において人間の専門家が必要になる、そういう状況はこれからも（それなりの期間は）続くだろうと思います。 ところが一方で、職業プログラマであってもなくても、ちょっとしたコードを書くとすぐ処理できるようなちょっとした手続き、というものは世の中に色々あるわけです。例えばCSVでダウンロードしてきたデータの特定の列の合計を見たいとか、単純な集計をしたいとか。「退屈なことはPythonにやらせよう」という素敵なタイトルの書籍がありますが、これはまさにそれです。そういうことはどんな職業でも一定数あり、プログラミングができると生産性が上がります。 こういった文脈からプログラミングというのは現代において極めて基礎的なリテラシーであり、どんな職業になるのであれプログラミングは学ぶべきである、というようなことは10年くらい前から盛んに言われてきました。 でももし、chatGPTなり何なりといったLLMがまともなコードを生成できるとしたら、そういう必要性はかなり下がってしまうかもしれません。こういう「ちょっとしたコード」は最初に述べた職業プログラマの仕事のコーディングとはかなり異なります。だいたい一回だけしか動かさないですし、その場で、今目の前にあるデータに対してだけ動けばそれでいいのです。セキュリティの問題とか、異常データへの対処とか、メモリリークがどうこうとか、そういう話はありません。ぱっと書いて動かして結果を見て終わりです。ほんとそれだけです。 そういうようなプログラムをAIが書いてくれるというなら、職業プログラマではないような人は本当にプログラミングを学ぶべきなんだろうか？　それはAIにやらせればよく、その人が本当に注力すべきこと、本職の専門性の方を磨くべきなんじゃないだろうか？ Jensen氏がそのような文脈においてこういう発言をしたのかはわかりませんが、自分としては、そういう文脈であれば納得はいく、と思いました。 ただそれでも生成してもらったプログラムコードを見て、その内容を理解し、意図した通りのことをやっていそうか、という程度のことはわからないと困るんじゃないだろうか、微妙なところをちょっとだけ手直ししたりといったことも依然として必要になるんじゃないだろうか、そんなふうに考えています。 それに、コンピュータにやらせたりプログラムを書かせたりするためには、その課題はプログラムにやらせればいい類のことだということを理解していないといけません。電卓の方が圧倒的に速く計算できるとしても人間は一応四則演算は手でこなせるぐらいには学習をしておいた方がいいだろうなと思うわけで、何らかの基礎的な知識、考え方、といっても何が必要なのかは自分にもわかりませんが、そういう基礎的な何かはやっぱり必要なんじゃないかなあ。 そういうわけで、仮に当てはまる文脈において正しそうだとしても、結論はやや誇大的なんじゃないか、とも思うのです。

Jun Mukai:関連する書籍として思い当たるものはないでもないのですが、それらも質問内容で問われていることに直接答えるものではないと思います。というかそういう情報そのものが書かれた書籍ってないか、あってもかなり珍しいのではないかという気がします。これまでほかの回答がつかないということもそのことを間接的に裏付けているように思います。 コードの綺麗さというのは、ファイルをどのように分割するかとか、クラスのなかにどれくらいインスタンス変数を入れるかとか、そういうことでは決まりづらいのですね。たしかに一つのファイルをなんでもかんでもごっちゃに入れてしまっては分かりづらいですし、一つのクラスに大量のインスタンス変数やメソッドがあったり、一つのメソッドに無数の引数があるのはあまりに分かりづらいですし、良いコードや綺麗なコードとは言えません。でも、何個ぐらいという適当な指標はあってなきがごとしです。たとえばクラスのインスタンス変数は必要なものだけであるべきですが、たくさんあったとしてもその全ては必要なものである（どこかで使われている）ものでしょう。なければ消せばいいわけなので。 結局、インスタンス変数の数とか引数の数とかファイルの中の関数やクラスの数、というのは、どのようにクラスなり関数なりを設計するか、ということによって決まる従属的なパラメータなのです。こういうものを制御するにはクラスの構造を作り変えたり、メソッドの呼び出し方を考え直して作り変えたり、意味的に関連するものを見出してそれだけくくり直したり、そういうことをする必要があるのです。良いコードは良い設計の下にあり、つまりは良い設計を導入する必要があります。いまここにあるコードをどうにかする場合、そのコードをときほぐして複雑さを解決するための適切な抽象化を行わなければなりません。また、クラスを再設計し、呼び出し方を変えたりすることになります。 ではどういう設計がよいのか、どう直せばいいのか？　こういうもののための書籍というものはあるといえばありますが、しかし書籍がどこまで参考になるかはむずかしいところです。学生として経験が浅いとイマイチピンとこないことも多いですし、書籍で書かれているのはわりと一般論であり、それを目の前の状況にどう当てはめていくかというのはそれほど簡単なことではないからです。たとえばRui Ueyamaさんは次のエッセイで、いかに一般的には良いとされる設計がうまくいかなかったかという話を描いています。これはかなり極端な事例ですが、ここまででなくても何事もバランスでありトレードオフなので、一般論をただ当てはめればそれで済むようなものではありません。 https://note.com/ruiu/n/n9948f0cc3ed3 さらにもう一つ、プロジェクトの性質によっても物事の良さというものは変化します。現代のソフトウェア開発において一般的なのはそれなりの期間でそれなりの人数が参加する継続的な開発ですが、世の中のソフトウェアプロジェクトというのはそれだけじゃありません。学生の研究という場合、おおくの場合にはコードに関わるのは少人数（極端な場合は自分一人だけ）だし、概念実証できればプロジェクトの継続性もそこまで必要なかったりもするでしょう。ですが逆に、様々にパラメータを変えたり柔軟な条件でいろいろな部分を変えられるような構造であるほうが良かったりするかもしれません。こういうことは設計方針に影響します。たとえば実行時の条件や設定はむしろ一箇所に集めたほうがよくてそこは少しごちゃごちゃしているけどそのほうがよかったりしますし、決め打ちにしたほうが設計的にはすっきりする場面でもなんらかの抽象化レイヤーを設けたほうがいい（そこを変えて実験するかもしれないから）みたいなこともあるでしょう。こういうことを伝えてくれる書籍というのは、あるとしてもかなり限られたものになるでしょう。 さて、話がずいぶんともとの話題からそれてきてしまいました。短くまとめるなら、クリーンなコードというものは良い設計から導かれるもので、設計の良さというのは問題領域によって変わるので、あなたのコードに直接助けてくれるものはない、ということになります。 もちろんなにかを学ばずに一人で考えてもなかなかうまくいかないでしょうが、書籍よりはほかの人の書いたコードからのほうが得られるものが多いだろうと思います。自身の研究に関連するコード（利用しているフレームワークや、関連研究のなかでコードが公開されているもの）を読むことによって、どのように問題領域を表現しているかを読んでいくことで学んでいくのが良いのではないかと思います。そして、そこででてきたキーワードで検索したりして情報を集めたり関連する書籍を読んだり……ということの積み重ねのほうが、まずいきなり書籍を読むよりも意義があるのではないか、などと思ったりします。

Jun Mukai:リクエストを頂いたのですが環境が違いすぎるので参考にはならなさそうです。 自分はVScodeを使っていて、LSPなどはVScodeで管理されています。開発環境にはコンテナなどは使わずそのままなので、質問にあるような問題は起こりません。 ただ、開発環境をコンテナ化するといってもそこまで問題化するようなことはあるのでしょうか？　それは開発環境の側の問題ではないでしょうか？　というような気もするのですが。 開発環境をコンテナ化するような環境で使われるようなモダンなプログラミング言語の処理系においては、依存関係みたいなものはローカルな環境に揃えることが多いように思います。顕著なのはnode.jsで、node_modulesにすべてを取り揃えています。私がよく使っているのはGoですが、go.modやgo.sumファイルに依存関係は記述され、パッケージはGOPATH内にダウンロードする必要がありますが、そのための処理はほぼコマンド一発でさほど手間ということはありません。Rubyも詳しくないけどbundlerなどの仕組みがあり同様という理解です。 こういう環境においても、もちろん開発環境と別にホスト環境に言語処理系をインストールしないといけませんが、そこの手間はほとんど大したことないという風に感じます。一度やってしまえばそれで済みます（言語処理系のバージョンが変わったときという問題もありますが、それ自体がかなりレアな事象ですし、そこで問題が起きるようなシチュエーションはさらにレアでしょう）。一度やってしまえばあとはほとんど何もしなくて良い程度のことでしょう。 モダンなプログラミング言語のなかでも特殊なのはPythonかもしれません。Pythonは（環境にもよるが）システム環境に依存関係を入れるのが一般的かもしれません。もっとも、ホスト環境に言語処理系を入れて、必要ならばvenvなどのセットアップを済ませておけば、Go言語などとそれほど違いなく手間のない環境はできそうな気もします。依存関係の再インストールは必要ですが、ほとんどコマンド一発で済むことですし、手間なら適当にスクリプトを書けばそれで済みますし。 というわけで、ふわっとした回答ですいませんが、自分としてはそこまで困る状況というのがあまり想像できないなという風に思っています。もちろん環境に応じていろいろあるのは当然ですが、この質問内容だけからでは答えづらいように思います。 もう少し具体的な情報があれば答えは変わるかもしれませんが……ただそれよりは社内で質問したほうがいいんじゃないでしょうか？　開発環境をコンテナ化するのはそれなりに人数のいる会社でしょうから、みんなこの環境でどうしているか質問したら答えてくれるんじゃないでしょうか。少なくともコンテナ化した人がそういうワークフローをどう想定していたかの答えは得られるかもしれません。もしほかの開発者の多い環境（たとえばVScodeなど）で問題が起きていないなら、どのような違いがあるかを調査することで解決策が見えたりもするのではないかと思います。

Jun Mukai:再帰呼び出しは計算機上はスタックと呼び出しにより実現されます。またチューリング機械には再帰がありません。ゆえに、非再帰版が書けないということは理論的にはありえません。 しかしたとえばアッカーマン関数などは再帰で書かないとまあまあ面倒になるでしょう。 https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%83%E3%82%AB%E3%83%BC%E3%83%9E%E3%83%B3%E9%96%A2%E6%95%B0 また竹内関数は（実際の値を求めたいとき以外には）再帰で書かないと行数はかなり増えるかもしれませんね。 https://ja.wikipedia.org/wiki/%E7%AB%B9%E5%86%85%E9%96%A2%E6%95%B0 質問内容に対するそのものの回答としては以上のようなところになると思います。 ただ、再帰は必要にせまられて行うのではなく、その処理を自然に表現するために使われるという山口さんの回答には強く同意するところです。再帰が必要かどうかということを考えるのは不毛かなあと私も思います。

Jun Mukai:そのようなタイプの推理小説はホワイダニット（whydunit）といわれます。 一見不可能な犯罪がどのようにして行われたかを解き明かすのがハウダニット（howdunit）、誰が犯人か解き明かすのがフーダニット（whodunit）で、それらとともに有力なサブジャンルといっていいと思います。 また赤毛連盟などを念頭に置くと、今で言う「日常の謎」のような作品群も質問の趣旨に近いかもしれません。日常の謎というのは、殺人事件などはおこらず、日常の些細な事柄について、なぜそのようなことが起きたかを論理で解き明かすといったタイプの小説です。 こうしたキーワードで検索すれば作品や作家はいくらでも出てくると思いますよ。

Jun Mukai:Haskell言語のコミュニティではカンマやセミコロンを行頭に配置するのはかなり一般的ですので、あなたの感性には合うと思いますが、たしかにそこまで広く共有される感覚ではありませんね。 ただ、おっしゃる論拠についてはわかりづらく、論理展開にかなり飛躍が見られるように思います。残念ながら、行頭に置くべきだというあなたの主張の根拠がわかりません。 第一に、カンマなどは二項演算子である、という点にまず議論の余地があります。そもそもカンマが区切りの記号なのかどうかがはっきりしません。たとえばセミコロンは文の区切り記号なのか、それとも文の末尾を指示する記号なのか、という議論があります。Pascalなどにおいては、ルーチン（手続き）の末尾はピリオドであり、セミコロンはそれ以外の文の区切りに用いるので区切り記号ですが、C言語においてはセミコロンは必ず文の末尾に配置しないといけないとめ、区切り記号とは考えられません。このようにプログラミング言語によって記号の意味や扱いは異なります。カンマにおいても、配列などでは末尾にカンマがあっても無視しエラーとしないという仕様はかなり一般的になってきており、カンマを単純な区切り記号であるとみなすのは困難であることが多いでしょう。 そして区切り記号であったとしても、はたしてそれを二項演算子と単純にみなしてよいかどうかはわかりません。これは感覚的なものであり、プログラミング言語の仕様や意味論とははなれて二項演算子として解釈できるという人がいることは確かですし理解できますが、それは全員が異論の余地なく同意できるものではないでしょう。たとえば二項演算子というのはそのプログラミング言語において定義されており、カンマはその定義には合致しないのであるから二項演算子とは言えない、という人がいても全くおかしくないし、そういう異論も正当な立場であると私は思います。 というわけで、「コンマなどの区切り記号は二項演算子なのであり」というが、まず区切り記号であるかどうかははっきりしないし、二項演算子であるというのは全員が同意するものではありません。 演算子は1つの手続きである、といいますが、普通は「手続き」ではないと思います。ただ、関数、処理、といった意味あいで用いているのかもしれません。その意味ではその通りだと思います。しかし、だとするとカンマなどの区切り記号はどのような演算を行うものであると考えられるのか、という点がまたむずかしいのではないかと思います。Haskellにおいては明確であり、カンマはタプル（など）のコンストラクタとして解釈できえますし、セミコロンも文同士を結合する演算子とみなせるでしょう。ですがほとんどのプログラミング言語においてはどのような演算であると定義すればよいか、プログラミング言語の意味論内でどのように位置づけるべきかははっきりしません（それゆえに二項演算子ではない、という考え方もあり、つまり一つ前の話と関連しています）。 さて、以上を認めたとして、では二項演算子や手続き（関数）は行頭に配置するのが一般的な慣習である、という点はわかりませんでした。一般的な慣習ではないと思います。 関数fに引数を与える際、f(x, y)のように関数を最初に書くというのは非常に一般的な表記法です。ですが二項演算子においてはxRyのように間に配置するのが一般的です。長い行を折り返すときも、二項演算子を行頭に置くのが一般的であるというのは思い当たりません。行末に置くこともかなり一般的ではないでしょうか。たとえば x + y + z + ... のような長い加算のとき、+はいつも行頭でしょうか？　そんな慣習はないと思います。 というわけで、二項演算子は手続きであるから行頭に置くのが一般的な慣習である、というのは全く理解できません。おそらくなにかしらの論理の飛躍があり、残念ながら相手には全く伝わらない主張になっていると思います。 ところで冒頭でも述べたようにHaskellではカンマやセミコロンを行頭に持ってくるスタイルはかなり一般的です。ただその理由は読みやすさとか美的感覚とか、レイアウトルールとの類似性などが主な理由であったように思います。多少の検索をしたところ正式な回答は見当たりませんでしたが、そのような論拠は多く見られました。たとえば、 https://stackoverflow.com/questions/10483635/why-do-lots-of-programmers-move-commas-to-the-next-line とか、 https://www.reddit.com/r/haskell/s/6gwhhz7qT0 などにはそのようなことが述べられています。 類似するものとして、たとえばJavascriptではメソッドチェーンする際のドット記号を行頭にもってくるスタイルがわりとよくある気がします。しかし演算子がどうこう、という理由付けは私は聞いたことがありません。 なお、英語（を含む欧州系の自然言語）の一般的な表記スタイルにおいては、カンマやセミコロンなどの句読点系の記号は直前の単語につけて直後に空白をあけて書きます。行頭に来ることはありません。なぜカンマやセミコロンが行頭に来ない表記スタイルが一般的なのか、という質問に対する明快な回答はむずかしいと思いますが、そういう自然言語の表記スタイルに由来するところが大きいのではないでしょうか。

Jun Mukai:「教育システム」について考えるなら日本企業ということになるんじゃないでしょうか。すべてを知っているわけではないですが、米国企業には「教育システム」はほとんどなかったりしますし、こうしたシステムの手厚さでいうと日本の大企業はかなりしっかりしている印象があります。 しかし、技術者として成長するということを考えたときに「教育システム」にだけ着目するのは非常に近視眼的であるように思います。仕事の内容などを含め、総合的に成長できる環境にあるのはどこか、という点で考えるなら答えは変わる可能性があります。 もちろん技術分野により、製造業や加工などの技術力では日本は優れており、自動車産業では世界トップクラスですから、機械エンジニアとしての成長では日本の自動車会社は素晴らしい選択肢ではないかと思います（私はこの分野では素人なので間違っている可能性もありますが）。 一方で私の専門性にちかいIT分野においてはアメリカは大きな存在感があり、大きく成長できる機会を得やすいのはアメリカの企業であると言ってもいいかもしれもせん。

Jun Mukai:三角比は負の値を取りません。三角比を拡張し一般化した三角関数は負の値を取りえますが、もはや三角形の辺の比という意味ではないので、対応する三角形や比というものは存在しません。 三角比というのは直角三角形の辺の比をいうものでした。斜辺と縦の辺の比がsin（サイン）、斜辺と横の辺の比がcos（コサイン）、横の辺と縦の辺の比がtan（タンジェント）という名前になっています。これらの値は三角形の角度が同じならどんな直角三角形でも同じ値になります。 この定義では三角比というのは直角三角形に対するものなので、角度は0度から直角までの値しか取りません。それ以外には定義できません。直角三角形になりませんからね。そして辺の長さの比ですから負の値にはなりません。 ところが、この三角比を一般化してどのような角度でもとりうるように拡張することができ、そうすることで数学的に興味深い特徴が見られるようになります。こうした拡張を三角関数といいます。三角関数においては負の値を取ることがあります。三角関数のことも含めて三角比と呼ぶこともありますが、一般的ではないと思います。 さて、どのように拡張するのでしょうか。まずxy平面の原点に半径1の円を配置します。そして原点からx軸の正の方向に線を引き、その方向を0度とし、反時計回りに少し回転させます。回転角度をα度（0°<α<90°）として、その線と円の交わる点をAとします。またAからx軸に垂線をおろし、その点をBとしましょう。原点OとこのABから直角三角形が構成されます。この直角三角形の三角比はどうなるかというと、斜辺は円の半径なので1ですから、sinは辺ABの長さ、cosは辺OBの長さとなります（tanはAB/OBですね）。これはよく考えてみると、点Aのxy座標系の位置yとxにほかなりません。そこで、直角三角形と三角比から離れて、任意の角度で半径1の円のy座標をsin、x座標をcosとして定義することにし、これを三角関数と呼びます。 三角関数においては座標の値なので負の値を取ることはあります。sinでは、y座標が負なので、180°から360°までの値は負であり、360°で一周してもとに戻るので360n°（nは任意の整数）を加えたものも負の値を取ります。またcosでは90°から270°までの範囲が負になります。tanではcosとsinの正負が異なる範囲、つまり90°から180°と270°から360°が負です。 このように、三角関数は当初の三角比から出発して拡張それますが、定義としては全く異なるものであり、座標の値という意味になり、直角三角形の辺の比という意味はありません。どんな直角三角形なのか、どういう比なのかという問いについては、そもそも比ではないという答えにしかなりません。そして直角三角形の辺の比である三角比は負の値にはなりません。

Jun Mukai:バージョン管理システムでdesign documentなどを管理するスタイルは、最近ではよく見られています。ただここにもいくらかのスタイルがあり、以下では同じレポジトリなど、ソースコードの近傍にそういうファイルを配置するスタイルについて考えます。 この利点は、 * ソースコードのごく近傍にあり見つけやすい。散逸しない * 設計上の変化に応じて変更される（ことが期待される） * 内容の変化をソースコードと同じ仕組みでレビューでき、変化をgitなどのツールで追跡できる といったところにあると思います。限界点や課題としては、強いて言うなら * Markdown などのフォーマットで書くので体験がかならずしも良いわけではない。たとえば、画像などの埋込みが面倒 * 横断的にすべてのdesigndocを集めたりができない（しづらい）。検索などもしづらい * 実際には、design documentが古いままで更新されないこともよくあったりする といったところではないでしょうか。ただ2番目の点については、なんらかの専用ツールによって改善されたりするでしょう。

Jun Mukai:自分にとってなにが最適かなんて一生かけてもわかりゃしないので、考えるだけ無駄だな、と私は思っています。自分の専門性とかそういうものは、それまで進んできた道筋を振り返って名付けるものでしかなく、なんでもいいからとにかく一歩一歩進んでいくしかない、とも考えています。また時として途中で道を変えることもそれほどおかしなことでもありません。 私自身についていえば、ソフトウェアエンジニアとしての最初の仕事は検索チームでした。とくに検索ランキングを調整したり、当時の携帯電話（今で言うガラケー）のための検索機能を改善するチームにいました。それから日本語入力のチームにうつってIMEをつくり、とくにMac版の開発に携わり、MacOSにおけるIME APIに詳しくなりました。またMacOS上でのIPCをどう構築するかも考えてMachカーネルのIPCについての知識も深めました。それからChromeOSチームに入り、グラフィックス、UIシステム、ウィンドウマネージャなどを扱いました。またクラウドチームに入り、gRPCやAPI、サービスメッシュなどに関わりました。今ではスタートアップで様々なクラウドシステムやとくにKubernetesについてのスキルを持っています。自分としては今の専門性についてはバックエンドよりかなと思いますが、様々な分野を横断してきたし、そのことが自分の強みでもあるのだろうなと思っています。 これはちょっと極端すぎるかもしれませんし、ここまで頻繁に分野を替えるのもキャリア上はよろしくないかもしれません。でも頻度はさておきそういうことはたくさんあるし、あるのが当然なのではないか、と思っています。 たとえば先日退職ブログが少し話題になったIan Hickson氏。これ読んで私がかなり驚いたのは、Chromeの時期よりもFlutterやっていた時間のほうがもう長いくらいだったということなのでした。 https://ln.hixie.ch/?start=1700627373&count=1 Ian HicksonといえばHTML5の人、というのが私の認識でした。この人はWHATWGというHTMLの仕様をきめるワーキンググループにいて、数多くの仕様を策定し、書いてきた人で、今のHTML living standardを作った人と言っても過言ではないくらいの人です。ところが9年くらい前にChromeから新しいチームに移り、それがFlutterとして結実する中でFlutterの開発者として働いていたのです。この退職ブログからはむしろFlutterの開発者としての自己意識のほうが今では強いくらいのようで、自分としても認識を改めないとなと思いました。仕様策定とUIフレームワークの開発者というのはかなり違う仕事だと思いますが、そういうふうに仕事を切り替えてきたのがこの人というわけです。いったい彼は何エンジニアなのか？それは考えるだけ無駄なのではないでしょうか。 このような話は全く珍しいものではなく、いくらでも例があります。友人知人にもたくさんいます。もちろん何かを一筋にやっているという人もいてそれは尊敬しますが、そんな人のほうが少数派なんじゃないだろうかとすら思います。ですから、そのとき興味のあることやできることをやるだけであり、結果として生まれるのがその人の専門性なのではないか、と思うのですね。 とはいえ最初に何かを始めるにしても何かは選ばないといけないし、どうやって選んだらいいのかはわからないし、そこで間違えたくないという気持ちもあることでしょう。私は間違えたっていいよと思うのですが、いやむしろ間違えるべきなんじゃないかと思います。もっとも駄目なのはなにも選ばないことなので、とにかくなにかをはじめてみること。そしてやりながら自分になにがあっているかを探索するのがよいのだと思います。最初の選択肢は多くの場合には間違いであり、それでよいのです。 それでもどうしても選べないと言うなら、たとえば今ここでコインでも投げなさい。表が出たらフロントエンドエンジニアを、裏が出たらバックエンドエンジニアをまずは目指しなさい。それが私のおすすめです。 --- もちろん真になんでもよいということはなくて、つらい職場はつらいだけだし、あわないところはあいません。いわゆるブラック企業で心身を損ねては元も子もありません。そういうことはなるべく避けないといけません。 フロントエンドとかバックエンドとか、そういうものよりは、どんなところで働きたいか、どんな人と働きたいか、そういう観点からなるべく自分にあった職場をみつけようとしてみてください。専門性とかはその後でもいいと思います。

Jun Mukai:「最初の」プログラミング言語としてC言語を採用している大学はそれほど一般的ではないし、減ってきているのが現状ではないか、と私も思います。どの大学もカリキュラムには苦慮して少しずつ変えているはずです。 現在おおいのがどのプログラミング言語なのかはわかりません。Pythonのことも多いのではないかと思います。 ただ、ほかの回答がカバーしていない面をあえて考察するとしたら、コンピュータサイエンスについての教育にはC言語は含まれるべきであるとわたしは思いますし、教育内容の依存関係から、比較的カリキュラムの序盤にC言語もやらざるをえないということもかなりあるのではないか、と思われます。 たとえば、コンピュータアーキテクチャやCPUの設計を扱う講義ではアセンブリ言語・機械語を扱うこともありますが、そこを理解するのにはC言語を知っていたほうがわかりやすいでしょうし、逆に機械語の知識があることでC言語の見通しがよくなることも考えられます。ほかにもOSやネットワークなどに関する講義や実習はあるはずで、そうしたところにはC言語を使わざるをえないものがたくさんあるはずです。 すると、年次が進んでそういうことを扱う講義が出てくる前にC言語をとりあえず教えておきたい、というカリキュラム全体の構成から生じる必要性があるのではないでしょうか。 もちろん最初に扱う「唯一の」プログラミング言語がC言語である必要はないでしょう。でも最初の学期で扱われる複数のプログラミング言語のなかにC言語が含まれる場合、そういう事情もあるだろうと思います。

Jun Mukai:こうした質問については、あれもあるこれもあるといった一般論にならざるをえない（また個別の事例についても外部からはよくわからないので憶測しかできない）ということをご承知いただいた上で答えると、だいたい次のようなことが多いだろうと思います。なお回答内の具体例に見えるものは私の想像の産物であり、現実にあったことではありません。 まず質問されている事象について答えるなら、ユーザーへのインタビューや調査といったことをベースにすることはあまりないと思います。あるとしてもかなり間接的な影響のことが多いのではないでしょうか。 それよりも、製品（質問ではOSのUI）が提供したい情報の構造に現状との不一致があったり、おかしなことになっているという設計上の課題があり、それを解決するためにUIが刷新せざるをえないということがあったりするのではないかと思います。 たとえば、通知システムを利用して音楽アプリのコントロールなどをできるような仕組みがあるけど、本来の通知的な用途と混在してわけがわからなくなってしまっているといった現状があり、それを解決するためにAPIを改善し、そのあたらしい構造にそってUIも作り変えられる、といったことがあったりするでしょう。 こういう現状認識がどのようにして起こるかと言うと、第一には作っている人からすると当然の課題であったりすることも多いのですね。また、自社の提供するフィードバックシステムから集約される知見であったり、各種の記事、ユーザのコメント、様々なコミュニティでの質問などが参考にされることがあるでしょう。ユーザー調査によるproactiveな情報収集の結果が援用されることもありますが、そこまで多くないのではないかな、と思っています。 また美的な感覚の変化を反映するという面もあるでしょう。かつての事例ではスキューモリズムからフラットデザインへの変遷が大きいですね。ただそのときも、ただ単なる美的感覚だけでの選択ではなく、どのような利点があるか、使いやすさを損なわないのはどんなものか、という話もありますし、一方で全体としての統一性を生み出すための仕組みも考えられているはずです。ただたんに他のUIを真似するのではなくて、なんらかのメタファーやモチーフ、コンセプトを裏に設けることで全体の統一性をはかるといったことです。たとえばフラットデザイン化するときに、透明な画面の板が重なったような画面構成だとか、紙のデザインをイメージして、とかそういったコンセプトを打ち出しておき、そこから派生する形で個別のUI部品を作ることで見た目や使い心地の統一感がえられるというわけです。当然、過去のメタファー・コンセプトとは異なるため、見た目も大きく変わり、情報構造の多くが変化することはあります。 また、コンウェイの法則による影響やその打破を目指すといったこともよくあるのではないでしょうか。コンウェイの法則というのは、製品の構造が組織の構造を反映しているというものです。もとはコンピュータハードウェアで言われていたもので、買ってきたコンピュータの蓋を開けて中を見ると、そのコンポーネントの分割や配線構造から社内の組織構造が透けて見えるといった揶揄を意味していましたが、現在ではソフトウェア製品でもよく言われ、また残念ながら非常によく見られる話です。 たとえば、部署aと部署bがそれぞれ機能Aと機能Bを開発しているとして、それぞれが別々の画面になっていて、それぞれの機能の設定もそれぞれの画面からアクセスするような仕組みになっていたり、統合的な設定コンソールでも、分類が「部署aの担当するものの設定項目」と「部署bの設定項目」でカテゴリ分けされているなどしており、ユーザからは全く直感的ではない分類になっているといったことがあったりします。 甚だしい場合には、組織改編の結果としてこういう構造が再変化したりすることもあるでしょうし、そこまでではなくても「メジャーアップデート」に際して最新の組織構造に対応して変わってしまうということはありえます。 逆にコンウェイの法則はよく知られているので、そのような現状を問題視して、組織構造にとらわれずにより適切な情報構造を対応した階層構造をとるべきだ、という変化が起こることもあります。これは基本的にはよいことのはずですが、結果として起こるのは抜本的な大変化なので、既存ユーザからはなにがどこに行ったのか分かりづらくなってしまう、ということもあるでしょう。 ほかにもいろいろなことは言えるでしょうし、もっとしょうもない話もいろいろあると思いますが、だいたいにおいてはこのような、各種の変化に対応するための変化であったり、新しいコンセプトのためであったり、ゼロベースで見直した結果であったたり、といったことがもとだと思います。

Jun Mukai:べつに大して重要なことはなにもないと思います。 もちろん、用語を正しく使えないことは専門家としてはずかしいし、場合によってはその人の正真性に疑いをもたらす危険性はあるかもしれません。顧客に説明するときとか同僚に見せる文章で間違ってたら、こいつほんとにわかってやってるのかなと疑念を抱かれかねません。そういう意味では重要ではあります。それに、どちらの概念も正しく理解しておく必要はあり、大学などでの授業で言えば正しく理解していることを証明するのは重要なことかもしれません。 ただ、プログラミング上のプロジェクト・タスク・やるべきことにおいて、並行処理と並列処理のどちらも検討してどちらもやらないといけないということは、基本的にほとんどないんですよね。並行処理の話しかしてないレイヤであったり、並列処理のことしか考えないということの方が大半なのです。なので混同することは現実的にはまずありません。今考えているのはどっちの話なのか、ということを把握しておけば良いだけです。 --- ちなみに並行処理と並列処理は、その違いを理解するという以前の問題として日本語の訳語が不幸なほど似ていて混乱しやすいという話があります。英語で考えたら多少は楽になりますよ。concurrencyとparallelismです。そちらで理解して把握しておくほうが理解しやすいんじゃないでしょうか。 日本語にするときは訳さないといけない時がありややこしいのですが（面倒ならカタカナで書いても押し通せる時も多いと思うけど）、自分は次のように覚えています。すなわち、parallelというのは数学では平行のことなのだけど計算機科学においてはそうでない方、つまり並列の方がparallelismであるというふうに。このことからconcurrencyが並行となります。それにしても並行と平行という微妙に違う字面なのがまた紛らわしいですね。書いていて嫌になります。

Jun Mukai:この記事についての質問ですよね？ https://github.blog/2023-12-07-upgrading-github-com-to-mysql-8-0/ あるいは、次の日本語の紹介を読んでの質問でしょうか？ https://www.publickey1.jp/blog/23/github1200mysql_5780.html この日本語の紹介記事だけからでも、単純なインプレースアップグレードなどではないということは読めばわかることではないでしょうか？ そもそもブルーグリーンデプロイメントとはなんでしょうか。古いバージョンのソフトウェアと新しいバージョンのソフトウェアが同時に存在する環境を作り、安定していることを確認したら徐々に新しいバージョンに移行していくという話ですよね。いきなり移行するとトラブルがあったときに大変だけどその大変さを軽減できるし、どちらのソフトウェアを使うかというルーティングを切り替えれば良いからダウンタイムを0にしたり削減したりできる、というものです。 カナリアリリースとはなんでしょうか。新しいバージョンをリリースするときに、まずごく一部のトラフィックだけを受け入れて様子を見て、問題がなければ徐々にトラフィックを増やしていく（問題があったら元のバージョンに戻す）というもので、炭鉱のカナリアになぞらえてこう呼ぶのでした。 今回のgithubの作業について、レプリケーションインスタンスを新しいバージョンにするときにin-placeで更新するという言葉尻を捉えてインプレースアップグレード戦略だ、などというのはあまりにも表層的すぎます。全然違うでしょう。 じゃあ例えばブルーグリーンデプロイメントなのか？というのはあまり筋の良い問いではないと思います。そういうわかりやすい分類にとらわれて、これは何の戦略なのか、という分類を始めること自体が本末転倒でしょう。具体的にどのような手順で更新をしていたのかを理解し、そこにはいわゆるインプレースアップグレードのような問題があるのかないのか、ないとしたらどのようにして解決されているのか、ブルーグリーンデプロイメントにおいて提示されるメリットは享受されるのかされないのか、といったことを考えた方がいいでしょう。 もう少し具体的に解説してもいいのですが、わざわざ要約して解説をしてあげる義理もないですし大変なのでやりません。でも、もうちょっとちゃんと読んで書いてあることを理解した方が良いと思います。

Jun Mukai:根本的に無理な話だと思っています。 ドメイン名を手放してしまったあとというのは、あなたはもうそのドメイン名に関わることができないということです。誰がどんな目的でドメイン名を取得し、運用してもあなたには関わりのないことであり、それを止める手立てはありません。 あなたが住んでいるところを引っ越しして別なところに移り住んだとき、前の住所に詐欺師が引っ越してきて悪い商売を始めたりするかもしれませんが、それを止めることはできませんよね。それと同じです。 したがって、ありうるべき工夫としてはむしろ、ドメイン名を手放さずに済ますとか、あるいは悪用したくなるような動機をいかに減らすか、というものでしかないだろうと思います。 ドメイン名自体の費用というのはもちろんかかりますが、年間せいぜい数万円程度です。企業にとっては大したコストでもないのでそのまま有効にしておいてもたいしたことにはなりません。そしてドメイン名を自分がもっているあいだは、悪用は確実に防げます。 そもそもあいたドメイン名を悪用されて困るというケースというのは、映画などの専用ドメインに多く見られる現象です。人々の認知も高く、トラフィックも多い割に生存期間が上映期間などに限られるため、上映期間をすぎてドメインを開放したところを再取得して、そこに無関係なコンテンツを入れてしまう。検索エンジンなどからはいまだよく出てくるのでトラフィックを得られる、というわけです。 であれば、未来永劫とはいかなくとも、たとえば数年単位でドメイン名だけは維持しておき、ウェブサイト自体は無効化しておくとか、映画会社などのサイトに転送させておく、という手があります。そのドメイン名自体の利用者が減ってしまえば、そこでドメイン名をあけわたしても、悪い人にとって再取得して利用する価値が低い（トラフィックがこない）ので、相対的には悪用される率を下げることはできるのではないか、という気がします。 しかしそこまで考えてみれば、そもそもそういうドメイン名を最初からとらなければ問題もおきないわけなので、無闇にドメイン名をとらないというのも悪用されるリスクの軽減につながることでしょう。

Jun Mukai:リクエストがありましたので、以下いろいろ思いついたものを書き並べます。 編み物 まさにコツコツやる作業ですが、だんだん形になっていくのも楽しいですし、作ったものを使えるのでなかなか楽しいです。まずは糸と編み方のセットになったキットから始めるといいでしょう。 料理 あまり自炊をしていないなら、やってみるといいですよ。レシピどおりにいろいろ作ってみるところから始めて、うまく行けば美味しくて達成感もあります。ハマったらいくらでもこだわる道筋があります。 プログラミング もしまだやったことがないなら。べつに職業プログラマになる必要はなく、単純なことをできるくらいのことでもできるようになると楽しいと思います。基本的にはコツコツ作業ですし、形になって何かアプリができたら達成感もあります。 電子工作 自分はあんまりやらないですが、プログラミングと同様で楽しいだろうと思います。出来上がったものが実物としてあるのもいいですね。最初はキットから始めるといいんじゃないでしょうか。 ジグソーパズル ピースの多いものなど時間もかかりますし、やることは地道ですが絵がだんだんできていくので達成感もあります。場所を取るかもしれませんが。 数独などのペンシルパズル これもひたすらコツコツやって解いていくものですし、一問解けたらそれだけでなかなかの達成感があります。 ランニング 近所の短い距離をジョギングすることから始めましょう。だんだん長い距離を走れるようになります。最終的にはマラソンを走れるようになったり、その時間を目標にしたりとやりがいもあります。 筋トレ べつに大会に出たりボディビルをするということではなく、健康のために簡単な筋トレをしてみるとなかなかよいです。淡々とタスクをこなすだけですが、続けるとだんだん筋肉もついてきますし、けっこう体格も変わったりして楽しいです。ジムに通うか、最近はYouTubeで動画を上げている人もいるのでそれにあわせてやるかでしょうか。 以上、なにか引っかかるものがあったらさいわいです。

Jun Mukai:AIになにをやってもらうのかを考え、定式化することは人間の仕事として残るのではないかという気がします。 というふうに書くと、あたかもPMのように指示を出す人間というイメージをもつ人もいるかもしれませんが、わたしのイメージは違います。現行のAI技術の延長線上には、具体的な計画に基づいてコードを生成したり既存のコードを修正することはかなりできるものはあると思いますが、それ以上のことはなかなか難しいと思っています。 例えば、先ごろgithubはcopilot workspacesというものを発表しました。これはissue trackerなどに書かれた報告やその後の議論を読み込んで修正内容を立案し、修正コードを生成してくれるというものです。 https://githubnext.com/projects/copilot-workspace ですが、「立案」というのが曲者で、ここを的確に行わないといけないのではないか、という気がします。そして、そのためにはそれなりの専門性やコードベースに対する知識が必要になるだろうと思っています。 例えばバグの修正を考えてみましょう。「この操作をするとき、たまにチラつくことがある」といったバグがあるとします。これを修正するためにはソースコードからその操作に関連する処理を見て、どのような原因によってチラつきが発生するかを突き止めないといけません。さまざまな手段で問題を分析することになります。トレーシングやログ解析をするかもしれないし、プロファイルを取るかもしれないし、printfデバッグをするかもしれないし、UIのフローを考えたりするかもしれません。そうやっていろんな分析をした結果、どこかの処理に抜けがあって本来やるべきではない再描画が行われていたことがわかったりして、そうしたらそこをどう修正するかを考えることになります。 こういう種類の問題においては、具体的なコードを書くこと、というのはどちらかといえば単純な種類の作業です。それよりはコードをよく理解し、さまざまな手法で分析を行い、なぜこの問題が起きるのかを理解することが重要です。そしてそれはAIは行ってくれないし、現行の生成的AI技術によっては達成されないタイプの作業であると思います。もちろん、「こういうバグを理解するにはどういう分析をすれば良いですか」と問えばやり方を教えてくれたりはするでしょうし、膨大なログから問題の箇所を抜き出したり、それに対する質問をしたり、といったことも可能になるだろうとは思います。そうやって個々の分析やデバッグの作業を簡単にできたりするようにはなるけれど、その結果を統合して、問題を解決するにはここを直すべきだ、といったことを決めるのは依然として人間であると私は思います。 そうやってログを貼り付けたり分析した思考の道筋をissue trackerに書いておけば、その内容から実際のコード修正をやってくれるというのが copilot workspace である、というふうに思います。 新機能も同様です。「新しくこういう画面のものを作りたい」みたいな機能があったとします。そのふわっとした説明に対して、この部分はこのように動作するとかを明文化したり、またデータソースとしてバックエンドのAPIはどのようなものを使うのか、また既存のものを使うのか新しくエンドポイントを追加するのか、スキーマの変更はあるのか……といったことは考える必要があり、それをするのは人間なのだろうと思います。 こういうことを行うためにはコードベースを理解し、さまざまな分析手法を利用したり、そのための基盤をセットアップしたり、といったことが必要で、それが技術者の仕事ということになるんじゃないかと思います。

Jun Mukai:「関数型言語を利用して開発するソフトウェアの設計において」の話ですよね？　関数型言語自体をどのように設計するかについてはあまり答えられる気がしませんが、その知見はあまり求められていないと思いますので。 基本的には関数型言語だからというのは言い訳にはならなくて、難しいソフトウェアの開発は難しいものであるのではないか、と思っています。関数型言語だからといって、そこに特有の難しさや課題があるわけではないと思います。 ただし、オブジェクト指向プログラミング言語によるソフトウェア開発は非常に広く一般化し、多くの知見が集まっているのに対して、関数型言語によるソフトウェア開発はそれほど一般的ではなく、あまり広く行われているものではないため、開発における知見、よくあるパターン、スタイルのようなもので広く定まったものが多くないのではないか、というふうに思っています。いわゆるデザインパターンのようなものや、MVCのようなアーキテクチャはそのまま関数型言語に応用できるのかどうか、応用するとどのような構造になるべきか、また違うより適したパターンがあるとしたらどうなのか……といった話にあまり結論が出ていないだろうということです。 また、そうして構築されたパターンはオブジェクト指向プログラミング言語のパターンと大きく常識が異なるため、既存の環境に慣れた人からは特有の難しさを感じるということもあるのではないか、と思います。 関数型言語によるソフトウェア開発が広まり、さまざまな知見が蓄積され、あるべきアーキテクチャや関連するデザインパターンが整備され、そうした知識が一般化していくことでしか、こうしたことはなかなか解決しないだろうと思います。

Jun Mukai:様々な処理を内包するトランザクションを実行する関数があって、その個別処理のテストと全体のテストをどうするか、という話ですかね。 個別具体的な状況に応じて多少の変化はあると思いますが、自分であれば、個別処理を関数に分けて、そこで様々な条件に応じたユニットテストを書くと思います。 トランザクション全体については、全体的な構成が自明な場合（例えばフレームワークやライブラリにtransactionalに実行するための関数などがあり、単にそれをよんで順次実行しているだけなど）にはあえてユニットテストを書く必要はない、ということはありえるでしょう。 テストを書くとしたらトランザクション自体の処理を適切に行えているかのテスト、すなわち、 * 途中の処理で失敗が発生した時に正しく中断して最終結果に影響を与えないこと * 同時並列的に実行しても整合性が取れていること などをテストすることはあるかもしれません。途中の処理で失敗してもらうためにモックを導入したりといったこともあるでしょう。 または、そういうことはユニットテストでは行わず、インテグレーションテストがあって、そちらで検証しているということもあるでしょう。 以上の話はトランザクションに限ったことではなく、より一般的な話だと思います。すなわち、 * ユニットテストは小さな単位で行い、細かい条件について色々検証する * 単純にそれらを組み合わせただけのような自明な処理についてはテストは書かなくても良いことはある * 組み合わせた処理についてユニットテストを書くなら、組み合わせ方が正しいかどうかを検証するテストを書く。その際、内部的な個別コンポーネントの詳細は無視して良い。必要ならモックなどを用意して意図的にエラーだけが起こるようにする * ユニットテストは行わず、インテグレーションテストを書くこともありうる

Jun Mukai:AIが「手を抜く」ことはありえないことを知っているので、そういう体験は自分としてはありません。基本的に入力に対して同じ計算を行った結果を返しているだけだからです。 結果として返されたものが充分な品質ではなかったり、間違っていたり、対話を繰り返したらもとの回答に戻ってしまったり、ということはあります。それはAIの挙動を理解していればそれほど異常なことではなく（役に立たないという意味では残念ですが）、手を抜くとはわたしは考えていません。 ところでAIにおける「手抜き」というのは何でしょうか？　これ、語源から考えてみると案外面白いですね。語源をたどれば、「手を抜く」というのは囲碁や将棋における行為で、定石的なパターンにおいて本来であれば必要であるとされる石の配置、駒の移動を行わないことです。その手を「抜いて」別なことをしてしまう。それをしないことで手薄になったところを攻撃されたりしたら問題が起こるかもしれないけれど、相手が気づかないかもしれない、または相手の実力的に気づかれても後で対処すれば大丈夫、あるいはそうした損を受け入れてもなお総合的には自分にとってプラスになる他の手があるなどと判断して必要な手順を省くこと、なわけでした。 このもともとの意味から考えてみると、ある意味ではAIはつねに「手を抜いて」成果物を出力していると言えます。画像生成系のAIで人間の手などの部分が難しいのは、AIは人間の身体構造などを理解せずそれっぽくなるように描画しているからと理解されています。つまり身体構造などを考えて姿勢や骨格がこうなるからこのような図像になるはず、といったステップをとばして（手を抜いて）いきなり画像を出力し、細部の辻褄だけを合わせていく。またLLMにおいても細かい論理展開を行うことなく過去の文脈だけからいきなり回答を出力しているという意味では「手を抜いて」いるとも言えるかもしれません。 このように考えてみると、chain of thoughtsというのは必要な論理展開を「手を抜かずに」明示的に行うことで正しい結果を出力してもらうことだとも言えるのかもしれませんね。 もともとの質問がここまでのことを含意していたとはあまり思わないのですが、ちょっと面白いと思った次第です。

Jun Mukai:もちろん、正解はないと思いますし、おいそれとどちらがいいとは断言できません。でも、例えば自分だったら次のようなことを気にするかなぁと思います。 1. 仕事の内容はどのようなものか、自分にとって楽しいものか。プロジェクトマネージャというのは結構幅広い仕事だと思います。具体的にどんな仕事をすることになるか、聞いているのでしょうか。それを毎日やって楽しめるでしょうか。ソフトウェアエンジニアも同様で、毎日コードを書くのが楽しみでそれをずっとやっていたいという人もいれば、コードを書くことだけが全てではないという人もいるでしょうし、コードは書かない人もいるでしょう。そこのミスマッチがあるとつらいかなという気がします。 2. 直属の上司になる人や同じチームの同僚はどのような人たちか、チームの雰囲気はどんなものか。自分の経験的に、いまいちチームに馴染めなかったり、やりづらい人と仕事をするハメになるとしんどいです。 3. プロジェクトや会社全体の方針と、自分の思っていることに齟齬はないか。例えば極端な例としては、あなたとしては自分（のチーム）で開発するつもりだけど、会社としてはベンダを導入して運営するのが当然でありあなたにはベンダの管理を任せるつもりだった、みたいなこともあるかも知れません（逆のパターンもあるかも知れません）。そういう齟齬があるとかなり辛いのではないか、という気がします。 4. 取り組むことになるプロジェクトに対する興味や愛着はあるか。やっているプロジェクトに意義を感じられなくなったりするとモチベーションが減ってしまったりすることもあるかも知れません。そこはプロなので割り切れるという人もいるかも知れません。 5. 会社全体の雰囲気、カルチャーはどんなものか。さっきのと別に、会社全体の雰囲気やカルチャーはどういうもので、そこに馴染めるかも大事だったりするかも知れません。 6. 会社内におけるソフトウェアプロジェクトの立ち位置はどんなものか。半導体業界ということですので、会社内での「地位」や重要度で言えば、例えば半導体設計が花形だろうと思います。ソフトウェアチームは甘く見られたりするかも知れませんし、会社のメインビジネスとは別なことをやることになるかも知れません。 7. ワークライフバランスなどは、自分の必要なレベルを満たしているか。例えば小さな子供がいて、ある程度は子供の世話をしないといけない（保育園への送り迎えなどは自分がやらないといけないので勤務時間に影響があるなど）とか、年2回のコミケは絶対に参加したいのでその日に休みが取れるような制度でないと困るとか、そういうようなことです 適当に思いつくままに書いてみましたが、これらの全てが等しく重要だということではありませんし、他にも重視すべき点もあるかも知れません。こういった回答から、自分にとってどのようなことが大事なのかを見直すことが重要ではないか、と思います。 例えば、あなたのスキルセットを評価しているということですが、それでいてプロジェクトマネージャとして採用したいというのは、それだけ聞くといまいちよくわからないな、というふうには思います。そのスキルセットは転職先においてはプロジェクトマネージャとして見込まれるべきスキルなんでしょうか。これは上の最初の点に関係しますが、あなたのスキルセットや仕事としてやりたいことと、その会社におけるプロジェクトマネージャの仕事内容がミスマッチしていると厳しいことになるんじゃないかな、という気がします。そこのすり合わせは大事かなと思います。 今後のキャリアパスについては、そこまで心配しても仕方ないという面はあるような気はします。異業種で少し異なる種類の仕事をした経験は糧となって新しい道が開けることはあるんじゃないかと思いますし、うまくいかなさそうだったらさっさと元の業種・仕事に戻ればいいかなという気もします。もっともこれも私の感覚的なものでしかないので、ご自身が重視するならそこを大事にした方がいいかも知れません（例えば、現在の勤務先や業種によってはそうそう気軽には戻れなかったりすることもあるでしょうし）。 また、もちろん、どうしたって事前には全てのことはわかりません。質問で色々聞くことはできますが、相手はどうとでも答えられる面はありますし、全体のごく一面的な部分からの回答であったとか、入ってみたら思ったのと違う、という面もあります。なのでどうしても賭けるしかない面はあります。それでもどうしても譲れないポイントとか、そういう点についての意識のすり合わせはやらないといけないんじゃないかな、という気がします。またネットで色々検索してみて会社の実態を推測してみるということもやったりはするだろうなと思います。 あ、あと家族や友達と色々話してみるということを、自分ならやると思います。自分の思ってみなかったような視点を与えてくれることもありますよ。 色々とっ散らかってしまいましたが、何か一つでも参考になる点があれば幸いです。

Jun Mukai:今井むつみさんという方は存じ上げないし、具体的な主張内容もわからないのですが、質問文に書かれているような内容については正当と感じます。 いわゆる大規模言語モデル、生成的言語モデルというのは、GPT（generative pretrained transformerの略）という名前からもわかるように、generativeなtransformerが基本になっています。近年のLLMについては、残念ながらその技術的な詳細やモデルの具体的な構造などは公開されていないために断言しづらいところではありますが、根本的に異なるようなものであれば喧伝されるはずなので、chatGPTを含むすべてのLLMはおおむねtransformerを基本としたモデルになっていることは間違いありません。 そして、generative transformerというものは学習データに対して次の単語をうまく予測するようなトレーニングを行い、パラメータを調整していくものです。したがって、やっていることは次の単語が何なのかを予測しつつどんどん単語を進めていく、つまり「言語予測マシン」でしかない、ということは完全に正しい説明です。これが「統計的」であるかというのは……統計的という言葉の定義によってかわりうるとは思います。従来的な統計学的な計算をしているわけではないのですが、大量の学習データに対してうまくフィットするようにパラメータを調整していくというふるまいを統計的と呼ぶことをおかしいとは、私は思いません。 「独自の思考能力」というのもまた定義がはっきりしないのでむずかしいですが、実際には学習データの内容を適当に組み合わせることで文（単語列）を生成していくことしかしていないので、思考能力などないという主張はありうるでしょう、というか私も積極的に同意するところです。 ところが、にもかかわらず、学習データが大規模になり、モデルも大規模化していくと、どういうわけか非常に高い能力をもつようになることがわかってきた、というのが今のところなわけです。しかし、どこまで高い能力を持つのか、その限界はどの程度なのか、そのモデル内にはどのような知識が蓄積されているか、それはどのようにして取り出せるか……ということはわかっておらず、それゆえに多くの人を魅了し、みんな可能性を探っているところだというふうに思っています。 しかし、いわゆる汎用人工知能ではないと私は思いますし、そのような理解の方が一般的であると思います。あくまでも学習を通じて得られたパラメータに対して単語列を生成しているだけであり、実際にそれほど「知的」ではないふるまいがしばしば見られます。プロンプトの一部を無視することもあるし、ハルシネーションと呼ばれる、現実ではないことを回答することもしばしばありますし、回答の内容が論理的に自己矛盾していることすらあります。ただ単に、これまでの文章から適した次の単語列を予測して生成していくというただそれだけのことでしかないからです。使えば使うほど、その可能性の凄さと同時に、知的ではない面も垣間見えるようになると思っています。 また、OpenAIもAGI（artificial general intelligence、汎用人工知能）の達成を目的としておりますが、その達成を宣言したことはありませんので、（まだ）汎用人工知能ではないという方が一般的であるのは間違いないと思います。 今後、規模の拡張によってAGIは達成されうるのか、根本的なアーキテクチャの変更が必要になるのか、そもそも無理なのか、というのは興味深い問いかけではあります。個人的にはそもそも無理だしそこは比較的どうでもいいことなんじゃないか、と思っているのですが、少なくとも現状のLLMのアーキテクチャだけからは限界が見えてきたのではないかと思っています。

Jun Mukai:倒叙形式の推理小説においては、主人公であり語り手が犯人というパターンはいくらでもあるのではないでしょうか。 倒叙というのは、あらかじめ犯人が誰かが読者に提示されている形式をいいます。犯人がはっきりと描写され、具体的な犯行現場も記述されます。一見うまくいっているはずの犯行のなかのほころびを探偵役がいかに見つけるかが見どころになります。有名なのはテレビドラマですが『刑事コロンボ』シリーズでしょうか。テレビドラマでは、犯人役はゲストスターとして大物俳優が演じることが多く視聴者にバレバレだったので、そこを逆手に取って倒叙を採用したと言われています。コロンボに影響を受けた『古畑任三郎』も倒叙です。「小説」に限ったとしても、たとえばコロンボはノベライズされており、語り手が犯人の形式をとっていました。もちろんそれ以外にも多数の例があります。 https://ja.wikipedia.org/wiki/%E6%8E%A8%E7%90%86%E5%B0%8F%E8%AA%AC#%E5%80%92%E5%8F%99 倒叙ではないが語り手が実は犯人であった、という作品も、たとえば思いついたものはあるのですが、それは明かさないほうがよいのではないかと思うので具体的な作品は挙げません。しかし、あるかないかでいえば、あります。