Android部門トップを務めるサミール・サマット氏は、TechRadarのインタビューで次のように語った。
「私たちは、ChromeOSとAndroidをひとつのプラットフォームへ統合する予定だ。いま人々がノートPCをどのように使い、どんな作業をしているのか、その実態に興味を持っている」
CNETが本件についてGoogleにコメントを求めたところ、同社はサマット氏がX（旧Twitter）に投稿したメッセージを案内してきた。
「私たちは現在、Androidの基盤技術をベースとして、その上にChromeOSの体験を構築している。これによりパフォーマンスを劇的に向上させ、迅速な開発を可能にし、ノートPCとスマートフォンの連携を今まで以上に快適なものにしていく。私自身、とても楽しみにしている」（サマット氏のX投稿）
このたびトゥーヴァージンズグループでは、株式会社秀和システムの出版事業を譲り受けました。今後は「株式会社秀和システム新社」として再出発することをご報告申し上げます。
長年にわたり多くの読者に親しまれてきた秀和システムの書籍を、今後も継続的に提供し、より一層の価値ある出版活動を展開してまいります。
これまで同社をご支援いただいてきた著者様、取引先の皆様、読者の皆様におかれましては、引き続きのご理解とご支援を賜りますよう、何卒よろしくお願い申し上げます。
実際のアプリケーションを見据えるとオブジェクト指向機能の使いどころがないんですよね。
アプリケーション全体にオブジェクト指向が使えるということを謳いながら、実際には単にデータ構造の定義だけになってしまいがち。実際、抽象データ型に継承を生やしたものがオブジェクト指向なので、メソッド付構造体としてデータ構造の定義に使うのが一番有用ということになります。そしてデータ分類にインタフェースをつかう。
ただ、そうすると「データ定義が便利なだけでは」となって「開発がとても素敵になります！」みたいなのとつじつまがあわなくなり、適当にアプリケーションっぽい空気を出しながら「大規模になったら便利なんです！小さいサンプルじゃわからないんです！」と誤魔化すことになります。
じゃあクラス継承は実際にどこで使うんだとなりますが、オブジェクト指向というのは状態管理技術なので、状態のあるところとなります。ただ、状態のあるところというのはアプリケーションの出入り口の入出力部分で、アプリケーションの中では状態を持たずステートレスになります。ということで、なかなかいい感じのサンプルができないということになります。
この手のMakefileを見るたびに次のようなことを考えています。
- そもそもREADMEを充実させる方がよい
- ワンショットで実行するものをいちいち載せたくない
- マシンに依存するコマンドはプロジェクト固有のツールではない認識なので違和感を感じる
- MiddlewareはDockerに寄せたい
複雑なコマンドの組み合わせを定義したいという動機は理解できるが、それが大量に存在している時点でプロジェクト構造やワークフロー自体に根本的な歪みがある可能性が高いように感じています。 「人が覚えきれないからMakefileに記述させる」というより、「本来、そんなに複雑であるべきではなかった設計をMakefileで補っているだけ」になっている危険性がありそうな印象です。
「本来はREADMEを充実させるべき」というのがAIにとっても新規開発者にとっても嬉しい施策だという理解です。 可能な限りREADMEなどのドキュメントをちゃんとメンテナンスしていきたいですね。
この分野の声が大きい人たちと同じように、私も生成AIシステムがソフトウェア開発にどのような役割を果たすのかについて大きな関心を持っています。LLM（大規模言語モデル）の登場は、アセンブラから最初の高水準プログラミング言語への移行と同じくらい、ソフトウェア開発を大きく変えると思います。その後に開発された言語やフレームワークは、抽象化のレベルや生産性を向上させましたが、プログラミングの本質に同じレベルのインパクトを与えるものではありませんでした。しかし、LLMには最初の移行と同程度のインパクトがあると思います。しかも、単に抽象化のレベルを上げるだけでなく、「非決定的なツールでプログラミングするとはどういうことか」という問いを私たちに投げかけています。
私はまだ最高の生成AIツールを本格的に使ったことはありませんが、友人や同僚たちの体験談を聞くたびに、非常に興味をそそられています。これは抜本的な変化であると確信しています。プロンプトで機械と対話するのは、Rubyでプログラミングするのとはまったく別物であり、その違いはFortranとアセンブラの違いと同じくらいです。これは抽象化のレベルが飛躍しただけではありません。Fortranで関数を書いたときには、100回コンパイルしてもまったく同じバグが必ず現れました。しかし、LLMは非決定的な抽象化を導入しているため、プロンプトをgitに保存しても、毎回同じ振る舞いが返ってくるとは限りません。同僚のBirgittaが言うように、私たちは抽象化のレベルを上げているだけでなく、同時に非決定性という横方向にも進んでいるのです。
私たちは仕事でLLMの使い方を学びながら、こうした非決定性とうまく付き合う方法を見つけなければなりません。この変化は劇的なものです。私はワクワクしています。残念ながら失うものもあるでしょうが、私たちがまだ理解できていない新たな価値も得られるでしょう。こうした非決定性の進化は、私たちの職業の歴史において前例のないものです。
秀和システムは7月1日、債務超過に陥り出版事業の継続が困難となったと書店に通知した。それによると「裁判所の手続を用いて弊社出版事業を他の出版社に引き継いでもらう手続を選択する」としている。現在の発行している書籍については「各取次ならびに裁判所の承認を得て、引継先が現状...
コードをきれいにする読みやすくするといった文脈でオブジェクト指向を擁護するのは見当違いだ。そうじゃなくて、ユーザーにとってとても魅力的な、だけど、手続き型では書けるかどうかすらわからないようなソフトウェアをさくっと実現できることにこそ、オブジェクト指向の価値を見出すべきなんだ。
オブジェクト指向的なコードは、それに馴染んだ人にとってはきれいで読みやすく感じられるが、そうでないひとにとっては、却って読みづらく感じられることが多い。だから、コードのきれいさ、読みやすさは、導入理由としてはあまり説得力がないんだ。
そこでは、中国企業のビジネスに一貫する「できるだけ早く失敗しよう（Shift-left testing）」といった思考を理解する必要もありそうだ。このコスト重視の反復志向の取り組みは、中国のファストファッションと同じようにテストプロセスの前倒しを繰り返した結果（Shift-left）、「とにかくまずは市場に出そう。それこそがもっとも効率的なテストだ」になってしまった。
これによって私たちは「最新プロセッサー搭載モデルをめちゃくちゃ早く、しかも驚く価格で！」手に入れられる。もちろん、テスト結果が悪ければブランド価値は毀損する。けど、それに備えてたくさんのブランドを並行で展開しているから、炎上ブランドはひっそり廃止するとか、まあ、どうにでもなるわけだ。ブランドWebさえろくにつくっていないのだから。
身近なアップルは、LTV（Life Time Value、顧客生涯価値）重視の反復志向の取り組みをしていて、私たちはそれに慣れてしまっている。ブランドには価値があり、その維持のために長期的なストーリーテリング、価値観、倫理観、それらを顧客の信頼に結びつける努力を重ねるのが「普遍的な」ビジネス思考だと信奉している。
だから、ブランドとは「使い捨てのために利用」するものであって、ブランドの一貫性やアフターサポートへの配慮ゼロな中華ミニPCの世界はなかなか理解できない。
画像ファイルフォーマットのひとつであるPNGが、22年ぶりに新仕様となる第3版を発表しました。この第3版ではハイダイナミックレンジ(HDR)やアニメーションPNG(APNG)、Exifがサポートされています。
時流に乗ろうというビジネスと、時流を作ろうというビジネスがある。僕がやりたいのは常に後者だ。これはずっとそうだった。
前者が悪いというわけじゃなく、ただ、僕にとってはつまらなく感じられるだけだ。
気象庁が、台風進路予測の精度向上などに向けた技術開発基盤に、さくらインターネットのGPUクラウド「高火力 PHY」を採用する。約25億5000万円の契約になるという。同社が6月25日に発表した。
「Wayland」は、「X11」に代わる新しいLinux向けのディスプレーサーバーであり、より現代的で安定性が高く、安全性にも優れている。Waylandは、描画性能の向上、複雑なGUIのより効率的な処理、セキュリティ面での大幅な改善を実現する。
Waylandは以前から存在していたが、課題となっていたのは、長年使われてきたX11からの移行に、Linuxディストリビューションやデスクトップ環境が時間を要していた点である。
しかし、状況は現在変わりつつある。人気の高いLinuxデスクトップ環境の1つである「GNOME」が、「GNOME 49」でX11セッションのオプションを無効化し、「GNOME 50」ではX11関連のコードを全て削除する方針を発表したためである。
Jordan Petridis氏によれば、「5月6日にGNOMEリリースチームで会議を行い、その中でX11セッションの扱いについても議論した。カラーキャリブレーションに関する既知の問題が1件あったが、それについては修正が予定されていた。会議では、X11の削除に関するスケジュールと想定されるシナリオについて検討し、GNOME 50や『Ubuntu 26.04 LTS』まで延期するよりも、『Ubuntu 25.10』のリリースとタイミングを合わせてGNOME 49で進めるのが最適であるという意見が出た。その後、この件はいったん保留とし、1週間後に予定されていたUbuntuチームからのフィードバックを待つことになった」と述べている。
その後、6月にUbuntuの「Discourse」サーバー上で、Ubuntu 25.10（開発コード名：Questing Quokka）から「Xorg」ベースのUbuntuセッションを廃止する方針が発表された。これにより、Ubuntuデスクトップの進化における重要な一歩を踏み出すことになる。このリリース以降、「GNOME Display Manager（GDM）」におけるUbuntuセッションは、Wayland上でのみ動作するようになる。
- 移行が必要なシステム
- 不十分なドキュメント
- 不十分なテスト
- 低品質なコード
- デッドコード/放棄されたコード
- 劣化したコード
- 専門知識不足のチーム
- 不安定な依存関係
- 失敗した移行
- 洗練されていないリリースプロセス
空の安全を守る米国の航空管制塔で、システムの老朽化に伴うトラブルが続発している。米連邦航空局（FAA）は管制システム近代化の計画を表明し、「フロッピーディスクと紙の運航票はもうやめる」と断言した。
直近でトラブルに見舞われたのは、ニューヨークへの空の玄関口、ニューアーク・リバティ国際空港の管制塔だった。4月下旬から5月にかけて、管制システムの通信障害や画面のブラックアウトなどのトラブルが繰り返され、同空港を利用する便の欠航や遅延、行先変更が続出。対応を強いられた管制官がストレスのため次々に病欠してさらに欠航が増える悪循環に陥った。
[...]そうしたトラブルが起きるたびに指摘されてきたのが、システムの老朽化だった。米公共放送NPRによると、米国の管制塔ではフロッピーディスクや紙の運航票、さらには「Windows 95」搭載のPCが今も普通に使われており、「米国内の管制塔に足を踏み入れると、まるで20世紀にタイムスリップしたような錯覚に陥る」という。
航空管制システムの近代化を求める声は以前から噴出していた。FAAは23年の時点で、米国内の管制システムの3分の1以上について、時代遅れの機能やスペアパーツ不足などを理由に「持続不可能」と判定していた。
ただし管制システムはノンストップで稼働させ続ける必要があり、入れ替えは簡単にはできない。そうした事情から、これまでに獲得した予算はアップグレードよりも、主に現在のシステムを稼働させ続けるために使われてきたという。しかしどれだけ修理を行っても、老朽化したシステムはいずれ使用不可能になる。
アップグレードにあたってはセキュリティ対策の徹底も課題になる。もし管制システムがサイバー攻撃を受ければ甚大な影響が出る。これまでは航空機の動きを運航票で記録して、システム間のデータのやりとりにはフロッピーディスクを使っていたことから、不正侵入とは無縁だった。24年7月に米CrowdStrikeのシステム障害が世界を襲った際に、管制塔が影響を免れたのは古いシステムのおかげだったともいわれる。
カーパシー氏は、ソフトウェアというものが過去2回にわたって急速に変化したものと考えています。最初に登場したのがソフトウェア 1.0です。ソフトウェア1.0は誰もがイメージするような基本的なソフトウェアのことです。
ソフトウェア1.0がコンピュータ向けに書くコードであるのに対し、ソフトウェア2.0は基本的にニューラルネットワークであり、特に「重み」のことを指します。開発者はコードを直接書くのではなく、データセットを調整し、最適化アルゴリズムを実行してこのニューラルネットワークのパラメーターを生成するのです。
生成AIが洗練されるにつれ、ニューラルネットワークの調整すらAIの助けを得て行えるようになりました。これらは専門的なプログラミング言語ではなく、「自然言語」で実行できるのが特徴です。自然言語、特に英語で大規模言語モデル(LLM)をプログラミング可能になった状態を、カーパシー氏は「ソフトウェア 3.0」と呼んでいます。
まとめると、コードでコンピューターをプログラムするのがソフトウェア 1.0、重みでニューラルネットワークをプログラムするのがソフトウェア 2.0、自然言語のプロンプトでLLMをプログラムするのがソフトウェア 3.0です。
カーパシー氏は「LLMは新しい種類のOSのようなものだと感じました。CPUの役割を果たすような存在で、LLMが処理できるトークンの長さ(コンテキストウィンドウ)はメモリに相当し、メモリと計算リソースを調整して問題解決を行うのです。これらの機能をすべて活用しているため、客観的に見ると、まさにOSに非常に似ています。OSだとソフトウェアをダウンロードして実行できますが、LLMでも同様の操作ができるものもあります」と述べました。
DuckDBの公式ブログにおいて、メタデータ管理をデータベースで担う新しいLakehouseフォーマット「DuckLake」が発表されました。
本記事では、DuckLakeがどういったものか簡単に紹介し、ローカルで軽く触ってみたのでその内容をまとめてみます。
「『Microsoft Teams』との関係はもう終わりだ」。ドイツのシュレースヴィヒ＝ホルシュタイン州のデジタル化担当相であるDirk Schrodter氏は、オープンソースのビデオプラットフォームでこう宣言し、Microsoft製の全てのソフトウェアを州政府の職場から段階的に廃止していくと発表した。目標は、Microsoft製プログラムからLinuxおよびオープンソースプログラムへ3カ月以内に完全に移行することである。
この決定の影響は、ほぼ全ての公務員、警察官、裁判官など、約3万人の職員に及ぶ。その他の公務員（主に教師）も、最終的にはオープンソースに移行することになる。この抜本的な改革は、「デジタル主権」に向けた重要な一歩であり、米IT大手への依存に対する欧州の抵抗の高まりを示すものとして支持されている。今回の発表の直前には、デンマーク政府高官がMicrosoft依存からの脱却を表明していた。
シュレースヴィヒ＝ホルシュタイン州の今回の動きは、しばらく前から計画されていた。同州の内閣は2024年4月に移行を宣言。Schrodter氏は当時、移行の理由を次のように語っている。「そのような（プロプライエタリーな）ソリューションの運用プロセスや、データの取り扱い、第三国へのデータ流出の可能性に対して、政府は影響力を行使できない。州には市民や企業のデータの安全を守るという大きな責任があり、使用するITソリューションを常に掌握し、州として独立した行動を取れるようにしなければならない」
Schrodter氏は今回の決定に関して、次のように付け加えた。「ここ数カ月の地政学的な動向により、われわれが選んだ道に対する関心が強まっている。ウクライナ戦争によって、エネルギー依存の問題が浮き彫りになった。そして今回、デジタル依存があることも明らかになった」
シュレースヴィヒ＝ホルシュタイン州には、Microsoftと決別する理由が他にもあった。プロプライエタリーソフトウェアから脱却することで、政府と市民の機密データをドイツの法的管轄下にとどめて、米国企業によるアクセスのリスクを排除したい考えだ。つまり、Microsoft製のソフトウェアを廃止するだけでなく、同州のデータを「Microsoft Azure」から欧州ベースのクラウドに移行する、とSchrodter氏は述べた。
言うまでもなく、同州はMicrosoftのライセンス料と予測できない必須のアップデートのコストを削減することで、数千万ユーロの節約を見込んでいる。後者に関してSchrodter氏が言及したのは、「Windows 10」から「Windows 11」への移行のようだ。
Linuxとオープンソース技術への移行は段階的に進められる。第1段階はすでに進行中で、「Word」と「Excel」を「LibreOffice」に置き換える。次の段階では、「Open-Xchange」を実装し、「Exchange」と「Outlook」を「Thunderbird」に置き換える予定だ。
最後に、LinuxがWindowsに取って代わる。具体的なLinuxデスクトップディストリビューションは明らかにされていないが、デスクトップインターフェースは「KDE Plasma」になるだろう。同州政府が使用する可能性のあるデスクトップとしては、「Ubuntu」の公式KDEフレーバーである「Kubuntu」や、「SUSE Linux Enterprise Desktop」（SLED）、「openSUSE Leap」などが考えられる。また、他のMicrosoft製品の廃止によって生じた穴を「Nextcloud」などのオープンソースツールが埋めるはずだ。
このような動きは失敗が目に見えている、という意見もあるだろう。よく挙げられるのが、ドイツのバイエルン州の州都であるミュンヘンの例だ。ミュンヘンは2004年にWindowsからLinuxに移行したが、Linuxを10年間使用した後、Windowsに戻した。これには、Microsoftの欧州本社をミュンヘンに誘致したいという市長の意向が少なからず影響している。しかし、詳しく調べてみると、「LiMux」は失敗に終わったものの、ミュンヘンは現在もオープンソースソフトウェアを使用しており、特にLibreOfficeに大きく依存していることが分かる。
欧州のLinuxプログラムには、10年以上前にUbuntu Linuxに移行したフランスの国家憲兵隊など、成功例もある。2024年6月の時点で、憲兵隊のワークステーションの97％に相当する10万3000台以上で「GendBuntu」（憲兵隊向けにカスタマイズされたUbuntuベースのLinuxディストリビューション）が使用されている。このプロジェクトはメンテナンスとアップデートが活発に実施されており、「GendBuntu 24.04 LTS」への最新アップグレードは2024年12月に完了した。
つまり、筆者が一貫して主張してきたように、WindowsからLinuxへの移行をうまくやり遂げることは可能だ。欧州連合（EU）が米国とそのテクノロジー企業への不信感を募らせている今、このような動きはさらに拡大していきそうだ。
先月開催された今年の Python Language Summit のライトニングトークに、Python の生みの親であるグイド・ヴァンロッサムが登場し、「悪いほうが良い（Worse is better）」原則は今でも通用するのか、と問いかけている。
プログラミング言語の Python の開発初期、主要プラットフォームだった UNIX の「悪いほうが良い」哲学には大きな影響を受け、長年この考え方がとても有用だったとグイド・ヴァンロッサムは認める。
この考え方のおかげで3か月で何かを動作させることができたと彼は言うが、その後、年月を経て、自分が手抜きしたすべてが最終的には修正されたとも認める。「当時はテストすらなかった」と言って、彼は笑いを取る。
その上で、『悪い方が良い』という考え方に今でも役目はあるのだろうかと彼は問いかける。今では Python には巨大なコミュニティがあり、開発体制も初期とはまったく異なる。
グイド・ヴァンロッサムは、機能の完成度に目をつむってコミュニティに試してもらうものを提供できた昔を懐かしんでいるようだが、昔に戻すこともできないのは承知している。
彼は最後に、Python で Rust を利用するためのバインディングを提供する PyO3 についての講演を引き合いに出し、これの開発には『悪い方が良い』原則が見られると評価している。PyO3 の開発は CPython よりずっと楽しそうだと言い、「とは言え、私は個人的に Rust を学ぶつもりはない……けど、後で試してみるべきかもな」と言って会場を笑わせたそうな。
今回はメタデータ管理をPostgresqlやMySQLなどのSQLデータベースが担う新しいOSSのLakehouseフォーマット、Ducklakeについて試してみました！
今回はPostgresql+s3(minio)+DuckDBで構築してます。
Ducklakeは公式HPの一文によるとSQLデータベースをカタログ置き場に、データをparquetファイルに保存する形式のLakehouseフォーマットだそうです。
今回は、TypeSpec を中心にしたスキーマ駆動開発をご紹介します。
結論からいうと、筆者は TypeSpec について「OpenAPI からの移行コストや技術的ロックインリスクを伴わず、開発体験を向上する最高のツール」と評価しています。その理由を順にご紹介します。
1: どんなフレームワークもいつか身の丈に合わなくなる
2: デザインパターンや方法論は、やがて通用しなくなる
3: 規模は時間とともに常に拡大する
4:「ストーリー」に注目するべし
5: 目指すべきは「真実」と「明快さ」である
6: 孤立を味わう可能性がある
7: それでも真実の追求を諦めないこと
一般社団法人PyCon JP Association 理事の石田です。
昨年10月に設立を宣言した、PyCon APAC 2023における登壇者採択に関する調査について、内部調査委員会による調査が完了しましたのでご報告します。
調査および取りまとめに時間を要し、当初お約束していた時期よりも遅れてのご報告となったこと、お詫び申し上げます。
PyConAPAC2023における登壇者採択に関する調査結果.pdf
内部調査委員会による指摘の通り、一般社団法人PyCon JP Associationは、今後もよりよいコミュニティ運営のための改善を責任持って継続していきます。
引き続き皆様のご協力・ご支援をよろしくお願いします。
- 実装手順書の管理は難しい上、人間はミスをする
- 手順に不備があることをコンパイルエラーとして表現したい
- Kotlinでは網羅性チェックを用いることで、コンパイルエラーとすることが可能
- 網羅性チェックを用いて手順の不備を検知することができるかも？
- 今回の実装例では大きく２つの定義を用いた
- コスト連携のステップを定義したインターフェース
- コスト連携の対象となるオーダーの定義
- V2の実装ではコンパイルエラーにより手順に不備があることを検知できた
ここ1年でプロダクト開発の環境は大きく変わりました。
AIエージェントが開発現場で“当たり前”のように使われる時代になりつつあります。
そんな中で、「DDD(ドメイン駆動設計)って今の時代にも必要なの？AI時代になったらもう使わなくなるのでは？」と疑問に思う方もいるかもしれません。
私はこう思います。
DDDは、AI時代にこそレバレッジを効かせることができる、価値を届けるための“武器”になる。 (少なくとも、あと数年はね。)
これまで長い間この国の施策に汗水を流してきた事業者を自治体システムの知識が低いワーキングメンバーがあたかもコスト増は事業者の責任の如く失礼極まりない会議が行われ公開処刑に近い形の議事要旨が公開された。界隈にいる人ならどの事業者かは想像に難くないだろう。
99％政治マターに踊らされた国の失敗である。無論これまでの自治体システムにおいて事業者側にもやるべきことがあったことは認める。しかし、今回の失敗は国の責任だ。これは曲げようもない事実。こちらは何度も軌道修正を呼び掛けたが応答することはなかった。いや、失敗が明らかになってから応答したものもある。時すでに遅し。処方箋は病気発覚後すぐに投薬するのがベストだ。お迎えまじかの患者に投与しても意味はないのである。
フロントエンドカンファレンス北海道2025実行委員会の実行委員長を務めております、n13u（西村航）です。この度は当実行委員会が運営する公式ウェブサイトの乗っ取りにつきまして、皆様に大変ご心配をおかけいたしました。
現在、公式ウェブサイトでは対応を行い2024年度開催分のページが公開されています。また、後述する原因に基づき、各種設定の見直しを行い再発防止策を実施済みです。公式ウェブサイトへのアクセスについて問題なく行えることを確認しておりますが、DNSレコード設定の反映等で一部の環境にて正しくない、または不正なウェブサイトが表示される可能性もございます。反映が完了する数日程度は継続してウェブサイトの閲覧をお控えいただくようお願いいたします。
まとめ
- Go におけるエラーハンドリング冗長性は長年の課題である。
- Go チームは check/handle → try → ? と三度の大規模提案を試みたが、いずれも広範な合意に至らず撤回された。
- 構文変更にはメリットもあるが、デバッグ容易性や設計哲学、移行コストなどマイナス面も大きい。
- 当面は構文をいじらず、ライブラリやツールでの支援に軸足を置くという結論に落ち着いた。
窮屈で仕方ない。決められたものを、決められた日までに作るだけ——プロジェクトの成功とは、そういうものなのか。
そんな疑問が頭をもたげるスクラムチームは、自らを “もどき” だと感じるようになります。スクラムで開発しているはずが、気づけば違うものに変わってしまっていた、と。
はじめから “何を作るか” にばかり集中すると、そうなります。そして、チームは次の四段階を経て、静かに侵食されていきます。
- はじめから全体を詳細に詰める
- 決定を開発へ一方通行で流す
- すべてのパーツを作ってから組み上げる
- スプリントレビューを進捗報告の場にする
優れたアイデアやデザインがあっても、それだけではソフトウェアプロジェクトを成功させることはできません。プロジェクトを円滑に進めるためには、ステークホルダーの理解と支持を得て、チームが協力できる環境を作ることが重要です。本書では、そのために不可欠で効果的なコミュニケーションの方法を解説します。具体的な例やパターンを通じて、適切にメッセージを伝えるためのドキュメントや図の作成方法を紹介します。
まず、ソフトウェアアーキテクチャの視覚表現を活用し、受け手にわかりやすくメッセージを伝える方法を解説します。次に、書面・口頭・非言語コミュニケーションの技法を用いて、相手に意図が正しく伝わるように工夫する方法を紹介します。また、ナレッジマネジメントを強化し、チームや組織の集合的な知識を最適化することで、生産性と革新性を向上させる手法についても解説します。さらに、アーキテクチャに関する重要な意思決定を的確に記録し、関係者と共有する方法を学びます。そして、リモートやハイブリッド環境において、同期・非同期の手法を適切に使い分けながら、円滑に連携するためのアプローチについても詳しく説明します。
『Five Lines of Code — How and When to Refactor —』(Christian Clausen著、MANNING刊)の日本語版。
リファクタリングはソフトウェア開発やプログラミングの世界においてコードの品質向上や保守性の確保のために重要です。 何をリファクタリングすべきかは、問題の兆候を示す「コードの臭い」で説明されてきましたが、この概念は抽象的で、経験の浅いプログラマーには理解しづらいものでした。
本書では、「メソッドを5行以内で実装する」といった明確なルールを用いてリファクタリングを行うテクニックをステップバイステップで解説します。ルールの解説後には、そのルールの元となった「コードの臭い」についても説明されており、効率的に「コードの臭い」への感覚も養うことができます。
第1部では、GitHubで公開されている2Dパズルゲームのコードを主要な題材としてリファクタリングのプロセスを示しながら、適用するルールやパターンを解説します。
第2部では、チームでの開発にも焦点を当て、ルールとリファクタリングパターンを実務でどう活用するかを掘り下げます。コンパイラの機能の活用や、コメントを極力書かないようにするためのコツ、価値あるコメントの見極め方、コードの安全な削除／追加方法、将来的なリファクタリングで見落とされないように悪いコードをさらに悪く見えるようにして品質レベルを明確にするテクニックなど、実践で役立つトピックを広範に扱っています。
新山祐介さんの投稿で知ったが、プログラミング技術に関するナレッジコミュニティ、共同創業者のジョエル・スポルスキーの表現を借りれば「ロングテールなプログラミングの質問のWikipedia」である Stack Overflow だが、「ほとんど死んだ」と評されている。
「投稿される質問の数はピーク時の1/10程度、黎明期の2009年あたりの数まで激減している」というのはショッキングである。
投稿される質問数でいえば、2014年～2017年あたりがピークで、コロナ禍が始まった2020年にも急上昇しているが、その後衰退期に入り、ChatGPT 開始とともにダメ押しのごとくガクッと下がっている。やはり AI が Stack Overflow の衰退を後押ししている。
AI活用が当たり前になる開発環境において、コードの「なぜ」を残すことは、技術的負債を防ぐ重要な実践だ。2年後により良いAIが登場したとき、過去の意思決定を理解できれば、真に価値のある改善が可能になる。
私たちエンジニアは、常に未来の自分や同僚のことを考えてコードを書いてきた。可読性、保守性、拡張性—これらはすべて「未来の誰か」のための配慮だ。AI時代においても、この精神は変わらない。むしろ、AIの進化速度を考えれば、より一層重要になる。
プロンプトは新しい形の設計書だ。コードレビューと同じように、プロンプトレビューが必要になるかもしれない。リファクタリングと同じように、プロンプトリファクタリングが日常になるかもしれない（プロンプトの可読性を議論する日も近い）。
PDRのような仕組みの標準化は、AI時代のソフトウェア開発における必須要件となるだろう。エンジニアとして、この課題に真剣に取り組む時期に来ているが、個人ではどうにもならない気もするので。頑張れ、Anthropic！！！
ソフトウェアテストには、対象とする品質要件に応じて様々な「手法」が存在します。しかし、個別のテスト手法を断片的に学ぶだけでは、プロダクトの品質を総合的に高めることはできません。本書は、複数のテストを補完的に組み合わせて、あらゆる側面から品質を検証するための技術・戦略を、体系的に学べる骨太なガイドブックです。
取り上げるのは、以下10種のテスト手法。それぞれについて、テストの原理原則・導入戦略・実践方法を、具体的なWeb／モバイルアプリケーションでの適用例を交えながら詳しく解説します。
□手動探索的テスト
□自動テスト
□継続的テスト
□データテスト
□ビジュアルテスト
□パフォーマンステスト
□セキュリティテスト
□アクセシビリティテスト
□モバイルテスト
□クロスファンクショナルテスト
本書は、各領域のテストを一貫した視点で解説するため、それぞれのテストの「役割」と「つながり」がよく理解できます。本書を通じて、広大なテスト分野を迷わず歩くための「体系的な知識地図」をインストールしてください。
【石破茂首相の発言】
「税率変更する時に、一体どれくらいの期間がかかるかということでございます」「スーパーを見れば分かりますが、そのシステムを変えるだけで1年はかかるということでございます」
（5月21日、立憲民主党の野田佳彦代表との党首討論で）
首相発言が「レジの変更に1年」と拡散 SNSで批判
石破茂首相は21日、立憲民主党の野田佳彦代表と党首討論をした。
物価高対策として、食料品の消費税を1年間ゼロにすると掲げた野田代表に対し、「減収が5兆円になる」と指摘。さらに、「スーパーのシステムの変更」に1年かかると述べた。
討論後、フジテレビが首相発言を「スーパーのレジなどシステム変更に1年かかる」などと伝えた上で、都内の商店街の小売店主らの「1日でできる」「一晩」などといった意見を報じた。SNS上では、首相の「1年発言」に対し、「1年もかかるわけねえだろ」「すぐばれる言い訳」などの批判が拡散した。アカウントの中には、投稿が見られた数や影響力などを示す「インプレッション数」が800万を超えたものもあった。
加藤財務相「短期間で可能とする事業者もいたが……」
首相が言う「スーパーのシステム」について財務省は、店内に複数レジがあるスーパーや小売りチェーンなどで導入されている、各レジの売り上げを集計する「POSシステム」としている。
加藤勝信財務相は27日、参院財政金融委員会で野党議員の質問に対し、複数の大手システム事業者への聞き取りの結果として「短期間で対応可能とする事業者があった一方で、少なくとも1年は要すると見込む事業者も複数あった」と答弁。「1日でできる」という声を紹介した一部報道については、「個人商店の場合は、割と簡易なシステムでありますから、そういった声も確かにある」などと述べた。
大手メーカー「1年以上でもおかしくない」
実際、POSシステムの税率変更にどれほどの期間が必要なのか。合わせて業界シェアの7～8割を占める大手システムメーカー3社（東芝テック、富士通、NECプラットフォームズ）に聞いた。
そのうちの1社の担当者によると、「個人商店などで使う単体の電子レジスターの設定変更なら別だが、POSシステムの税率変更はシステム改修が必要。過去の税率変更の際も、すべての顧客の対応が終わるのに1年はかかった」と話す。
別の社の担当者も、税率変更に伴いPOSシステムに関連する会計管理システムや在庫管理システムのチューニング（調整）が必要になると説明する。「期間限定かどうか、軽減税率をどうするかなどでも所要期間は異なるので一概に言えないが、1年以上かかったとしてもおかしくはない」という。
この2社によると、消費税をゼロにする場合は、「そもそもそういう設定を想定しておらず、新たなシステム開発に近い」ため、単なる税率変更よりも改修期間が長引く可能性があるという。
一方、「そこまで大規模な改修は必要ないので、数カ月から半年」とした社もあった。この社では、外食産業や小売りチェーン、企業の社食のシステムを多く担当しているという。
ただ、「あくまで、メーカー側で要する時間。小売り側の都合やスケジュールもあるので、実際は数カ月から半年より、もう少しかかるのではないか」と話している。
【判定結果=ほぼ正確（一部は不正確だが、主要な部分・根幹に誤りはない）】
スーパーやコンビニ、小売りチェーンなどで使われるレジの販売記録を管理する仕組みは、「POSシステム」と呼ばれる。システムメーカーの大手3社に取材したところ、2社はシステム改修などが必要になるため1年以上かかる見通しを示し、1社は数カ月から半年と回答した。
本書は、コードレビューに関する実践的なガイドブックです。「なぜコードレビューを行うのか」から始まり、ワークフローの徹底解説、最初のプロセスの構築と、段階的に解説します。さらに高度な要素として、「チームワーキングドラフト」「自動化」、そして最も大事な「効果的なコメント」について、じっくり説明します。「伝わるコメント」には、言葉遣いや文章のトーンが重要で、それを実現する著者の経験から生まれたメソッドが明かされています。
本書を通して、ソフトウェアテストの知識・技術を体系的に学びます。そしてその中でテストによって次の課題にどのように対応していくか学び、現代的なソフトウェア開発に対応するため総合力・基礎力を強化します。
- 開発成功や顧客満足実現をどう支えるか
- 開発の高品質と高スピードの両立を支えるアプローチとは
- アジャイルや継続的デリバリー、DevOpsの導入にどう対応するか
- テスト自動化といったテスト技術導入を成功させるには
- チーム全体でテストを推進していくためには
- 定番のテスト失敗要因に対しマネジメントでどう対策すべきか