倉貫義人のレビュー一覧

「納品」をなくせばうまくいく

業務内容としては、別に珍しくもなんともない、技術的にそれほど凄くもない、規模的にも非常に小規模を想像させるな。。。と7割ほど読み進んでから、ようやくビジネスの話がされて、おぉぉ！と唸った

基本的に顧客は自分達の条件に合う企業のみに絞っているという点がある。

・システムは資産化しない、解約＝システム利用不可
・技術はこちら選定（それ以外は受け付けない）
・打ち合わせはWEB or 自社訪問限定

これに見合うとしたら、顧客は小規模、かつ起業間もない起業となる。実際にSierには高額＆ハイスペックすぎて頼めない企業が顧客となるようだ。
現在、日本の起業率の低さをこのビジネスモデルが少しでも解決、また地方でアイディアは持ちながらも実現できない人々を支援できるならば、それは凄いなぁと感じた
これ以外にも今の社員たちを、のれん分けで独立させるなど、まだまだ色々とありそうだ。

「納品」をなくせばうまくいく

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

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

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

「納品」をなくせばうまくいく

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

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

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

「納品」をなくせばうまくいく

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

人が増えても速くならない ～変化を抱擁せよ～

エンジニアの様子を横目で見てきた立場なのですが、この本を読んでだからつらそうなのか、、、ということがわかりました。
自分の会社の具体プロダクトを考えた時に、どうしたらより生産性をあげられるか、の想像があまりつかなかったので、思考を深めてみようと思います。

人が増えても速くならない ～変化を抱擁せよ～

設計と建築が同時に発生する。
ちゃんと土台をミルフィーユのように重ねる。

一過性のものではないということを理解。

人が増えても速くならない ～変化を抱擁せよ～

経営者向けのVUCA時代におけるUP開発の心得。今の自分には全く関係ないが、現役時代にこれをお客が読んでいたらかなり楽になっただろうなと思われる。

人が増えても速くならない ～変化を抱擁せよ～

感想
なぜ生産性が上がらないのか。仕組みができていない。仕組みを理解していない。それ故に現場は散発的な思考を要求される。一本化されない。

人が増えても速くならない ～変化を抱擁せよ～

エンジニアの考え方や事情をただ記述するような、いい意味でで思っていたような本ではなかった。エンジニアをマネジメントする場合の考え方を示してくれる良き本でした。

人が増えても速くならない ～変化を抱擁せよ～

　システム開発がプロジェクトからプロダクト中心に変わると、関わる人たちの関係性も変わることになります。これまでの完成を目指したシステム開発であれば、「システムを依頼する人たち」と「システムを開発する人たち」という形で分かれていました。しかし、社外に限らず社内であっても受発注のような関係では、変化に柔軟に適応していくシステムは手に入りません。動かし始めてから、次々と直したいところが出てきても、その度に発注するように依頼することになってしまうからです。プロダクトという共通の成果物と、目指す共通の目標を持つことで、システムは「依頼して作ってもらうもの」から「協働して一緒に作るもの」に変わります。そして、システムは完成を目指すものでなく、事業と共に改善を続けるものになるのです。成長し続けるために、変化に適応できるソフトウェアの作り方と考え方を身につけましょう。

■なぜ正確な見積もりが出せないのか
・詳細までの仕様を把握しきれなかった
・例外的な処理を把握しきれなかった
・想定していた技術が使えなかった
・担当する人によってばらつきがある


　事業側と開発側が受発注の関係ではなく、共通のゴールを目指す同じチームとして協働の関係を築くためには、システムを作ることだけを目的とした体制やマネジメントをしないことです。あくまで事業や活動があり、その成長や成果のためにシステムを作るとするのです。
　そのためには、まず「大きな機能の見積もりは、あくまで見通しである」というスタンスでいることです。一度に機能も期間も大きな約束をして、あとは出来上がるのを待つのではなく、1~2週間の単位で少しずつ確認しながら作っていくのがいいでしょう。それぐらいの期間であれば、どれくらいの進捗を出すことができるのかは精度を高めに見積もることが可能です。エンジニアではない人間からすると、エンジニアたちが何をしているのかわからないため、きちんと頑張っているのかどうか不安になるわけです。しかし、ある程度の頻度で、作るべきサイズを小さくすれば、進んでいるかどうかは確認できます。


　大規模なソフトウェアは、一度に作るのではなく、小さなソフトウェアに分解し、小さなプロジェクトとして何回かに分けて進めていくことで、失敗のリスクを小さくすることができます。それも、実際に動くところまでをゴールとしたプロジェクトにすることが肝要です。ソフトウェアは動いてこそ価値があり、使ってこそ直したい箇所が見つかるからです。
　そして、何度も打席に立ち、自分たちのプロセスや取り組み方に学びを得ることで、ソフトウェア自体の不確実さは解消されないにせよ、進め方のノウハウが溜まることで成功確率を上げていくことができます。同じチームで、小さなプロジェクトに何度も挑戦していくことで、チームビルディングも進むでしょう。

人が増えても速くならない ～変化を抱擁せよ～

アジャイルの考えを平易かつ簡潔に説明した本。アジャイルの勉強を始めたばかりの自分にとっては、これまでの学びを別の表現で復習できた。

◾️覚えておきたい標語
近い未来は解像度を高く、遠い未来は曖昧なまま

◾️見積もり
・見積もり精度を高めるために、どこまでも詳細に考えていくとしたら、それはもはやそれは設計である。つまり、限りなく正確な見積もりは、実際にやってみることでしか出せない。
・大きな機能の見積もりは、あくまで見通しである。1〜2週間の期間であれば、どれくらいの進捗を出すことができるのかを、高めの精度で見積もることができる。

◾️本書のテーマ外だけど覚えておきたいこと
・コードレビューは属人性の排除に有効。優れたエンジニアに指摘してもらうことで品質の向上が見込め、かつ、良いプログラムの書き方を学ぶことができる。
・週に一度、1時間を「ふりかえり」の時間にして、仕事を通じて経験したことを抽象化、言語化する。これを学びとして、次の仕事に活かす。

人が増えても速くならない ～変化を抱擁せよ～

他の一般的な業務では通用することでも、システム開発では通用しないことがまとめられている。システムをわかってない上層部にどう言えば伝わるのか？参考にしたくて読んだ。
手伝いを入れると生産性が下がるってのは、自分が言いたかったことをちゃんと言ってくれた感じ。育成と生産性向上の両立は、システム開発では難しすぎる。システムを知ってるはずのシステム開発会社のマネージャでもこういうことをわかってない人は多いと思う。

人が増えても速くならない ～変化を抱擁せよ～

ソフトウェア開発におけるよくある勘違いについて、実際の開発での難しさを説明している。ソフトウェア開発に対して完全に素人レベルのユーザーや管理職であれば得るものがあると思う。自分としてはそういう人たちがどんな勘違いをにているのか知ることで役に立つかと思ったが、あるあるネタ中心なのであまり参考にならなかった。

人が増えても速くならない ～変化を抱擁せよ～

システム屋さんがおすすめしてくれた本です。
簡単な言葉で説明してくれているので、システム屋さんがどんな想いで仕事をしているのかがわかりました。
これから社内へシステムを導入する予定の製造業で働く方におすすめの1冊です。

ザッソウ 結果を出すチームの習慣

報連相は時代遅れ感を感じていた。チームは段階があるのを知った。同意形成はチームが未熟の段階なのは驚いた。

未来ビジネス図解 働き方シフト

本書から学んだこと
『これまでの一律的な働き方は、個人に適合した多様な働き方にシフトしていく』

コロナウイルスの感染拡大により後押しされたリモートワークに代表されるような多様な働き方へのシフトは、もう元には戻らない可能性が高い。
ならばもうボクらに残された手段は変化を楽しむことだけだと思う。
本書は、個々人に合った「働き方シフト」成功の一助となることを目指して書かれている。

【感想】
・多々共感するところあり。だが、多くのビジネス書でここ数年言われていることばかりで目新しいものはない。
・サイボウズで数年前からリモート中心の働き方シフトに成功した著者の経験上で知り得た知見には一定の価値があると感じた。
・リモートワークが単純に働く「場所」だけの変化ではないことがわかった。多面的な変化が必要で、そうなると変化を嫌う現代の高齢化した日本組織には難しい部分も多いはずであると思えた。

ザッソウ 結果を出すチームの習慣

職場での雑談の重要性と雑談によって得られる成果や安全性など。雑談をするための環境づくりや雑談のポイントなどの記載も。
実現するためには少人数から初めて徐々に広げるようなやり方をすれぱ浸透していくようにも感じた。

リモートチームでうまくいく

働いているフリはできない
場所と時間にとらわれずオンオフできる
働く時間を小口化できる
リモートワーク可が売りになる
イノベーションは雑談から生まれる
リモート飲み会は四人まで
リモートワークは信頼が前提
頭のスイッチを切り変える朝会

ザッソウ 結果を出すチームの習慣

ホウレンソウではなく、ザッソウ＝雑談・相談が大事、という著者の主張は納得。

ただ、昨年の出版なので難しいのですが、コロナ禍にあってリモートワークが一気に普及したことを考えると、そういった勤務体系にあっても雑談・相談を促進するためのヒントがもう少し欲しかったところです。

ザッソウを普及させるポイントとして書かれている内容はどちらかというとリアル出社を前提としている内容に思えました。著者の会社も全員リモートワークにより勤務とありますので、それにも関わらずザッソウできているということであれば、そこからの知見こそが、いままさに大事なものといえると思います。

「納品」をなくせばうまくいく

スタートアップの会社には
・新規事業の要件が煮詰まり切っていなくても明確な事業方針があれば開発に着手でき、
・進めながら変わっていかれる
・スタートアップの会社がこだわりたい見せ方は、顧客側で作る（一緒に作り上げる）
・月額設定なので事業計画も立てやすい
といった面で魅力的。