俺のためのライフマネジメントブログ

良い人生を送るために、生活に関わることを書く

PMFやプロジェクトマネージャーの本を読んでみた

まだよう分かってない。

  • 勝てるプロダクトは勝つべくして勝っている
  • 市場のニーズのある商品を投下せよ

てのは分かったけど、人員の面は簡単に解決できないし、市場のニーズのある商品を投下するのも簡単なことではない気がした。

ただ、自分の会社での成功例だが、顧客さえ獲得してしまうえば、その顧客が飛びつく商品を市場に投下すればある程度勝てるのでは?という事は分かったつもりかも。

客が客に仕事を提供する、というプラットフォーム会社で働いているんだけど、「客がいる」という事を思わせてプラットフォームを作りあげれば、その客に仕事を投下すれば、食いついてくれるだろう、という期待は大いにある。

自分でいつか会社を作る時、マッチングプラットフォーム作りたいなー。。(客と客がトラブル起こしたりもするから危険だけど。)

仕事にどうやっていけせば良いんだろう

現状分かってない。 しかし、色んな観点からプロジェクトを見ないといけない事は分かったので、盲点になりがちな法的観点に興味を持って今回は本を買ったので、良い方向に動くのを信じたい

プロマネ的な知識と設計の知識どっちが対峙かな?

設計の知識

意外と良い気がする。 細かい知識も面白いではあるが、設計の知識も社会人として商売をする上で役に立つ知識な気がする。

仕事は一人ではできず、複数人で役割分担をするが、その際にルールを作る必要がある。 その際に、設計の知識が生きる気がする。

ガバガバにせず、不変であることをよしとし、どれが依存してもよくて、どれは依存してはいけないとか、どういうのを決める知識は役立ちそう。

ソフトウェアが変更に強くないとビジネスは加速しない。

変更に強いソフトウェアを作るのは難しい。 その際にルールが必要になるし、名前が大事。 整理整頓術が大事。

マジックナンバーを使うと(これは何?)になりがち。

定数なんかもモデルに置くのが良いと思う。 ドメイン知識をドメインに置いておくと、責務が確率しやすくなる。 コントローラーにロジックを置かずに、モデルにロジックを置くのは良い

プレゼンテーションにロジックを置くと、移植する際に大変そう。

アプリケーションが進化して、役割分担する時に、htmlにロジックかくと分担が大変そう

本質的な仕事をしないと無駄になりがちなんじゃないか?

て気がしている。 リッチにしようとし過ぎてるから無駄なことを考える気がする。

相手に媚びず、こちらが相手が欲しいものを提供すれば良いだけな気がする。

こちらが追いかけるから、相手に媚びてしまうんだと思う。 そうじゃなくて、相手を追いかけさせたい。

本質的な事をやろうとしなかったら無駄な事をやりがちな気がする。 無駄な事をやらないで、本質的な事をやった方がいいと思う

確かに、ビジネスはマネされると言うが、本質的な事ばかりを考える姿勢を持つと勝てるのではないか?

企業は人が辞めたりして新陳代謝する。 ずっと無敵ではない。 戦力となる人が辞めたりして、本質的な成長はしない気がする。

大きな視点からマクロ的な事をできる者が勝てる気がする

独り言

抽象と具体について

タグやカテゴリーのようなものが抽象だと思う。

DBの外部キーについて

それがあれば、他のテーブルを参照できるもの。 このレコードは、他のテーブルの特定の行を知っている、という概念を表現できる。 それを使えば、親テーブルから子を知れたり、子から親を知れたりする。

中間テーブルは、そのテーブルを使えば互いのテーブルのレコード同士を知れるので、それを活用したテクニック。

idと外部キーは超基本。

idはユニークな値。 それがあるから外部キーが生きる。

クラスやインターフェイスについて

色んなステージで色んな課題があるっぽいな

IT企業における企業の成長を支える、とか、運用をして利益を上げていく、という行為に対して、考える事がいっぱいあるっぽい。

機能追加やバグ修正は容易にはいかない。

色んな事を考慮する必要がある。

俺の頭の中をクリーンにしたい

関心ごとが多すぎる。 クリーンにしていきたい。

エラーの解決が早くなりたいし、問題解決がすぐできるようにしたい。

自社開発と受託だと、自分で会社作る時どっちが良いんだろう?

自社開発

自社製品を客に提供している。 自社製品を売り込んで、それをサポートする体制まで学べるよな気がする。 俺の会社はオペレーションを社内の従業員で回しているが、 外注してオペレーションさせてる会社もある(コルセンとか)

自社製品を売り込むために、広告とか営業活動もある

受託

商品を作りますよ、で営業をかけて、それを承って納品するビジネス。

自社開発のすでにある製品の開発を担当するケースや、 社内にエンジニアがいなく、しかしシステムを作って欲しい会社が外注するケースがあるっぽい。 また、元エンジニアが、前いた会社から開発依頼を受けて作るケースもあるらしい。

受託の営業周りの担当者や、マネージャーと話してみたい気がする。

仕事として「納品する」という行為を行うので、それ相応に難しいと思う。

色んな使われ方するし(後から言われたら困るので)、 プッシュ通知とかメール通知とか、色んな要望出てくるし。 自動化の要望や、saasではなく、自社用にカスタマイズしたチャットツールなどを使いたい、って要望もあるし(客と従業員がやり取りするツール)

客(従業員)の要望は無限で、取捨選択しないといけないんじゃないか?

作るかどうかのジャッジをする前に、

  • 既存のものでどうにかする
  • オペレーションで対応
  • saasなど、他のもので対応できないか考える

等の工夫をするべきだと思う。

「作る」というジャッジメントをすると、それに付随して色んなことをしないといけなくなる。

思った以上に工数がかかって大変なので(使われた後にも改善要望や修正依頼がくるので)

自分が会社を作ったら、従業員や客の声にあまり耳を傾けたくない

と思う。 耳を傾ける => 言うことを聞かないと

  • 言ったのにやってくれない
  • 申請が通らない

とかになる事もあるから「耳を傾ける」は聞こえは良いけど、それが正しいのか考える必要があると思う。

少なくとも「現場が言うから正しい」は疑うべき。

沖縄で生活すると結婚する、という選択肢をとる人が多い

沖縄は人の交流が少なく、結婚して子供を産んで、地元のやつと繋がってるやつが多い。

やることがないのでそういう風になっているのだと思う。

若い奴は内地に出るやつも多い。

嫌なやつの話は耳に入れない方が良い

ライブとかの予定は入れない方が良い。

時間を大幅に拘束されるし、宿泊費用がかかる可能性もあるから。

というか一人がいいんじゃね?
気楽だし