倉貫義人のレビュー一覧

創業にあたり、事業展望をきっちりと見据えることは難しい。打ち出した新機軸への思いがあってもいきなりの成果は確約できず、かといって当然に発展は目指している。事業の成長とともにシステムも成長させていけばいいのだが、創業時点で導入すべきシステムの規模と、運用・保守の規模をどの程度に設定したものか。要件定義...続きを読むが固まらずして仕様が書けない。よって、無駄なバッファが乗るのを否めない。現在抱えている課題が、ある側面から浮き彫りになった。ただ、受注者であるベンダーの質と意識も大いに問われる。

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソフトウェアを所有すると利用するの区別は大事
その区別なくソフトウェアは所有するものだという考え方が染み付いてる業界はまだまだ多く存在する

ソフトウェア受託開発の人月ビジネスに疑問を抱いた筆者が、「納品の無い受託開発」という新しい形に挑戦している姿を書いた本。
理念と行動は悪く無いと思う一方で、ビジネスとしては限定的になってしまうかなとも感じた。

さくっと読める一冊。


メモ

自分達のポリシーに合わない仕事をしない、会社とお付き合...続きを読むいしない。
一部参考になる部分はある。
確かに人月ビジネスは違和感と変な部分は多々ある。その常識に真っ向勝負するのは素直にカッコいいと思う。
がしかし、まだまだ理解はされないし、スケールは難しいだろうから、中々業界を変えるまでは時間が掛かるだろう。
納品が無い分、チームになりやすく、最終的に良いプロダクトになる確率は高まるかとも思う。

ソフトウェアを「所有」から「利用」への考え方のパラダイムシフトという考えはとても良い

ワークレビューは面白い考え方。

読みやすいです。同僚にも読んでもらいたい。
WEBシステムは最初からやりたいことが決めらられなんだから、だったら最初から「納品」をなくした方がいいんじゃない？という話。
最初にやることを決めない替わりに、1週間単位でやることを決めて実装していくというスタイル。
こんな会社で働きたいと思った。

気に...続きを読むなったのは、以下の二つ。

* 人の単価をどうやって決めるのか？「この人は何年目だからこの単価です」とかで、客は納得してくれる？
*「来週ここまでやります」という、何を説得材料として説明するのだろうか？

読み終わったー＼(^o^)／
「納品のない受託開発」の提唱本。顧客に付き、段階的にソフトウェア開発を進める受託開発手法でした。