超動く家にて - 社会学的ラブソング・改
今週のお題「最近読んでるもの」 小説とか怪談とか。 メンタル的な体力（？）があんまり無いので、実話怪談集やSF・ミステリーの短編集が大変有難い。 「超動く家にて」（宮内悠介／創元SF文庫）読んだ。 超動く家にて (創元ＳＦ文庫) 作者:宮内 悠介東京創元社Amazon祝・「トランジスタ技術の圧縮」ドラマ化、という事で。 「世にも奇妙な物語」って、そういう話もやるんだ・・・柴田さんの「走馬灯のセトリは考えておいて」もやるらしいし。 「トランジスタ技術の圧縮」ってどういう話かというと、「トランジスタ技術」を圧縮する話である。 しかも競技化してる。 圧縮するだけで、其処までドラマチックに動いていくのか、と。 「超動く家にて」は確かに超動く家だし、「文学部のこと」は文学部の話だし、「犬か猫か？」は犬か猫か議論する話である。 ・・・確かにそうなんだけど、ちょっと違う。 超動く家も文学部も、言葉をじゃ
HonoとDenoで社内ツールを作ってみた - RAKSUL TechBlog
こんにちは！ラクスルの灰原です！ 軽量かつ高速なWebフレームワークであるHonoと、新進気鋭のJSランタイムであるDenoを使って、社内ツールを作ってみましたので紹介します。 作ったツール 技術スタック index.tsx の内容 Tips HonoでTwindを使う HonoのJSXでAlpine.jsを使う Hono+Denoでesbuildを使う おわりに 作ったツール テックブログ向けのアイキャッチ画像ジェネレータを作りました。 タイトルを入力して、 背景画像と文字色を選んで、 文字の位置と大きさを調整して、 後は「Download」ボタンを押せば画像が手に入ります。 これは以前、弊社デザイン組織で作られた「Zoom背景ジェネレータ」に多分に影響されています。 こちらのデザイナーブログも是非ご覧ください！ note.com 技術スタック このツールは利用頻度がそこまで多くないと思
生成AIの新システム開発 安全性確認などのルール作り検討 政府 | NHK
生成AIの利活用をめぐり政府は、事業者が新たなシステムを開発する際に安全性が保たれているか確認するため外部監査を行うなど、具体的なルールづくりの検討を進めていくことになりました。 生成AIの利活用をめぐっては、著作権侵害や犯罪への悪用などといったリスクも指摘されていることから、政府は7日の有識者会議で今後の対応策を協議しました。 そして、事業者が新たなAIのシステムを開発する際に安全性や透明性が保たれているか確認するため第三者による認証や外部監査を行うなど、具体的なルールづくりの検討を進めていくことになりました。 また、不正なAIのサービスが提供されれば財産や生命に関わるリスクが生じる可能性が高い分野として金融やエネルギー、それに運輸や医療などを例示し、こうした事業者への規制の在り方を議論することも確認しました。 さらに新たなシステムの開発に省庁などが持つデータを積極的に活用してもらおうと
［速報］GitHub、組織のコードやドキュメントを学習しカスタマイズやファインチューニングが可能な「Copilot Enterprise」発表。GitHub Universe 2023
［速報］GitHub、組織のコードやドキュメントを学習しカスタマイズやファインチューニングが可能な「Copilot Enterprise」発表。GitHub Universe 2023 GitHubの年次イベント「GitHub Universe 2023」が米サンフランシスコで開幕しました。 1日目の基調講演で、Copilotが組織のコードやドキュメントを学習することで、カスタマイズやファインチューニングが可能になる「GitHub Enterprise」が発表されました。 Copilot Enterpriseは、外部に公開されていない組織内のコードやドキュメント、プルリクエストなどを追加でCopilotに学習させることで、組織内のコードベースに基づいたCopilotによるコードの生成や、Copilot Chatでの質問に対する回答が可能になるというものです。 さらに言語モデルそのものを組織
【入門】要件定義
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
OpenAIのCEO、「GPT-5」の開発には「困難な課題」--ハードウェアの可能性にも言及
OpenAIの大規模言語モデル（LLM）プログラムの次期バージョン、通称「GPT-5」は、非常に困難な科学的課題に直面しているため、リリース時期について明確なスケジュールを設定するのは難しいという。同社の最高経営責任者（CEO）Sam Altman氏が米国時間11月6日に明らかにした。 サンフランシスコで開催された同社初の開発者会議「OpenAI DevDay」後の記者会見で、同氏は「GPT-5と呼ぶモデルを開発する前に、われわれが解決しなければならないことはまだたくさんある」と述べた。 この発言は、同技術の今後の方向性について出された多くの質問に対し、同氏と最高技術責任者（CTO）のMira Murati氏が回答する中で出たものだ。やり取りの中には、OpenAIが独自の消費者向けハードウェアデバイスを開発する可能性に関する話題もあった。 Altman氏はGPT-5までの道のりについて、「
自分の癖にあったファインチューニング用データセットをLLMで作ろう！【Calm2】
まとめ LLMのファインチューニングにおいて、データセットは重要なものとなりつつある 以前までは人力で作る必要があったが、プロンプトが効く7Bモデル（Calm2-chat）を用いることで、LLMでファインチューニング用データセットを作ることができる データセットを作成しつつ、動的にプロンプトを修正していく手法が相当よかった 導入 LLMのファインチューニングには、大量のデータセットが必要です。良く言われているのは「少なくとも数百～数千はあった方が良い」というものです。翻訳など、皆が使うであろうようなタスクのデータセットは存在する一方で、「女の子の日記をLLMで作りたい」のような、完全に自分の癖に従ったようなデータセットは基本的には存在しません。一から自分で作っても良いのですが、人間の時間とやる気は有限なため、かなり無謀な挑戦と言えるでしょう。 この作業にLLMを用いることで、労力を最小限ま
ビッグモーター支援、ガリバーのＩＤＯＭが検討中止…コンプライアンス欠如が障害
【読売新聞】 保険金の不正請求問題で業績が悪化している中古車販売大手ビッグモーターの支援先探しが難航している。同業大手のガリバーを運営するＩＤＯＭ（イドム）は、８日までに支援しない考えを伝えていたことがわかった。企業体質が改善してい
マネジャーは「組織メンバーの能力と意欲が高い状態」をどうつくり上げたらよいか。
みなさんは自身の組織メンバーの意欲と能力を高めることができていますか？ 多くの企業へのコンサルティングに携わってきた経験から、成長する組織の重要要素は次の5つのポイントであると実感しています。 競争優位性のある戦略があり組織に浸透している 組織メンバー個々の能力と意欲が高い 組織内相互の関係性が良好である 素早く環境変化をとらえ対応できている（定期的な改善行動がとれている） 今の成長の柱だけでなく、次の成長の柱を仕込み続けている 今回は要素2である、育成において「組織メンバー個々の能力と意欲が高い状態」をミドルがどうつくり上げていくか、そこに潜む矛盾とは何で、どう乗り越えていくのかを考えていきたいと思います。 能力と意欲を高めるには上司の支援が重要 有名な「ロミンガーの調査」では、人が育つ要素の7割は仕事の経験、2割が上司などの薫陶、1割がOFFJTなどの研修と言われています。つまり、育成
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
不確実性や心理的安全性に向き合い自己組織化するチームを作る実践プラクティス
こんにちは。Gaudiyでソフトウェアエンジニア兼スクラムマスターをしている Namiki ( @ruwatana ) です。 「チームが向き合う不確実性が大きいと手戻りが増えて価値提供のリードタイムが遅くなる」 「チーム内の心理的安全性の低さや認知負荷の高さによってエンゲージメントが低下して従業員がオンボード・定着しにくい」 ... などなど、昨今のチーム開発はこうした課題で溢れかえっていることかと思います。 結局のところ、我々は具体的にどんなプラクティスを行うことで、こうした課題を解決できていくのでしょうか？ 本稿では、筆者と筆者が4ヶ月ほど前に配属することになったチームがこうした問題に対して執ったアプローチおよびその効果をより具体的に示すことができればと考えています。 プロダクトチーム開発を行う皆様に何かしらの参考になれば幸いです。 1. チーム構成と特性 2. 特性が生み出しうるリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「40歳で何者にもなれなかった人」こそボンヤリ生きた方が幸せになれるワケ
106万円の壁 130万円の壁【解説】国の支援策で希望通り働ける？ | NHK | WEB特集
AIが「言語生成AIとの対話」で賢くなり続ける自動成長モデル 米Meta含む研究者らが開発