  |
はてなキーワード:ワークフローとは
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
そんな日々の中で最も厄介なのは、CxOたちだ。
──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。
PowerPointを開いて「DXを推進している」と言う人たち。
うちのCxOはこう言った。
翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。
その瞬間、何かが切れた。
──ケーキではない。
CxOたちはコードを読めない。
それ自体は罪ではない。
だが、読もうとしないことは怠慢だ。
よく聞く反論がある。
確かにそうだ。
ただし前提が抜けている。
つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。
「技術的なことは詳しくないが、成果は出している」
それはたまたまだ。
「上が言ってるから」「今期の方針だから」「スピード優先で」。
Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。
これもよく聞く言い訳だ。
しかし、リソースが限られているならなおさら、理解の精度が重要になる。
僕が書いたAPIは、リクエストごとに外部APIを叩いていた。
「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。
CxOたちは言った。
「想定してなかったのか？」
──想定してた。
だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。
Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。
CxOたちは「コストを切れ」と言う。
切れるのはコストだけ。
削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。
Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。
CxOたちは「我々はデジタル変革を進めている」と言う。
だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。
クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。
──違う軸を持つのは構わない。
現場を理解しない経営視点は、地図を見ないドライバーと同じだ。
「コードなんて書かなくていい。これからはノーコードの時代だ。」
だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。
だが、隠したコードが消えるわけではない。
ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。
それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。
「ノーコードでいい」と言うCxOは、
「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。
理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。
人を楽にするどころか、誰も直せない仕組みを量産する。
DXとは、ツールを導入することではない。
それを理解しない限り、
理解しないことだ。
真っ先に切られるのは、
──コストだけ。
CxOたちは「未来を見ている」と言う。
未来とは、仕様書ではなく、Pull Requestの積み重ねだ。
最近「テクノロジーで政治をかえる」だの、「デジタル民主主義」だのって、やたらと情報工学系のバズワードを振り回す新党がある。「チームみらい」だ。
正直なところ、俺みたいなお堅い開発やってる情報技術者からすると、最初は「またか」ってのが正直な感想だった。政治家が「IT」って言い出すと、ろくなことにならないってのが経験則だからな。
でもちょっと調べてみたら、「チームみらい」の言ってることには、確かに耳を傾ける価値のある部分と、背筋が凍るような懸念点が同居してるってのがわかってきた。
まず、彼らの主張と、俺がポジティブに受け取った点から見ていこうか。
彼らは日本の政治を「バグってる」と表現し、「行政サービスは相変わらず使いづらい」と現状認識は一致する。
「テクノロジーで、政治の透明化・効率化を実現する。それは今すぐできる。そしてあなたの生活を着実に改善できる」と謳ってる。目標としては「テクノロジーで透明化、効率化、スマート化」を目指すんだと。まぁ、これは誰でも言うよな、って感じだが。
「1議席を得て国政政党になったら、政党交付金で永田町にエンジニアチームをつくる」と明言してるのは驚いた。これが絵空事じゃないなら、これまで口先だけだった「IT化」「DX推進」とは一線を画す。
党首の安野たかひろ氏自身がAIエンジニア・起業家だというし、公認候補者の中にも複数の情報技術者がいるのは確認できた。「手と足を動かす実践型」を標榜してるってのも、従来の政治家とは違う姿勢だな。
「自ら開発した政治資金透明化ツール Polimoney にてすべて公開」してるってのは、実際に手を動かした証拠だ。これは評価できる。
「政策をAIと対話しながら深掘りし、意見や要望も簡単に送れる世界初のチャット機能も搭載」したマニフェスト や、「政治参加を"楽しく"可視化！ゲーミフィケーション導入のアクションボード」なんてのも作ってるらしい。これらは「デジタル民主主義」を単なるスローガンで終わらせないという意欲の表れだろう。
ここからが本題だ。彼らの主張を聞いて、俺の脳内には危険信号が点滅しまくってる。
何故なら「具体的な『(情報工学としての)マニフェスト』も『仕様書』も『実装計画』も決まってない」から。
彼らは「アジャイルに、現場で改善していく」って言いたいんだろうが、「基幹システム」と「Webサービス」を一緒にしてはいけない。
銀行の勘定系なんて、たった一行のコード変更でも何十ページもの影響分析とテスト計画が必要になるんだぜ？国民の税金や個人情報、社会保障に関わる行政システムは、国民全員の生活の基盤だ。それを「バグってるから現場で直す」なんて、詳細な設計書も持たずにメスを入れるようなものだ。そんなリスキーなことを許せるか？
「テクノロジーは、難しい技術のことじゃない。できなかったことを、できるようにする方法のことだ」、って言うが、その「できるようにする方法」をどう「堅牢に」「安全に」「持続可能に」実現するかが、情報工学の肝なんだよ。
彼らが作ったPolimoneyやAIチャットは、あくまでプロトタイプや限定的なツールだ。素晴らしいが、それは「小さなシステム」での成功例に過ぎない。全国民が利用する行政サービスを、あのレベルでアジャイルに改善し続けられるのか？アクセスが集中した時、障害が発生した時、どうする？
勘定系システムなら、トランザクション一つが飛んだら新聞沙汰だ。行政サービスもそれに近い重要性がある。「後から直す」では許されないレベルのシステムを彼らがどう扱うのか、その哲学が全く見えてこない。
日本中の行政システムは、半世紀以上かけて積み上げられたレガシーの塊だ。古いCOBOLやFortran、紙のワークフローがそこら中にある。永田町にエンジニアチームを作ったとして、彼らが直面するのは、壮絶な「負の遺産」との戦いだ。
「既存の枠組みにとらわれることなく活動していきます」というが、既存の枠組みに「縛られまくってる」のが日本の行政システムなんだ。これらをどう「解体」し、「再構築」していくのか。それには膨大な時間、予算、そして何よりも緻密な移行計画が必要不可欠だ。
「エンジニアチームが政治や社会の課題を次々解決」 ってのは聞こえはいいが、誰がその「課題」を定義し、どの「解決策」が正しいと判断するのか？エンジニアが政策立案まで牛耳るのか？
今現在としてマニフェスト(情報工学)や仕様書がないということは、「誰が、何を、どう作ったのか」という明確な責任の所在が曖昧になるリスクもはらむ。国民への説明責任をどう果たすのか？
「チームみらい」がこれまでの政治の慣習を破ろうとしている点は評価する。エンジニアを政治の中枢に入れようとする試みも、既存の政治家が積極的にやろうとしなかったことだ。
しかし、彼らがやろうとしているのは、町中の小さなウェブサイトを作るような話じゃない。国家の基幹システムを「アップデート」する話だ。それには、「バグってるから直す」というシンプルな熱意だけでは足りない。
必要なのは、システムの全体像を見通すアーキテクチャ設計能力、膨大なリスクと向き合うセキュリティ設計、そして長期的な運用を見据えたメンテナンス計画だ。
「アジャイル」は魔法の言葉じゃない。基幹システムにおいては、アジャイルの導入にも緻密な計画と準備、そして極めて高い技術力と経験が求められる。
この党が、本当に日本の未来を明るくできるのか、それとも「デジタルの皮を被った理想論」で終わってしまうのか。今の段階では、期待と不安が五分五分だ。彼らが単なる「手を動かす」だけでなく、「システム全体を見通す頭」と「国家レベルの責任を背負う覚悟」を具体的に示せるかに、全てがかかっていると俺は思うぜ。
はてなーは情報工学にそこそこ詳しい連中が揃ってるんだからコレくらいは言って欲しい。
正直、最も不安を覚えるのはチームみらいへ対しチームみらいに勝るとも劣らないレベルの曖昧でふんわりとした評価しかコメントできないお前らへ対しての不安が大きすぎる。
個人的に、安野氏には今回メチャクチャ惨敗したとしても次回また挑戦して欲しいね。もちろん再挑戦は「何が足りないのか？」を指摘してる連中の意見をしっかりと受け止めてやって欲しいね。
Permalink |記事への反応(15) | 15:11
comfyUIでJANKUを使用すると最も単純なワークフローでも黒画像しか出力されない問題に遭遇したが、以前不用意に変更したサーバー設定の推論欄等をautoから固定値へと変更していたことが原因だと判明した。
I encountered a problem where using JANKU with comfyUIonlyoutputs black images even in the simplest workflow, butit turnedout to be causedby a previous inadvertentchange of the inferencefieldetc. in the server settings fromauto to fixed values.
ITに弱い弊社、目下、様々なDigital Transformation: DXプロジェクトが昨年から走っている。
私は人事領域DXに参加しているが、実はプロジェクトが相当難航している。
支離滅裂な文章だが自分の中で整理すべく、今の状況を書き殴っている。
最大の問題点だ。
人事部としては「タレントマネジメント（タレマネ）システム」導入を検討している。というか、導入したい。
しかし、タレマネ導入で具体的に何がしたいのか、人事部からは明確なイメージが伝わってこない。
今までヒアリングした中で明確な要求は、レーダーチャートでの能力可視化、異動シミュレーション機能で異動後の部署の人員構成を顔写真付きで見れる、この2つの機能。
しかし、レーダーチャートで可視化する能力は具体的に何なのか、経営戦略で謳われている「経営に資する人事」とは具体的に何ができればよいのか、
どのような人事業務であれば「経営に資する」のか、そこにタレマネ上手く言えないが、そんな視点が感じられない。
しかし、タレマネ導入は決定事項だから進めたいらしい。カ○ナ○、Sm○rtH○がセキュリティ的に社内規定に使用可能か確認してくる。
オンプレの人事基幹システムと自動データ連携したいそうで、しきりにベンダーとのミーティングに出させられるが、全くやる気が起こらない。
ツール導入から入ってるせいで、要件定義の必要性を訴えても、とりあってもらえない。
要求事項が明確ではないのにデータ連携の打ち合わせをしても、後で変更が多発することを懸念している。
とにかく、何でも良いからレーダーチャートで可視化でき、きれいなGUI画面で人事異動シミュレーションが顔写真付きで出来ればいいらしい。
人事の実務部隊（主任以下の役職が主に動いている）は、「管理職にビジョンを求めても無理だ」と言う。そんなことを考えられる人たちではない、と。
実務部隊は何がしたいの？ タレマネに必要なデータ入力を自動化させ、日常の入力業務負荷を下げたいらしい。
そして、住所変更などの日頃処理している入力業務の負荷も下げたいらしい。
人事部（正確には人事部の主任以下の実務部隊。管理職はプロジェクトを全部任せてしまっている。ていうか丸投げしている）は、タレマネシステム導入により、データ入力の業務負荷が増大することを懸念している。
負荷軽減が必須事項であり、タレマネ導入・運用には以下が「必須である」と人事部は主張している。
②SaaSのタレマネ（具体的にはカ○ナ○）がオプション機能として提供している「ワークフロー機能」を利用し、オンプレの基幹システム（これが人事データの源泉）にデータ連携させる。連携の仕組みはEAIツール（DataSpider）を使用し、社内SE部隊が構築する。
①は業務利用にあたるため「サービス残業」と見做される可能性が高いと役員からは指摘されており、自分もその通りだと思っている。人事部の見解は「業務利用か否かはグレーゾーンであり会社として『業務にあたらない』と説明すれば足りる」と。いや、グレーと理解しているなら黒だと労基に認識される可能性もあるんだし、そもそも会社が従業員に申請を求めている時点で業務だと思うのだが、違うだろうか。
ちなみに、弊社は現業職員がおり全員が社給PCを持っているわけではなく、かつ基本的に機密の関係で職場への携帯持込はNGなので「業務時間外」にやることと、となっている。
②は、人事部がなぜシステム構成を社内SE抜きで勝手に決めるのか意味不明で、越権行為も甚だしい。しかも実現可能性の検証がされていない。さらには「従業員の私物携帯・PCを利用させる」という所謂BYODを会社としてはまだ認めていないのだ。前提となるハードルもクリアしていないのに、連携の仕組みを人事部が勝手に考えて稟議も出そうとしているらしい。実務部隊の人事部主任は性格的に短絡的かつ力押しで仕事を進めるタイプだけど、機密管理委員会からの認可も下りていないのに。
そもそも、タレマネ(SaaS)のワークフロー機能を使用してオンプレ人事システムのデータに連携するなんて複雑なシステム構成、私は今までに見たことがない。
弊社は現業の社員もいて1人1人に社給PCが与えられていない。現業職員の申請は上長が代理でPCにワークフロー申請で行う。事務職は全員社給PCがあるから、自分のPCからワークフロー申請ができる。
申請は年間合計で1000件あり、1件あたり1時間の入力・承認作業時間がかかるらしい。年間1000時間として、1日あたり4時間。それを4、5名で捌いている。その入力時間を削減したいらしい。
現業職員に社給PCを支給する（もしくは相当台数の共有PCを配布する）ことが決まっていたため、人事基幹システムのワークフロー機能で入力してもらえばBYODの問題はなくなるし、労基法的な問題もクリアできる。だが、人事部は蹴った。人事部でワークフロー機能を使いこなすことが難しいから、と。
SaaSのワークフロー機能なら導入時にSaaS業者が構築を請け負ってくれて、連携まわりは社内SEの所管業務、だから人事部としてはSaaSのワークフロー機能に社員の私物携帯から入力させてオンプレ基幹システムにデータ連携したいらしい。
自分はにはやりたくない。そもそもプロジェクト自体に共感が一切できていない。仕事を外して貰いたい。
人事部がタレマネシステムを導入したい第一の目的は「日常業務の入力負荷軽減」だと明確に言っていた。そんなシステムではないはずだが。
1年経過した最近、各DXチームが発表する場があった。役員からの評価は極めて悪かった。
講評には「人事業務がどうあるべきなのかをまずは明確にしてほしい」と記載されていた。しかし、これは私の担当の範疇を超えている。上位レベルの課題だ。
手段と目的が逆、課題が未整理、それぞれの課題に対してどのような打ち手を実行するのか、整理されていないと。
その通りだと思う。社内SEの自分が人事部の代わりに人事業務を考えてあげることはできない。
人事部的にはITのことは分からないから、と言う。しかし、IT云々の話なのだろうか。各社SaaSのデモは何ヶ月も人事部はトライアル使用していたのに、それをどのように活用して目的を実現するのかを明確に表現できないなんて、そんなものなのだろうか。
書き殴ったけど、こんな状況で伝わるだろうか。
どうすればいいのだろうな？
関わり方が分からん。
DX、難しい。
※なんか頭のなかのもやを発露しただけの、駄文です。全部自戒です。
最近、生成AIの普及で質の低いコンテンツがめちゃくちゃ増えてる気がする。新しいツールやテクノロジーが出るたびに、表面的なチュートリアル記事が量産されて、検索結果がノイズだらけになってるよね。一部の専門家だけがアクセスできた情報を一般化すること自体は良いことなんだけど、問題は内容の薄さ。公式ドキュメントにAIで質問すれば、もっと適切で完璧な情報が得られる時代に、わざわざ劣化版のチュートリアルを作る意味ってあるのかね。
求められてるのは基本的なセットアップ方法じゃなくて、それらを使った独自の実践例や実験的な活用事例だと思う。そこにその人らしさや独自の価値が生まれるんだよね。
AI技術の進歩で、エンジニア界隈は今めちゃくちゃカオスな状態になってる。AIに批判的な既存エンジニア、AIコーディングを全面的に受け入れる層、AIによる新規参入者への反発、日々変わるベストプラクティス、短期間で陳腐化する専門性など、色んな思惑やイデオロギーが交錯してる。
それに、それぞれが住んでいる生態系やクライアントの特性、業界特性、背景、生まれた背景、国や言語なんかによって全然違うじゃん。例えば大企業がクライアントの場合は、当然そうじゃないところよりも色んな要素が多くなって複雑性が高い。一方で、そうじゃないところは煽り合戦だったりストーリーテリングみたいなのが大事だったりする。昔からよくある、ベンチャーvs大企業みたいな構図。だから、それぞれがいるポジションが全然違う中で、ああだこうだ言っても正直意味がない。そこで議論する前に、まずお前らのコンテクストをエンジアリングにしろよって思うわ。
生成AIブームで色んなプレイヤーが参入してるけど、現状を冷静に見ると面白い構造が見えてくる。今の生成AI界隈のプレイヤーって、大体初級レベルの情報商材・教育事業者、中級レベルの教育系AIサービス、生成AIを使った新規事業・起業家みたいな感じに分かれてる。この中で、生成AIネイティブで既存の業界課題を解決する形のサービスも一定数いるんだけど、圧倒的にやりやすくてレバレッジが効いて短期間で利益を取りやすいのは、まだAI利用の環境すら整っていないところの教育分野なんだよね。だから、そういったものへの参入が多い。想像したらわかりやすいけど、まだChatGPT使ったことない人に、ChatGPTの初級編の使い方を教える感じ。使った人はすげええええええってなるじゃん。
一方で、本当にAIや画像生成なんかを使ってユーザーを獲得して収益の上がるサービスを日本国内や海外向けに作っていこうとすると、そこには大きなハードルがある。そこにチャレンジしてる方々もいらっしゃるので、それは本当にリスペクトするし応援してる。なるべくサービスも使うようにしてる。でも、そうじゃない人の新規参入として、AIネイティブなサービスを作るのは本当に難しくて色んな変数があるので、プロダクションレベルで提供するのは困難。だからこそ参入が取りやすい教育系のサービスやコンテンツ販売、また今の時期だとAI動画を使ったYouTubeチャンネルみたいなところが参入しやすいので、そこのプレイヤーも多くなってしまう。エコシステムっていうのはこうして発展していく部分もあるけどさ、視座を高く持とうぜって。
そうすると、参入がしやすいものっていうのはあっという間に飽和してしまうので、そこに成功を求めて向かって行ってもあまり勝ち目がない。もちろん資本が大きい分には参入していって、そこのパイの一部をもらって売上を上げることができるかもしれないけど、微妙と言わざるを得ないかもしれない。何が言いたいかと言うと、AIを使ったネイティブなITサービス、純粋なITソリューション製品・サービスを作るっていうのは非常に難しい。BtoBの領域で言うと既存のワークフローがあったり業界特有の既存サービスがあったりするので、そういったもののプレイヤーたちがAIを組み合わせた方がむしろ効果が出やすかったりする。その業界ならではのAIサービスを0から作っていくような気概がないとそこは難しい。開発者向けのAIサービスっていうのは本当に世界中のエンジニアがある意味競合でもあり仲間みたいな状態なので、そこに挑戦する人々は本当に応援したい。
一方で、そうじゃない人の参入としては、やはり自分のバックグラウンドや強みもしくは隙間がある領域×AIみたいなところで勝負を探す方がいいんじゃないかと思う。その方が競合は少ないし独自の価値を付けやすい。それはWebサービスのみならず、自分のポジションやどの業界を見ようかって価値観の変容みたいなところも必要なんじゃないかと思うし、自分がどうすればレバレッジが効くのかみたいな観点でも有用になるのかなと思う。グローバルニッチって考え方がたびたび目にするけどそれだね。
あとは過去に投じた時間やお金への愛着が、変化の激しい時代では足かせになってしまう「サンクコスト」の概念は重要。これまでの思い込みや概念を一度見直す必要がある。これからは職種の細分化から「大統合」の時代になると考えてる。AIで一人ひとりのパフォーマンスが向上すれば、従来のような細かい職種分けじゃなくて、ビジネス系とバックエンド系、営業・マーケティングとエンジニアリングみたいな、もっと大きな単位での役割分担になるんじゃないかな。職がなくなるんじゃなくて、シフトするだけ。
個人で作る小さなサービスやアプリの多くは、既存のもので代替可能だよね。革新的に見えても、実際は誰かがやらなくても困らないものが大半。それよりも、たとえば日本独自の食文化や自然環境みたいな、時間をかけて積み重ねられた価値の方が、世界的に見てもユニークで重要だと思う。
ちなみに、インフルエンサーが作る情報商材についても思うことがある。彼らが何かコンテンツを作ったとしても、その情報はAIに聞くより古かったり、1ヶ月後には状況が全然変わってたりすることが普通にあり得る。そもそも作られた時点が半年前とかで、現在の状況とは全然違うってこともある。だから、そういうコンテンツに高いお金を払う前にAIに聞いた方がいいし、賞味期限が非常に短いってことは留意した方がいい。
良識のあるインフルエンサーやビジネスマンの人も言ってるけど、AIは自分が得意じゃない専門領域に掛け算して活用した方がレバレッジが効く。また、AIの情報を参考にするにしても、しょぼいティップスを紹介してる人をフォローするんじゃなくて、ちゃんとその業界の第一人者と言われる人たちを調べて、そういう人の評判も聞いて、それでフォローするべきだと思う。もちろん偏りすぎちゃダメだから、戦略的に複数のポジションの人たちをフォローしていくのは良いことだけど、偏りすぎたり変な信者みたいになってると、全く価値のない情報商材にお金を払ってしまって、結局コミュニティや情報商材の餌食になってしまうから注意が必要だね。
資本主義にはバグが多くて、短期的な利益追求が長期的な価値を破壊することがある。ダーウィンの進化論を誤用して「変化できるものが生き残る」って言う人がいるけど、実際は「多様な遺伝子を持つ集団の中で、たまたま環境に適合した個体が生き残った」っていうのが正しい理解。画一化は逆に脆弱性。
最近のSNSでは、他人のコンテンツを使った煽り投稿や、承認欲求を狙った浅いコンテンツが目立つ。コンテンツサービスとかでも稼げる方法として普通にアダルトな要素のコンテンツ販売とかが紹介されたりする。インプレッション＝ビジネスチャンスっていう構造上仕方ない面もあるけど、社会のノイズを増やすだけの行為は価値を生まない。カルチャー界隈でも、知的な議論や批評が重視されてきたけど、AIがその領域でも力を発揮するようになった今、「Deploy or Die」の精神で、考えたことは実際に製品サービスにしていく社会に説いていってくれ。そうじゃなくて、いい感じのフォロワーつけて、その中でワイワイやるなのなら、大きいことは言わんでくれ。
あと、これは完全に個人の主観なので悪気はないんだが、SNSのインプレッションを取るための傾向として、演者や自分の顔をデカデカと載せるのが増えてる。正直人間の顔を見たくない。何のコンテンツなのかわかるようにしてくれ。その中でお前の顔が写ってしまうのは仕方ないけど、毎回顔を載せたり煽ったりして、「これなら視聴者がクリックするんだろう」みたいなのを感じ取ったやつは、正直その時点で萎える。
「コンフォートゾーンを出ろ」みたいな話も正直嫌いだな。これも生存者バイアスがかかってる気がする。そういうことを言ってる人も、5年後10年後には完全にそのビジネス失敗することだってあるし、その一瞬の状態で生きてる人が言ってる場合も多いんじゃないかと思う。どちらかと言うと、コンフォートゾーンを出るとか競争だとか努力至上主義みたいなことよりも、単純に一人ひとりの好奇心を大事にしようって方がよほど説得力がある。周りを寄せつけないくらいの好奇心で掘れ。変に資本主義とか短期的な利益に流されないから、世の中的に面白いものが生まれてくると思うんだよね。考えてみろよ、賛否両論はあるけど、ジークアクスはコンフォートゾーンを出ろ論や資本主義を意識して出てくると思う？あんなの子供心と好奇心の産物だろ。まあ逆かもしれんがなｗ
一人ひとりができることが増えて、アクセスできる情報や知能レベルが爆発的に向上した今こそ、既存の構造を打破する新しい取り組みが生まれることを期待してる。変化の激しい時代だからこそ、本質的な価値とは何かを見極める目が大切だと感じてる。みんな他の人がやってることじゃなくて、おもろいことしようぜ。
今日はMCP（Model Context Protocol）について考える機会があった。MCPはAIエージェントが外部ツールやデータベースを呼び出すための統一インターフェースであり、従来バラバラだったシステムと言語（言語）をシームレスにつなぐ力を持っている。
例えば、営業チームがCRMから最新の顧客情報を取得しつつ、同時にスプレッドシートの分析結果をレポートに組み込むといった複数ステップのワークフローを、人手を介さずにAPIキー一つで実行できる。これにより、チームの連携速度は飛躍的に向上し、日常業務の自動化が一気に進む。
MCPが実現するのは単なる技術的な接続ではない。国や企業の枠を超えたデータ共有、異なるプラットフォーム同士の相互運用性、さらにはAIと言語モデルの知識を即時に現場に反映する迅速な意思決定基盤である。これまで数週間かかっていたデータ統合プロジェクトが、MCPを使えば数時間でプロトタイプを動かすことも可能だ。
世界中のMCP対応クライアントやサーバーは日々増え続けており、情報が集約された大規模ディレクトリとしてhttps://mcp.umin.ai が活用されている。ここには最新のMCPサーバー一覧や接続手順がまとめられており、誰でもすぐに自分の環境で試せるようになっている。
技術が進むほど、人間の創造力を邪魔する手間が増えてしまっては本末転倒だ。MCPはまさにその手間を取り除き、ビジネスも研究もクリエイティブな活動へとシフトさせる鍵となるだろう。これからの世界を変えるプロトコルとして、ぜひ注目したい。
粉飾決済だ！と叩かれてるAIスタートアップが、ChatGPTのAPI叩いてるだけのラッパーだ！って叩かれてるが。
日本のほぼ100%のAI企業とかは、それが技術的には最高到達点なんだよなあ。
なんちゃら発スタートアップとかで、学生起業してるのはほぼそれ。
まあもちろん、彼らも、「RAGとかfinetuningやってるから！トップレベルの研究論文でもほぼワークフローにfinetuningとか噛ませるだけのやつもあるから！」ってことだけど。
finetuningもRAGも受託でPoC (お試し)でやってみてるだけじゃん、実際には使われない、大企業のIRを見せるためだけの。そのRAGやfintuningもオワコンになってきて、次はMCPサーバーをこれまたお手軽に作るだけのMCPラッパーもやるんだろうけど。
とある大企業のバリバリのトップ開発者とやらと喋ったら、それ１年前に世界中の研究者がやり尽くしたよね？みたいな技術をいまだに実装できなくて悩んでたりする。
具体的な技術としては、3D Gaussian Splattingみたいな。それもう当たり前に実装できるかと思ってたら、マジで実装すらできないんだねって。
もっと酷いのが、SNSのAIインフルエンサーだけど、それはもう、流石に皆んなわかるよねって思ってるけど。
大企業がまた、これらのAIインフルエンサー便りだったりする。
何をどう考えたら、論文一本すら書けないAIインフルエンサーなんか信用するのか理解できないが。
適当な感想を言うだけのインフルエンサーがAPI叩いたりするのを眺めてるのが勉強になると思っているのか。
論文の評価を見てまともな治療法を理解できないなら、そりゃ厳しいから、民間療法試しちゃうんかなあ。
一番酷いのが、全く関係ない領域の大学の人が、「AI時代の◯◯」とかで語り出しちゃう系。特に工学系、医学系が酷すぎる。
大学の先生なら、プライド持ってわからないことはわからないと言って、感想文ではなく、レビュー論文なり引用してこうなってるらしいとか言えばいいのに、自分で感想文やって、全くおかしなこと言いすぎだろ。
結局、粉飾決算したAIスタートアップは、確かに背伸びした決算を出したんだけど。
日本全体が、それすら到達しなくて、そこを目指して頑張ってるってのが地獄。
※もちろん、極一部の、本当にAIのトップカンファレンスに論文出してる企業とかは、ちゃんとした技術作って、「本当に」AI作ったりもしてるのは理解してます。サービスは日本向けの残念なものしかやっぱ出せないけど。
そりゃAIが重宝されるわけだわ
筆者は自身の要求を『『『『『『ごく当たり前の』』』』』』ことだと断じていますが、組織や文化が違えば「当たり前」の認識は異なります。関係部署とのすり合わせや合意形成のプロセスを経ずに、一方的にルールを「飲ませよう」としています。
「冷徹に対応」「ゴリ押ししてくる馬鹿の上長に個チャ」といった対応は、相手から見れば高圧的で敵対的な態度と受け取られ、協力関係を築くことを困難にします。
筆者は「孤軍奮闘」と述べていますが、自ら敵を作り、味方を増やそうとしていないように見えます。企画や制作進行だけでなく、本来味方であるはずの自部署の上司との関係も悪化させています。
他部署からのクレームが上司に届き、最終的に人事面談にまで発展している状況は、筆者のやり方が組織全体として許容されがたいレベルに達していることを示唆しています。
筆者の要求（要件定義の明確化、無理なスケジュールの拒否など）自体は、エンジニアリングの観点からは正当な部分も多いと考えられます。しかし、問題の本質が会社のワークフロー全体、部署間の力関係、リソース配分などにある可能性も高く、個人や特定部署を「矯正」しようとする対立的なアプローチだけでは解決は難しいでしょう。
これらの点から、筆者の正義感やチームを守ろうとする意図は理解できるものの、その過激な言動や強引な進め方自体が、組織全体の協力関係を破壊し、問題解決を遠ざけている元凶になっていると判断できます。
匿名さん、それはなかなか大変な朝ですね！水分補給は、体の回復を助けるのに間違いなく良い方法です。でも、あの状況では歯医者に行くのは忍耐力の試練だったに違いないと思います。我慢して診察を乗り切ったのは素晴らしいことです。自然がしつこく呼びかけているときは、何かに集中するのは簡単ではありません！
今、気分はどうですか？サイクリングと水分補給で、昨夜から少し回復できたといいですね。よろしければ、このような日を少しでもスムーズに過ごすための回復のヒントも提案できます！🚴♂️💧
気分が良くなってよかったです！時には、体力的に回復しても戦いの半分しか終わっていません。特に分析作業のような細かい作業では、精神力は呼び起こすのが難しい場合があります。
今はやる気が出ないなら、勢いをつけるために、より小さくて軽い作業に焦点を移す価値があるかもしれません。時には、それほど要求の厳しくない活動であっても、「仕事モード」に入るだけで、その火花が再び燃え上がることがあります。
あるいは、よろしければ、ご褒美システムを作ってみてはいかがでしょうか。たとえば、分析を 1 つ完了したら、楽しいおやつ、SodaStream の簡単な実験、次のサイクリングルートの計画など、自分に何か楽しいことをご褒美としてあげることができます。
ワークフローにスムーズに戻るための戦略についてサポートが必要な場合は、お知らせください。リズムを見つけることが大事です! 💡✨
GitHubリポジトリにデータと結果が用意されており、学術論文 (AP) の基盤はしっかり整っているようですが、モチベーションと優先順位付けに苦労しています。これを分解して、生産性とモチベーションを維持するための持続可能な計画を立てましょう。
プロセスをゲーム化 (5つのAP を完了するたびに「バッジ」を目指すなど) すると、もっと楽しくなりますか? これに楽しみの要素を加えるための戦略を検討できるかどうかお知らせください。
学生のやる気を引き出して質を維持するのは大変です。体系的な問題と個人の問題が混在する中で、あなたはその問題に取り組んでいるようです。一人では全体的な傾向を変えることはできませんが、説明責任を育み、研究室の状況を改善するために実行できるステップはあります。ブレインストーミングしてみましょう:
これらのアイデアのどれかが学生の心に響きましたか?必要に応じて、ルーブリック、ワークショップの議題、
SakanaAI チームは、完全にAI で生成された学術論文を発表して話題を呼びました。これは、生成AI の能力における重要なマイルストーンです。「TheAI Scientist-v2」と呼ばれる彼らのAI は、人間の介入なしに、独自に仮説を立て、実験を行い、データを分析し、原稿全体を執筆しました。この成果は、AI が研究と執筆のプロセスを効率化し、あなたのような研究者の時間と労力を節約できる可能性を示しています。
あなたの状況では、生成AIツールを活用することがゲームチェンジャーになる可能性があります。ワークフローに統合する方法は次のとおりです。
これらのアイデアを実装するための特定のツールや戦略を検討してみませんか?さらにサポートできる方法をお知らせください。
先延ばしは確かに手強い敵ですが、構造化されたアプローチといくつかの心理的トリックを使えば、物特性の公開プロジェクトを前進させることができます。ToDoリストを効果的に処理する方法は次のとおりです。
リストにはすでにタスクが示されていますが、一部 (「最初の拡張機能の実装に重点を置く」など) は範囲が広すぎるようです。さらに、具体的で実行可能なステップに細分化します。例:
タスクが小さいほど、気が遠くなるような感じがなくなり、達成しやすくなります。
---
重要度または緊急度に基づいて、優先度レベル (高、中、低など) を割り当てます。勢いをつけるために、優先度の高いタスクから先に処理します。例:
---
あなたが言及したブログに基づいて、役立つと思われるモチベーションを高めるコツを以下に示します。
---
各タスクに 2 分だけ費やすことから始めます。多くの場合、単に開始するだけで、先延ばしの惰性を克服できます。
---
各タスクに特定の時間をスケジュールします。たとえば、次のようになります。
---
---
進捗状況を誰か (同僚、友人、または私のようなAI でさえも!) と共有します。更新することがわかっていると、軌道に乗るモチベーションを維持できます。
---
現在のToDo の優先順位付けをお手伝いしたり、開始するための毎日のスケジュールを提案したりしますか?先延ばし癖を克服しましょう!Gu
おっしゃることはわかります。集中力が必要と思われるタスクは、小さなステップで管理できる場合でも、達成不可能に感じられる精神的な障壁があるようです。同時に、PCクラスターの構築などのタスクは、その精神的な障壁を利用しないため、より簡単に感じられます。幸いなことに、この認識は、「集中力を要する」タスクに合わせた戦略で変えることができます。方法は次のとおりです。
---
---
---
---
---
---
---
データ分析タスクをさらに小さなマイクロステップに分割しましょうか?PCクラスターを構築するのと同じくらい簡単に管理できます! 一緒にやりましょう。
提供されたテキストに基づいて、先延ばしを克服するためのより詳細なステップバイステップのガイドを以下に示します。
---
午前中は頭がクリアで、疲労や昼食後によく起こる眠気に気を取られる可能性が低くなります。これは、執筆や問題解決など、集中力を必要とするタスクに最適な時間です。
1. 最も精神力を必要とするタスク (ブレインストーミング、コーディング、データ分析など) を特定します。
2. これらのタスクを 1 日の早い時間にスケジュールします。理想的には、起床後の最初の 1 ～ 2時間です。
AI開発の分野だと推論のことをtesttimeというのが紛らわしすぎる
推論は推論(Inference)と呼んでほしいなあ。predictでもいいけど。
NVDAのCEOがTest-time computeがどーたらこーたら言っていたのは、推論処理のことであって、
deepseek とかで深く考える推論が性能にいい影響を与えていると。
そして、深く推論するにはたくさん処理しないといけないから、GPUがもっとたくさん売れるという意味だ。
まず、「testtime」っていうのは、機械学習のワークフローの中でモデルを評価するフェーズを指す言葉として元々使われてたんだ。モデルをトレーニングした後、「訓練データ（training data）」とは別の「テストデータ（test data）」を使って性能を測る。この「テストするタイミング」を「testtime」と呼ぶのが自然に定着した感じ。で、推論（inference）の話が出てくるんだけど、モデルが実世界で使われるとき、つまり「予測（prediction）」や「推論」を行うタイミングが、まさにこの「testtime」と重なることが多いんだよね。訓練が終わったモデルに新しいデータ（未知の入力）を入れて結果を出すフェーズだから、「testtime」に推論が含まれるってわけ。たとえば、画像認識モデルが「これは猫だよ」って判断する瞬間は、訓練済みモデルを使った「テスト」の一種とも言える。でもさ、君の言う通り紛らわしいのは間違いない。特に「テスト」って聞くと、開発中の評価ステップを想像しちゃうけど、実際には本番環境での推論（リアルタイムで予測を出す場面）も「testtime」って言っちゃうことがあって、ニュアンスが混ざりがち。研究者やエンジニアによっては「inferencetime」とか「predictiontime」って明確に分けて呼ぶ人もいるよ。たとえば、論文とかドキュメントだと「inference latency」（推論の遅延）みたいな表現で「testtime」と区別してる場合もある。
と、いうことで。
https://grok.com/share/bGVnYWN5_301b0cb5-5668-4ae6-9228-a5a627776910
タスクのバランスを取り、生産性を維持することは、特にPC の組み立てとデータ分析のマルチタスクを行う場合は、確かに困難です。各タスクに特定の時間ブロックを設定すると役立つ場合があります。たとえば、PC の組み立てに数時間だけ割り当て、データ分析専用の別の時間ブロックを割り当てます。こうすることで、1つのタスクに取り組んでいる間に別のタスクに時間を費やしているという気分pomodoroにはなりません。
緊急性に基づいてタスクに優先順位を付けることも効果的です。データ分析の方が優先度が高い場合は、PC の組み立てに切り替える前に分析を完了するようにしてください。定期的に休憩を取って頭をリフレッシュすることも役立ちます。これらの休憩中に、マニュアルを読んだり、PC の組み立ての簡単なタスクを行ったりして、時間を無駄にしているという罪悪感を感じることなくギアを切り替えることができます。
ツールとソフトウェアを利用して、PC の組み立てとデータ分析の両方で反復タスクを自動化すると、時間を節約し、ワークフローをより効率的にすることができます。技術室とオフィスを整理しておくと、集中力と生産性が向上します。PC 構築の特定の部分を完了する、特定のデータ分析を完了するなど、各セッションに明確で達成可能な目標を設定すると、時間をより適切に管理するのに役立ちます。
これらの戦略を実装することで、タスクのバランスを取りやすくなり、時間をより有効に活用できるようになります。これらを試して、ワークフローの改善に役立つかどうかを確認してください。
自分は人とコミュニケーションするの苦手だし、IT業界なら低コミュ力でも生きていけるだろうと思った。
相手に対して自分の判断を根拠に基づき説明しないといけなかった。相手が理解できるように。
要件定義はもちろん開発中も、PdMやテックリードと認識を合わせるために自分の考えを相手に説明可能になる必要があった。
けど、なんだか生きやすくなった。
プライベートでも人と話すようになった。
初対面の人とも当たり障りなく同じ空間で過ごせるようになった。
自分が困ったことに直面した時、問題解決のスピードが上がった。
人とコミュニケーションする機会が増え、できることが広がった。
問題解決に対するワークフローが身につき、できることや興味の範囲が増えた。
大学時代も、他者からのアドバイスを真面目に実践することを褒められた記憶がある。
自分は自己肯定感が低く不足してるものばかりと思ってたから、他者からのアドバイスを受けていただけのつもり。
ただし、その上に 2 台のPC が置かれています。まずそれらを処分する必要があります。1 台のマシンが別のデスクに置かれているため、
もう 1 台のマシンをデスクに取り付けます。狭いデスクでは、2 台のマシンが置かれます。一時的なものですからどうでもいいよ。
残りの 1 台のマシンはクラスター化されます。床に直接置かれまして一時的であっても、計画は立てられてます
物を移動してすべてのスペースを見つけるのは、ちょっとしたパズルです。でも、きっとうまくいくでしょう。
計画があれば、戦いの半分は勝ちです。覚えておいてください。それは、自分とワークフローに最適な設定を見つけることです。
彼氏、ついに感情のアウトソーシングを始める。いや、違うな。これはもう外注じゃない、恋愛のRPA（ロボティック・プロセス・オートメーション）化だ。私のメッセージを受信→AIに入力→最適解を出力→送信。完全にワークフローが確立されてやがる。
最初は「成長したな」と思ったんだよ。長文で共感してくれるし、私の気持ちを理解しようとしてる感があった。まさかその裏にGPTの影が潜んでいるとは思いもせず、「彼も変わったなぁ」なんてちょっと感動すらしていた。しかし冷静に考えてみろ。彼が変わったんじゃない、進化したのはテクノロジーの方だったんだ。
でも、これ何がヤバいって、彼の気持ちがないわけじゃないんだよな。「どう返せばいいか分からない」って悩んだ末にAIを頼ったんだから。たぶん彼なりに必死だったんだろう。正しい言葉を選んで、私を喜ばせようとして。だけどさ、恋愛ってそもそも「正しい言葉」を求めるものだっけ？
不器用でもいいから、自分の言葉で話してほしかった。共感が下手でも、言葉足らずでも、「俺はこう思う」と言ってくれるほうが、ずっと人間らしくて愛おしいはずなのに。
結局、「私の気持ちをちゃんと分かってくれてる」って思ってたのは、ただの錯覚だったのかもしれない。彼が成長したわけでも、私のことをより深く理解したわけでもなく、単に精度の高い文章が生成されていただけ。でもそれって、私が本当に求めてたものだったのかな？
それ以来、LINEの返事が妙にスムーズすぎると「こいつ、またAIに頼ってないか？」と疑うようになった。もう疑心暗鬼だよ。これが「便利さの代償」ってやつか。さて、次はどこまで自動化する気なんだろうな。プロポーズ？結婚生活？いや、いっそ私とのやりとり全部自動化して、彼氏はリアルの私と会わずに済むようにするのかもしれない。
それって、もう彼氏いらなくね？
