「ビジネスの仕組みがわかる 図解のつくりかた」という本を全文公開します！この本は、2020年4月に出版されたスマホサイズのコンパクトな新書です。『ビジネスモデル2.0図鑑』を出版後、多くの反響をいただき、さまざまな企業でビジネスモデル図解について講演・ワークショップを開催してきたノウハウを凝縮した一冊になっています。 ※当記事の情報を転載、複製、改変等は禁止いたします それではここから全文公開をご覧ください。 第１章：ビジネスモデル図解、基本の「き」はじめに 僕たちが『ビジネスモデル2.0図鑑』を出版したのは２０１８年９月のことです。「Amazon Go」や「Spotify」など、１００の事例のビジネスモデルを同じフォーマットで図解した本は、７万部を超えるベストセラーになりました。その後さまざまな反響を得て、企業から多数の講演・ワークショップの依頼をいただきました。「ビジネスモデルを自分で

はてなって会社としてどんなあんばいかというのを知ってもらうために、書いてみます。しかし明日には変わるかもしれません。 詳しくは、id:jkondoが執筆した「「へんな会社」のつくり方」を是非ご覧ください。 「へんな会社」のつくり方 (NT2X) 作者: 近藤淳也出版社/メーカー: 翔泳社発売日: 2006/02/13メディア: 単行本購入: 57人 クリック: 1,701回この商品を含むブログ (1081件) を見る 組織 朝10時始業 遅刻すると胸にid:jkondoの顔写真付きのバッジ+ひらひらを貼らねばならない屈辱 夜9時にはだいたいみんな帰る 週休二日だが土曜と水曜で休みが選べる 開発合宿 机が自由 椅子は個人に所属 社員は現在17名。男性15名、女性2名 ミーティング ミーティングは部屋の真ん中にある胸の高さまであるERECTAを囲んで 立ってミーティング ミーティングにいて意味

ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増

700万人※1が登録！ 日本最大級の無料メーリングリスト 面倒な出欠確認・スケジュール調整 (日程調整) も、 メール1通ですぐにできる！ 新規登録する(無料) ログインは こちら ※1 2022年9月30日時点 700万人※1が登録！ 日本最大級の 無料メーリングリスト 面倒な出欠確認・スケジュール調整 (日程調整) も、 メール1通ですぐにできる！ ダウンロード

学校や図書館などの教育機関やインターネットカフェのような複数のユーザーが1台のパソコンを共有しているところは多い。こうした場所ではスパイウエアを組み込まれてパスワードが漏えいするなどのセキュリティ上の問題が起こりやすい。不特定多数の人間が使用するためセキュリティへの対策がおざなりだったり、そもそもシステムの管理者がおらず、担当者が片手間で作業していたりすることが多いためだ。 「Trustworthy Computing（信頼できるコンピューター環境）」構想を進めるマイクロソフトはこうした状況に対して、2005年12月、システム管理者ほどの知識がなくても、不特定多数のユーザーが利用する共有パソコンを安全に設定・運営できるシステムツール「Shared Computer Toolkit for Windows XP」（以下、SCT）の配布を開始した。同社のWebサイト（http://www.mi

筆者はプログラミングは好きだったが、テストについてはずっと苦手意識があった。プログラムがそれなりに完成してしまうとそれで満足してしまって、さっそく次のプログラムにとりかかりたくなる。結局、システムテストの段階でハデにバグが見つかってどれだけ周りに迷惑をかけたかわからない（今思い出しても冷や汗が出る）。「自分に代わってテストだけをやってくれる要員」がいてくれたらと本気で願っていた。 だから、１年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。その発想は考えれば考えるほど合理的かつ発展的だ。筆者なりに肉付けした形で紹介したい。 ◆新人は現場のお荷物である 多くのソフト開発企業での新人教育が何から始まるかというと、大学の一般教養課程のような「コンピュータ概論」だったりする。その後に「ソフトウエア分析・設計」とか「プログラミング」の学

人気再燃！ポケモンGOをより楽しむウェアラブルデバイス4選 街中で『ポケモンGO』を遊ぶにしても、スマートフォンを出したりしまったりしながら歩くのはなかなか難し…

前編「マインド・マップの基本と応用」の最後で、マインド・マップとUMLを融合させるというアイデアに触れました。その中で、発散と収束という思考活動の分類を紹介しました。 思考の発散・概念の収集過程（要求ギャザリング）では、マインド・マップを用い、思考の収束・概念のモデル化過程（要求モデリング）では、UMLを用いる。 しかし、実際にマインド・マップとUMLをどう使い分けて、どう連携させていけばいいのでしょうか。役割分担としては、マインド・マップを使って情報を書き留め、UMLを使ってそれを整理するということになります。しかし実際の手順を見てみないことには、イメージがわきにくいでしょう。また、UMLはツールを使って描くことが多いですが、ツールの使い勝手も考える必要があります。 そこで後編では、マインド・マップでお客さんとの打ち合わせの議事録を取り、その結果をUMLダイヤグラムにまとめていく流れを具

マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開