ID:85070さん

■プロジェクト概要 大阪花博のCG映像制作でFACOM VPシリーズ向けに開発されたCGライブラリを、UNIX／Sun環境へポーティングする派生プロジェクトに参画しました。 FACOM VPシリーズはベクトルプロセッサを備えたシステムで、CG映像制作のためのライブラリが同環境向けに開発されていました。本プロジェクトでは、そのライブラリをUNIX／Sun環境でも利用できるようにすることを目的として移植作業を行いました。 ■担当業務 CGライブラリのうち、比較的機種依存性の低い部分を担当し、FORTRAN／Cを使用してUNIX／Sun環境へのポーティングを行いました。 FACOM VP固有のベクトル処理部分そのものの移植ではなく、既存ライブラリの構造や処理内容を確認しながら、担当部分を移植先の環境で利用できるよう対応しました。 入社後最初に担当したCG関連の開発案件でしたが、FORTRANは高校時代に、Cは大学時代の組み込み開発ですでに使用経験があったため、両言語とも基礎知識を持った状態で開発に入りました。 ■プロジェクトの経緯 大阪花博本体のCG映像制作ではなく、そこで開発された技術資産を別環境へ展開するための派生プロジェクトでした。 約3か月間開発に携わりましたが、プロジェクト自体が途中で開発中止となりました。 ■技術環境 移植元：FACOM VPシリーズ 移植先：UNIX／Sun 言語：FORTRAN／C ■期間 約3か月 ■役割 CGライブラリのポーティング

■プロジェクト概要 図書館で使用するFACOM 9450端末に、通常のキーボードからロシア文字を入力するための入力補助機能を追加するプロジェクトに参画しました。 通常のキー入力を起点として、キーの組み合わせを判定し、対応するロシア文字へ変換して入力できるようにする機能をアセンブラで開発しました。 ■担当業務 キー入力によって発生する割り込み処理から実装し、入力されたキーの組み合わせを判定して、対応するロシア文字へ変換する処理を開発しました。 FACOM 9450の限られたアドレス空間の中で実装する必要があり、メモリ使用量などハードウェアに近い制約を意識しながらプログラミングを行いました。 デバッグにはハードウェアデバッガーを使用しました。16個のトグルスイッチでブレークポイントを指定し、実機の処理を停止させながら、LED表示で各レジスタの内容を確認してプログラムの動作を追跡しました。 現在のIDEのように画面上でブレークポイントや変数を確認する環境ではなく、実際のCPUの状態をレジスタレベルで確認しながら原因を追うデバッグを経験しました。 ■大学時代の経験とのつながり 大学では制御工学の研究室に所属し、卒業研究としてZ80を使用したマイクロマウスの制御システムを研究していました。 計測系・駆動系・統括系の3CPUを協調動作させる構成で、自身はハードウェア設計を担当し、Cのクロスコンパイラを使用した組み込み開発も経験していました。 そのため、入社後にアセンブラ、割り込み処理、限られたアドレス空間、ハードウェアデバッガーによる実機デバッグという環境に入っても、ハードウェアに近い開発そのものには特に抵抗感はありませんでした。 実務期間は約2か月と短期間でしたが、大学時代から制御・組み込み開発の基礎経験があったことも、短期間で実装・デバッグまで担当できた背景の一つだったと考えています。 ■開発環境 端末：FACOM 9450 言語：アセンブラ デバッグ：ハードウェアデバッガー 開発内容：キー入力割り込み処理、キー入力判定、ロシア文字変換処理 制約：限られたアドレス空間での実装 ■期間・体制・役割 期間：約2か月 体制：2名 担当：プログラミング、単体テスト、実機デバッグ

■プロジェクト概要 電力事業者の工事・資材・計画に関連する業務システム開発に参画しました。 ■担当業務 COBOLによるプログラミングおよび単体テストを担当しました。 COBOLは高校時代に授業で学習しており、大学時代には約3年間、臨床検査会社（血液検査センター）でのアルバイトを通じて、NEC製オフィスコンピュータ上で動作するCOBOL業務システムの開発を経験していました。 そのため、入社後の本プロジェクトでも、COBOLによる業務システム開発には抵抗なく取り組むことができました。 ■開発環境 言語：COBOL ■期間・役割 期間：約4か月 担当：プログラミング、単体テスト

■概要 建築CGを得意とするCGスタジオ、株式会社プラス・ワンにソフトウェアエンジニア／技術スタッフとして入社しました。 主な役割は、CGそのものを制作することではなく、デザイナーやCGアニメーターが制作を行うための技術環境を整え、必要なソフトウェアやインハウスツールを開発することでした。 HP製UNIXワークステーションを開発・制作環境として使用し、主にC言語による開発を担当しました。 ■CG制作支援・インハウスツール開発 CG制作現場から必要とされる機能に応じて、制作を支援するインハウスツールを開発しました。 市販ソフトウェアだけでは対応できない処理や、制作工程上必要となる機能をプログラムとして提供し、CGクリエイターが技術的な処理をできるだけ意識せず、制作作業に集中できる環境を整えることを重視しました。技術そのものを目的とするのではなく、実際にツールを使用する制作スタッフにとって扱いやすい仕組みにすることを意識していました。 ■CADデータの解析・CGデータへの変換 建築CGでは、設計会社が保有するCADデータをCG制作で利用する必要がありました。 そのため、CADメーカーとも連携しながら、CADデータの構造や仕様を調査し、CG制作で利用可能なデータへ変換するプログラムをC言語で開発しました。 データ形式の内部構造が十分に把握できない場合には、CAD上でプリミティブな図形をいくつか作成し、図形の種類や座標などの条件を意図的に変えながらバイナリファイルをダンプしました。それぞれのダンプ結果に現れるパターンの違いを比較し、変更した条件とバイナリ上の差分との関係から、図形や座標等がどのように表現されているのか仮説を立て、さらに条件を変えて検証することでデータ構造を解析しました。 大学時代にはZ80を使用したハードウェア設計とCのクロスコンパイラによる組み込み開発、前職ではアセンブラ、割り込み処理、メモリやレジスタを意識した実機デバッグを経験していたため、バイナリダンプをコンピュータ内部のデータ表現として捉え、低いレベルから構造を追うことにも抵抗がありませんでした。 解析したデータ構造を基に、CADデータからCG制作に必要な情報を抽出し、CG側のデータ形式へ変換するプログラムを開発しました。 ■設計会社・CADメーカーとの技術調整／長野オリンピック誘致CG CAD→CG変換は、プログラムだけで完結する仕事ではありませんでした。 実際の設計業務でCADデータがどのように作られているのかを理解するため、設計会社と連携してデータや運用を確認しました。また、必要に応じてCADメーカーともデータの書き出し方法や仕様について確認・調整しました。 こうした経験を実際の制作案件で活用した一つが、長野オリンピックの開催決定前に制作された誘致活動用CGです。 オリンピック施設をCG化するため、設計会社等が保有するCADデータを受け取り、CG制作で利用できるデータへ変換する技術支援を担当しました。 設計側のCADデータは、必ずしもそのままCG制作へ利用できるものではありません。設計業務で必要とされる情報と、CGで形状や空間を再現するために必要な情報には違いがあるため、CADデータの構造や内容を確認し、CG制作側で必要となる情報を取り出して利用できる形へ変換する必要がありました。 そのため、CG側の都合だけで変換方式を決めるのではなく、設計会社がどのようにCADデータを作成しているのかを理解し、必要に応じてCADメーカーともデータの出力方法を調整しながら、設計データとCG制作の間をつなぐ仕組みを構築しました。 私の役割はCG映像そのものを制作することではなく、設計会社から渡されるCADデータを、CGクリエイターが制作に利用できる状態へ橋渡しすることでした。 また、建築CGを専門とするスタジオであったことから、業務を通じて安藤忠雄氏、隈研吾氏、原広司氏など著名建築家の建築作品に関するCG制作に、技術面から触れる機会もありました。 こうした環境の中で、建築・設計側の情報とCG制作側の技術をつなぐ経験を積みました。 ■技術的な特徴 この時期は、すでに仕様が確定したプログラムを実装するだけではなく、制作現場から必要なものを把握し、分からないデータ構造は自ら調査・解析し、必要なツールや変換プログラムとして実装する仕事を経験しました。 特にCADデータ解析では、 ・単純なデータを作る ・条件を一つずつ変える ・バイナリダンプを比較する ・差分から内部構造について仮説を立てる ・別の条件で再度検証する ・解析結果をプログラムへ落とし込む という方法で、仕様が十分に分からない対象についても構造を明らかにしていきました。 また、技術者だけで閉じるのではなく、実際にツールを使用するCGクリエイター、データを提供する設計会社、CADメーカーなど、それぞれ異なる立場の関係者とやり取りしながら、制作現場で実際に使える仕組みへ落とし込む経験を積みました。 ■開発環境 ハードウェア：HP製UNIXワークステーション OS：UNIX 言語：C 主な開発内容： ・CG制作支援用インハウスツール ・CADデータ構造解析 ・CAD→CGデータ変換プログラム ■その後へのつながり この時期に、ソフトウェアを単独で考えるのではなく、「誰が何のために使うのか」「前後の工程やシステムとどうつながるのか」を考えながら開発する経験を積みました。 また、分からない対象に対しても、観察できる状態を作り、差分から仮説を立て、検証しながら構造を理解していくという問題への取り組み方は、その後の技術支援やシステム開発にもつながっています。 さらに、CAD→CG変換では、設計会社、CADメーカー、CG制作スタッフという、それぞれ異なる目的や専門性を持つ関係者の間に入り、技術によってデータを橋渡しする経験をしました。 こうした技術的な経験を土台として、その後は顧客との技術的な打ち合わせや提案にも関わるようになり、制作ディレクションや技術営業へと担当領域を広げていきました。

■プロジェクト概要 大手住宅メーカーが参画するNEDO関連研究プロジェクトにおいて、同社へのCG技術支援を担当しました。 大手住宅メーカーの担当範囲では、外構設計に見られる規則性を利用した自動生成と、その結果のCG化に取り組んでおり、プラス・ワンはCG技術の専門会社として研究を支援しました。 ■担当業務 大手住宅メーカーを技術支援する立場でワーキンググループ（WG）に参加し、CG技術に関する知見を提供しながら、技術的な検討に携わりました。 外構設計に含まれる規則性をどのようにコンピュータで扱い、自動生成された結果をCGとして可視化するかという研究に対し、CG技術面から検討を支援しました。 また、技術的な検討だけでなく、研究結果の整理や報告書作成にも携わり、研究活動の成果を文書としてまとめるところまで支援しました。 ■役割 ・大手住宅メーカーへのCG技術支援 ・ワーキンググループ（WG）への参加 ・CG技術に関する技術的検討 ・研究結果の整理 ・報告書作成 ■この経験から広がった役割 このプロジェクトでは、プログラムやCG制作だけを担当するのではなく、大手住宅メーカーの担当者とともに研究内容を検討し、技術的な知見を提供しながら成果を整理する経験をしました。 それまでのCG制作支援・ソフトウェア開発から、技術を理解したうえで社外の担当者と一緒に課題を考える仕事へ、担当領域が広がる経験の一つとなりました。 また、このプロジェクトで技術支援した大手住宅メーカーの担当者が、その後、同社の展示施設へ異動しました。その担当者から展示システムについて相談を受けたことが、後にマルチメディアシステム制作のディレクションへ担当領域を広げるきっかけとなりました。

■制作ディレクターへ担当領域を広げた経緯 CGスタジオのソフトウェアエンジニアとして、CG制作支援ツールやCAD→CGデータ変換などの開発に携わる一方、NEDO関連研究プロジェクトでは、大手住宅メーカーへのCG技術支援としてワーキンググループ（WG）に参加しました。 WGでは技術的な検討だけでなく、研究結果の整理や報告書作成にも携わり、大手住宅メーカーの担当者とともに課題を考え、技術的な知見を提供する経験をしました。 その後、このプロジェクトで関わった担当者が同社の展示施設へ異動し、展示システムについて相談を受けたことをきっかけに、マルチメディアシステム／コンテンツ制作のディレクションへ担当領域を広げました。 ■企画・ストーリー構成 制作ディレクターとして重視していたのは、顧客から提示された要望をそのまま制作物にすることではなく、まず「誰に、何を、どう伝えるのか」を顧客と一緒に整理することでした。 企業の展示施設や販売促進用キオスクなどでは、利用者は必ずしも最後までコンテンツを見てくれるとは限りません。途中で立ち去ることもできる利用者に興味を持ってもらい、自ら操作しながら最後まで体験してもらうためには、情報を並べるだけでなく、コンテンツ全体にストーリーを持たせる必要があると考えていました。 顧客や広告代理店との打ち合わせを通じて、制作の目的や対象となる利用者を整理し、コンテンツ全体のストーリーや構成を企画しました。 ■顧客・広告代理店との折衝／制作ディレクション 企画した内容を実際の制作物へ落とし込むため、デザイナーやCGアニメーターなどの制作スタッフへ、制作意図や方向性を伝え、制作指示、進行管理、成果物の確認を行いました。 単に個々の制作物をチェックするのではなく、プロジェクト全体を俯瞰し、映像、CG、文章、ナレーション、ソフトウェアなど、それぞれの要素が一つのストーリーとして成立しているかを意識していました。 また、顧客・広告代理店と制作スタッフの間に立ち、顧客側の要求や意図を制作側が理解できる形へ整理するとともに、制作・技術上の制約については顧客側へ説明し、双方を調整しながらプロジェクトを進めました。 ■ナレーション原稿作成・収録ディレクション ナレーションを使用する案件では、原稿作成にも携わりました。 文章として正しいことだけではなく、実際に声にしたときにどのように聞こえるか、こちらの意図がナレーターにどのように伝わるかを意識して原稿を作成しました。 同じ読み方をする言葉でも、意図するニュアンスを伝えやすくするために、ひらがなとカタカナを使い分けることもありました。 「何を伝えたか」だけではなく、「相手にどう伝わるか」を考えることを重視していました。 また、ナレーターの選定・手配、収録場所の確保、関係者とのスケジュール調整、収録時のディレクションなど、企画した内容を実際の成果物として成立させるための各種手配も担当しました。 ■ソフトウェア・外部機器を含めたシステム制作 制作ディレクターへ担当領域を広げた後も、ソフトウェアエンジニアとしての経験を活かし、必要に応じて自らオーサリングやプログラム開発を行いました。 Macromedia Directorを中心にシステムを構築し、案件に応じてVisual Basic／ActiveX等も使用しました。 展示施設や販売促進システムでは、画面上のコンテンツだけでなく、プロジェクタ制御、サーマルプリンタによる印刷、パンフレット印刷など、外部機器と連携するシステムにも携わりました。 そのため、コンテンツの企画だけではなく、ソフトウェアや外部機器を含めて、「実際の展示空間や利用場所でどのように動くのか」まで考えながらディレクションを行いました。 ■主な制作案件 ・大手住宅メーカーの展示施設向けマルチメディアシステム ・マンション販売関連の展示キオスク／プロジェクタ連携 ・大手化学メーカーの学生向けCD-ROMコンテンツ ・ガス事業者の展示システム／サーマルプリンタ連携 ・住宅関連展示システム／パンフレット印刷 ・老舗茶メーカーの店頭キオスク 大手住宅メーカーの案件などでは、顧客と直接打ち合わせを行い、目的や対象者の整理、コンテンツのストーリー構成から制作まで携わりました。 また、老舗茶メーカーの案件は、大手住宅メーカーとの仕事を通じた紹介から受注につながりました。 ■後進スタッフの育成 制作ディレクションの経験を重ねる中で、デザイナー／CGアニメーター2名に対し、オーサリングや制作ディレクションの方法を伝え、後進育成にも携わりました。 技術や制作方法を一方的に教えるのではなく、成果物全体を俯瞰して考えること、自分で課題に気づき改善できるようになることを重視しました。 細部を逐一指摘するのではなく、全体のバランスや方向性を示したうえで本人に考えてもらい、最終的にはそれぞれが案件を担当できるようになることを目指して指導しました。 ■この時期に培った考え方 ソフトウェアエンジニア時代には、異なるシステムやデータの間を技術でつなぐ仕事を経験しました。 制作ディレクターになってからは、その対象が「人」にも広がりました。 顧客が伝えたいこと、制作スタッフが理解すべきこと、一般の利用者が実際に受け取るものは、必ずしも同じではありません。 そのため、「自分が何を伝えたか」だけではなく、「相手にどう伝わったか」を意識し、それぞれ異なる立場の人の間に立って、目的や意図を共有しながら一つの成果物へまとめることを大切にしてきました。 また、システムやコンテンツは、それ自体が完成すればよいのではなく、実際に利用する人が興味を持ち、自ら操作し、その中で意図した内容が伝わって初めて意味を持つものだと考えるようになりました。 この時期に培った、相手の立場から考えること、異なる専門性を持つ人の間をつなぐこと、全体のストーリーを共有することへの意識は、その後の社内SEとしての現場とのコミュニケーション、業務改善、システム導入における関係者間の認識共有にもつながっています。

■技術営業を担当するようになった経緯 CG制作技術支援やソフトウェア開発を担当する中で、設計会社、CADメーカー、大手住宅メーカーなど社外の担当者と技術的な打ち合わせを行う機会が増え、次第に顧客への技術提案にも携わるようになりました。その後、制作ディレクターとして案件を担当する一方で、技術営業にも並行して携わりました。 ■技術営業で重視していたこと 技術営業では、顧客から提示された要求に対して、単に自社の製品や特定の技術を提案するのではなく、自社が保有する技術や人材、過去の経験を把握したうえで、「自社であれば何を提供できるのか」を考えることを重視しました。 まず顧客が何を実現したいのかを理解し、その要求を自社へ持ち帰る。そのうえで、社内にどのような技術・人材・経験があり、それらをどう組み合わせれば要求に応えられるのかを検討し、実現方法と提供価値を顧客へ提案するという進め方です。 ソフトウェアエンジニアとして自ら開発してきた経験があったため、技術的な実現可能性や制約を考えながら顧客と話せることも、この役割では活かすことができました。 ■国土地理院／GPS地殻変動監視システム 代表的な案件の一つが、国土地理院のGPSを利用した地殻変動監視システムです。 代理店から、ワークステーションで構成されていた既存システムをダウンサイジングできないかとの相談を受けました。 代理店担当者とともに国土地理院を訪問し、担当者から既存システムの状況や要求を直接ヒアリングしました。ヒアリングした内容を自社へ持ち帰り、自社が保有する技術、人材、過去の経験などを踏まえて、どのようなシステムとして実現できるかを検討しました。 検討結果をもとに提案内容をまとめ、顧客へのプレゼンテーションを行い、受注につなげました。 受注後は技術営業だけでなく、システム開発にも一部携わりました。Oracleを利用したGPSデータサーバの一部として、GPSデータを定期的に取得する処理をVisual Basicで開発しました。 この案件では、 ・代理店からの相談 ・顧客への訪問、要求ヒアリング ・自社の技術・人材・経験を踏まえた実現方法の検討 ・提案内容の作成 ・顧客へのプレゼンテーション ・受注 ・受注後の一部システム開発 まで、顧客要求の把握から提案、受注、その後の実装まで一連の流れを経験しました。 ■携帯電話事業者／販売店向けWebマニュアル 携帯電話事業者の販売店向けWebマニュアル案件では、代理店とともに要求内容を整理し、顧客への技術提案、プレゼンテーション、実現方式の検討、価格交渉などを担当しました。 当時の通信回線速度などの利用環境を考慮し、過度に重い仕組みを採用するのではなく、HTMLを中心とした構成を提案しました。技術的に実現可能であることだけではなく、実際の利用環境で無理なく使用できることや、制作・運用コストとのバランスも考慮しながら提案内容を検討しました。 また、価格交渉では、単に受注価格を調整するのではなく、提供する内容とその価値、自社側の制作コストなどを踏まえながら、顧客・代理店との調整を行いました。 ■技術営業とソフトウェアエンジニア経験との関係 技術営業を担当する以前に、UNIX／CによるCG制作支援ツール開発、CADデータの解析・変換、外部機器を含むシステム開発などを経験していました。 そのため、顧客から要求を聞いた際にも、「できます」「できません」と即答するだけではなく、どのような技術を使えば実現できるのか、社内のどのような技術や人材、過去の経験を活かせるのか、どのような制約があるのかを考えながら提案することを意識していました。 自分自身が技術者として開発を経験していたことは、顧客の要求と実際の技術との間をつなぐうえで役立ちました。 ■この時期に培った考え方 技術営業を経験したことで、「自分が何を作れるか」だけではなく、「組織として何を提供できるか」という視点を持つようになりました。 自社が保有する技術や人材、過去の経験を理解すること。 顧客が本当に必要としていることを理解すること。 その両方を見たうえで、どの技術や人材、経験を組み合わせれば価値を提供できるのかを考えること。 そして、その価値を顧客が理解できる形で提案すること。 技術営業では、こうしたことを重視していました。 この経験は、その後の社内SEとしての仕事にもつながっています。社外の顧客に対する提案から、社内の利用部門や現場に対するシステム提案へと立場は変わりましたが、「要求をそのまま受け取るのではなく、相手が必要としていることを理解し、利用できる技術や人材、条件を踏まえて実現方法を考える」という基本的な姿勢は共通しています。

■プロジェクト概要 三協入社後、大手電機メーカーの海外生産拠点向け部品を取り扱う物流倉庫のシステム担当として、入庫・在庫管理・キッティング・出荷を支える倉庫ローカルシステムの開発・運用・改善を担当しました。 取り扱う部品の年間倉庫通過金額は一千数百億円規模で、メーカーの生産活動を支える川上物流として、システムだけでなく実際の物流現場や工程を理解し、安定した業務を継続することが求められる環境でした。 倉庫ローカルシステムはVisual Basic＋SQL Serverで構築し、メーカー側の基幹システムと連携しながら、物流現場で必要となる情報を、より現場に近い粒度で管理していました。 ■事業部生産系基幹システム刷新／切り戻し・再稼働 メーカー側で進められた事業部生産系基幹システム刷新では、三協側のシステム担当代表として参画しました。 新システムへの移行では、基幹側の仕組みと実際の物流運用との間に不整合が生じ、安定した業務継続が困難となったため、一旦旧システムへ切り戻すこととなりました。 その後、約半年後の再稼働に向けて、メーカー側と物流現場の双方でシステムと運用を見直しました。 基幹システム側では、当初導入しようとしていたフリー在庫という考え方を改め、ロット管理を細分化する方向へ変更されました。倉庫側でもそれに対応してローカルシステムを改修するとともに、増加したロットを実際の物流現場で混乱なく扱うための運用方法を検討しました。 この経験を振り返ると、初回移行時には、私自身も含め、担当者間で「新しいシステムの上で業務全体がどのように動くのか」というストーリーを十分に共有できていなかったという認識があります。 個々の機能や仕様だけでなく新しい仕組みの中でどうつながり、それによって各現場の仕事がどう変わるのかを関係者間で共有することが、システム刷新には重要であると学びました。 一度切り戻しを経験したことで、再稼働に向けた会議では、初回移行前とは関係者の意識や議論の雰囲気も変わり、実際の業務がどう動くのかをより具体的に確認するようになりました。 ■簡易ロット／現場で瞬時に識別できる情報設計 基幹システムの方針変更によってロットが細分化され、物流現場で扱うロット数が大幅に増えることになりました。 システム内部では6桁のロット番号を正確に管理する必要がありますが、それをそのまま倉庫作業者に扱わせると、現品票を見比べながらロットを識別する負担が増えます。 そこで考案したのが「簡易ロット」です。 6桁のロット番号を、現場ではひらがな・カタカナ1文字に置き換えて表示することで、一度に90数種類のロットを視覚的に識別できるようにしました。 現品票番号についても同じ考え方を採用しました。 システム内部では一意性や正確な管理のため8桁の現品票番号を保持していましたが、物流現場で現品を識別する際に8桁すべてを表示する必要はありませんでした。 そこで、内部では8桁の情報を維持したまま、現品票上では識別に必要な4桁のみを表示するようにしました。 現品票上で作業者が主に確認する情報を、 ・仕向地：3桁 ・簡易ロット：1桁 ・現品票番号：4桁 の合計8桁に整理しました。 さらに、大物部品と小物部品についても、白抜き表示の有無によって視覚的に識別できるようにしました。 この設計で重視したのは、「システムが管理するために必要な情報」と「人が作業するために必要な情報」を分けて考えることです。 コンピュータ内部では6桁のロット番号や8桁の現品票番号を正確に保持する。一方、現場にはその情報をそのまま見せるのではなく、作業者が瞬時に認識・判断できる情報量まで整理して提示する。 システム側の都合に人を合わせるのではなく、システム内部の正確性を維持しながら、人には人が扱いやすい形で情報を渡すことを意識しました。 また、この表示方法は通常運用だけを想定したものではありません。 万一システム障害が発生し、人手中心の運用へ切り替える必要が生じた場合でも、現品票を見れば仕向地、ロット、現品を識別しやすくし、混乱を抑えることを意図していました。 通常運用においても、異なるロットの混入を視覚的に発見しやすくなり、再稼働後の安定運用に加え、棚卸しの精度向上・時間短縮にもつながりました。 ■物流工程分析／オリジナル計測機器の導入によるリードタイム約30％短縮 当時、納品遵守率の低さから航空輸送が増加し、輸送コストが課題となっていました。 メーカー側から物流リードタイムの短縮を求められた際、個々の作業を単純に速くするのではなく、物流工程全体を分析し、作業の順序そのものを見直しました。 着目したのは、輸出用ケースの寸法・重量を測定する「メジャー」作業です。 従来、この作業は入荷締切後のキッティング工程に組み込まれていました。しかし工程全体を分析すると、必ずしも入荷締切後に行う必要はありませんでした。 そこで、メジャー作業を入庫直後へ前倒しし、独立した流れ作業として構成することを提案しました。 個々の作業者に「もっと速く作業する」ことを求めるのではなく、作業の順序そのものを変えることで、入荷締切後に行う工程を減らし、後工程を早く進められるようにする考え方です。 一方、この工程変更を成立させるには、入庫直後に流れてくる大量の輸出用ケースについて、従来より短時間で寸法・重量を測定できる環境が必要でした。 そのため、新しい工程で使用するオリジナル計測機器について、必要となる処理能力や機能を整理し、機器に求める仕様・性能をまとめました。 さらに、計測機器を単体で使用するのではなく倉庫ローカルシステムとの連携を前提とし、RS-232Cによる通信方式を採用しました。システム側から機器を制御するために必要な通信仕様についても、こちらから要求しました。 メーカー資材部門と調整し、要求した性能・通信仕様を踏まえた機器をメーカー側で手配いただき、物流現場へ導入しました。 導入後は、倉庫ローカルシステムと計測機器をRS-232Cで接続し、システム側から機器を制御することで、採寸・重量測定を入庫直後の新しい物流工程へ組み込みました。 この改善では、既存工程の一部を単純に効率化するのではなく、 現場の課題 → 物流工程全体の分析 → ボトルネックとなる作業の特定 → 作業順序の変更 → 新しい業務フローの設計 → 必要な機器性能の定義 → 通信仕様の要求 → 業務システムとの連携 → 現場導入 までを一つの改善として進めました。 その結果、入荷締切からキッティング、輸出資料作成、出荷までに要していた物流リードタイムを、5日から3.5日へ約30％短縮しました。 ■現場に近い粒度での在庫情報管理／メーカー資材部門への展開 倉庫ローカルシステムでは、メーカー側基幹システムよりも物流現場に近い粒度で在庫情報を管理していました。 単純な在庫数量だけでなく、ケース数、ケースサイズ、ロット、現品の状態など、実際に倉庫に存在する物理的な在庫状況を把握できることが特徴でした。 この情報は通常の在庫管理だけでなく、突発的な生産計画変更に伴って緊急出荷が必要となった場合にも活用されました。 例えば航空便を手配する場合、単に「部品が何個あるか」だけではなく、何ケースになるのか、それぞれのサイズがどの程度なのかといった物理的な情報が必要になります。 倉庫ローカルシステムでは、こうした現場に近い情報を把握できたため、メーカー資材部門からも直接確認したいとの要望を受け、同部門にも倉庫ローカルシステムを導入しました。 物流現場で必要になったローカルシステムが、結果としてメーカー側の意思決定にも利用されるようになりました。 ■担当・技術環境 担当： ・倉庫ローカルシステムの開発・運用・改善 ・メーカー基幹システム刷新への三協側システム担当代表としての参画 ・新システム移行、旧システムへの切り戻し、再稼働対応 ・物流現場の運用設計・改善 ・簡易ロット、現品票等の情報表示設計 ・物流工程分析・改善方式立案 ・オリジナル計測機器の要求仕様・性能整理 ・RS-232C通信仕様の要求・調整 ・業務システムと計測機器の連携 ・メーカー資材部門との調整 開発環境： Visual Basic SQL Server RS-232C ■この時期に培った考え方 この時期には、システムだけを見ていても業務上の問題を解決できないことを、実際の物流現場を通じて経験しました。 コンピュータ内部では6桁のロット番号が必要でも、人には1文字の方が分かりやすい。 システム内部では8桁の現品票番号が必要でも、現場で識別するためには4桁で十分な場合がある。 重要なのは情報を単純に減らすことではなく、システム内部では必要な正確性を維持しながら、人にはその仕事に必要な情報を、認識しやすい形で提示することだと考えるようになりました。 リードタイムを短縮するために、作業者へ速度を求めるより、工程の順序を変えた方がよい場合がある。 必要であれば、ソフトウェアだけで解決しようとせず、業務から必要なハードウェア性能や通信仕様を考える。 基幹システムが持つ在庫情報だけでなく、実際の物流現場で何が存在しているのかという、より高い解像度の情報が意思決定に役立つ場合もある。 そして、新しいシステムを導入する際には、個々の機能や仕様だけではなく、「新しい仕組みの上で業務全体がどう動くのか」というストーリーを関係者間で共有する必要がある。 川上物流を担当した経験を通じて、システム、データ、ハードウェア、物流工程、そして実際にそこで働く人を別々に見るのではなく、それらの関係を一つの業務システムとして捉えることの重要性を学びました。

■概要 大手電機メーカーの川上物流を担当した後、三協社内全体のITを担当しました。 本社および5倉庫を対象として、拠点間ネットワークの構築・運用、ネットワーク機器の選定、社内システムの技術検証・パイロット開発など、社内IT基盤から業務アプリケーションまで幅広く担当しました。 ■本社・5倉庫を結ぶ拠点間ネットワークの構築 本社と5倉庫をネットワークで接続するため、導入・運用コストとセキュリティの両面を考慮しながら、通信方式およびネットワーク機器を検討しました。 当時利用可能だったサービスやコストを比較したうえで、NTTのフレッツ・グループによる閉域ネットワークを利用し、YAMAHA製ルーターを組み合わせたVPN環境を構築しました。 単にネットワーク機器を設置するのではなく、複数拠点を継続的に接続・運用する社内インフラとして、必要な通信環境を整備しました。 構築後も社内IT担当として運用を行い、本社・各倉庫間で社内システムや情報を利用するためのネットワーク基盤を支えました。 ■社内システムの技術検証・パイロット開発 社内業務を支援するシステムについても、新しい開発技術や構成を検討しました。 技術選定では、特定の技術を採用することを前提にするのではなく、実際の社内環境で必要となる性能、導入・運用のしやすさ、開発・保守コストなどを考慮して判断しました。 当時、新しい開発環境として.NETについても実際に技術検証を行いましたが、当時のPC環境や利用条件では動作が重く、社内システムへ採用するにはまだ負担が大きいと判断しました。 そのため、より軽量で運用しやすい構成としてPHP＋PostgreSQLを採用し、社内システムのパイロット開発を行いました。 新しい技術だから採用するのではなく、実際の利用環境で安定して使用できるかを検証したうえで、当時の会社規模や運用条件に適した技術を選択することを重視しました。 ■担当・技術環境 担当： ・社内IT全般 ・本社／5倉庫の拠点間ネットワーク設計・構築・運用 ・通信方式の検討・選定 ・ネットワーク機器の選定・設定 ・VPN環境の構築・運用 ・社内業務システムの技術検証 ・開発技術の比較・選定 ・社内システムのパイロット開発 ネットワーク： ・NTT フレッツ・グループ ・YAMAHAルーター ・VPN システム開発： ・.NET（技術検証） ・PHP ・PostgreSQL ■この時期に培った考え方 川上物流担当時代には、物流現場、業務システム、ハードウェア、メーカー基幹システムなどを一体として考える経験をしました。 その後、社内全体のITを担当するようになり、対象が一つの物流業務から、本社・各倉庫を含む会社全体のIT環境へ広がりました。 ネットワークについては、単に高性能な構成を選ぶのではなく、会社の規模、必要なセキュリティ、導入・運用コストを考えながら、現実的に継続運用できる構成を選択しました。 社内システムについても同様に、新しい技術を採用すること自体を目的とせず、実際に検証したうえで、その時点の利用環境や運用条件に適した技術を選ぶことを重視しました。 この時期を通じて、特定の製品や技術に依存するのではなく、会社や利用者に必要なものを考え、その条件に合った技術・サービスを選択し、実際に運用できる仕組みとして構築する経験を積みました。

■活動の位置づけ 2008年の退職後は療養に専念していましたが、体調の改善に伴い、仕事への復帰を見据えた技術の再習得と実践的なリハビリを兼ね、2016年頃から知人へのIT支援を報酬を伴わない個人活動として始めました。 雇用契約や継続的な業務委託契約による仕事ではなく、実際の利用者や業務に触れながら、長いブランクの間に変化した技術や開発環境を学び直し、自分自身の知識や開発方法を現在の環境に合わせて更新することを主な目的とした活動です。 ■身近なIT支援からスタート 一人親方として建設業に携わる知人に対し、業務で使用するPC等の機器選定やWi-Fi・ネットワーク環境の整備など、身近なIT支援から始めました。 最初からシステムを作ろうと考えていたわけではなく、実際の仕事の中で何に困っているのかを聞き、必要なところから支援していきました。 その後、見積書・請求書の作成について相談を受け、Microsoft Accessを使用した見積・請求システムを作成し、実際の業務で使いながら改善を続けました。 ■Accessから.NET MAUI＋EF Core、Flutterへ 長期的な保守を考えたとき、特定の開発環境に依存し続けるよりも、全ソースコードを自ら管理し、必要に応じて変更できる状態にした方が継続的に支援しやすいと考えました。 そこで、仕事への復帰に向けた技術の学び直しも兼ね、AIコーディング支援を活用しながら、.NET MAUI＋Entity Framework Coreで見積・請求アプリを一から再構築しました。 その後、実際に業務アプリとして開発する中で、UIの自由度やマルチプラットフォーム対応、将来の利用環境などを改めて検討し、Flutterへ再構築しました。 一度選んだ技術にこだわるのではなく、実際に使ってみて、要件や保守性、将来の拡張性に合わないと感じれば、技術選択そのものを見直すようにしています。 ■現在の見積・請求アプリ Flutter版は、macOS、Windowsでの利用を想定した、完全オフライン型の建設業（一人親方）向け見積・請求アプリとして開発しています。 案件、見積、請求、入金、支払、各種マスターを一体的に管理し、見積の改訂履歴、協力会社見積や参考資料の管理、見積書・請求書のPDF生成、バックアップ・復元、郵便番号データの更新、ダッシュボードによる業務状況の可視化などを実装しています。 学習用のサンプルではなく実際に利用する人がいるため、機能を作って終わりではなく、使ってもらいながら継続的に見直しています。 ■利用者に近いシステムを作る 長く付き合いのある知人が実際に使用するため、業務内容だけでなく、仕事の進め方や生活リズム、何を面倒に感じるのか、どのような操作が不得手なのかといったことも分かります。 そのため、「一般的なユーザー」だけを想定するのではなく、その人と業務との関わりを見ながらシステムを改善しています。 こうしたことを考える背景には、身近なところでデジタル化について考えさせられた経験もあります。 以前、高齢の母が銀行で手続きをした際、デジタル端末に本人が署名する必要がありました。母は手が少し不自由なうえ、こうした端末の操作にも慣れておらず、署名を終えるだけで5分近くかかりました。 銀行側から見れば、本人確認を含めた手続きをデジタル化することには合理性があります。一方、利用する人によって身体的な条件やデジタル機器への習熟度は異なります。仕組みとして正しく作られていても、それがすべての人にとって使いやすいとは限らないことを、改めて実感しました。 これは業務システムでも同じではないかと考えています。 人を標準的なシステムの操作へ合わせるだけではなく、可能であればシステムも、利用する人の特性や、その人と業務との関わりに合わせて変化できる方がよい。 AIによって実装に必要な時間やコストが下がれば、従来は開発コストの問題から拾いきれなかった利用者ごとの違いまで、システムへ反映できる可能性があります。 既製服に人を合わせるのではなく、その人に合わせて仕立てる「オートクチュール」のような開発が、以前より現実的になってきたという感覚です。 ただし、すべてを利用者ごとに作り込めば、変更や保守が難しくなります。 そこで、業務上守るべきルールやデータと、利用者や利用状況に応じて変えられるUIや操作方法を、できるだけ分けておくことを意識しています。 ■現在の開発方法を実践しながら学ぶ 長いブランク以前の知識だけに頼らないよう、現在のソフトウェア開発についても、実際のアプリを作りながら学んでいます。 DDD（ドメイン駆動設計）は、業務上の概念や責務、境界を整理する際の参考にしています。 TDD（テスト駆動開発）も取り入れ、特にAIにコーディングを任せる際には、期待する振る舞いや守るべき条件から外れていないかを確認するガードレールとして活用しています。 テストケースの作成にもAIを利用し、自分だけでは見落としやすい境界値や異常系、想定外の状態などについても検証範囲を広げています。 Result型やエラーハンドリングの統一なども取り入れていますが、特定の設計手法を採用すること自体を目的にはしていません。 実際に開発・保守してみて役に立つものを取り入れ、合わなければ見直すという姿勢で試しています。 ■生成AIと「AI駆動開発の燃費」 現在は生成AIによるコーディングを積極的に利用しています。 使っていて興味深いと感じるのは、AIが速くコードを書けることと、開発全体が効率的に進むことは、必ずしも同じではないという点です。 業務や仕様が曖昧なままAIへ実装を依頼すると、短時間で多くのコードはできますが、後から業務との不整合や設計上の問題が分かり、大きな手戻りになることがあります。 そこで私は、単純なコードの生成速度ではなく、AIへ与えた情報や指示に対して、どれだけ少ない手戻りで必要な成果へ到達できるかを、少し比喩的に「AI駆動開発の燃費」と呼んでいます。 実際に試していると、AIへ細かな実装方法を指示すること以上に、その前段階で業務の概念、ルール、制約、例外などを整理しておくことの方が効く場面があります。 また、ソースファイルを必要以上に肥大化させないことも、「燃費」に影響すると感じています。 複数の責務が一つの大きなソースファイルに集まった状態でAIに変更を依頼すると、本来変更する必要のない箇所まで書き換えられ、既存コードとの整合性が崩れてコンパイルエラーやスクリプトエラーが発生することがあります。実際の開発でも、こうした意図しない変更によるエラーを何度も経験しました。 そのエラーを修正するために再びAIへ変更を依頼すると、さらに別の箇所へ影響し、修正が連鎖してしまうこともあります。 そうなると、最初の変更自体は短時間で生成できても、エラーの確認、再修正、テスト、人間による確認などに時間やコンテキストを消費し、開発全体としては効率が悪くなります。 そのため、単純に「1ファイルを何行以内にする」といった形式的なルールではなく、責務を適切に分け、AIが一度に理解・変更しなければならない範囲をできるだけ小さく保つことを意識しています。 変更範囲が明確になれば、AIに渡すコンテキストも絞りやすくなり、意図しない変更や手戻りを減らすことにもつながります。 DDDやTDDを取り入れているのも、こうした試行錯誤の中で、AIと継続的に開発するために役立つと感じているためです。 AIへ渡す業務や仕様の整理、ソースコードの責務分離、テストによる検証、エラー発生後の再修正、人間による確認までを含め、開発全体としてどれだけ効率よくAIを利用できるか。 こうした視点を含めて「AI駆動開発の燃費」と捉えています。 ■「AIにやさしいアーキテクチャ」という考え方 AIと一緒に開発を続けているうちに、人間にとって分かりやすいシステムは、AIにとっても扱いやすいのではないかと考えるようになりました。 責務や境界が分かりやすく、業務ルールがコードのあちこちに散らばっておらず、ソースファイルも必要以上に肥大化していない。そして、テストによって期待する振る舞いが確認できる。 そのような構造であれば、AIに変更を任せる場合にも、AIが一度に理解する範囲や変更による影響範囲を限定しやすく、設計意図から大きく外れる可能性を減らせるのではないかと考えています。 私はこうした考え方を、自分なりに「AIにやさしいアーキテクチャ」と呼んでいます。 現在のアプリでは、例えば業務ロジックとUIを分離し、利用者に合わせてUIや操作方法を変更しても、見積や請求などの業務ルールには影響しにくい構造を意識しています。 また、責務ごとに変更範囲をできるだけ局所化することで、人間がコードを理解しやすくするだけでなく、AIへ変更を依頼する際にも必要なコンテキストを限定できるようにしています。 これは将来、利用者や状況に応じてUIを柔軟に変えるGenerative UIのような仕組みを取り入れる場合にも役立つのではないかと考えています。 まだ自分自身でも試行錯誤している段階ですが、AIがコードを書く能力が高くなるほど、「AIに何を書かせるか」だけではなく、「AIが理解しやすく、変更しやすいシステムをどう作るか」も重要になってくるのではないかと考えています。 ■メダリオンアーキテクチャとデータの整理 AIによるデータ活用についても試行錯誤しています。 アプリ内部のデータをそのままAIへ渡すのではなく、元となるデータを保持しながら、用途に応じて整理・標準化し、利用しやすい形へ変えていく方が扱いやすいのではないかと考え、メダリオンアーキテクチャの考え方も参考にしています。 もともとはデータ基盤で使われる考え方ですが、「元のデータ」と「利用目的に応じて整理されたデータ」を分けて考える点は、業務アプリとAIをつなぐ場合にも参考になると感じています。 データがどこから来て、どのように整理・変換され、何のために使われるのかが分かる状態にしておくことは、AIだけでなく、人間が将来システムを変更・保守する際にも役立つと考えています。 ここでも、メダリオンアーキテクチャをそのまま当てはめることが目的ではなく、自分のアプリにとって有効な考え方を取り入れながら試しています。 ■AI時代の「意味モデル」 さらに最近考えているのが「意味モデル」です。 AIが業務システムを利用するようになると、データを取得できるだけでは十分ではなく、「そのデータが業務上何を意味するのか」が分かることが重要になるのではないかと考えています。 例えば現在のアプリには、「案件」「見積」「請求」「入金」「協力会社見積」などの概念があります。 それぞれが何を意味し、どのような関係にあり、どの状態で何ができるのか。 人間は業務経験から自然に理解できても、AIが扱うためには、その意味や関係をもう少し明示的に表現する必要があります。 DDDで業務上の概念や境界を整理し、データを利用しやすい形へ整え、そのうえで業務上の意味や関係性を表現する。 そうすることで、AIに単なるデータではなく、「意味の分かるデータ」や「意味の分かる業務機能」を渡せるのではないかと考えています。 意味モデルについては、今後さらに理解を深め、実際のアプリで試していきたいテーマの一つです。 ■MCPによる業務アプリとAIエージェントの連携 AIを開発支援だけでなく、業務アプリそのものと連携させる実験も行っています。 Flutter版の見積・請求アプリにMCP（Model Context Protocol）対応機能を実装し、Codexをクライアントとして接続することで、AIエージェントから案件、見積、協力会社見積などの業務情報を検索・参照できることを確認しています。 一方、AIにすべての情報を無条件に公開するのではなく、アプリ側で外部AIへ公開する機能を個別に設定し、用途に応じて読み取り可能な情報を制限できる仕組みも実装しています。 今後は、単にデータベースの情報をAIへ渡すのではなく、業務上の意味を整理したデータや機能を、適切な境界を設けたうえでAIから利用できるようにする方法を試していきたいと考えています。 ■技術・開発環境 これまでの主な変遷： Microsoft Access → .NET MAUI＋Entity Framework Core → Flutter／Dart 現在利用・検討している主な技術・考え方： ・Flutter／Dart ・SQLite ・DDD（ドメイン駆動設計） ・TDD（テスト駆動開発） ・Result型 ・メダリオンアーキテクチャ ・意味モデル ・生成AIを活用した開発 ・MCP ・AIエージェント連携 ・マルチプラットフォーム開発 ■活動を通じて考えていること これらは、受託開発や事業として行っているものではなく、仕事への復帰に向けて、実際の業務課題を題材にしながら、自身の技術や開発方法を現在の環境