内上昌裕 / Co-CEO harmo株式会社

社会人10年をSIerでPG→SE→PL→PMと過ごし、次の10年は事業会社で新規立ち…

内上昌裕 / Co-CEO harmo株式会社

社会人10年をSIerでPG→SE→PL→PMと過ごし、次の10年は事業会社で新規立ち上げPM→PdM→プロダクト企画マネジャーと進む。現在は、お薬手帳アプリの harmo株式会社で役職ありながらも本職PM・PdMをやってます。

最近の記事

上位概念を見失ったルールの適用とその教訓

システム開発の現場ではしばしば起こることと思われますが、バグレベルのものが「仕様どおり」として、見逃されてしまうことがあります。 このことは、その時点の仕様決定のルールのなかだけで判断すると、まったく合理的な判断をしたと言える状況だったりします。 ただ、これは言い換えると、「ルールに従うこと」が、その現場で目的になってしまっていると言えます。   プロダクト開発における仕様の上位概念は、「仕様決定のルールに従うかどうか」ではなく、「ユーザーにとってわかりやすい・使いやすい

    • ITプロダクトにおける段階的進化の重要性

      日英伊が次世代戦闘機を共同開発するという新聞記事を見て、 三菱がジェット機の開発を断念したことを思い出す。 そういえば、Appleが電気自動車の開発を断念した。 そういえば、LINEとみずほがネット銀行の開発を断念した。 なぜか? 私の思うところとしては、いきなり「完成品」を作りにいって、あまりに複雑で不具合の収束しなかった、ということに尽きると思う。 Appleの場合はいきなり自動運転レベル4 or 5 を狙いにいったのだと思う。今から参入するにはそこから入らねば意

      • 家事から学ぶ業務改善の落とし穴

        自宅の浴室がなんかにおう。雑巾臭がする。 浴室の掃除は毎日私。 「普段づかい」のところは、必ずバスマジックリン&スポンジで洗っている。頻度の濃淡はあるが、ニオイなんて出るはずないと思っている。 なのになぜニオイが取れないのか分からない。 あっちこっち漂白剤も使ってみる。取れない。時は経つ。 そこでつい最近やっとニオイの元にたどり着く。犯人は「壁」。 確かにここは日々の掃除対象から漏れていた。 「普段づかいを掃除してるから大丈夫」という習慣が、 無意識に「浴室の壁」を選

        • システム開発における課題解決に要する時間短縮の可能性について

          結論から言えば、「全体」を把握した人々が、それぞれ課題解決の「部分」業務に当たることで解決までの時間は短縮できると思われます。 システム開発における課題解決の一連のプロセスはざっくりいえば以下のようになります。 ①「初動/影響範囲特定」 ②「解決策の検討」 ③「解決策のレビュー」 ④「対策の実施」 このうち②③で「部分解決」的なスコープで動き出すと、このフェーズから抜けられなくなります。「全体」を把握していないと運用も含めて考えた時に、辻褄が合わなくなってしまうからです

        上位概念を見失ったルールの適用とその教訓

          組織の成長を阻む言葉の壁:解釈のズレをどう乗り越えるか

          なにか会社で広く人を集めて議論する場や、普段の業務で議論する場でも、常々思うことがあります。 それは、発せられる「言葉=文字による表現」というものは、「時間的にも空間的にもある瞬間を切り取ったもの」であって、「概念の広がり」や「言葉に貼り付いている経験」を汲み取って解釈するのは、受け手に委ねられてしまうということです。 だから「発信側」と「受け手側」の「思い/意識/認識」は絶対にズレる。このズレをあらかじめ無くせば議論の精度は高まる。しかしズレがあるがゆえに、多様性を生み

          組織の成長を阻む言葉の壁:解釈のズレをどう乗り越えるか

          Webシステム開発:「学問」と「現実適用」の間にあるもの

          システム開発における「異常系テスト」は、「教科書通り」(=学問:ソフトウェア工学)であれば、「システムテストフェーズ」で実施することになる(テキストによって微妙なユレあり)。 しかしながら「教科書通り」というのは、「理想的なウォーターフォール」である。 ここに「工数・時間の制限」と「開発体制の規模」を勘案する必要がある。現場は「理想的」な状況は ほとんどありえない。よって「テストフェーズ」をいかにミニマイズできるか、ということがいつも課題となる。 これに対して現状私は、

          Webシステム開発:「学問」と「現実適用」の間にあるもの

          ビジネスおける「直感」と「論理」について

          日々の「プロダクト企画~仕様検討」業務で、陥りやすいことがあります。 論理(考慮ケースの不足)と感情(私はこう思う)の整理が交錯状態となって、意思決定や優先順位づけがやりづらくなってしまう、ということです。 この現状について、感じたところを書き残しておきたいと思います。 「直感の側」から「論理の不毛」を撃ってみる 論理の使い方は、推論によって「このケースは可能性としてない」ということを導いて、選択肢を減らしていくことが主だと思われる。   論理は、それ自体、自律性はな

          ビジネスおける「直感」と「論理」について

          DX成功の鍵:文化的土壌/精神的態度と技術導入の関係性

          アラブ諸国には民主主義は根付かない。アメリカはそんな失敗をイラク統治あたりで本格的にしたわけだが、ある制度/考え方が成立する精神的土壌・文化的土壌が揃っていないと、方法だけ移植しても、うまく運営できない。ということはいつでもどこでもなんにでも発生する。 これは日本における「DX」も同様であろうと思う。 DXは表面的には現場業務をIT化するわけだが、それがその後のプロセスや意思決定にどのように使われ、どのように影響を及ぼすのか、それによって組織全体として「全体最適」がどのよ

          DX成功の鍵:文化的土壌/精神的態度と技術導入の関係性

          社会人の勉強は Howから入って原理原則 に至ると長持ちする

          先日、社会人の勉強時間がとても少ないという記事がありました。 【衝撃】日本の「ゼロ勉強社会人」は52.6% なんと1日の勉強時間は平均13分だけ(横山信弘) - エキスパート - Yahoo!ニュース 私自身が「ITサービス開発のプロジェクトマネジメントの勉強会」を開催していて、改めて自分の「自分のPMスキルの源流」を訪ねてみる機会が増えましたが、 知識/考え方の側面において、およそ「武経七書」に負っているところが大きいということが確認できました。 ここに書かれている

          社会人の勉強は Howから入って原理原則 に至ると長持ちする

          Excelワークの落とし穴

          近頃、経理系のファイルを作成・更新することが多いです。 集計項目をいくつも作るわけですが、 ここで、1セルだけで計算可能なように 関数を組み合わせて作るとします。 この瞬間、シートがとてもシンプルになるし、スッキリするし、感動的だったりします。 ですが、後日の修正や 検算作業ですぐに気づきます。 その組み合わされた関数を 読み解くのにとても時間がかかります。別の人に渡すと、理解されません。 となると、高度な関数を組み合わせて作りきれば良い、というわけにはいかなくな

          日本と西洋においける「計画」に対する考え方の差

          象徴的に言えば、 東京の街並みと西洋の街並みを比較すれば、計画や設計に対する考え方の差が分かる。 銀閣寺とサグラダ・ファミリアやルーブル美術館(←数百年で今の形)を比較すれば、拡張性に対する考え方の差が分かる。 日本は、1つ1つの完成度は高いが、そのあと手を入れられない。 西洋は、すこしずつ手を入れて、途中段階でも使えるものでありながら、完成を目指す。 こういった差は、今のITサービスのあり方にも色濃く影を落としていると思う。 プラットフォーム的なサービスなどもまさにこ

          日本と西洋においける「計画」に対する考え方の差

          ITを「量の世界」ではなく「質の世界」に使うことを意識する

          ある会議で、(円安もあったりで)日本の衰退みたいな話題が出ました。 その時に、昔見た『ゴジラ対キングギドラ』(1991年作:バブル最後の年、私は10歳)のことを思い出してしまいました。 20世紀後半、日本はすごかったこの作品の出だしは、23世紀には日本が経済的に世界を支配しており、それを良しとしない未来人が過去(1991年)にタイムトラベルしてきて、ゴジラとキングギドラを復活させて、日本を再起不能なように壊滅させてしまおうというものでした。   1991年当時のいわゆる「

          ITを「量の世界」ではなく「質の世界」に使うことを意識する

          ビジネススキル習得:座学と経験のバランス問題

          つい先日にピアノ発表会があり、幼稚園の息子との連弾(伴奏)で、この日のために、私は今年の2月に初めてピアノを習い始めました。 この私自身のピアノ練習のなかで、「習得プロセス」というものを、この齢(42歳)になって 改めて 意識する ことで、気づきが 多かったです。 その気づきというのは、 なにかを習得するためには、「手と脳」「五感と脳」を使うということ。そして、毎日やり続けること。「毎日」という威力が凄まじいということ。 ピアノの先生から そうご教授いただきました。 転

          ビジネススキル習得:座学と経験のバランス問題

          プロダクトとは課題解決そのもの

          顧客(現場ユーザー)と直接情報交換をする機会を得る。   プロダクト開発は、現場ユーザーとの対話が重要と改めて思う。   サービスとはなにか?それは顧客の課題解決。 顧客の課題は現場にあり、課題解決のヒントも現場にあり。 プロダクトは課題解決サービスそのものだから、現場との対話抜きのプロダクト開発はありえない。   もちろん、社のプロダクトの方向性や構想(harmoの考えていること)と、顧客が考えていることのベクトルの一致点を見出しながら話を進めないと、すぐにプロダクトのバラ

          プロダクトとは課題解決そのもの