ふわふわエンジニアの覚書

ふわふわエンジニアの覚書

ホームピグアメブロ

芸能人ブログ人気ブログ

30Dec
- 基本設計で押さえること
  1. 基本設計書の作成目的基本設計書は、**「何を作るか（What）」**を定義する文書です。その主な目的は以下の3点に集約されます。ステークホルダーとの期待値調整: 顧客や経営層が抱く「やりたいこと」と、システムが提供する「機能」を合致させ、合意を得る。開発現場への指針提供: 詳細設計や実装を担当するエンジニアに対し、業務ロジックや画面遷移、データの性質などの「正解」を示す。品質の担保: 非機能要件（速度、セキュリティ、可用性など）をあらかじめ定義し、運用に耐えうるシステムであることを保証する。2. 基本設計を「ちゃんとしない」ことのリスク「早くコードを書きたい」という焦りで基本設計を簡略化すると、プロジェクト終盤に以下のような代償を払うことになります。「手戻り」によるコストと納期の爆発: 開発の最終局面で「思っていたのと違う」という指摘が入ると、修正コストは設計時の数十倍に膨れ上がります。データの不整合とロジックの歪み: データの性質（売上の定義など）を決めずに進めると、開発者ごとに解釈がバラバラになり、不整合が起きます。「動くが使い物にならない」品質: 速度やセキュリティを後回しにすると、リリース後にシステムダウンや情報漏洩といった致命的な事態を招きます。運用のブラックボックス化: 設計書がないシステムは、作った本人以外には誰も触れない「技術負債」となり、メンテナンスが不可能になります。3. 基本設計において対応すべきこと基本設計を「機能させる」ためには、単に書くだけでなく以下の行動が必要です。ステークホルダーとの徹底した対話: 曖昧な要求を掘り下げ、機能の優先順位（やる・やらない）を確定させる。業務フローの再定義（To-Be）: システム化によって「現場の仕事がどう変わるのか」を、イレギュラー対応も含めて定義する。非機能要件の合意: 性能、セキュリティ、障害時の復旧目標など、ビジネス継続に必要な「品質」を経営層と握る。変更管理の仕組み作り: 設計変更が発生した際、どのドキュメントを更新し、誰に周知するかというルールを決めておく。要求仕様との紐づけ:要求仕様で挙げていた内容と漏れがないかわかるように仕様Noを記載しておく。　　　（生成AIにて、対応表の作成や仕様不備、仕様変更時に変更箇所がわかるなど利点が多いため）4. 作成時の注意点：陥りがちな罠良い基本設計書を作るためには、以下の点に注意を払う必要があります。「コンテキスト（背景知識）」の共有を怠らない: ベテランには「当たり前」の前提も、新人や別チームには未知の領域です。「なぜこの仕様なのか」という背景（理由）を併記しないと、意図しない実装ミスを招きます。「言わなくてもわかるだろう」を捨てる: 「暗黙知」は事故の元です。言葉の定義を「用語集」としてまとめ、部署や世代間での認識のズレを徹底的に排除してください。保守不可能なドキュメントにしない: 細かすぎる記載は、実装変更に追いつかずすぐに形骸化します。基本設計書は「不変的なビジネスルール」と「主要な仕様」に絞り、メンテナンス性を保つべきです。「画面」だけで満足しない: UI（見た目）の合意は取りやすいですが、その裏にあるデータ構造や計算則（ビジネスロジック）こそがシステムの「心臓」です。ここを疎かにすると、後に必ず崩壊します。5. 基本設計書 Markdownテンプレート# 基本設計書## 1. システム概要・スコープ### 1.1 背景・目的* [導入に至った経緯と解決したい課題]### 1.2 スコープ* **実施範囲:** [本プロジェクトで実現する範囲]* **対象外:** [将来フェーズまたは実施しない範囲]### 1.3 前提・制約事項* [予算、納期、利用技術等の制約]## 2. 業務フロー (To-Be)### 2.1 業務プロセス図* [業務の流れをステップごとに記述。Mermaid記法等の活用を推奨]### 2.2 例外処理・判断方針* [エラー発生時やイレギュラー時の業務ルール・判断主体]## 3. 機能一覧| 機能ID | 機能名 | 機能概要 | 優先度 | 備考 || :--- | :--- | :--- | :--- | :--- || F-01 | | | | |## 4. 画面遷移図### 4.1 遷移定義* [画面間の繋がりと、遷移のトリガー（ボタン押下等）の定義]## 5. 画面レイアウト (UI)### 5.1 画面ID：[XXXX] 画面名：[XXXX]* **情報の優先順位:** [最も強調すべきデータ、判断ミスを防ぐための視覚的優先度]* **レイアウト要件:** [配置や入力補助に関する注意事項]## 6. データモデル・ビジネスルール### 6.1 主要データ定義* [エンティティ（ユーザー、受注、売上等）の性質と保持期間]### 6.2 ビジネスルール・計算式* [計算ロジック、ステータス遷移の条件、データの不整合を防ぐための制約]## 7. 非機能要件| 項目 | 目標値・定義 | 備考 || :--- | :--- | :--- || 可用性 | [稼働時間、復旧目標時間(RTO)] | || 性能 | [画面レスポンスタイムの目標値] | || セキュリティ | [認証方式、権限管理、暗号化範囲] | |## 8. 用語集| 用語 | 定義 | 英語名（コード命名用） || :--- | :--- | :--- || | | |まとめ：急がば回れ、基本設計こそが最短ルート基本設計を丁寧に行うことは、一見遠回りに見えます。しかし、不確実性の高い開発現場において、**「全員が同じ地図（設計図）を持っている」**こと以上の安心感はありません。「後で変えればいい」という甘えを捨て、この段階で徹底的に「目的」を擦り合わせること。それが、結果として最も速く、そして最高品質のシステムを届けるための唯一の方法です。
- プログラムの再利用が進まないのと今後の開発はどうすればいいか
  1. なぜ僕たちの「再利用性」は報われないのか？私たちは「モジュール化」や「クラス化」こそが、再利用性を高める正解だと教わってきました。しかし現実は、車輪の再開発の連続です。高機能すぎる: 一部の機能を使いたいだけなのに、巨大な依存関係まで付いてくる。仕様が微妙に異なる: 既存コードを修正・適合させるコストが、新しく作るコストを上回る。フレームワークの壁: 以前のプロジェクトの「作法」が、今の環境では足かせになる。結局、本当の意味で再利用に耐えるのは、ライブラリや関数型プログラミングのように**「状態を持たず、単一の目的に特化したシンプルなもの」**だけではないか？というあなたの疑問は、極めて本質を突いています。2. 生成AIによる「再開発コスト」の逆転これまでは「似たようなものがあるなら、探して使い回すのが正義」でした。しかし、生成AIがこの計算式を書き換えました。「探す」より「作る」方が早い: 社内の古いレポジトリから宝探しをするより、今の要件をAIに伝えて、その場に最適化されたコードを生成させる方が圧倒的に低コストです。 AIは「人類の知」の再利用エンジン: AIが生成するコードは、ネット上の膨大な既存コードを学習した結果です。つまり、**AIで再開発することは、間接的に「世界中の優れた実装を再利用している」**ことと同義なのです。3. AIにライブラリを作らせ、人間がそれを使う「分業」「ライブラリをAIに構築させ、利用側を人間が作る」という分業をすることでプログラマはこれからの開発において有効な戦略になり得ると考えられまう。AIが「ライブラリ（基盤）」を作るメリットライブラリのような「仕様が明確で、汎用的なロジック」はAIの得意分野です。標準への準拠: 複雑なアルゴリズムや標準規格に沿った実装を、AIはミスなく短時間で書き上げます。高機能・高品質の両立: 単機能から高機能なものまで、テストコードを含めて一気に生成させることができます。人間が「利用側（コンテキスト）」を作る意味一方で、システムが「どう使われるか」というビジネスの文脈（コンテキスト）やユーザー体験（UX）を理解しているのは人間です。「意図」の注入: AIが作った純粋な部品を、現実のドロドロとしたビジネス要件に繋ぎ込む。柔軟な調整: フレームワークの制約や納期、ユーザーの好みに合わせて、AI製の部品をどう組み合わせるかを判断する。4. これからの「効率的な開発」のカタチAI時代の効率化とは、コードを「ストック（貯蔵）」することではなく、「フロー（流れ）」として捉えることにあるかもしれません。「実装」ではなく「仕様」を再利用する: コードを資産として残すのではなく、AIへの「的確な指示（プロンプト）」や「要求仕様の定義」を資産にする。疎結合な部品をAIに量産させる: 無理に一つの巨大な共通クラスを作るのではなく、その場その場で必要な「小さなライブラリ」をAIに作らせ、使い捨てるように組み込む。インターフェースの設計に注力する: 中身がどうあれ、部品同士の「繋ぎ目」さえ綺麗であれば、AIはそれらを繋ぐフローを簡単に生成してくれます。5. まとめ：エンジニアの役割は「ライブラリ」から「コンポーザー」へ今後は、「過去のコードを大切に再利用する」時代から、「AIに世界中の知恵を再構成させ、人間がそれをオーケストレーション（編成）する」時代へとシフトします。エンジニアの価値は、コードの再利用性を高めるための複雑なクラス設計をすることから、「AIという巨大な力を、どう組み合わせて目的を達成するか」というアーキテクトとしての判断に移っていくのだと思います。
29Dec
- 生成AIを活用した開発ってどうなるのだろうか
  1. はじめに：開発プロセスの「高速道路」が完成しつつある最近、エンジニアの働き方が劇的に変わってきています。生成AIの導入で、コードレビューやテストコードの生成、さらには「仕様書を食わせればコードが出てくる」といった仕様駆動開発（SDD）も現実味を帯びてきました。これまでは「いかに速く、正確に実装するか」がエンジニアの腕の見せ所でしたが、そのハードルはAIによってどんどん下がっています。では、開発プロセスが爆速になった先で、僕たちは次に何を重視すべきなのでしょうか？2. アジャイルの「試行錯誤」をAIでブーストするこれまでのアジャイル開発では、「まずは動くものを作り、ユーザーの反応を見て、そこから修正していく」というサイクルが基本でした。これは、事前の市場調査には限界があり、実際に触ってもらうのが一番確実だったからです。しかし今は、検索系AIやSNS分析ツール（Grokなど）を使えば、「作る前に、ユーザーが何に困っているか」の解像度を、今まで以上に手軽に、かつ高く引き上げることができるようになりました。3. 検索系AIが「最強の市場調査ツール」になるそこで僕が注目しているのが、GrokやPerplexity、SearchGPTといった検索系AIの活用です。これまでの市場調査や課題の抽出は、専門の部署が時間をかけて行うか、エンジニアが直感に頼る部分が少なくありませんでした。しかし、今のAIはX（旧Twitter）などのリアルタイムな声や、Web上の膨大なフィードバックを瞬時に分析してくれます。「今、この瞬間の不満」を可視化する: ユーザーがどんなツールに、どんな不満を感じているのか。潜在的な課題を炙り出す: 統計データだけでは見えてこない、ユーザーの「生の声」の裏にある本質的な痛みを抽出する。こうした「課題の特定」をAIで行うことで、「当たるかどうかわからないけど作る」という博打のような開発を減らすことができるのです。4. 仕様駆動開発の「種」はAIで見つける仕様駆動開発（SDD）が進むと、僕たちの仕事は「仕様を定義すること」に集約されていきます。その仕様の「種」となるのは、もはやプロデューサーの思いつきではなく、**AIが解析した「市場の切実なニーズ」**になるでしょう。検索系AIで、解決すべき課題の「解像度」を極限まで高める。その課題を解決する仕様をAIと共に練り上げる。生成AIで爆速で実装し、検証する。この流れこそが、アジャイルのさらに先を行く、AI時代の開発スタイルだと感じています。5. まとめ：プログラマは「課題のハンター」へ「コードを書く時間が減る」ことは、寂しいことではありません。むしろ、これまでは時間がなくて手が回らなかった**「ユーザーと向き合い、本当の課題を見つけ出す」**というクリエイティブな工程に、エンジニアが直接関われるようになったということです。実装が速くなったからこそ、その余ったエネルギーを「市場の声を聴くこと」に使う。 AIという強力な武器を片手に、「何を解決すべきか」を誰よりも深く知るエンジニアが、これからのプロダクトづくりをリードしていくはずです。
28Dec
- なぜ「手順書通り」は失敗するのか？
  1. はじめに：なぜ「手順書通り」が失敗するのか「手順書通りにやったはずなのに……」という事故。その原因を「担当者の不注意」の一言で片付けてはいけません。多くの場合、真の原因は手順書に書かれていない「コンテキスト（背景知識）」の欠如にあります。作成者と実行者の間で「当たり前」の基準がズレているとき、手順書は牙を剥きます。2. 「世代間ギャップ」の正体はコンテキストの欠如「昔からこのやり方だから安心だ」という言葉は、実は非常に危険です。暗黙知の壁: 10年前からいるエンジニアには「当然知っているはず」のサーバ構成や依存関係も、今日入った新人には全く見えていません。コンテキストの未共有: 「なぜこのコマンドを打つのか」「このエラーが出たら何を意味するのか」という背景（理由）が共有されていないため、想定外の事態が起きたときに、担当者がバイアス（思い込み）で間違った判断を下してしまいます。3. 「間違えようのない」手順書へのアップデート術形式（HTMLやMarkdownなど）が何であれ、手順書を「人間を物理的にサポートする仕組み」に変える必要があります。① 認知負荷を下げる「徹底したルール化」人間は情報を探すときにミスをします。構造の統一: どの手順書も「作業前確認」「実行」「作業後確認」の場所を同じにする。重要操作の可視化: 実行漏れが許されない箇所は、一目でわかるように強調し、担当者の意識を強制的に引きつけます。② 「コピーミス」を構造的に排除する人間は「手入力」や「置換操作」でミスをします。コマンド生成機能の活用: 環境名やホスト名などの「変数」を入力欄に入れると、手順書全体のコマンドが自動で書き換わる仕組みを導入する。コピーの容易性: Wordなどの「コピーしにくい」ツールから、1クリックで正確にコマンドをコピーできるデジタルな形式へ移行し、余計な改行や記号の混入を防ぎます。③ 精神論ではない「ダブルチェック」の組み込み単に「二人で見る」だけでは生産性が下がるだけです。エビデンスベースの確認: 「重要操作の前に、特定の確認コマンドの結果をエビデンスとして残し、それをチェック担当者が確認する」というフローを明確にします。チェック用コマンドの提供: 人間の目視による「OKなはず」を信じず、「期待通りの状態か」を判定する専用のチェックコマンドを用意します。4. まとめ：手順書は「未来の担当者への手紙」手順書を保守することは、システムを保守することと同義です。「今のメンバーならわかる」という甘えを捨て、**「コンテキストを全く持たない人が見ても、迷わず安全に完結できるか」**という視点で手順書を設計し直す必要があります。「手順を守れ」と叱咤するのではなく、手順書そのものを「間違えようのないインターフェース」へと進化させる。それが、世代を超えて技術を繋ぎ、安定した運用を支えるプロの仕事です。
- 問題が起きた時には、次に起こさないために対応の水平展開が大切
  1. はじめに：「また同じか」の重み障害が発生したとき、最も避けなければならないのは、少し時間を置いて「別の場所で同じような障害を出す」ことです。利用者から見れば、コード上の場所が違おうが、原因が似ていれば「同じ不具合」です。この「またか」という心証は、エンジニアチームへの信頼を著しく損ないます。目の前の火を消すだけでなく、システムのあちこちに潜む「火種」をどうやって一掃するか。今回は、再発防止の鍵となる「水平展開」の進め方について考えます。2. 「問題の抽象度」を上げて類似箇所を炙り出すバグが見つかったとき、その一行だけを直して終わっていませんか？水平展開を成功させる秘訣は、問題の抽象度を一段階上げて考えることにあります。具体:A関数の引数にNullが入ると落ちる抽象:外部APIからのレスポンスを検証せずに、特定のデータ構造を期待して処理している箇所が他にもないか？この「抽象化」のプロセスにこそ、生成AIが非常に役立ちます。現場で許容されている範囲内で、発生した事象をAIに投げ、「この問題の本質的なパターンは何か？」「他にどのようなケースで同様の不具合が起きうるか？」と壁打ちをします。自分一人の視点では気づけなかった、類似の「脆い設計」が見えてくるはずです。3. AIと自前調査の「ダブルチェック」で漏れを防ぐ影響範囲の調査には膨大な時間がかかります。IDEの検索（Grep）だけでは、意味的に似ているコードまでは拾いきれません。 AIによるセマンティック（意味的）検索: 「これと似たような処理をしている箇所を教えて」とAIに依頼し、コードベース全体を俯瞰した候補を出させます。自前調査による確証: AIの提案を鵜呑みにせず、エンジニアが実際にソースを読み、ビジネスロジック上の文脈を確認します。この「AIの網羅性」と「人間の正確性」を組み合わせたダブルチェックこそが、最も効率的で漏れのない水平展開の方法です。4. 影響範囲が広すぎる場合の「戦略的撤退」と「段階的修正」水平展開を進める中で、「修正箇所が多すぎて、一気に直すとデグレードのリスクが高すぎる」という場面に直面することがあります。その場合は、無理に一度で直そうとせず、段階的な修正を検討すべきです。優先順位の策定: 利用頻度の高い機能、またはデータ破壊などの致命的な影響が出る箇所から順次適用する。暫定処置と恒久対応: まずはガード節を入れるなどの安全な修正を行い、後日のリファクタリングで構造的に解決する。大切なのは、「直さない」のではなく「計画的に全て直す」という意思を証跡として残し、実行することです。5. まとめ：水平展開は、未来の自分への投資障害対応は辛い作業ですが、その不具合を抽象化してシステム全体を点検するプロセスは、コードベースの健全性を一気に引き上げるチャンスでもあります。「その場しのぎ」の修正で終わらせるか。 AIを相棒にして「類似問題を根絶」し、二度とユーザーを失望させない体制を作るか。この徹底した姿勢の積み重ねが、ブレないシステムと、揺るぎないプロの信頼を形作るのだと僕は信じています。
- 障害調査は「推理」と「根気」の総力戦
  1. はじめに：調査の成否は「コードを読む前」に決まるシステム障害が発生したとき、すぐにコードを一行ずつ読み始めていませんか？実は、障害調査のプロが最初に行うのは、コードの分析ではなく**「前提条件の整理」と「初歩的なミスの排除」**です。ここを疎かにすると、存在しない幽霊を追いかけて何時間も浪費することになります。2. まず「足元」を疑え：初歩的なミスの確認高度なロジックを疑う前に、まずは以下の「サニティ・チェック（健全性確認）」を行いましょう。バージョンの不一致: 今見ているソースコードは、本当に本番で動いているバージョンと同じですか？「直したはずのバグが再発した」と思ったら、古いイメージがデプロイされていた、というのは非常によくある話です。環境の取り違え: 接続先DBや設定ファイルが、開発環境のものになっていませんか？そもそも動いているか: サービスは起動しているか、ポートは開いているか、ディスク容量はフルになっていないか。こうした「前提」が崩れている場合、いくらロジックを調査しても正解には辿り着けません。3. 生成AIを「壁打ち相手」にして思考のバグを取る一人で調査していると、どうしても思考にバイアス（思い込み）がかかります。ここで有効なのが生成AIを活用した壁打ちです。ラバーダック・デバッグの拡張: AIに今の状況を説明してください。「〇〇という現象が起きていて、自分は××が原因だと考えているが、他に可能性はあるか？」と聞くことで、自分では気づけなかった「第3の可能性」をAIが提示してくれます。前提条件の検証: 「このエラーログが出る場合、システム構成上、どこに矛盾があるか？」と問いかけることで、自分の「前提」が間違っていないかを客観的にチェックできます。4. 障害の「場所」を絞り込む：仕様か、実装か「どこで起きているか」の切り分けは、以下の2軸で考えます。システム知見による「当たり」: 「この挙動ならあのミドルウェアかDBだ」と経験で絞り込む。内部実装の深掘り: OS、ライブラリ、外部サービスの仕様や内部実装を読み解かないと解けない問題。特に外部サービスの仕様変更などは「知らないと解けない」ため、ドキュメントの読み込みが必須です。5. 再現性との戦い：泥臭い検証のプロセス場所が絞れたら、機能とログから「犯人（原因）」を追い詰めます。再現できる場合: 当たりがついた証拠です。デバッガを動かし、仮説を検証すれば解決は目前です。再現できない場合（真の難所）: 机上確認: ソースコードを読み込み、レースコンディション（競合）などを理論立てて推測。ログの強化: 再現を待つために、より詳細な情報を出す「罠（デバッグログ）」を本番に仕込みます。根気が必要ですが、証拠を掴むための重要な一歩です。 6. まとめ：急がば回れ、基本を疑え障害調査は、パズルを解くような知的な楽しみがある一方で、多くの時間は「思い込みとの戦い」です。「自分が正しいと思っている前提は、本当に正しいのか？」「AIならこの状況をどう見るか？」この視点を持つだけで、調査のスピードは格段に上がります。根気強く、かつスマートに。基本とAIを武器にして、迷宮から脱出しましょう。
- システムの健全性を保つための「戦術的撤退」と「論理的抵抗」
  1. はじめに：システムを守るのは、コードを書く手だけではない運用を続けていると、必ずと言っていいほど「リソースの有効活用」という名の無理難題が降ってきます。「ライセンス料を浮かせたいから、既存のDBを別のシステムにも開放してくれないか？」こうした依頼は、経営やコストの観点からは正解に見えるかもしれません。しかし、安易に「YES」と答えることが、数年後の「運用地獄」の引き金になることを、私たちは知っています。2. 「安易な許可」が招く、見えないコストなぜ私たちは、リソースの共有や強引な変更を渋るのでしょうか。それは保身ではなく、システムの安定という「約束」を守るためです。障害の切り分けが困難になる: どちらかのシステムの負荷や不具合が、もう一方を巻き添えにする。原因究明に倍の時間がかかるようになります。メンテナンスの自由が奪われる: 片方のパッチ当てのために、もう一方の合意が必要になる。「いつでも直せる」はずのシステムが、身動きの取れない巨塔に変わってしまいます。3. 「感情」ではなく「論理」で戦う「なんとなく嫌だ」という感情的な反論は、プロフェッショナルではありません。私たちがすべきなのは、リスクを可視化し、相手に選んでもらうことです。論理的な説明: 「DBを共有すればライセンス料は下がりますが、障害時の復旧時間は○倍に延び、メンテナンスの調整コストが年間でこれだけ発生します」と、定量・定性両面で示します。「説得」は誠実さの証: 頑固に突き放すのではなく、「このシステムを健全に保ちたい」という共通のゴールに向かって、最善の妥当案を模索します。4. それでも「やる」と言われた時の立ち回り論理を尽くしても、ビジネス上の判断でリスクのある道が選ばれることはあります。その時、エンジニアができる最後の防衛策は**「証跡」**です。リスクの合意（インフォームド・コンセント）: 発生しうる問題とその責任の所在を明確にし、文書として残します。「私たちはリスクを伝え、相手はそれを理解した上で受け入れた」という事実が、後の自分たちを救います。保身ではなく、プロとしての責任: 嫌われてプロジェクトから外されることを恐れて「YES」と言うのは、プロの誠実さとは言えません。たとえ疎まれても、言うべきことを言う勇気が必要です。5. まとめ：ブレない軸を持つということ「いいエンジニア」とは、なんでも言うことを聞く人のことではありません。システムの未来を見据え、時には衝突を厭わずに「守るべきライン」を死守できる人のことです。プロジェクトから外されるリスクはあるかもしれません。しかし、技術的な良心を売ってまで手に入れた「平穏」に、どれほどの価値があるでしょうか。ブレないシステムを創り続けるために、今日も私たちは論理という武器を持って、建設的に戦いましょう。
- ソフトウェア開発の「管理のための管理」を終わらせる
  1. なぜ2025年になっても「Excel方眼紙」が生き残るのかBacklog、Jira、Notion……世の中には優秀な管理ツールが溢れています。それでもExcel方眼紙が駆逐されないのは、以下のような「現場の制約」があるからです。外部接続の禁止: クラウドツールへのデータ保存が許可されない。サーバ設置の壁: 自前でRedmineなどを立てたくても、情シスの許可やメンテナンスコストが壁になる。「誰でも開ける」という呪縛: 結局、標準インストールのExcelが一番無難とされてしまう。しかし、Excel方眼紙での管理には大きな代償があります。タスクの組み替えに時間を取られ、本来すべき「改善」や「問題への対処」に時間が使えなくなる。これこそが真の「管理コスト」です。2. 生成AIで「自分専用の管理ツール」を自作するサーバを立てられず、外部サービスも使えない。ならば、**「自分のPC内で完結する軽量ツール」**をAIに作らせるのが、現代のエンジニアの生存戦略です。案①：ポータブルな「プロジェクト管理HTML」AIに、JavaScriptを活用した単一のHTMLファイルを作成してもらいます。「入力用」と「表示用」を分けることで、データの管理もスムーズになります。メリット: ブラウザさえあれば動く。インストール不要。機能: ガントチャートの自動描画、タスクのソート、JSON形式でのデータ保存。AIに頼めば、数分で自分好みのUIが手に入ります。案②：Python等のGUIプログラムもし実行環境が許すなら、AIにPython（TkinterやPyQt）でデスクトップアプリを書かせるのも手です。メリット: ファイル操作が楽になり、履歴のバックアップ（Snapshot機能）なども実装しやすい。解決策: 「スケジュール見直し前のデータに戻れない」というExcelの弱点を、AIに「世代管理機能」をコードに含めてもらうことで解決します。3. どうしてもExcelを離れられない場合の「AI活用術」組織のルール上、どうしてもExcelで提出しなければならない場合も、AIを使って「方眼紙の呪い」を軽減しましょう。 VBA/Officeスクリプトの生成: 「日付が変わったらガントチャートの色を塗り替える」「タスクを追加したら自動で段を整える」といった面倒な作業を、AIにスクリプトを書かせて自動化します。「記録」をAIに任せる: Excelの問題点である「何を行い、何が起きたか」の記録しづらさ。これを、日々のメモをAIに食わせて「Excelに貼り付けるための進捗報告テキスト」へ整形させることで補完します。4. まとめ：管理の目的は「描画」ではなく「意思決定」Excel方眼紙の最大の問題は、**「スケジュールを変更することへの心理的・物理的ハードルが高くなり、変化に対応できなくなること」**にあります。生成AIを活用してツールの構築コストを下げれば、浮いた時間を「タスクの再検討」や「リスクの特定」といった、本来のプロジェクト管理の仕事に充てることができます。「環境が許さないから」と諦める必要はありません。AIという強力なエンジニアを雇ったつもりで、自分たちの現場に最適な「脱・方眼紙」の仕組みを今こそ構築しましょう。
- SES会社の現場任せの脱却できないか
  1. はじめに：SESエンジニアの「孤独な成長」SESという働き方は、多様なプロジェクトを通じて短期間に多くの経験を積める、エンジニアのキャリアにとって非常に魅力的な仕組みです。しかしその一方で、エンジニアからは**「自社は何もしてくれない」「現場に放り出されただけ」**と思われ、離職に繋がってしまうケースが後を絶ちません。会社として何かしたくても、そこにはSES特有の「構造的な壁」が立ちはだかっています。2. 知識共有を阻む「NDAの壁」と「自律」の限界会社が教育やナレッジ共有を行おうとしても、現場の具体的な技術情報は**秘密保持契約（NDA）**に縛られています。具体的に教えられない: 「あの現場のあのコード」を自社で共有することはできません。自助努力への依存: 結果として、スキルアップはエンジニア個人の努力に委ねられ、会社は「案件を割り当てるだけ」の存在になりがちです。しかし、現場で起きる問題の多くは、実は「最新技術の知識不足」ではありません。**「プロジェクトの進め方」や「コミュニケーションの齟齬」**といった、ソフトスキルの領域であることがほとんどです。3. 生成AIが「24時間寄り添うメンター」になる未来ここに、SES企業が提供できる新しい価値のヒントがあります。具体的な技術情報は共有できなくても、**「業務の進め方のベストプラクティス」や「メンタルケア」**なら、会社として全方位的にサポート可能です。 AIによる業務ナレッジの提供: 「炎上しそうな時の報告の仕方」や「仕様が曖昧な時の確認方法」など、NDAに触れない汎用的な「現場での立ち回り方」をAIがアドバイス。生成AIメンタルケア: 自社の人間には言いづらい悩みも、AIチャットなら気軽に吐き出せます。孤独を感じやすい客先常駐において、AIが「最初の聞き役」になることで、心理的安全性を高めます。4. DXで実現する「科学的なマッチング」とサポートさらに、エンジニアの声をデータとして集計・分析することで、会社側のサポートはより戦略的になります。相談事のデータ集計（DX）: AIへの相談内容を匿名化して集計。どの現場でどんな「負の予兆」が出ているかをいち早く察知し、手遅れになる前に人間が介入（フォロー面談など）を行います。マッチング精度のAI分析: 「どんなスキルの人が、どんな文化の現場で活躍したか」を分析。単なる技術マッチングではなく、「定着率や満足度が高い現場」への最適配置をAIがレコメンドします。5. まとめ：SES企業は「プラットフォーム」へこれからのSES企業に求められるのは、単なる「人貸し」ではなく、エンジニアがどの現場に行っても最高のパフォーマンスを出せるための**「高機能なサポート・プラットフォーム」**としての役割です。AIとDXを駆使して、エンジニアのメンタルとキャリアを科学的に支える。それこそが、「自社にいてよかった」と思ってもらえる、次世代のSESの姿ではないでしょうか。
- ITエンジニアの人手不足とは？
  1. 「人手不足」の正体：現場で起きている3つの矛盾世間では「ITエンジニアが足りない」と騒がれていますが、現場の実態はもっと複雑です。人が足りないと言いながら、実際には「人を入れられない」構造的な矛盾が3つ存在します。「時間」のミスマッチ：単純な工数不足。本来は納期調整やスコープ削減で解決すべきですが、「決まったものは変えられない」という空気がそれを許しません。「知見」の偏り：特定の人（Aさん）にしかわからない業務が山積みになり、新人を投入しても教育コストがかかりすぎるため、結局Aさんが一人で抱え込み続けています。「予算」の壁：残業代は出せない、追加予算もない。でも成果は欲しい。この「詰んでいる」状況が、現場を疲弊させています。2. 生成AIで人手不足は解消するのか？結論から言うと、「定型的なエンジニアリング」における人手不足は解消へと向かいます。しかし、「ビジネス上の課題を解決する」ためのエンジニア不足は、むしろ加速するでしょう。解消される部分：「コードを書く」「テストを作る」「不具合を探す」「古いコードを読み解く」といった作業時間は、AIによって50%以上削減可能です。これにより「時間の不足」は劇的に改善します。解消されない部分：「何を作るべきか決める」「複雑なステークホルダーと調整する」といった、人間の意図や感情が絡む領域は依然として残ります。現場への影響：AIを使いこなす1人が、AIを使わない数人分の仕事をこなすようになるため、単純な「頭数（人数）」を揃える必要性は確実に減っていきます。3. 生成AIで「人手不足」をハックする具体的な4つの方法予算も時間も限られた現場で、どう効率化を進めるべきか。具体的な活用プランを列挙します。① 「知見の偏り」をAIで民主化する（有識者の保護）コードベースの要約と解説：「前任者がいなくて解読不能なコード」をAIに読ませ、ロジックを解説させます。ドキュメント学習型QA：過去の仕様書やSlackのログを学習したAIを設置。メンバーがAIに質問して自己解決することで、有識者の「質問攻めに合う時間」を1分でも多く削減します。② 「実装とテスト」の工数を極限まで削るボイラープレートとデモの瞬時生成：雛形作成はAIに任せ、人間は核となるロジックに集中します。ワイヤーフレームからのデモ生成：手書きスケッチ等から即座にプロトタイプを生成し、発注元との合意形成を高速化して手戻りを防ぎます。③ 「ドキュメントと調整」をショートカットする仕様書からタスクへの分解：曖昧な仕様から具体的なタスクリストをAIに作らせ、設計の初動を早めます。事務作業の自動化：進捗報告や定型メール、バグ票の起票など、地味に時間を食う作業をAIに代筆させます。④ 成果の「傾斜配分」による戦略的リプレース 100点と80点の使い分け：発注元が気にする「肝となる機能」には人間が時間を割いて100点を狙いますが、それ以外の一般的な機能（設定画面など）はAIに「標準的な仕様」で埋めてもらい、80点の出来で素早く仕上げます。これにより、全体の設計コストを大幅に圧縮できます。4. まとめ：これからの「人手不足」との向き合い方今後、人手不足を嘆き続けるチームと、AIを味方につけて悠々と開発を進めるチームの二極化が進むでしょう。人手不足を解決するのは、さらなる採用ではありません。開発速度を上げ、コストを下げ、浮いたリソースで「価値ある部分」に注力することです。「人が足りないから人を入れよう」という発想の前に、**「AIでこの知見不足を補えないか？」「AIでこの作業時間を1/10にできないか？」**と考える。それが、予算も時間も限られた現場で、エンジニアが自分たちの身を守る唯一の手段になるはずです。
- 今こそレガシーシステムを駆逐するべき
  1. なぜ「ゾンビシステム」は生き残り続けるのかレガシーシステムが駆逐できない理由は、技術的な問題よりも「恐怖」と「無知」にあります。ブラックボックス化: ソースコードはあっても、意図を理解できる人間がいない。ドキュメントの喪失: 最後に更新されたのは10年前、といった「化石」のようなドキュメント。環境の制約: 「Windows 11で動かないから、古いOSを仮想環境で無理やり動かす」といった綱渡りの運用。これまでは、これらを紐解くために膨大な工数と「有識者の記憶」が必要でした。しかし、その前提が今、崩れ去っています。2. 生成AI：24時間働く「超凄腕リバースエンジニア」ソースコードさえ残っていれば、生成AIは現代の「考古学者」として機能します。コードの意図を瞬時に解読: スパゲッティコードや、今はなき古い言語（COBOLやVB6など）であっても、AIは「このロジックは何をしようとしているのか」を現代の言葉で解説してくれます。ドキュメントの自動再生成: コードから仕様書やER図を書き起こし、失われた「設計図」を取り戻せます。モダンな言語への翻訳: 動作ロジックを維持したまま、JavaやGo、Rubyといった現代的な言語、あるいはクラウドネイティブな構成へと変換・修正案を提示してくれます。3. 「失敗しない」リプレース戦略：並行稼働と漸進的移行レガシー刷新における最大の恐怖は「一斉切り替え（ビッグバン・リプレース）の失敗」です。ここでもAI時代の新しい戦術が有効です。シャドウ稼働（並行稼働）: 旧システムと新システムに同じ入力を流し、出力が一致するかをAIを使って自動比較検証します。ストラングラー・フィグ・パターン（絞め殺しパターン）: システムの端から少しずつ、特定の機能だけをAPI化して新システムへ逃がしていく。問題があれば即座に旧システムにルーティングを戻すことで、ダウンタイムとリスクを最小限に抑えられます。 AIによるデバッグ支援: 移行中に不一致が起きた際も、AIが両方のコードを突き合わせ、「なぜ結果が異なるのか」の原因を特定してくれます。4. 2025年、レガシーを放置するリスクは最大にWindows 10のサポート終了など、プラットフォーム側の限界が近づく中、「動いているから触らない」という選択肢は、もはやリスクでしかありません。AIを活用すれば、これまで1年かかっていたリサーチが1ヶ月で終わるかもしれません。「システムを理解している人がいないからできない」という言い訳が通用しなくなった今こそ、攻めのリプレースに転じる絶好の機会です。まとめ：技術負債を「技術資産」へレガシーシステムの中に眠るロジックは、長年ビジネスを支えてきた「知恵」の塊でもあります。それをAIの力で抽出し、モダンな環境へと解き放つこと。それは単なる「古いものの破棄」ではなく、**過去の資産を未来の競争力へと変える「錬金術」**です。
- LinuxコマンドのようにAPIを繋ぐ。関数型思考が加速する「自動化の未来」
  1. はじめに：Unix哲学が今、再び輝き始めたプログラミングの世界には、古くから愛されているUnix哲学があります。「1つのことをうまくやり、プログラム同士が協力できるように、テキストストリームを通じて繋ぐ」。あのcat | grep | sedのようなパイプの快感です。最近、この「ステートレス（状態を持たない）な部品を繋ぎ合わせる」という関数型に近い考え方が、Web APIの設計や業務自動化の文脈で再評価されるべきだと感じています。2. ステートレスAPIは「Web界のLinuxコマンド」これまでの社内システムは、巨大なデータベースを抱え、複雑な「状態（ステート）」を管理するモノリスなものが主流でした。しかし、これからはもっと**「単機能でステートレスなAPIサーバ」**が活躍するのではないでしょうか。入力に対して一意な出力を返す: 関数型プログラミングの「純粋関数」のように、副作用を最小限にしたAPI。状態を持たない強み: どこからでも、何度でも呼び出せる。この「予測可能性」が、システムを部品に変えてくれます。こうしたAPIが揃うことは、いわば社内システムの中に「自分たち専用のLinuxコマンド」を揃えていくようなものです。3. n8nと生成AIが「シェルスクリプト」になるこうした「部品としてのAPI」が揃った時、それらを繋ぎ合わせる役割を果たすのがn8nのようなワークフロー自動化ツール（ノーコードツール）です。かつてエンジニアがシェルスクリプトを書いてコマンドを繋いだように、今はn8nのフローでAPIを繋ぎます。ここで面白いのが生成AIの存在です。 AIがフローを組み立てる: ステートレスでシンプルなAPIさえ用意されていれば、AIに「この業務を自動化するn8nのフローを作って」と頼むのが容易になります。複雑な状態管理はAIも苦手: 逆に、システムが複雑な状態（フラグやセッション）を抱えていると、AIでもフローを組むのが難しくなります。つまり、**「人間（エンジニア）がシンプルなステートレスAPIを用意し、AIがそれを繋いで業務を自動化する」**という役割分担が成立するのです。4. 社内システムを「自動化のツールボックス」へもし社内の基幹システムや、日常的なDB操作がすべて「ステートレスなAPI」として切り出されていたらどうでしょう。「承認を投げるAPI」「在庫を確認するAPI」「Slackに通知するAPI」これらが用意されていれば、非エンジニアであっても、あるいはAIであっても、それらを組み合わせて「自分たちの業務に最適な自動化フロー」を即座に作れるようになります。これこそが、本当の意味での業務改善の加速ではないでしょうか。5. まとめ：関数型プログラムの思想が、組織を自由にさせる「関数型プログラミング」というと難しく聞こえますが、その本質は**「予測可能な部品を作る」**ことにあります。システムを巨大な塊として作るのではなく、ステートレスなAPIという「部品」として構築し、AIやノーコードツールという「糊」で繋ぎ合わせる。この構造シフトが進むことで、エンジニアは「実装」だけでなく、組織全体の「自動化の可能性」を広げる存在になれるはずです。Linuxコマンドが40年以上愛されているように、シンプルで純粋な「繋がるAPI」こそが、これからの自動化時代の基盤になる。そう確信しています。
- 日陰となってまったRubyの再興はあるか
  1. はじめに：型安全の時代、そしてAIの襲来ここ数年、エンジニア界隈のトレンドは「自由」から「秩序」へと大きく舵を切りました。TypeScriptやGo、Rustといった型安全（タイプセーフ）な言語が支持されるようになったのは、システムの巨大化に伴い「自由すぎるコード」が怖くなったから、という側面があるでしょう。Rubyは「古き良き自由な言語」として、少し脇役に回ったように見えました。しかし、今ここに**「生成AI」**という巨大な変数が加わったことで、ゲームのルールが再び変わろうとしています。2. 「書く」ことが減る時代の、新しいボトルネックGitHub CopilotやCursorを使っていると、コードを書く量は劇的に減りました。今や、数百行のボイラープレート（定型文）はAIが一瞬で吐き出してくれます。そこで重要になるのが、**「コードリーディング容易性」**です。AI時代、エンジニアの時間のほとんどは「AIが書いたコードが正しいかチェックする」「少しだけ意図に沿うように修正する」ことに費やされます。となれば、**「パッと見て意図がわかること」「1行直すのが苦じゃないこと」**が、かつてないほど重要になるのです。3. Rubyは「AIと人間の最良の通訳」になるAIにとって「読みやすい（パターンが明快な）」コードは、人間にとっても読みやすいとは限りません。しかし、Rubyは徹底的に「人間にとっての美しさ」を追求して作られました。「読む」コストの低さ： Rubyのコードは、まるで自然言語（英語の文章）のように読めます。AIが生成したロジックを人間がレビューする際、この「認知的負荷の低さ」は、バグの早期発見やメンテナンス性の向上に直結します。「型」の窮屈さをAIが補完する：かつて、型がないことは「不安」でした。しかし今は、AIがコンテキストを読み取り、推論してくれます。人間は厳格な型定義に追われる代わりに、Rubyの柔軟なシンタックスを使い、AIと対話しながら「意図（インテント）」を表現することに集中できるのです。4. 「少しの修正」に宿るワクワク感生成AIによって仕事の8割が自動化されたとしても、残りの2割——「自分の手でコードを磨き上げる瞬間」——に喜びがなければ、プログラマとしての人生は味気ないものになってしまいます。Rubyの素晴らしいところは、たとえ一行の修正であっても、そのコードの短さや表現のスマートさに「おっ、いいな」と思える**ワクワク感（Developer Happiness）**があることです。AIに下書きをさせ、人間がRubyで最後の一筆を入れる。この「心地よい修正」の体験こそが、これからのエンジニアのモチベーションを支える鍵になるのではないでしょうか。5. 2025年、立ち位置を問い直すRubyは今、単なる「Web開発の道具」から、**「AI時代のヒューマン・インターフェース」**へと進化しているように思えます。性能の進化：YJIT等の恩恵で、実行速度の不安も過去のものになりつつあります。適材適所：堅牢さが絶対のコア部分はGoやRustで。でも、人間が直接触れ、AIと共に試行錯誤するフロントやロジック層にはRubyを。多種多様な言語が求められる今だからこそ、「書き心地の良さ」というRubyの本質的な価値が、一周回って「最強の武器」として戻ってきていると感じます。結びに：コードに「愛着」を持てる幸せAIが何万行のコードを書こうとも、最後にそのスイッチを押すのは人間です。その時、自分の目の前にあるコードが愛せるものであるかどうか。「効率」や「型」だけではない、プログラミング本来の楽しさを教えてくれるRuby。AI時代という新しいステージで、僕はこの言語とさらに深く付き合っていきたいと思っています。
21Jul
- CakePHP ログの出力
  CakePHP では、ログの出力が簡単に出来ます。// Cakephp Objectクラス継承したクラスでは$this->log('ログに出力するメッセージ', ログタイプ);// その他CakeLog::write(ログタイプ, 'ログに出力するメッセージ');log関数では、CakeLog::writeを呼び出すだけのためどちらを使っても処理としては同じパフォーマンスを気にするならば後者（関数呼び出しがひとつ不要）将来処理が変わるかもしれないことを気にするならば前者くらいに思っていればいいのかなログタイプはあくまでタイプでありbootstrap.phpに定義されているファイルの出力方法に従ったりするここからはしたは、CakePHP 2.3の場合として読んでくださいLOG_DEBUGに設定したとしてもcore.phpのConfigure::write('debug', 0);にしてもファイルは出力される。App::uses('CakeLog', 'Log');if (Configure::read('debug') != 0) { CakeLog::config('debug', array( 'engine' => 'FileLog', 'types' => array('notice', 'info', 'debug'), 'file' => 'debug', ));}CakeLog::config('error', array( 'engine' => 'FileLog', 'types' => array('warning', 'error', 'critical', 'alert', 'emergency'), 'file' => 'error',));debugの設定を見てCakeLog設定を行うか切り替えることで対応しました。検索するとdebugを0にするとログ（デバッグ、エラー）が出来ないやデバッグログは出力されないという情報もありますがあくまでCakePHP 2.3の場合または、うちの環境の場合という事しか言えないですが
22Jun
- ubuntuで ivy bridgeを使用した場合　グラフィック面で弱い
  調べてみてもubuntu 12.10でカーネルが対応していると言われているがwebサイト閲覧だけでCPUの負荷が高くIntel hd 4000 この程度なのか、ドライバーが正しく使用されていないのかが判断できない様々な対応を行なってきた1.intelが配布しているドライバーのインストール2.xorg.confの設定2.が効果あったように思える/etc/X11/xorg.conf.failsafeSection "Device" Identifier "Intel" Driver "intel" Option "AccelMethod" "sna"EndSectionなにかと不安だけどこれを設定し再起動することで多少体感できるくらいよくはなった不安要素--------■xorg.confではなくxorg.conf.failsafeなこと本当に効果あるのか■snaってSandy Bridge New Accelerationの略ivyでも使用出来るのかまた今後のcpu haswellなどでも使用できのか--------haswellが発売しているっていうのにいまごろやっとivyのちからが発揮されるようになるとは・・・
26May
- cakephp 同じviewファイルを使用する
  同じビューファイルを使用し同じ事を記述する事を書くのは無駄なため同一のファイルでできたら最高です!!Controllerのアクションメソッドに$this->render(view名);この記載するとPHPUnitでNotfoundになる場合がありました。大文字小文字の問題でなぜかアクションによって正常に動作する場合としない場合がありましたこの場合もっと正確な名称を記載することで解決ができます。$this->render(クラス名/view名);または、$this->render(common/view名);実際は、クラス名言うよりもViewのフォルダ名だったりしますが置いている場所を指定してください
23May
- Web系開発で注意事項
  まだ経験は浅いものの現在わかっているWeb系開発で注意すべきこと問題解決に向けて同様の問題で悩んでいる記事、掲示板を見るときは、バージョンを気にする必要がある。PHPで言えば5.4から内蔵Webサーバが含まれるようになったFrameworkは、バージョンがすぐに上がり下位互換性がないバージョンの情報の場合は、閲覧しても意味がない環境構築について環境には、様々な要因があり環境構築にどうしても時間がかかる。開発開始時にしっかりと環境を構築するべきサーバが用意できない場合ローカルで環境を作ることはいいがローカルの環境が変更する可能性もあるため仮想環境にサーバを用意したほうが柔軟に対応でき且つ一度作れば、結構安心
22May
- CakePHP Oracle DBの接続
  Cake PHP 2.3.xには、Oracle接続クラスが存在しないそのため、Githubからクラスを取得し使用する。Add support for oracle databasehttps://github.com/cakephp/cakephp/pull/1188ここでのdatabase.phpの記述方法で記述するとcache時に長い名称で警告が出るdatabase.php設定public $default = array( 'datasource' => 'Database/Oracle', 'driver' => 'oracle', 'connect' => 'oci_pconnect', 'persistent' => false, 'host' => 'ip_address', // DBアドレス 'login' => 'username', // DBユーザ 'password' => 'password', // DBパスワード 'database' => 'ip_address:1521/test', // アドレス:ポート/サービス名 'prefix' => '', 'schema' => 'schema_name' // スキーマ名 'charset' => 'AL32UTF8' // UTF8);長々書きましたが上記のクラスには問題があり驟雨性版が以下のサイトに存在します。CakePHP 2.0 Oraclehttps://bitbucket.org/odin88/cakephp-2.0-oracle/overview