自社開発デバイスの新規機能追加、問題改善（プロジェクト進捗、メンバ作業の管理）
・デバイスに対して必要とされる機能の洗い出し
→発売時の付加価値の検討、具体化
・新機能対応に関する作業内容のブレークダウン
→細分化した作業をメンバに割り振りし各メンバに手空き時間が極力内容に配慮
・デバイスの市場提供後は問題発生時の対応
→問題ごとに優先順位を設けて優先度の高いものから対応
従来は市場に存在しないデバイス（製品）の開発に対応していたため、機能追加に関しても確実な正解はなく企画部隊や経営陣のアイデアを技術者の技術不足で実現できないというケースが生じないようにしたいと考えていました。また、当然ですが出されたアイデアについてエンジニア視点、利用者視点で意見を出してより良い製品に出来るように心がけました。
参画したスタートアップ企業はエンジニアをマネジメントするメンバが居なかったため、当初はタスクを明確にするためのredmineの導入（2014～2015年のため）を行い、エンジニアのタスクを個々に細分化して登録、進捗管理に利用しました。当初は自分一人での参画でしたが最終的に10人前後の規模になり、製品発売後は五月雨に発生するユーザーからの問題報告への対応の整理に寄与しました。また、台湾のODMベンダーとAndroid（OS,framework）のソースコード管理をする必要も有ったため社内gitサーバ（gerrit）の導入を行いました。gerritはgoogleもAndroidのソースコード管理に利用しており、ベンダーとのコード共有に役に立ちました。特にパッチ単位（機能単位）での動作検証（テスト）、masterへの取り込みが全メンバに可視化され、全員が同じ環境で作業できたため、開発スピードに大いに寄与したものと考えます。
私が得意なことは「自分の想定したゴールへの道筋を引いてその通りに進めれば想定したゴールには到達出来る」というものだと考えて居ます。それ自体は自身の強みであり、例えばある程度規定の業務が固まっているようなSIerの業務であったり、顧客の求めるものが既に固まっているような受託開発では有用だと思っています。ただ、スタートアップや小規模ベンチャーでは仕様はもちろん、製品コンセプトが固まっていなかったり、良く言えば常に臨機応変にゴールを変える必要にも迫られます。そのような場合にPM/PLとしては当初想定したゴールを変えずに進めたいと考えることも少なくはありません。実際、雇われPMやPLは製品の付加価値向上よりも自分の責任になるプロジェクトの進捗を優先する傾向にあると思います。（エンドユーザーからの発注があり、納期がある場合には敢えてゴールを変えずに突き進む必要もあるかも知れませんが）私は自社製品を開発するスタートアップ企業においては、必要に応じて臨機応変にゴールを変え、それに技術者も同じ目線で対応する必要があるものと考えています。特に、自分の発言力がある現場で自分が無難な選択を提案してしまうことで製品価値を毀損することが無いかということは常に懸念して常に製品価値を高めるにはどうすれば良いかを意識して作業していました。