ID:85877さん

キャリアビジョン


Aiによってイメージを形にしやすくなった今、個別の顧客ニーズに沿ったものを作りたいです。

学生のころから、個別最適を志向しながら、デザインや仕事をしてきました。開発したサービスがいろんなお客様に使われて大きくなっていくうちに、最近では、サービス全体としていろんなお客様に有用なものが求められるようになって、個別のお客様から遠くなってきてしました。 生成AIによって、開発の速度・コストが変わってきた今、顧客の顔の見える開発ができるチャンスが増えてきていると思っていて、そういう仕事に携わりたいです。

プロジェクト経験

2019年/2年以上

製品マニュアル用ドキュメント制作システム iShare DX 開発・保守

## プロジェクト概要 印刷会社役員からi-Shareをベースとして、いろんな業種で使用できる業務マニュアル用編集・ワークフロー管理システムが開発したいという依頼があり開発を開始しました。新入社員と契約社員をアサインされた状況で、発注元の機能企画担当者に対し、要件整理やUI企画、開発の進め方を支援しました。プロトタイプ開発フェーズでは、社外のUIデザイナーをアサインしてUI設計を進め、開発のサポートから実装・保守までを担当しています。現在も、都度改修が発生しています。 法人向けのマニュアル制作公開システムで、現在10社以上の企業が利用している状況です。 ### 自身の担当範囲 システム・データベースの設計、エディタのベース開発、バックエンドおよびサービス(デーモン)の開発・改修・保守を担当しています。フロントエンドは主担当のエンジニアと分担し、サブ担当として開発に携わっています。また、機能企画担当者に対して、プロジェクトの進め方やUI企画の支援も行っています。 以下の他メンバーが担う業務を除き、システム全体の設計から実装、継続的な機能追加・保守までを担当しています。 ### チーム体制と役割分担 私以外のメンバーの担当は以下の通りです。 - 機能企画担当2名(発注元社員):機能の企画を担当。 - フロントエンドエンジニア:編集システム・公開システムのUI開発を主担当として担当。 - DITA-OTプラグイン開発エンジニア:組版用プラグインの開発を担当。 - カスタマーサクセス数名:利用企業の増加後に加わり、カスタマーサクセス業務を担当。 ### 実装技術・実行環境 編集システム・公開システム - 実行環境:Amazon EC2(Windows) - データベース:Amazon Aurora PostgreSQL - ORM:NPoco - Webフレームワーク:ASP.NET Core 3.1(のちにASP.NET Core 8へバージョンアップ) - 検索エンジン:Elasticsearch 7.2 - フロントエンド:jQuery - エディター:React 組版サービス - DITA-OT 4.1 - Antenna House Formatter ## 主要機能 システムは、 - 業務文書や手順書などを編集し、レビュー・承認といった工程を経て、公開システムで社内ユーザーに公開することができるマニュアルシステムです。 - 編集ライセンス、レビューライセンス、公開管理者ライセンス等のライセンスをユーザーにアサインして、使える機能の制御ができます。 - DITAに基づいたデータ構造をしており、DITA-OTによる組版処理で、PDFとHTMLを出力することができます。 - 目次作成、トピック編集は、ドラッグ&ドロップで構造ルール通りのデータを作成できるので、DITAのデータ構造に対する知識のないユーザーでもデータを作成することができます。構造に沿っての入力しかできず、スタイルの細かい調整といった作業はできないので、スタイル調整の作業に時間がとられることはなくスピーディに文章を作成できます。 - レビューや承認が履歴として残り、ドキュメントに改定履歴が自動で生成されます。(生成後、編集することもできます。) - マニュアルを公開システムに閲覧ユーザーに公開できます。一覧ページのレイアウトを定義して、アイコンや配色の変更ができます。マニュアル毎に公開日、終了日を設定して公開制御できます。 製品サイト:https://www.kwix.co.jp/isharedx/ ## システム機能追加 ### 作図システムLucidchartと連携したマニュアルの図表編集機能(2021年5月~) 作図システムの[Lucidchart](https://lucid.co/ja/)と連携して、図表を編集できる機能を追加しました。 OAuthによる認可とAPI連携を用い、Lucidchartで作成した図表を画像として取り込み、ドキュメントに配置できるようにしました。 ### 編集システムのOTPによる二要素認証機能(2024年6月~) フォーム認証にOTPによる二要素認証機能を追加しました。ユーザーの設定画面に、キーから生成したQRコードを表示し、スマートフォンのOTPアプリで読み取ってコードを登録することで二要素認証を有効化できるようになりました。また、クライアントの管理者がクライアントのすべてのユーザーにOTPによる二要素認証を有効化させたい場合、管理者設定から設定することで、二要素認証を設定していないユーザーの場合、次回ログイン時に、二要素認証の設定画面に遷移して、二要素認証を有効化しないとログインできないようにしました。 ### アクセスログのビジュアル表現(2024年6月~) 公開システムでマニュアルを閲覧したユーザーの導線やページの滞留時間、検索キーワードなどのアクセスログを記録し、Elasticsearchに格納しました。日時を軸に集計したデータをD3.jsで可視化しました。 - 棒・円・折れ線グラフによるアクセス数、アクセス時間帯などの表現 - Sankey diagramによるページ遷移を表現 - フォース・ダイレクテッド・ダイアグラムによる検索キーワードマップ 表現したい項目を決めてもらい、D3.jsでのデータ表現の中からどういう表現が良いかイメージの提案とプロトタイピングしながら、開発しました。 ### 公開システムユーザーの閲覧権限設定機能(2024年6月~) 編集システムの管理画面で、ユーザーのプロパティと閲覧設定を行い、公開システムに設定を送信することで閲覧制限が反映されます。 ドキュメントには、2種類のカテゴリーの設定がされており、登録された閲覧ユーザーの役職・所属部署ごとにカテゴリーに閲覧許可を設定することで、カテゴリーごと許可されていないユーザーには表示されないようになりました。 ### PDFをDITAに変換するためのAIワークフロー(2026年2月~) PDFをDITAデータに変換して、システムの文章として登録する機能を追加しました。 Cursorを使って実装し、PDF変換を行うコマンドラインプログラム(ワーカー)と、i-ShareDXとの通信を担うLinuxデーモン(サービス)を開発しました。 AI OCRでPDFをHTML化し、LLMによるHTMLの整形とC#によるDITA変換を行いました。変換後のデータはXML Schemaで構造を検証し、LLMで修正することで、システムにインポートできるDITAデータを作成しました。使用した技術とモデルの選定理由は以下の通りです。 - AI OCR:yomitoku-pro - LLM連携・制御:Microsoft Agent Framework(C#) - 使用モデル:Gemini 3.5flash:ページ画像判定 , GPT5:HTML構造変更 - 選定理由:Gemini 3.5flash は、画像を送信したときのトークン使用量が固定で、コストが安い割に、Gemini3.1Proと比較して回答があまり変わらなかった。GPT5は、HTMLの見出しの抽出精度がGeminiに比べて高く、Opus4.8に比べてコストが安かった。 - PDF操作:PDFsharp 処理ステップとしては、 1. PDFの各ページについて、前処理を行った画像と、前処理を行っていない画像を作成します。 2. LLMで2つの画像を評価し、OCRに適した画像を選択します。 3. ページごとの判定結果に基づいてPDFのページを差し替え、OCRでHTMLを出力します。 4. LLMでHTMLの見出しや構造を整え、文書の意味に沿ってDITAに変換しやすい形にします。 5. C#でHTMLをDITAマップとトピックに変換します。 6. XML Schemaによる検証処理を関数として実装し、DITAトピックとともにLLMから利用できるようにしました。構造の検証とLLMによる修正を繰り返し、スキーマ検証に合格するDITAトピックを作成します。 LLMは、モデルや設定を切り替えられるように実装し、複数のPDFを変換しながら、精度・コストを考慮しながら実行するモデルを決定しました。 既存のドキュメントをたくさん持ち、システムでの運用にあたり既存のドキュメントの登録コストのために導入が停滞していたお客様が評価トライアルをしていて、良い反応をいただいています。 ### マルチテナントの公開サーバーにおけるフォーム認証・SAML認証機能(2026年2月~) 使用するユーザーの増加に伴い、公開システムのサーバー数が多く更新・確認作業、保守に工数がとられることが多くなってきたため、認証をマルチドメイン対応してサーバーを統合しました。 フロントエンドの改修がなかったのですべて私が対応しました。 使用しているライブラリにはマルチドメインに対応する実装例やドキュメントがなかったため、ライブラリとASP.NET Core 8の該当部分のソースコードを読み、動作を検証しながら実装を進めました。 この統合作業により、公開用サーバー13台が1台に集約されました。 ### AWS WAFルールによるシステムにアクセスできるIP設定機能(2026年2月~) i-ShareDXの管理画面より、IPアドレスと対象サーバーを登録して、登録されているサーバーのホワイトリスト方式でIPフィルターを開発しました。 フロントエンドの実装以外すべて対応しました。 登録されたIPアドレスを基にAWS WAFのIPセット(IPSet)を作成し、そのIPセットを参照するルールを、Application Load Balancer(ALB)に関連付けたWeb ACLに設定することで、ユーザーが管理画面からIPアドレスによるアクセス制限を設定できるようにしました。 ### 公開システムのドキュメントを対象としたRAGによるAI検索機能(2026年2月~) 公開システムに登録されたHTML、PDF、DOCX、PPTX形式のドキュメントを対象に、RAG(検索拡張生成)によるAI検索機能を開発しました。ドキュメントのテキストとベクトルデータをElasticsearchにインデックスし、検索結果を基にLLMが回答を生成する構成です。 インデックスする際のチャンクで文書の意味を壊さないようにインデックスすることに注意しました。 - HTMLはDITAから変換したものなので、トピックに対応するsection要素を抽出してチャンクを構成しました。 - PDFは、AIコンバーターの資産を活用して、LLMで文書を意味に沿ったトピックに分けてチャンクを構成しました。 - DOCX、PPTXは、DoclingでMarkdownに変換した後、HTML化してインデックスしました。 - テキスト検索、ベクトル検索によって取得した結果を、AWS BedrockのAmazon Rerankを使ってリランキングしています。 - LLMの応答が、503を返した場合フェイルオーバーを実装し別のLLMで処理を実行するようにしています。 - LLMのモデル、フェイルオーバーのモデルは、コストや精度で変わってくると思われるので、設定ファイルで設定できるようになっています。 - インデックスする際に、ドキュメントのカテゴリー、ドキュメントIDを登録することで、回答時のLLMの検索対象を閲覧制限の設定に沿って、フィルターできるように実装しました。 AI検索は公開システムの通常の処理より応答に時間がかかるため、回答生成処理をASP.NET Coreの公開システムとは別のプロセスに分離しました。バックエンドにデーモンを実装し、HTTPリクエストを受け付けて回答を返す構成にしました。 現在、β版を提供していて、回答精度、コストを元に本番運用用モデルを選定中です。

2015年/2年以上

製品マニュアル用ドキュメント制作システム iShare 開発・運用

## プロジェクト概要 Web上でマニュアルの編集、多言語展開、組版・HTML出力まで行える、DITAベースの多言語マニュアル制作システムを開発しました。独立後に作成したプロトタイプを既存顧客のマニュアル制作会社に提案したことをきっかけに、共同開発を開始しました。 主な機能は、構造ルールに沿ったXML編集、一次・二次翻訳言語の管理、原文の変更内容の同期、翻訳が必要な段落のXML出力と翻訳結果の取り込み、言語別の画像・用語管理、PDF・HTML出力です。 現在は合計6社で利用されており、4社では初期開発の機能を、残る2社ではドキュメントの特性や制作ワークフローに合わせて改修した機能を利用しています。メーカーのマニュアル担当者や製品開発者が直接編集し、システムから組版・HTML出力を実行する運用にも対応しています。 ## 開発体制 - 私:機能企画、システム・DB設計、エディタのフロントエンド実装、バックエンド実装、システムデータをDITA形式に変換してDITA-OTを実行するサービスの開発 - 制作会社のシステム開発担当者:機能企画、マニュアルのXML設計、DITA-OTプラグイン開発 - フロントエンドエンジニア:エディタ以外のUI設計、フロントエンド実装 私は、DITA XMLの構造を踏まえ、エディタ・バックエンド・DITA変換サービスの設計・実装を一貫して担当しました。 ## 使用技術 - フロントエンド:HTML、JavaScript、jQuery - バックエンド:asp.net 4.5.2(最終的に4.8に更新) dotnet frameworks 4.5.2 ともにC#で実装 ‐ ORM : Dapper - Database : PostgreSQL - 検索用ストア : Elasticsearch - 組版 : DITA-OT, Adobe Framemaker,Adobe Indesign (マニュアルによって変更) ## 技術的な課題と設計上の工夫 ### 翻訳・校正中のデータを維持するトピック管理 翻訳元言語の変更が、翻訳・校正中のマニュアルに影響しないようにする必要がありました。 翻訳言語のマニュアルを作成する際は、翻訳元のマップ(目次構成)を複製し、各トピック(本文データ)は翻訳元と同じものを参照する設計にしました。トピックの編集時には既存データを上書きせず、新しいトピックを作成し、編集対象のマニュアルだけ参照を切り替えます。翻訳言語側で独自に編集する場合も、同様にそのマニュアル専用のトピックを作成します。 翻訳元の変更を取り込むため、初校・再校などの区切りで実行する同期処理を開発しました。前回同期時点と最新のマップ・トピックを比較して変更部分を翻訳言語側に反映し、変更のない部分は既存の翻訳結果を維持します。 これにより、原文の編集と翻訳・校正を並行して進めながら、作業の区切りで原文の変更を取り込めるようにしました。 ### 翻訳ソースIDによる差分翻訳 他言語のマニュアルは、XMLで翻訳出力し、翻訳したXMLをインポートすることで、翻訳データを登録できます。翻訳出力は、変更したところだけが翻訳出力されます。従来の制作フローでは、すべての文書を翻訳出力し、翻訳支援ツールにて過去に実施した翻訳は、その時の翻訳データを翻訳メモリから取得してあてはめることによって、必要な部分だけを翻訳するようになっていました。 この翻訳メモリから過去の翻訳を割り当てる場合も翻訳会社としては、翻訳よりは安いながら、費用が発生していました。この差分翻訳機能により翻訳費用を抑制することができます。 - 編集を行った際に、XML上の段落要素内のテキストやインライン要素をDBに翻訳ソースとして登録し、XML側には翻訳ソースIDを記録します。 - エディタで段落内のテキストやインライン要素を変更すると、変更ログを記録し、保存時にその段落の翻訳ソースIDを更新します。多言語側への同期時には、参照するIDも更新します。翻訳出力では、対象言語の翻訳結果が登録されていないIDの段落だけを抽出することで、変更のない段落の既存訳を維持し、翻訳が必要な段落に対象を絞りました。 ### 用語の多言語管理 - マニュアルで使う固有名詞や専門用語など、翻訳を固定したい部分を変数としてXMLに設置できます。対訳の付いた変数と用語リストを登録することで、各言語の変数の用語を設置して組版することができます。 ### XML構造の制御と再利用しやすい編集UI 編集言語のマニュアルをWebインターフェイスで編集する。ドラッグ&ドロップでDITAトピックの構造ルールに沿ったXMLの編集ができます。 - エディタで扱えるXML構造を、DITA-OTで出力スタイルを定義した範囲に限定しました。これにより、編集時点で、出力スタイルが適用されない構造やマニュアルとして不適切な構造の作成を防ぎました。 - 目次の編集とトピック内の記述の変更するUIを分離しました。目次の編集画面には、編集対象の目次を表示した右側に別の目次を表示する機能をつけました。表示したほかの文章の目次から、目次項目を選び、左側の目次ツリーにドラッグ&ドロップで移動して、インサートできるようにしました。 - トピックの編集画面には、目次ツリーのレイアウトに沿って、トピックを連続して並べて表示するようにしました。こちらにも、右側に別の文章を表示して、どの構造をドラッグ&ドロップで編集対象のトピックにインサートできるようにしました。 ### 言語別イラストの参照 マニュアルで表示するイラスト、参照設定するファイルを登録することができる。ファイルシステムとしてフォルダを作成してファイル登録できます。 - マニュアルで使用されるイラストは、例えば画面の説明イラストのように言語が違った場合に、差し替えが必要なものがあります。そのため、各言語のフォルダを作成してそこに配置されたイラストは、組版の際に差し替える処理を実装しました。例えば、日本語=>英語=>フランス語という翻訳順の時、フランス語のフォルダのイラストを参照して、不足分を英語のフォルダから取得、さらに足りないものを日本語のフォルダから取得といった処理になっています。 ## 顧客別の機能拡張 このシステムは、マニュアルのドキュメントとしての機能やお客様と制作ワークフローに合わせるために改修して運用している場合があります。 ### 制作会社とメーカー間のデータ移行 製品の製造メーカーが、複数の制作会社にマニュアルの制作を発注している状況で、制作会社・メーカーようにそれぞれシステムを構築して、マニュアル完成したら、完成データを納品しメーカーのシステムにインポートするという形で運用するとのことでした。プロジェクトを編集言語、他言語の関係を崩さないようにデータエクスポートする機能と、そのデータを別のシステムでインポートして運用できるようにするインポート機能を開発しました。 これにより、いろんな制作会社にマニュアルの変更内容に応じて発注したり、翻訳のための小変更であればメーカーで対応したりできるようになりました。 ### 製品別マニュアルの生成とマスター更新 住宅設備メーカーのマニュアルで、OEM含め多種のマニュアルを制作しているメーカー向けにシステムを改修しました。様々なマニュアルの記載を1つのマスターマニュアルとして記載して、各記載のXML要素に製品の種別を登録し、新規マニュアルを作成する際に製品の種別を定義することで、必要な記載を抽出してマニュアルを生成する機能を実装しました。この機能で作成されたマニュアルデータに対して、追加・変更を加えることで製品マニュアルが完成します。また、部品の変更などによりマスターマニュアルの記載が更新された際には、その内容を製品マニュアルに反映する機能も実装したことで、マスターの反映をマニュアル更新の際に自動で反映できるようにしました。この機能を実現するために、製品マニュアルの編集は、構造の追加・削除のみを実施し、その操作を要素の属性として記録するように機能を制限しました。これにより、マスターのトピックと製品のトピックがどちらも変更されたとしても、マスターのトピックに対して、操作の属性にしたがって、要素の追加、削除処理をすることで、マスターの反映ができるようになりました。

2018年/2年以内

複合機向け Web 設定 UI 開発

## プロジェクト概要 オフィス用複合機の設定を行うWebインターフェイスのリニューアルプロジェクトです。既存のWebインターフェイスは独自の仕組みで実装されており、新しいブラウザやスマートフォン・タブレットへの対応が課題となっていました。海外販社からの対応要求を受け、リニューアルを行いました。 メーカー側はハードウェア・組み込み開発を中心とした体制であり、Webインターフェイスの開発を弊社が担当しました。既存の設定値の取得・更新の仕組みを活用し、ハードウェア側の変更を最小限に抑えながら、操作性と保守性を改善することに取り組みました。 ## 開発体制と担当業務 開発チームは、私、弊社のフロントエンドエンジニア1名、ユーザビリティ専門家1名、外部のWeb制作会社のWebデザイナー2名の計5名です。Webデザイナー2名は画面デザインの作成を担当しました。 私は受注前のヒアリングから参画し、開発工程の設計、見積、要件定義、デザインディレクション、プロジェクト管理を担当しました。ユーザビリティ専門家とメニュー構造を分析・設計し、メーカーと海外販社による評価を経てデザインを決定する流れを組み立てました。 開発面では、既存アプリケーションの解析、共通UIの実装方法の設計、設定画面の開発、XMLからHTML・JavaScriptを生成する変換プログラムの開発を担当しました。フロントエンドエンジニアが開発したHTML・スクリプトをベースに、各設定項目のUIと、ネットワーク設定やアクセス権限設定などの特殊なUIの一部を実装しました。 ## 使用技術と開発した機能 - HTML、JavaScript、jQuery:設定値の表示・入力・送信を行うWeb UI - Ajax:実機の設定値を取得する通信処理 - XML:メニュー階層、設定項目、使用するUIの定義 - C#:XMLからHTML・JavaScriptを生成するコマンドラインツール 設定画面に加え、ユーザーがよく使う機能をカスタムメニューとして登録できる機能を企画・実装しました。多数の設定項目の中から、利用頻度の高い機能にアクセスしやすくするための機能です。 ## 課題と工夫 ### メーカー・海外販社との合意形成 海外販社からの要求を起点としたプロジェクトのため、メーカーと海外販社を含む複数の関係者の間で、メニュー構造や画面デザイン、機能について合意する必要がありました。 ユーザビリティ専門家と既存のメニュー・UIを評価し、設計コンセプトとデザイン要求を明文化しました。そのうえで、メニュー案に基づくモックアップを作成し、Web制作会社に画面デザインを3案依頼しました。メーカーと海外販社に評価してもらい、具体的な画面を確認しながらデザインを決定することで、メーカー側が合意形成を進めやすい状況を作りました。 ### XMLによる画面生成と個別実装の分担 複合機は、フラグシップモデルをベースに、搭載機能の異なる複数のモデルへ展開されます。そのため、各モデルの機能構成に応じて、Webインターフェイスのメニューや設定項目を変更する必要がありました。一方、メーカー側のエンジニアはハードウェア・組み込み開発が中心で、Web専任のエンジニアがいないため、機種展開に伴う変更の一定範囲をハードウェアエンジニアだけで対応できる環境が必要でした。 そこで、メニューと汎用的な設定UIをXMLで定義し、HTML・JavaScriptを生成する方式を採用しました。UIの開発がある程度進んだ段階で、この変換を行うコマンドラインツールを開発しました。メーカー側がHTMLやJavaScriptを直接修正せずに、XMLの定義変更によって機種ごとの画面構成を調整できるようにすることを目的としました。 XMLには、設定項目のラベル名、リード文、設定値のキー名、値の型、使用するUIを定義しました。これらをメニュー階層に沿って階層的に配置することで、メニュー構造と設定画面のレイアウトを定義できるようにしました。生成するUIは、値の表示、選択式の設定、数値の設定、テキスト入力・送信による設定に対応しました。 同じ型の設定値でも用途に合った操作方法を選べるよう、数値設定にはスピンボックス、直接入力、スライダーバーを用意しました。選択式の設定にはラジオボタン、ボタンによる項目選択、ドロップダウンを用意し、XMLで使用するUIを選択できるようにしました。 一方、Wi-Fiネットワーク設定や認証設定など、サービスや他のサーバーとやり取りしながら設定値を決める必要があり、かつ複数箇所で再利用しないUIは個別実装としました。これらはXMLからメニューとUIの配置領域のみを生成し、その領域に独自に実装したUIを組み込む構成にしました。共通化できる設定UIと個別の処理が必要なUIを、同じメニュー構造の中に配置できるようにしました。 ### 既存の設定値取得・更新の仕組みの活用 新しいWebインターフェイスを実現するにあたり、ハードウェア側の変更を最小限に抑える必要がありました。デザイン作業と並行して既存の仕組みを解析し、設定値の取得と更新の両方で活用する方法を検討しました。 既存の仕組みでは、テンプレートファイルに実機の設定状態を参照するパラメーターを記述すると、その値が出力されるようになっていました。従来のWebインターフェイスでは、この仕組みで設定値をHTMLに埋め込んでいました。また、設定値の更新は、所定のキー名を指定してフォームから送信する方式でした。 私はテンプレートの出力を工夫し、実機の設定値をJavaScriptの変数宣言として出力するようにしました。この出力をAjaxで取得し、JavaScriptとして読み込んだ設定値をオブジェクトのプロパティとして扱うことで、UIに表示しました。更新処理についても、既存のフォーム送信で使用するキー名や送信ルールに従った処理をJavaScriptで実装しました。これにより、ハードウェア側の変更を最小限に抑えながら、新しいWebインターフェイスを実現しました。 ## 成果と納品物 スマートフォン・タブレットからWeb設定画面へのアクセスを実現しました。次期開発機のベースとなるモデルのWebインターフェイス全体を実装し、実機上で動作する状態まで開発して、メーカー側で実機に搭載していただきました。開発したWeb設定ツールは、現在販売されているプリンター・複合機に搭載されています。 XML化により、設定画面の約8割を生成できるようになりました。メニューや設定項目の並び替えなど、標準的な画面の構成変更は、HTMLやJavaScriptを直接修正せずにXMLの定義変更で対応できます。 また、私が企画・実装したカスタムメニュー機能に関連して、後に顧客が特許第7491211号を取得しました。私も発明者の一人として記載されています。 - 発明の名称:表示処理装置、表示処理システム、メニュー表示方法、情報処理装置、及びプログラム - 関連特許:[特許第7491211号(公報情報)](https://patents.google.com/patent/JP7491211B2/ja) 納品物は以下のとおりです。 - UIのソースとなるXML - XMLからHTML・JavaScriptを生成する変換プログラムとそのドキュメント - 個別に実装した特殊なUI - 実機上で動作するプログラム

2004年/2年以上

GUIプロトタイプ開発

2004年に参加した、液晶画面を備える製品のGUIプロトタイプを制作するプロジェクトです。製品に組み込むUIについて、画面の見た目に加えて画面遷移や操作時の動きを実装担当者へ正確に伝えるため、PC上で動作するプロトタイプを作成しました。イスラエルのE-sim社製プロトタイピングツール「Rapid Plus」を用い、携帯電話、地上デジタルテレビ、ヘッドマウント型機器を対象とした制作に携わりました。 担当範囲は案件によって異なり、プロトタイプの実装を中心に、企画担当者との仕様調整、開発担当者へのヒアリング、画面遷移・画面要素の設計、グラフィックデザイナーへの制作指示まで担当しました。製品ごとの目的や既存仕様を把握し、それぞれの検討に必要な画面と動作をプロトタイプとして具体化しました。 ### 携帯電話の派生モデル向けプロトタイプ制作 2004年4月から2004年7月 既存の携帯電話を別の国内キャリア向けに展開するため、派生モデルのプロトタイプを制作しました。4名のチームで、ベースモデルのメニューから主要機能までをプロトタイプ上に実装しました。私は実装を担当し、制作したプロトタイプを基に携帯電話メーカーの商品企画担当者と打ち合わせを行い、その内容に応じて変更を加えました。 既存モデルを起点として、新モデルで求められる内容を確認しながら実装を進め、約3カ月で新モデルのプロトタイプを完成させました。企画担当者との検討内容を動作する画面へ反映する作業に携わった案件です。 ### 地上デジタルテレビのUIプロトタイプ制作 2004年8月から2004年11月 試作機を基に、地上デジタルテレビのUIプロトタイプを制作しました。3名のチームのメンバーとして顧客先に常駐し、プロトタイプの作成を担当しました。 プロトタイプを元に、機能を検討しメニュー階層の組み換えや新機能の追加を商品企画担当者が自ら担当するということだったので、メニューの遷移やプロトタイプの画面レイアウトをCSVファイルで定義できるようにプロトタイプを実装しました。 画面解像度も大きく、プロトタイプとしては表示のための負荷の大きいプロトタイプでしたが、実機と同等の表示速度を実現するために、表示ロジックを作りこみました。完成したプロトタイプはメーカーの企画担当者へ納品しました。 ### ヘッドマウント型機器の先行開発向けGUI設計 カメラメーカーが開発したヘッドマウント型オーディオプレーヤーの先行開発機について、展示会向けGUIの仕様を示すプロトタイプを開発しました。私は仕様設計のディレクションとプロトタイプ実装を担当しました。 まず、開発担当者にGUIの目的、現行機能、目指す製品イメージをヒアリングしました。その内容を基に、後続のグラフィックデザインに影響しない範囲で画面遷移と画面要素を設計しました。その後、グラフィックデザイナー2名に制作指示を出し、コンペ形式でデザイン案を比較して採用するデザインを決定しました。 デザイン確定後はプロトタイプの実装を担当し、画面遷移とUIの動きをプロトタイプ上で確定して納品しました。要件の聞き取りから画面構成の設計、デザイン制作の進行、動作の実装まで、一連の工程に関わった経験です。

2006年/3ヶ月以内

海外メーカーの海外仕向け携帯電話 国内キャリア向け仕様書作成

006年、海外携帯電話メーカーがイスラエル向けの端末を国内キャリア向けに開発するにあたり、日本語画面を含む画面遷移図を作成するプロジェクトに参加しました。開発開始時点では必要な画面遷移図が揃っておらず、まず日本語の画面を確認できる最低限の資料を用意する必要があり、所属部署へ支援の依頼がありました。 当時は正常系の画面遷移図がPowerPointで存在していました。この既存資料を基に画面を作成し、日本語ワーディングを反映した画面遷移図として整備することが、プロジェクトの目的でした。 ### 担当範囲と開発体制 私はプロジェクトリーダーとして、作業着手前の現状把握からチーム構築、進捗管理、問い合わせ対応、遅れている作業の支援まで担当しました。開始時には約2週間顧客先に常駐し、資料や作業の状況を把握するとともに、自社が担当する作業範囲を確定しました。その内容を基にチームを構築し、画面の設計とドキュメント内の画面リンク設置を、10名のチームで約3カ月かけて進めました。 管理業務と並行して、日本語ワーディング設計の補助にも携わりました。専任のワーディング設計者に画面の内容を説明しながら、日本語表現の設計を支援しました。 ### 画面作成と日本語ワーディングの整備 画面の作成にはプロトタイピングツールを用い、Excelのワーディングシートと連携する画面を作成しました。画面に表示する文言をExcelのシートで扱い、日本語ワーディングの設計と画面作成を並行して進めました。 日本語表現の設計にあたっては、対象キャリアのワーディング設計者をアサインしてもらいました。私は設計者を補助し、対象画面の内容や意味を説明する役割を担当しました。画面を作成する作業と、国内キャリア向けの文言を設計する作業の両方に関わり、成果物に反映するための支援を行いました。 画面と日本語ワーディングが完成した後、プロトタイプから日本語画面を出力しました。既存のPowerPointに含まれる画面を日本語画面に差し替え、日本語の画面が入った画面遷移図として納品しました。プロトタイプそのものに加え、既存のドキュメント形式に合わせた画面遷移図を作成した案件です。 ### 課題への取り組みと工夫 開始時の課題は、画面遷移図が十分に整っていない状態で、日本語画面を確認できる資料を準備することでした。私は顧客先で現状を確認し、まず自社が担う作業を確定してから、必要なチームを構築しました。既存の正常系の画面遷移図を起点に、プロトタイプによる画面作成、Excel上でのワーディング設計、PowerPointへの反映という作業を組み立てました。 進行中は、チーム全体の進捗を把握するだけでなく、問い合わせへの対応や遅延している作業の支援も行いました。また、ワーディング設計者への画面説明を自ら担当し、管理業務と実作業の双方からプロジェクトを支えました。 ### 成果と経験 10名のチームで約3カ月の作業を行い、日本語画面を含む画面遷移図を作成して納品しました。作業範囲が十分に整理されていない段階から、顧客先での調査、チーム構築、実制作の進行、納品までに携わった経験です。プロジェクトリーダーとしての調整・進行管理と、画面および日本語ワーディングの設計支援を組み合わせて担当した点が、この案件で示せる強みです。

マネージメント能力

アピール項目


アウトプット

GitHub アカウント
未入力です
Qiita アカウント
未入力です
Zenn アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

未入力です

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

未入力です

生成AIの活用状況

未入力です

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
未入力です
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
未入力です
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で50代前半
好きなテキストエディタ
未入力です
希望勤務地
静岡県 / リモート勤務
常時リモートが必要
希望年収
未入力
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?