倉貫義人のレビュー一覧

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

倉貫義人

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

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

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

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

倉貫義人

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

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

倉貫義人

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

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

倉貫義人

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

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

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

倉貫義人

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

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

倉貫義人

システム開発を進める上での「啓蒙書」である。

人が増えても速くならない、というタイトルが既に真理を述べている。遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけになりかねない。人を増やすことで、教育コストやコミュニケーションコストが嵩むし、タスクを分解するにも限度がある。マネジメントの難易度も高まる。

ソフトウェアのプログラミングにおいては、人数と生産性に必ずしも短期的には相関関係がない。工程を分離するよりも、できるなら、1人の人間が一気通貫で担当する方が、動的なソフトウェアを維持しながら変更していくには都合が良い。

そう考えると、既にいる人たちの生産性を上げることの方が有効な場合がある。高い生産性を出せるような環境の用意やクラウドの性能の増強など。給料や受注金額を上げ、そのプロジェクトに関わる少数に振り分ける方が、人を増やして、一人当たりの取り分を減らすよりもよほど有効だと思う事は多々ある。しかし、組織は特例を作りたがらず組織の慣習に従うのが常だ。既得権化させたくないし、他者からも同様な要求を受けかねないからだ。インセンティブ制度は、事程左様に難しい。

プログラムは単純に手を動かすだけでは開発できず、プログラムを書く仕事で求められるのは抽象化能力である。「近い未来は解像度高く、遠い未来は曖昧なまま」。肌感覚で分かっていた事を言葉にしてくれたような本だ。

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

倉貫義人

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

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

倉貫義人

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

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

倉貫義人

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

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


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


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

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

倉貫義人

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

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

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

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

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

倉貫義人

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

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

倉貫義人

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

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

倉貫義人

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

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

倉貫義人

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

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

藤村能光 / 倉貫義人

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

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

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

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

倉貫義人

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

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

倉貫義人

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

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

倉貫義人

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

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

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

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

倉貫義人

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

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

倉貫義人

ソフトウェア業界の"常識"を変えるビジネスモデル「納品のない受託開発」を紹介するビジネス書。

職場の知り合いから、長い間借りたまま積読になっていたので、そろそろ返さないと、と半ば強制的に読みました(^-^;

タイトルを見たときから「アジャイル」と何が違うのかが気になってましたが、要は広義のアジャイル開発手法というか、「手を動かすコンサル契約」のようなイメージのビジネスモデルです。

実際、開発手法を「スクラム」のようなアジャイルで進めようとしても、顧客との契約が旧来の契約である限り、また社内開発であっても、プロジェクトの評価方法が旧来の方法である限り、アジャイルは絵に描いた餅になります。
おそらくSIerで働く誰しもが、契約面から見直さないとアジャイルの適用は難しいと感じていたと思いますが、この書籍は、その契約面からのアプローチを実際に実践した形だと思います。

今後は、こういったビジネスの形が主流になっていくような気がしていますが、多くのユーザー企業は欧米のように自社でエンジニアを抱えて、アジャイルで開発していくようになるんじゃないかなー。。

なので、こういったビジネスモデルは、自社でエンジニアを抱えられない、中小規模の会社をターゲットにやっていくのでしょう。結局は、多くのITコンサルと同じですね。

それにしても、SIerの未来が心配です。ホントに世の中に置いてかれるぞ・・・。