はじめに以降の写真は全て私が撮影したものどうも、「AIは学習しない。」イコラです。 医師を辞めて、AI・スタートアップ界隈に来てからもう少しで3年になります。 「石(医師)の上にも3年」ということで、ここらでスタートアップやAI業界について振り返ってみようかと思います。 自分自身はAI業界に転身したつもりなので「スタートアップ界隈」という認識は薄いのですが、やっていることは「ザ・スタートアップ」なので、何かの参考になれば幸いです。 ※よく聞かれますが、医療AIはほとんど開発していません。ずっと画像生成、音声合成、大規模言語モデルといった、エンタメやディープテックに近い領域で戦ってきました。toBよりもtoC寄りです。 1. 医師から「虚構」の世界へ医師からこの業界に来て、最初に食らった洗礼は「言葉の重みの違い」でした。 医療の世界では、正確性とエビデンスが命です。「この手術、たぶん成功する

ダイヤモンドの↓の記事が盛りすぎでブクマカが釣られまくっているので、ちょっと落ち着けという意味で少し解説する フリック入力を発明して「人生100回分」稼いだ日本人がAppleじゃなくてMicrosoftに特許を売却したワケ https://b.hatena.ne.jp/entry/s/diamond.jp/articles/-/374568 普通の人が「フリック入力を発明」というフレーズを見たら、どっちを想像する? 1. 上下左右方向のフリック操作で文字入力する手法を考案した 2. 1を改良し、入力効率を向上させる工夫を考案した 普通は1を想像するよね。でも、上の記事の「発明」は2の意味。8割くらいのブクマカはここを勘違いしてコメントしてるように見える 同じ発明家氏の記事でも3ヶ月前の東洋経済のほうは、「フリック入力を発明」という釣りフレーズこそ使っているものの本文を良く読めば発明のキモの

Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志

いわゆるエンタープライズ向けソフトウェア開発技術者向けにお勧めする本をまとめてみた、というか10年くらい前に書いた記事を見直したもの。後輩から「後輩に勧めたい本を教えてください」という相談を受けることがあって(白目)記事が古くなっていたことに気づいたのだった。10年前の記事と同様にSIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。なお学生、新人、初心者向けにはなっていないのであしからず。 10年以上前に書いた記事はこちら agnozingdays.hatenablog.com ソフトウェア開発ライフサイクル全般IPA 応用情報処理技術者試験プロジェクト管理 デッドライン 人月の神話 アート・オブ・プロジェクトマネジメント 見積もり ソフトウェア見積り ~人月の暗黙知を解き明かす~アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と
ソフトウェア開発の現場が日々感じている問題は、しばしば組織設計の不備を映し出す鏡である。 そうであるなら、現場で営まれる改善に向けた努力は “対症療法” にしかなり得ない。一時的に症状を緩和できても、しばらくすれば問題はぶり返す。現場はそれを再び抑えにかかる。これではまるで、終わりのないモグラたたきだ。 組織設計の改善による “原因療法” が必要なのだ。もちろん対症療法も必要ではある。しかし、根本原因を取り除かなければ、そこから生じる問題が現場を苦しめ、ソフトウェア開発の足かせであり続ける。それはビジネスの足かせでもある。 だから、組織設計に携わるマネージャーには、現場に現れる症状から組織設計上の問題を読み解く力が問われる。そして、現場のチームも巻き込んで、組織の欠陥修正や、組織のリファクタリング、リアーキテクティングに取り組むのだ。 参考資料 組織設計のひずみは現場に問題をもたらす 例1

家業「テキストエディタ」。EmEditor開発者は、息子の決意を初めて聞く【フォーカス】 2025年9月1日Emurasoft, Inc. 代表 江村 豊 兵庫県生まれ。筑波大学大学院工学研究科修士課程修了。インテルジャパン株式会社を経て、1994年に汎用通信ソフト「EmTerm」を開発。1995年8月に有限会社エムソフトを設立。1997年にテキストエディタ「EmEditor」の開発を開始した。2000年に米ワシントン州レドモンド市でEmurasoft, Inc.を設立し、2001年に現地へ移住。Emurasoft, Inc.エンジニア 江村 誠 日本生まれで、5歳の時に米国に移住。豊氏の長男。10代の時に、ゲームをきっかけとしてプログラミングに親しむ。2018年、米ベルビューカレッジの学士課程で情報工学を学び始め、同時にEmurasoft, Inc.にパートタイムで参画。2022年

はじめに 生成AIを使ったコード開発が急速に普及している。GitHub Copilot、ChatGPT、Claude、そして各種IDEに統合されたAIアシスタントや独立したコーディングエージェント。これらのツールは開発効率を飛躍的に向上させ、もはやAIなしでの開発は考えられないという声も聞こえてくる(主に心の底から)。 しかし、この革新的な変化の中で、看過できない問題が顕在化している。現在のAIで生成したコードは、2年後の進化したAIで再生成すれば、より効率的で保守性の高いコードに置き換えられる。これ自体は技術進歩として歓迎すべきことだが、重要な情報が失われている。 それは「なぜそのコードをそのように実装したのか」という意思決定の記録だ。 この問題は単なる技術的な課題ではない。私たちがどのようにソフトウェアを作り、保守し、進化させていくかという、エンジニアリングの本質に関わる問題だ(そして
AI によるコーディングの支援はコード補完型からチャット型、そして自律型へと進化しています。この記事では現時点で主流となっているコーディングエージェントの種類とその特徴を整理したうえで、エンジニアの仕事の変化について考察します。 コーディングの仕事におけるAI技術の関わりといえば、GitHub Copilot を代表するエディタ補完型が主たるものとして認識されてきました。補完型のAI はユーザーが途中まで書いたコードを補完する形で提案を行うことから、ペアプログラムの相方のような存在として捉えられていました。例えば function add と書き始めると、AI は (a: number, b: number): number { return a + b; } といった形で関数の定義を提案します。ユーザーは Tab キーを押すことで提案を受け入れたり、提案が気に入らなければそのままコ

急速に進化する大規模言語モデル(LLM)を、視覚的に理解しながら実践的に学べるハンズオンガイド。本書では、JupyterNotebookやクラウド上で実際にモデルを動かしながら学ぶことができます。大規模言語モデルに欠かせないTransformerの仕組みをはじめ、要約、セマンティック検索、テキスト分類、クラスタリング、RAG(検索拡張生成)といった技術も、図解とともに直感的に理解できます。豊富なコード例と既存ライブラリの活用法を通じて、直感を重視したアプローチでLLMを学びたい読者に最適な一冊です。 賞賛の声 訳者まえがき まえがき 第I部 言語モデルの理解 1章 入門大規模言語モデル 1.1 言語AIとは? 1.2 言語AIの近年の歴史 1.2.1 Bag-of-Wordsによる言語の表現 1.2.2 埋め込みによる言語の表現 1.2.3 埋め込みの種類 1.2.4 注意機構による文脈

ビルゲイツは人と話をするのがとても好きです。そのスタイルもビルゲイツが一方的に喋るようなスタイルではなく、相手の話を引き出し自分の意見を述べ、一緒に考え相手が見つけた解に何か自分が協力できることはないかと提案するそんなスタイルで誰とでも会話をします。 マイクロソフトの日本法人ができた1986年から数年の間は年間に2回から3回ほどビルゲイツは日本を訪問していました。パソコンを生産されている企業訪問や取材だけではなく、秋葉原に出かけたり、マイクロソフトの社員とあらゆる会議に出席したり、社員との懇親パーティにも参加したりして、それこそ社員の一人ひとりと会話を楽しんでいました。ある社員がビルゲイツに近づいて名前と所属部署を語ったときのことです。ビルゲイツ君は「そう、頑張ってね」なんてありきたりの対応はしません..その時はこんなパターンでした.. ビル:「今どんな仕事をしているだい?」 社員:「私は

免責事項 この文章はAIを使わずに人間(GOROman)が書いたので誤字脱字が多いです。読みにくい点などございますがバイブス感を大事にしたいためご了承ください。 その2 Qmanというやつに唆そそのかされて、ヤツの車ランサーエボリューションで拉致られて東京へ向かう。持って行ったのはまだあどけないローンが残るノートパソコンMN-7250 Mebiusだけだ。深夜の東名高速道路で名古屋を経由して東京に。住んでいた下宿も放置。研究室の先生にも何も言わずに失踪する。今思えば色々なんかやっていたが全て放置してしまう。すいません。 上京してゲーム会社にバイトで入る。学校の籍は残したまま。 「これからはインターネットの時代だ!!」とシェアウェアで稼いだり、Sunのワークステーション使ったり、むちゃくちゃインターネットとUNIXにハマってたのに何故かゲーム業界に来てしまう。正直失敗した。 月給10万で住み

今や、AIを活用してソフトウェア開発すること自体は一般的になり、一種のブームと化している。 しかし、Web上で見かけるのはワンショットでテトリスを作る程度の小規模なプロジェクトの話がほとんどで、驚けるものの、正直あまり実用性は無いように感じる。 俺たちが本当に知りたいのはテトリスの作り方じゃねえ!現実の中規模以上のシステム開発で、いかに楽に良いものを作れるかだろ! ということで、まずは弊社から現時点のノウハウを全公開しようと思う。 弊社ではCursorを1年以上活用(サービスがGAになったタイミングから全社員で利用)しており、一定のノウハウを蓄積してきている自負がある。ただ、あくまで一例ではあるので、ぜひみなさんの現場での活用事例も共有してほしい! 免責事項AIエディタでの開発は、LLMとAIエディタの進化に伴い、常に変化している。 そのため、この記事で述べる方法論は、現時点での、弊社での

こんにちは、カイテクでエンジニア責任者を務める岩本です。 突然ですが、皆さん、D/D/Dという指標をご存知でしょうか?これは「Deployments/Day/Developer」の略で、開発者一人あたりの一日あたりのデプロイ回数を表し、開発組織のパフォーマンスを測る重要な指標の一つです。 先日、2025年1月のカイテクの開発組織でこのD/D/Dを計測したところ、なんと「1.32」という数値を記録しました。業務委託は稼働時間を(勤務日数x勤務時間8時間)で割った値をEng一人として換算しています。一般的に、D/D/Dが0.1あれば健全な組織と言われるようです。この数字をみてみるとカイテクの開発組織は、極めて高いパフォーマンスを発揮しているようです。 一言断っておきたいのは、私たちはこれまでD/D/Dを意識的に追い求めてきたわけではありませんし、これからも追いかける指標ではありません。しかし、

PayPayの6年の歴史の中で、私たちは急速な成長を遂げてきました。現在、6700万人以上のユーザーにサービスを提供し、日々数百万件の決済を処理しています。しかし、これを成功させるためには、トラフィックと信頼性の要求を満たすための技術的な挑戦が伴います。 PayPayは設立当初からJavaとNodeJSを採用しており、これらの技術は非常にうまく機能してきました。しかし、成長に伴いサービスをスケールアップする必要が生じ、これによりKubernetesクラスターでのCPUとメモリの使用量が増加しました。これにはサーバーコストの増加が伴います。2023年末、私たちはコアサービスでのトラフィックをより効率的に処理する方法を模索し始め、GraalVMやGo、Rustなどさまざまな技術を調査しました。Rustは、その優れたパフォーマンスとメモリの安全性が保証されていることから、PayPayの多くのユ

【PR】 2025.01.10ITニュース 注目企業 データセンターも、クラウドも、ECサイトも……わざわざ自前で用意する必要のないこの時代に、圧倒的自前主義を貫く企業がある。国内売上2位のECサイト『ヨドバシ・ドット・コム』でもお馴染みの、ヨドバシカメラを展開するヨドバシグループだ。 膨大な時間とお金がかかる道をなぜあえて選ぶのか。その理由を、グループ全体のサービスをITで支えるヨドバシリテイルデザインの事業部長・戸田宏司さんは「目先の利益よりも10年後、20年後も愛されるサービスづくりが重要なんです」と語る。 国内家電量販店の中でも売上2位を誇る同グループだが、「10年後、20年後も愛されるサービスづくり」とは一体どういうことなのか。戸田さんに話を聞いた。 ヨドバシリテイルデザイン 事業部長 戸田宏司さん 1982年、小学生時代からプログラミングを開始。1998年、フリーランスとして

昨今、 Cline 等のAI エージェントによる開発支援を試されている方が多いかもしれません。Ubie でも先日から Devin をトライアルしており、生成AIによる開発生産性の向上を模索している最中です。(この様子は下記記事によく書かれています) Devinはアウトプットを考えるとコストが安いとは感じますが、 Cline のようなローカルで動作するエージェントはさらに安く高速動作します。これらがUbie の一定規模になったコードベースで動作するのか、どのようなツールが有力候補となりえるのかを軽く検証してみました。 TL;DR ローカルで動作するAIエージェントはコスト・速度・機能においてかなり活用しうる。今回は Cursor や Roo-Cline を使用して、「一定規模のコードベース」において「テストコード追加や簡単な改修」が数十~数百円程度のコストで実現 できた。ただし現状エン

結果的に1200行を越えましたが。 kilo 成果物はこれ↓ 参考サイトはこれです↓ インスパイア元↓ 感想 C言語は10年ぶりくらいに書いた 進めていくうちになんとなく思い出すことができた 最初にちゃんと授業で学んだ言語なので懐かしく思った Cに出会っていなければプログラミングしてなかったかもしれないので感慨深い しかしこのレベルのメモリ管理は正直たいへん 「この関数で確保したメモリはこっちの関数で開放されるので問題ありません」みたいな この調子でやっていったらバグる未来しか見えない 1000行・1ファイルというコンセプトは良いのだがファイル分けて管理したいナ〜〜と思った 配列や文字列の操作、メモリ管理がやりやすい別の言語で書き直したい Cを書くの大変だな…という感想を持った 速さはともかく他の言語で書きたい もっとimmutableに… お手本よりも行数が増えた 1行のif文などでもブ

カイテクのエンジニア責任者の岩本です 。 カイテクでは高速にリリースすることができています。実測してみたところ、2024年5月の機能のリリース回数は37回でした。当時は短時間勤務の業務委託の方たちがメインでフルタイム換算すると3.5人月程度でした。 (なお私は別の新規システム開発のため未カウント) お客様から不具合を報告された際にも、場合によっては当日中に修正完了の連絡をすることができています。利用者様からはカイテクは改善が早いと声をいただくことも良くあります。下記はその抜粋です。 「見ましたよ!あの機能いいですね!とても便利です」 「カイテクさんは、いつも本当にすぐに新しい便利な機能を増やしていてすごいですよね」 それなりに高パフォーマンスだと自負していますが、次のような体制・運営方針ですすめています。 カイテクでは仕様調整・設計・実装・テストができる自走可能なエンジニアのみでチームを構

Sansan株式会社技術本部 Sansan Engineering Unit 部長 笹川 裕人 大学院でコンピュータサイエンスの博士号を取得後、リクルートを経て、2018年4月にエムスリーへ入社。AIチームでデータ基盤の整備と、バックエンド、クラウドインフラを担当。2023年4月にSansan株式会社へ入社し、現在はSansan Engineering Unit 部長として営業DXサービス「Sansan」の強化を担う。 X Profileインボイス管理サービス「Bill One」や契約データベース「Contract One」など、近年続々と新たなDXサービスを立ち上げているSansan。それに伴ってプロダクト開発組織である技術本部も拡大し、いまや総勢500名のエンジニアと13のチームを抱える大所帯になっています。 一般的にプロダクトの数や組織の規模が急拡大すると、リソースが追いつかず

今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vsアジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く