【ゴールデンウィーク営業のお知らせ】 2024年4月27日(土)~2024年5月6日(月)の期間中、GWのため休業とさせていただきます。 ※4月30日(火)、5月1日(水)、2日(木)は通常営業いたします。 ※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。

ID:63609さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


新規事業を立ち上げ、会社を運営する一員になる

今までの業務の中で映像を活用した社会インフラにはまだまだ可能性と課題が多くあると感じている。特にヘルスケア分野については日本の習慣や文化、思想などの特性と、ハードウェアに関する技術背景を考えると世界に先駆けた新たな仕組みを創出できる可能性があると考えている。 ソフトウェアの力をハードウェアと組み合わせて新たな付加価値を生み出したい。

年収評価シート

2020年/2年以上

デジタルカメラの新たな活用による病院システム開発

①【プロジェクト概要】 大手メーカーの新規事業開発として、デジタルカメラの市場規模縮小に手当する為の有望な新規ビジネス開拓の一つとして医療・ヘルスケア分野での映像活用ソリューションを開発 ②【チーム情報】 構成人数:約50名 構成要員;3つの異なる部署に所属しているソフトウェアエンジニアからなる ③開発・実装内容 ・【概要】 新たなデジタルカメラ写真の活用を医療の現場に広げるために、既存のカメラの改造を伴う院内システムの開発をおこなった 既存製品開発がメインの組織の中で新規事業を立ち上げる特別プロジェクトとして立ち上げ、市場性や付加価値検証のためのプロトタイプ開発から始め、最終的に製品として顧客の病院へ収めるまでを一貫しておこなった ここで私は全体の開発責任者として約3年間に渡り現場の取りまとめと会社内・顧客との調整を担当した。 システムアーキテクチャや機能などの決定の責任を責務として持ち、新規事業立ち上げの社内改革の一端を担うプロジェクトであった ・【どのような機能の開発・実装か】 システム構成として、オンプレミス環境で動作するサーバー機能部分と、現場の医師・スタッフが利用するための端末PC上のアプリケーションから構成されるものを開発 サーバー側利用技術:Node.js, JaveScript, CSS, HTML, JQuery, MySQL, 端末PC側利用技術:C, C++, C#, WPF, 利用ツール:VisualStudio2017, GitLab, Jira, VisualStudioCode,Confluence ・【課題・問題点】 1. 組織に新規事業を立ち上げる仕組みや文化が確立されておらず、組織内での協力が十分にえられなかった 2. ターゲットシステムを構築するためには複数の部署にまたがる技術が必要なため、異なる考え方や価値観を持ったメンバーを同じ成果に向けてまとめていく必要があった 3. 医療分野に関わるシステムで、従来例が存在しないシステムであるため、国の医療認証機関等との調整が必要で、全体の日程や工数管理が困難であった 4. 複数のグループ会社との共同プロジェクトとなった事もあり、会社間の調整が難しかった ・【打ち手・使用した技術】 1.の課題を解決するためにプロトタイプを小さく初め、既存製品開発に影響を与えないプロセスで本プロダクトの意義や市場での反応を現場に通いながら積み上げ、経営層にインプットした また、既存製品の本部として判断が困難な局面には社内の医療関連部署の役員にアクセスし、全社的な活動へとステージを上げ、本部外から本部長に話を持ちかけてもらうようにした 2.の課題を解決するために、各メンバーの資質を日常のコミュニケーションを通じて理解し、仕様や日程が決めにくい探索フェーズの業務と製品化の際に必須となるベース技術の開発とに分けてアサインし、徐々に相互の連携が取れるように運用した またConfluenceやJiraなどのツールを用い、各メンバーのコミュニケーションを活性化し、リーダーやマネジメントも適宜Watchできるようにした 3.の課題を解決するために、業界の調査や影響力のあるステークホルダーとのコミュニケーションを持つように行動し、特に学会理事や主要大学病院の教授などと一緒に国の認証機関であるPMDA等との検討のためのデータを用意した それにより見えてなかった計画を具体的なものに落とし込んだ 4.の課題を解決するために、学会や医師の現場での本プロダクトに対する反応と、世界の関連技術動向や業界の標準化技術に関する可能性をまとめ実際に各企業の事業部門と現場の方達と議論する場を適宜設け、グループ全体の利益を各企業の事業担当部門自分自身で理解してもらうように努めた

2018年/2年以上

FA映像活用画像処理システムプロダクト開発

①【プロジェクト概要】 大手メーカーの新規事業開発として、映像の新規活用をFA分野に広げるため工場など製造現場での映像活用の導入工数軽減のための映像処理エディットシステムを開発 ②【チーム情報】 構成人数:約20名 構成要員;ソフトウェアエンジニアと自社工場生産技術エンジニアからなる ③開発・実装内容 ・【概要】 生産現場でのカメラを用いた映像活用はここ数年業界でも注目されていたが、その導入には多くの課題が存在している その一つが生産現場では、その現場のニーズにかなり厳密に合わせ込んでシステムを組み上げないと利用に値しない物になってしまうと言うものだ それを実現する為には映像処理の設計を現場に合わせて組み立てることができるSIerがそれほど多く存在しない、さらにそのコストも大きいと言う課題がある事がわかった そこで映像処理を現場でできるだけ容易に組み立てられ、しかも多様なカメラシステムに対応できる仕組みを取り入れた仕様でパッケージされたプロダクトを開発した 私の役割は、この開発チームの責任者として、コスト・工数・日程・仕様・性能、そして全体のシステムアーキテクチャ決定について方針と決定を行うこと、事業部門や顧客との技術的な交渉や説明を行うことであった ・【どのような機能の開発・実装か】 システム構成としては生産現場に設置される産業用PCにインストールされるパッケージアプリケーションとして仕上げた 実装は画像処理周りの機能はCとC++によるネイティブ開発とし、処理速度と他システムへの展開を想定してモジュール構成とした UIを含むアプリケーション部分はPCがWindowsで、現場のSIerがWinFormsの経験が多いう状況からWinFormsを採用した 開発に利用した技術:C, C++, C#, WinForms, 利用ツール:VisualStudio2017, GitLab, Jira, ・【課題・問題点】 1. 自社工場の生産技術担当との協力で、アプリケーションの機能や性能を決めていったが、彼らとソフトウェア開発部門とは根本的に業務の目的が異なるため、価値観の共有が難しく調整が難航した 2. まだこの分野の市場が十分立ち上がっていないため、PoCを繰り返すのみで止まってしまう状況になってしまった 3. 新規事業立ち上げが得意な組織ではないため、新規要素開発係る開発費や人的リソースに対するトップの理解が得られなかった ・【打ち手・使用した技術】 1.の課題を解決するために工場の担当者にソフトウェア製品を作る際の重要事項を共有し、現場での要件をソフトウェアの仕様に落とすための共通認識を持てるようにした 2.の課題を解決するためにPoCを開始する前に顧客が自分達で私たちのパッケージを活用した場合の効果について検証できるためのサンプルアプリケーションと、サンプルスクリプトを用意し、無駄に時間とコストをかけてPoCをする必要性を低減した その上でPoCを実施する顧客の場合には、現場だけではなく、決裁者に対して理解してもらえるような情報をパッケージとして用意した 3.の課題を解決するために、この開発で新規に開発するソフトウェア成果物が、他の自社開発案件にも流用可能となるようにアーキテクチャをドーナツアーキテクチャとし、しかもインフラ部分はSDKとしてアプリケーションの対象ドメインごとに利用できるようにAPIの設計を行なった APIはフローズンスポットとホットスポットの加減を用途に応じて対応可能になるように今後拡張設計できるように開発した またその効果をわかりやすくするために、サンプルユースケースを数個用意して、実際に開発成果物が再利用可能なものとなっている事を説明しながら予算の継続や人的配置を確保した

マネージメント能力

大手メーカーにて開発部門のプロダクト開発全体チーフマネジメント 約50名の開発エンジニアの開発行為の方針、目標、工数指針などを立て、どの進捗や外部との調整を行った 複数の組織にまたがるメンバーの管理も含まれており、各組織との調整や提案も行った
プロダクトの市場導入が目的であった為、構成しているメンバーがそれぞれ十分に役割を達成できるように組織としてのアウトプットを最大化する事が大きな責務だった。 また新規事業案件だったため、機能や仕様が当初から確定していたわけでは無く、試作からPoCを経て最終製品完成まで異なるフェーズを同じ限られたメンバーでこなす必要があった。 その為、各メンバーの特性に合わせて役割をアサインし、フェーズに応じてそれぞれの仕事でのポイントを設定して異なる価値基準への動機付けを行うなどの対策が必要となり実施した。
私は先ず組織を横断して活動が必要な案件である事、組織としても今まで取り組んだ事がない事案だった事もあり、本部の開発部門長と言う開発トップと今回の仕事をする意義とそれがその組織の将来のためになるロジックを共有する事から始めた。 大きな組織で起こりやすい部門のサイロ化と既得権の確保への意識がやはりかなり存在しており、さらに既存事業の開発をメインで行なっている組織であることもあり、新規事業に関わる人的リソースを容易に提供してくれる雰囲気は無かった。 そこで今回のプロダクトが自社の利益にどの程度将来関われる可能性があるか、この分野でのビジネスが市場規模や業界動向、時勢のニーズから極めて有望である事を各開発部門の部長に説明して理解と協力を求めた。 しかし、概ね総論賛成各論反対的な雰囲気から中々脱せない状況で、限られたメンバーで開始するしかなかった。 それを打開する為に杖術した開発部門のトップにリーダーシップをとってもらうべきと考え、行動した。 ここで考えたのは会社の中での我々事業本部の役割を活用する事である。 この会社の場合会社は事業本部制を取っていた。 各事業本部は独立した事業運営体として責任と権限をもっていた。その為事業本部長はどうしても自身の本部の中でしかそのリソースや経営を考えない状況になっていた。しかし一方で、会社全体としては主要な事業体が市場の行き詰まり感を抱えていて、新たなビジネスの創出に苦労している状況だった。 その中で当事業本部に技術的新規活用に期待する声は聞こえていた。 そこで医療・ヘルスケアを新規に検討している他の事業本部との交流を強め、その分野の担当役員に話をつなぐ事を実現した。 そしてその担当役員から当事業本部長に働きかけてもらい、会社全体の取り組みを立ち上げてそれに参加すると言う形をとった。 これにより渋っていた各部長達も徐々に協力的に関わってくれるようになった。 次にこのプロジェクトに関わるメンバーの意識を一つの目的に合わせる事に取り組んだ。 組織が異なるメンバーが集まった事で、それぞれが従来の仕事の進め方や価値観が異なっていた。 その為、お互いの行動に理解が不足しており、小さな揉め事からかなり重大な問題まで現場では発生した。 特に既存製品を開発していたメンバーは決められた仕事の範囲でしか業務にを行った経験が無かったり、日程と仕様が明確になってない仕事はやった事が無かったりした。彼らは、このプロジェクトの初期段階での調査や試作を繰り返しながら業務を進めていく事に大きな戸惑いと不安があった。 そこで私はどんなメンバーにはプロダクトの基本的な要素に関する開発を先ずは担当してもらうことにした。 これらの部分は比較的に仕様は確定するのが早く、プロトタイプから最終製品までのロードマップを意識しながら開発が進められるため、彼らに安心感を与えながら全体の利益に貢献できた。 関連部門、特に事業部門外崎調整は更に工夫が必要だった。 先程記載したように事業本部体制の為、本部の事業部門も自事業本部長の耳障り通い内容に話をまとめがちとなった。 今回の案件は関連会社も巻き込んだプロジェクトと発展していた為、一事業本部の利益にかなう立て付け方では成立しない要素が存在していた。 大きな方向性や利益に関しては各関連会社でコンセンサスは取れていたが、具体的な細部に至っては調整の余地は大きかった。 そこで私はそれぞれの会社に事業部門に対して、今回の狙いである分野の中で影響力がある大学病院の供述や学会の理事などを引き合わせ、彼らから今回のプロダクトの業界における意義を説明してもらうことにした。 これによりよりリアルにこのプロダクトの将来や現場の期待を感じ取ってもらい、足元の利益以上に期待値が持てるプロダクトであると言う認識を自分自身で感じ取ってもらうようにした。 人に説明されたり、説得されるのではなく、自分で考えて理解してもらった事で、各会社の事業部門も、自発的に協力して戦略的な思考を行うようになった。 最後は製品として仕上げるフェーズでの取り組みである。 ここに至っては登場人物として重要なのは品質管理部門である。 そもそも既存事業の品質管理を行う部門である為、新規事業である今回の案件では彼ら自身なんら経験や知見が無い状況であった。 その為最初はこの業務自体に抵抗され、本部として評価業務が実施できない可能性が浮上した。 関連会社ではこの分野で実績がある部隊が既に存在したが、残念ながら異なる会社の部隊を簡単には活用できなかった。 そこで私は部分的にプロダクトの評価業務を関連会社に依頼できる手段を考えた。 今回のプロダクトの構成要素を分解し、出来るだけ疎な関係性を認めてもらえるようにシステムを構成した。 そして自本部で対応可能な構成システムの一部を既存製品の評価部門に担当してもらえることにした。 他方関連会社の経験豊富な部門には彼らの従来の業務の隙間に入れてもらえるようなものに仕立て、先ほどの事業部門のみ理解と協力を得て担当してもらうことになった。 システム最終的にこのシステムが今回の顧客の現場で確認される作業は我々開発部門が実際の作業を代替する事で各部門の調整ができた。 またこれを実現する為に品質部門の力を借りて本部内のQMS改良なども行った。 以上のように新規事業を立ち上げるプロジェクトであった為、多くの課題があり、大企業という環境か動きにくい状況でもあったが、結局は、その仕事に本当に意味があると信じらてえだけの体験を自分自身で咀嚼し腑に落とした上で、それを発信して仲間を広げていくことがプロジェクトを成果の出るものとする為には欠かせなかった要素だと考えている。 今、世の中で日本はイノベーションが生まれにくいと言われている。 確かに大企業では特に既存と新規事業の両立が困難な状況もある。 「両効きの経営」など注目されている研究もあるがやはり現場ではトップの協力なくしては新しい動きは難しい。 私はトップが出来るだけ安心感を持って投資判断できる取り組みを心がける事も現実的には重要な要素だと感じている。

アピール項目


アウトプット

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

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

クラウドネイティブな設計 マイクロサービス

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

裁量を持たせてもらい、ある程度自由に活動させてもらえる環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
問題解決力 / 巻き込み力 / 経営判断力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
理念や社会的意義
やりたくない分野
アダルト
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で50代後半
好きな Text Editor
VisualStudioCode
希望勤務地
東京都 / 神奈川県 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
1000万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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