倉貫義人のレビュー一覧

著者の1人、倉貫さんのブログや書籍を読んでいれば、大体は聞いたことあるネタが多いが、それでも改めて図解されると頭の中で整理が進む。
自分は世の中的には割とリモートワークには適応している部類なんだと思うが、振り返ってみて一番重要なのは全員がリモート前提になること。それにいち早く気づいて実践したソニック...続きを読むガーデンは本当に先見の明がある。

本書を読む前は、リモートワークでチームワークを発揮する環境・仕組みのイメージがなかった。

しかし、本書を読むことで、実体験に基づいたリモートチームの環境作り、マネジメント方法を学ぶことができる。

今後の働き方の標準となり得るリモートワークを検討している人に読んでもらいたい一冊です。

リモートチ...続きを読むーム構築中にうまくいかない時に本書の内容を実践します。

これは、まさに今の時代を反映している。
オープネスが大事だという本を以前に読んだが、それを作りだすための空気作りに「ホウレンソウ」ではなく雑談＋相談の「ザッソウ」が必要だということに、心から賛同した。

ソフト開発を月額定額制料金にして、納品なし顧客のパートナーになるというソフトウェア開発会社。
ソフト開発者の理想の形かと。

倉貫さんの2冊目。
ソニックガーデンのオフィスには何回かおじゃましていて、実際にリモートチームの様子の一端も見たことがあるけれど、その裏にある考えや歴史がわかって良かった。

ツールがどうこうというところだけでなく、チームとしての一体感を醸成することが必要。これは、文脈は違うけどほげほげショアでも一...続きを読む緒だと思う。

5年ほど前の本なので知っている内容がほとんどだったが、ビジネスモデルとして実践しているという点でとても参考になった。

これまでのソフトウェア開発の狭間を埋める、納品のない開発。所有ではなく、利用に焦点を絞って、毎月定額で、ソフトウェア開発サービスを提供するという感じか？成果に焦点を当てるという非常に意欲的な取り組み。取り回しの良い小規模企業でないとなかなか上手く行かなそうだが、ギルドという仕組みで、フリーランスやそ...続きを読むれ以外の共感する人々を取り込んで行こうという発想は素晴らしいと思う。

以下注目点

・本当に必要な機能を本当に必要な順番に少しずつ開発していく
・デフェンシブな開発からアグレッシブな開発へ。
・オーダメイド、納品しない、派遣しない。
・開発と運用を担当
・完成責任は請け負わない代わりに、圧倒的な費用対効果を提供する
・専門性の高い職種に対して、他の社員と同じ扱いはできない。
・プロフェッショナルサービス
・新規事業と要件定義の相性は最悪
・一ヶ月から3ヶ月程度で開発できる機能で、はやめに運用に入る。
・作らない提案。思いつき程度の機能は、すぐには作らない。
・納品ではないので、瑕疵担保責任は負わない。
・ドキュメント読み終わった、訪問読み終わった、納期や完成品の約束読み終わった。
・要件を定義するのではなく、事業の目的を共有する。
・顧客が動作確認できるレベルで作業を切り出す。
・なぜその機能が必要なのか
・所有から利用へ、完成から持続へ
・本当に必要になるまで、予想で作ったりするのはやめよう。
・資料を残さない代わりに、コードを読みやすくすることにこだわっている。
・KPT keep, problem, try
・そもそもを考え、何をやらないかを決める。

顧客のビジネス成功をゴールとするシステム構築をする場合、派遣やSESなどの客先常駐をすることが多いのだが、本書ではそれをせず、月ごとに定額の費用を払うビジネスモデルの解説をしている。
実際にこのようなビジネスモデルに理解をしてくれる顧客が多い企業だとできそう。従来の企業、大企業などは理解を得られにく...続きを読むいかも？でも実現できればお客様・働く側双方にとって良いビジネスモデルとなるから広まって欲しいと思った。

フリーランスとして会社や場所に囚われずに自由に働くのとは違う、リモートチームに必要なことは、信頼関係とセルフマネジメント、チームワーク。
でも、これってリモートかどうかに関わらず、トップダウンではなく一人ひとりが自立した組織づくりの上ではとても大事なこと。

本書の中にもあったけど、リモートワークっ...続きを読むて表面上の状況として見えてきているだけで、仕事の在り方や、仕事の成果をどうはかるか、チームワークとは何か、仕事と暮らしのバランスをどう作っていくか、ということだなと思った。

製品ではなく、サービスを提供する点、またコンサルもできるエンジニアであること。顧客満足度・エンジニアの達成感ともに非常に強く感じられ、ベストなビジネスモデルであると感じた。

また一般的な開発であっても、顧客が真に必要としていることを読み解き、システム化していく点については、共通して重要であり、難し...続きを読むい要素が多いと感じた。

リモートを想定することで、チームに必要なエッセンスを抽出していくプロセスが興味深い良書。

・小さな成果の積み重ねによる信頼創造を、セルフマネジメントにより実現できる採用と育成が、リモートチーム成功のベース

・セルフマネジメントを醸成する自律性の一要素として、情報開示は重要


p.77:
よい仕...続きを読む事をしてくれる期待があり、その期待に応える。少しずつの成果の蓄積の結果が信頼。

p.79
タスクを分解し、一つずつに応えることで信頼を得る…30-60分単位

p.95
主体性のカギは情報格差

p.132
リモートの前提はセルフマネジメント

デスマーチを経験して、受託開発のデメリットを実感した中でこの本を読んだ。
受託開発自体は魅力的な仕事であると思うので、この本に書いてある事が理想的な受託開発だと感じた。

業界の問題を解決する為に自分でビジネスモデルを作る
ことは凄いと思う。作者の思想がよく描かれていて理解もできるけど、会社経営の視点でみると最低限の利益を得なければ長期的な経営が難しいのではないかと思う。
印象としては気の合うエンジニアの集まりに近い感じが
する。若手を育てる感じはあまりなさそう。

受託開発（会社）の観点から、顧客のみならずその先のエンドユーザーそして社員を幸せにする仕組みとしての会社ないしはビジネスのあり方を提唱している素晴らしい一冊。

製造業からサービス業へ、工場から工房へ。サービス開発やソフトウェア開発そのものが目的ではなく、ビジネスを成長を望み、目的と手段が混同せず、...続きを読む正しいを追求する姿勢を保ってくれる素晴らしい発想だと思う。

アジャイル開発を前提とした、ソフトウェアビジネスモデルの話。
市場の反応を見ながら仕様を変えていくwebサービスにぴったりというか、いわゆるITベンダーならどこもやっていそうな話。
非IT企業に同じような開発プロセスを提供できるビジネスモデルというところが新しい。

1番の問題は、受け入れ側に、今ま...続きを読むであった要件定義という明確な仕様がない状態での発注ができる仕組みがあるかどうか、というところだったりする気が。

製造系の会社って、なぜなぜ的な問いの立て方は得意だけど、そもそも系の問いの立て方は苦手なイメージというかステロタイプがあるので、文化の違いで衝突しそうな…。
そもそも、そんなアタマの硬い製造業の会社はもう淘汰されているか。

従来の一括請負ではなく、月額定額でソフトウェア開発の対価をもらうビジネスモデル。

エンジニアは基本１人で対応するため、ビジネスを理解し、かつ技術的にもフルスタックエンジニアが求められるので大変そう。
また、著者も言っているが、今のところ大規模開発には対応できない、と。

ただ、この業界にいる身とし...続きを読むては、契約形態のパラダイムシフトの第一歩、って感じで良いな、と思った。

DevOps の実践の一つでしょうか。
瑕疵担保責任はないため、善管注意義務でユーザ側がリスクをテイクできるかがポイントでしょう。
あとはユーザ側に使用を決める設計者がいることも必要。