#author("2024-07-13T10:12:22+09:00","default:irrp","irrp")
#author("2024-08-09T08:36:43+09:00","default:irrp","irrp")
→IT業の経営・戦略など

→デジタルトランスフォーメーション

#contents


*一般 [#h4bfa645]
-[[全社横断で「誰が何をやっているのか」を可視化する取り組み | Recruit Tech Blog>https://techblog.recruit.co.jp/article-265/]] 2024.6

-[[印刷会社が突然の事業閉鎖 韓国支社が管理システムやサーバを乗っ取り→日本本社は何もできず - ITmedia NEWS>https://www.itmedia.co.jp/news/articles/2406/06/news180.html]] 2024.5

-[[「『撤退はしないくせに投資もしない』はインパール作戦みたいなもの」 “撤退”か“追加投資”しかない中で、プロダクトマネージャーが持つべき心構え - ログミーTech>https://logmi.jp/tech/articles/330436]] 2024.4

-[[我が社かよ!優秀な人材に「見捨てられる会社」の恐るべき共通点とは | 酒井真弓のDX最前線 | ダイヤモンド・オンライン>https://diamond.jp/articles/-/341519]] 2024.4

-[[「外資系企業に根回しはない」はウソである…グローバル企業が「神速時短」のために必ずやっていること スムーズな意思決定には入念な準備が不可欠 | PRESIDENT Online(プレジデントオンライン)>https://president.jp/articles/-/79984]] 2024.3

-[[米国ができたことを、日本にできない理由はない―JEITAが「日米デジタル経営調査」の結果を発表 - INTERNET Watch>https://internet.watch.impress.co.jp/docs/news/1574528.html]] 2024.3

-[[日立 "激務だけれどホワイト"な働き方のリアル 「課長が何人も辞めた」「低姿勢すぎる上司」 | 最新の週刊東洋経済 | 東洋経済オンライン>https://toyokeizai.net/articles/-/737808]] 2024.3

-[[技術ポートフォリオとは?技術ポートフォリオの図表や戦略を決める方法を解説 | ストックマーク株式会社>https://stockmark.co.jp/coevo/technology-portfolio]] 2023

-[[経産省が出てきた時点でアウト…日立の元技術者が「日本の半導体の凋落原因」として国会で陳述したこと 「技術で勝って、ビジネスで負けた」は大間違い | PRESIDENT Online(プレジデントオンライン)>https://president.jp/articles/-/69408]] 2023.5

-[[アメリカ企業が日本企業に勝るたった一つの事 デザイン会社 ビートラックス: ブログ>https://blog.btrax.com/jp/us-japan/]] 2023.4
--既存の法規や仕組みで決められた事に対しては無理に逆らおうとせず、「しょうがない」という表現で納得をする。実に日本っぽい。
--実は英語には「しょうがない」という単語は無い。近い表現はあるが、端的に一言ですべてを諦めてしまうような、そんな便利な単語は存在していない。アメリカでは「しょうがない」と言うコンセプト事態が存在していない。

-[[ピボット/事業戦略の転換 - いつ、どう判断し、どうピボットするか|原健一郎 | Kenichiro Hara|note>https://note.com/kenichiro_hara/n/na714c266b2b9]] 2023.2

-[[ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1〜CSFはWBSみたいなものと捉える: プログラマの思索>https://forza.cocolog-nifty.com/blog/2023/02/post-7e3f7c.html]] 2023.2

-[[なぜ変化を起こすのが難しいのか? - 数年以上にわたって難しさに向き合い・考え取り組んできたこと / The reason why changing organization is so hard - What I thought and faced for more than several years - Speaker Deck>https://speakerdeck.com/iwashi86/the-reason-why-changing-organization-is-so-hard-what-i-thought-and-faced-for-more-than-several-years]] 2023.1

-[[多くのマーケターが誤解しがちな主要施策の「できること」と「できないこと」のまとめ|池田紀行@トライバル|note>https://note.com/ikedanoriyuki/n/n06bbffdeb155]] 2022.11

-[[主要スタートアップサービスの初期ユーザー獲得方法 デザイン会社 ビートラックス: ブログ>https://blog.btrax.com/jp/first-users/]] 2022.9

-[[創業の手引き sougyou_tebiki_book_202206.pdf>https://www.jfc.go.jp/n/finance/sougyou/pdf/sougyou_tebiki_book_202206.pdf]] 2022.6

-[[特別調査委員会による調査報告書公表のお知らせ | ニュース | 日野自動車株式会社>https://www.hino.co.jp/corp/news/2022/20220802-003303.html]] 2022.8
--日野自動車の法令違反に対する外部調査結果。日本の組織のダメな所が濃縮された感じで一読の価値があるので、IT業ではないが収録しておく。

-[[日本の経営者は「ムチャをしてすごい成果を挙げることこそ、魅力的なリーダーの条件」と勘違いしている | Books&Apps>https://blog.tinect.jp/?p=76781]] 2022.6
--「緊急事態に際して、ムチャをする覚悟」と、「普段からムチャな仕事を常態化すること」は全く別の話だ。
--経営者やリーダーは、平常時においては「汗水垂らさずに金を稼ぐ仕組みづくり」を目指さなければならない。
--そんな環境を用意する事ができない者は経営者ではなく、中抜きしかできない無能な手配師である。

-[[「偉い人」は存在せず、働く場所も休暇も自由に選べる 中途社員も驚く「フラットな組織」は、どのように作られたのか - ログミーBiz>https://logmi.jp/business/articles/326641]] 2022.5

-[[22年勤めたIT系の会社を退職した話 - Qiita>https://qiita.com/yas_sol/items/aa7b6e4d745bbea43846]] 2022.4
--SIerにくる仕事は、マネジメントできない会社からの確率が高い
--会社は「たとえ、エンジニアがどんどん辞めても、補充できると考えている」
--プロジェクトリーダー育成で、プロジェクト計画をないがしろにする
--自社サービスを立ち上げると言っているが、必要なリソースを投下しない

-[[システム開発で曖昧な要望を形にしていく方法 - arclamp>https://arclamp.hatenablog.com/entry/2021/12/09/230643]] 2021.12

-[[インスタ、エアビー、Slack等】人気サービスの初期ユーザー獲得方法>https://blog.btrax.com/jp/first-users/]] 2019.11

-[[「エンジニアが起業に向いてない」?嘘をつけ>http://d.hatena.ne.jp/JavaBlack/20131013/p1]] 2013.10.13
--たとえば「コスト意識のないエンジニアが素晴らしい新製品開発ができる理由」「コスト意識のある経営者が新製品開発にむかない理由」と書いたら,大抵の経営者は「それは違う」「嘘つけ」って言わないかな.コスト意識があるけど,ビジネスチャンスを先読みして巨額の投資ができる経営者/技術者と,そもそもコスト意識がなかったりビジネスチャンスが理解できなかったりして,赤字を垂れ流す経営者/技術者とは全く異なる.

-[[IT・システム判例メモ>http://d.hatena.ne.jp/redips+law/20591231/1327156349]]

-[[まじめに規則を守って仕事をすればするほど、ダメになっていく日本>http://d.hatena.ne.jp/Takeuchi-Lab/20130420/1366411326]] 2013.4.20
--多くの規則は、過去に何か問題があったために、作られる。
--では、そういった過去の事例に学んで規則を積み上げると、何が起こるのか。
--規則だらけで、解が無くなるんですよね。
--あるいは、部門間の調整にとてつもなく時間がかかったり。
--企業で半導体の設計をしていた時のことです。
--歴史のある企業では、過去の失敗事例をもとに、様々なルールがある。
--でも、ルールをすべて守ると、半導体のチップの面積が大きくなって、コストが増える。
--あるいは、設計ミスが無いか、念には念を入れて検証ばかりしていると、設計期間が延びてしまって、市場への製品投入が遅れる。
--一方、新興企業だった三星には、そんなルールがない。

-[[IT・ソフトウェア産業が老化に弱い3つの理由 -倒産の真相>http://gundari.info/?p=170]] 2013.1.18

-[[こんなソーシャル活用をしているくらいなら、今すぐやめた方がいい>http://media.looops.net/naoto/2012/09/20/181/]] 2012.9.20
-[[これから10年生き抜くための「スモールビジネス」とは?>http://www.wakatta-blog.com/what_is_smallbusiness.html]] 2012.8.22

-[[会社を設立しよう>http://blog.myrss.jp/archives/2009/10/_1.html]]

-[[ポール・グレアム ベンチャーの実態>http://d.hatena.ne.jp/lionfan/20091102#1257154993]] 2009.11.2
--1. 共同設立者に注意せよ
--2. ベンチャーが生活のすべてとなる
--3. 感情のジェットコースターだ
--4. 楽しみになりうる
--5. 粘り強さが鍵だ
--6. 長い目で見ろ
--7. 雑用がいっぱい
--8. 最小のものから始めろ
--9. ユーザを巻き込め
--10. アイデアを変更しろ
--11. 競争相手の心配をするな
--12. ユーザの獲得は大変だ
--13. 取引は最悪の結果になると思え
--14. 投資家はバカだ
--15. お芝居をすることになるかもしれない
--16. 運の要素が大きい
--17. コミュニティーの価値
--18. まったく尊敬されない
--19. 成長すると万事が変わる


-[[Ruby on Rails開発者のDavid Heinemeier Hanssonによる「企業の学校」講演>http://toshio.typepad.com/b3_annex/2008/04/ruby-on-railsda.html]]
--「いい製品を作り、価格を設定し、利益を上げる」、これこそシンプルな持続可能なビジネスの基本である。(もちろん、価格をつけたとして、簡単に利益があがるわけではないが…)
--みんな、Facebook、Myspace、YouTubeのようなメガヒットベンチャーを作り出そうと思い込みすぎている
--そんな確率は、低いので、もっと、地に足がついた目標を掲げるべし。
--少ない顧客を対象にすることで、次のトレンドを掴まえるといったことを考えずに、ほかの人よりも少しだけいいものを作ることに集中すればいい。
--イタリア料理店を開くとして、世界最高級のイタリア料理を作ることはなく、町でなかなかいいイタリア料理を目指せばいいのと同じだ。
--ビジネス向けといっても、大企業=Fortune500ならぬFortune500万ともいうべき、小さいな事業をターゲットにすることで、持続可能なビジネスができる。
--だからといって、家族経営の小さなビジネスというわけではない。大企業と、家族経営の小さなビジネスの間に、さまざまなビジネスがあり、何かを犠牲にすることなく人生を楽しむことができる。
--最後に、気楽にやること。この先、やることが減ることはないのだから。

-[[“在宅起業家”が米国で台頭>http://business.nikkeibp.co.jp/article/world/20091029/208351/?P=1]] 2009.10.30
--在宅事業を営むことで家計の少なくとも半分を担っている「在宅起業家(homepreneurs)」は、米国内で推定660万人。在宅起業家全体で民間労働者の10人に1人を雇用していることになり、自宅外に事務所を構える同業他社と多くの点で遜色ないことが判明した。

-[[誰得?と言われない企画書の書き方>http://www.yukawanet.com/sunday/2009/06/post_454.html]]

-[[たった一つの冴えたやり方>http://blog.livedoor.jp/dankogai/archives/51207856.html]] 2009.5.2
--必要になる前に手を打つのではなく、必要になってから速攻で縄をなう。ヒトもカネも、そして会社というヴィークルさえも、必要になってから調達する。これが、どうやらIT界の成功法則のようである。
--これはある意味、熟練度が高い人ほど、そして誠実な人であればあるほど、不快で不愉快な設定である。熟練度が高ければ高いほど、「それをやるのに何が必要なのか」がよくわかるようになり、そして誠実であればあるほど「必要なものがない」状況を許しがたく感じるのだから当然といえば当然である。 kennがはまった罠は、まさにこれだったのではないか。

-[[情報商材業界のダークサイドに巻き込まれないために知っておくべきこと>http://web-tan.forum.impressrd.jp/e/2008/10/27/4269]]
--たとえば管理しているサイトにGoogleアドセンスやYahooアドパートナーなどのコンテンツ連動型広告を表示している場合もあるだろう。そこに怪しげな情報商材の広告が掲載されるということはあり得ることだ。
--たとえ広告の内容に関与していないとしても、ブランドイメージに悪影響を与える可能性がある。それを防ぐためには、Googleアドセンスの管理画面にログインし、「競合広告フィルタ」や「広告レビューセンター」を使って、悪質な可能性のある広告がサイトに表示されないようにするのがいいだろう。

-[[月に20万稼ぐ方法…ねぇ…うーむ>http://slashdot.jp/~okky/journal/462716]] 2009.2.17

-[[こんな企業サイトはイヤだ」ベスト20>http://japan.cnet.com/marketing/story/0,3800080523,20376549,00.htm]] 2008.7.4

-[[ソフトウェアの部品化が失敗する理由>http://www.atmarkit.co.jp/news/analysis/200804/21/software.html]] 2008.4.21
--1. 再利用は品質の安定期まではかえってコストが上がる
--2. 初期目的外のテストは過剰で、そもそも行われてない
--3. 汎用化を目的とせず使い捨てコードを書くことで、短期的コストは下がる
--4. 高い再利用性を持った部品群を作成する方が、使い捨てコードよりも高度な技術が必要
--部品化の実現には、技術的な課題以上に実は経営資源的な課題が横たわっている。日本のソフトウェア企業が部品化を推進できない理由。それは「納品物の作成に手一杯かつ、採算はギリギリで再利用に足る品質を持ったコード作成に必要な資金投下がそもそもできない」ことも理由である。そもそも日本のソフトウェア企業の研究開発予算比率はきわめて低い。

-[[成功している中小企業が持つ5つの要素>http://www.geekpage.jp/blog/?id=2006/12/11]]
--強いリーダーシップ
--質の高い人材を引き付け、確保する能力
--計画性
--戦略的に技術を利用する能力
--外部機関との連携
-[[フリーランサーがやってしまいがちな10の間違い>http://www.geekpage.jp/blog/?id=2008/4/11/4]] 2008.4.13

-[[会社のカルチャーの大切さ>http://satoshi.blogs.com/life/2007/10/post-1.html]] 2007.10.5
--誰かが新しいアイデアを出すと、すかさず「それは○○が過去にやって失敗したよ」「それはあまりにも常識はずれだ」「もう少し良く考えてから提案すれば」と水を差すような発言をする人がいる。経営者として意識すべきなのは、その手の発言がどのくらい企業カルチャーにダメージを与えるかを強く意識することである。そんなネガティブな発言を言う人が大きな顔をしていられる会社ではイノベーションは起こらない。

-[[世界を変える力を、ゆとり経営から生み出そうということ>http://d.hatena.ne.jp/habuakihiro/20040130#p3]]

-[[要件定義カード1枚8万円──脱・人月商売宣言>http://www.atmarkit.co.jp/news/200707/19/starlogic.html]] 2007.7.19

-[[仕様書の責任の所在を明確化>http://itpro.nikkeibp.co.jp/article/COLUMN/20070601/273341/?L=rss]] 2007.7.6
--仕様書を作る作業を別個の有償契約とすべき
--提案書に法的拘束力はない

-[[ソフト開発の3つの契約形態>http://itpro.nikkeibp.co.jp/article/COLUMN/20070601/273310/]] 2007.6.29
--「請負型契約」「委任型契約」「混合型契約」
--契約という観点からは、システムの完成に障害が発生したときの原因が発注者側にあるときのリスク回避を忘れてはならない。例えば、要件定義の段階で、ユーザー企業が提出した要望や指示に従って作業したために生じた瑕疵(かし)については、一切責任を負わないという明確な免責をしておかなければならない。意外にこの部分をいいかげんにした契約が少なくない。

-[[ソフトの価格下落は止まらない>http://itpro.nikkeibp.co.jp/article/COLUMN/20070508/270263/?ST=saas&P=1]] 2007.5.14
--簡単な解決策はありません。1つの結論は、ソフトとサービスの「ハイブリッド企業」になることです。サービスはソフト製品と違って、コモディティ化や不正コピーのリスクが少ない。特定顧客のニーズにフォーカスして、その解決策を提供するものだからです。

-[[社会貢献うたうIT経営者の偽善:http://it.nikkei.co.jp/business/news/index.aspx?n=MMITzv000020072006]] 2006.7.24

-[[著作権の帰属規定は契約で移転できる>http://itpro.nikkeibp.co.jp/article/COLUMN/20070601/273347/]] 2007.7.24
--著作権法第14条が著作権者を推定する基準は、誰が開発資金を支出したかではなく、誰が著作行為を行ったかなのである。
--ただし実際には、契約によって著作権の帰属を変更することができる。著作権法第14条の規定は任意規定であるため、開発したシステムの著作権者を誰にするかに関して、関係当事者が、推定された者を著作権者としない合意をすれば、その合意が著作権法第14条に優先する効力を持つ
--著作権の帰属規定は契約で変更できるということを理解しておけば、単に著作権をどちらが持つかだけに限らず、ユーザーにとって重要な一部のプログラムに限定してユーザー企業側に著作権を帰属させるなど、発注者側とユーザー企業側で、お互いに納得のできる様々な手法を考案できる


*営業 [#a0162f63]
-[[セールスアニマルになろう スタートアップ初期の営業戦略 | PPT>https://www.slideshare.net/slideshow/startup-sales-animal/49722472#9]] 2024.8

-[[仕事ができない営業ほど「困りごとはありませんか?」と聞く…一流営業が使う「心の距離を縮める」最強フレーズ 「売り込み臭」が消え、相手のニーズを引き出せる | PRESIDENT Online(プレジデントオンライン)>https://president.jp/articles/-/83486]] 2024.7

-[[営業の崩壊と再生〜営業の問題を解決する14の処方箋 | knowledge / baigie>https://baigie.me/officialblog/2023/08/28/sales-team-super-phoenix/]] 2023.8

トップ   編集 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS