読者です 読者をやめる 読者になる 読者になる

futoase

よろしくお願いします。

カンバン ソフトウェア開発の変革を読んだ。

カンバン ソフトウェア開発の変革を読んだ。

カンバン: ソフトウェア開発の変革

カンバン: ソフトウェア開発の変革

カンバンシステムそのものについては、以前読んだリーン開発の本質にも書かれている。

リーン開発の本質

リーン開発の本質


が、リーン開発の一部として取り上げられいた、トヨタの成功について書かれていたのでカンバンそのものについている本として、会社に置いてあったから借りて読んだ。

著者、David J. Anderson さんがなぜカンバンを勧めるのか、本を書いたのか、について書かれている。

読んだ最初からおお・・・となった

カンバン ソフトウェア開発の変革 p.28より引用

一般に、ソフトウェアエンジニアリングとIT部署は、他のグループのなすがままになり、
どんな理にかなった客観的な計画を立てても、交渉や甘言、威圧で覆されてしまうようだ

初めて作る製品につても、

カンバンソフトウェア開発の変革 p.28より引用

まして徹底的な分析手法も過去データも持たないほとんどのチームは、未知の(全く不合理であることも多い)納品物への確約を強く求める他のチームに対して、まったく無力である

お、おう、、となってしまった。最初からきつい感じだ。

著者が大規模な開発会社を渡り歩き、その中で実践してきた内容について書かれている。

各章で、押さえておきたいポイントということで、何が言いたかったのか、カンバンとはなにか、リードタイムを抑えるためにWIP(Work in progress)の量を抑えるには...がまとまっているので読み返しやすい。

カンバンという形式は、当たり前なんだけどホワイトボードにただ単に見えるように、ポストイットで今やってる仕事をペタペタはるのではなく、一人あたりの作業容量は3なので、今とりかかっているのは2だから1追加しよう、ということでしっかりとホワイトボード(もしくはソフトウェア)を設計・運用しないと意味ないということ。

特急案件、普通案件、いつでも良い案件などの区切りや、特急案件をする場合は普通案件が止まることをビジネス・パートナー(ソフトウェア、サービスを内製している会社であればビジネス・マーケティング担当者)と予め同意を取る、など政治的なきちんとしたやりとりも行うことが書かれていた。

心情はとても大切だ。

リーン開発の本質にも書かれていたが、この本にも、「ゆとり」は大切、と書かれている。また、ワークライフバランスを大切にしよう、というのが各章で見られた。詰め込めば詰め込むほどよい、という考えでは全てがロックし、生活がボロボロになればいつか消えていく、そんな業界だからなんだろうなあというところ。

カンバンソフトウェア開発の変革 p.69より引用

時間に余裕のある人達は、環境の整備に時間を費やすようになる。作業空間を片付け、トレーニングを受ける。スキルやツール、上流や下流の人と交流する方法の改善に取り組むかもしれない。やがて小さな改善が別の改善につながり、常に改善が行われるようになる。文化が変化する。仕掛りを制限し、仕事に余裕があるときだけ新しい作業を引き取ることで、「ゆとり」が生じ、誰も可能とは思っていなかった改善が可能となるのである。

ただし、心情で訴えるだけではなく、メトリクスを取り、どれだけのチケット数が発行され、どれだけの重要度のタスクを引き取り、こなし、回してきたのかを説明できるようにしようということが書かれていた。計測大事。

カンバンソフトウェア開発の変革 p.218より引用

ばらつきを把握するために、時系列で傾向を追跡(トラッキング)する必要がある。常時改善が行われていることを示すには、平均値の傾向が時系列で改善されていることを示す必要がある。予測可能性が改善されている可能性を示すには、ばらつきが減少し、納期パフォーマンスの値が増加していることを示す。

相手に自分の仕事のペースをわかってもらうということ

重要な案件についてはリリース日時を守り(SLA)、普通案件については、数日遅れる、その数日遅れる日数は大体固定化されているので、相手は安心するようになる。と書かれている。

カンバンソフトウェア開発の変革 p.210より引用

「特急」と「必須納期」の優先度分類を設けることによって、重要な項目は必ず時間通りに実現されることが保証された。その結果、「標準」の他の項目は通常1または2リリース(14日または28日)遅延した。顧客はこのリリースのリズムに信頼を寄せた。実行により信頼が形成されたのだ。

定期リリース、より重要な、必要とされている機能をリリースする、定期的なリズムを刻むことが大事と書かれていたりもする。

カンバンソフトウェア開発の変革 p.210より引用

リリースは隔週の水曜日に継続して行われた。「標準」(そして当時は明確に区別されていなかった「無形」)の多くの項目で遅延して発生する小さめのコストよりも、今までにデリバリーされた内容と将来の計画の方を、ビジネス側の担当者は重要視した。仕掛中の項目な納品日はあまり心配しなかった

高品質なソフトウェアデリバリーを目指す

高品質なソフトウェア開発体制、自動化を行う、などでデリバリー品質を維持しよう、とも書かれている。

今でいうところのGithubでのPRレビュー、自動テスト、Netflixが使ってるようなBotがプロダクション環境で暴れるような仕組み、Seleniumか、それに準じた何かしらのヘッドレスブラウザを利用したお客さん側からの製品テスト。などなど。

取れる手段を少しずつ取っていくのがよい、常に改善するということを忘れないように。と。

結局のところ

すべての内容について感想を書くのは難しい。時折読み返して、考え方の補強に使おうかなというのが短めの感想。自分の置かれている状況、問題点にあっているか、あっていればその方法を、あって無ければ自分なりに開拓するか、他のやり方を、というDDDもそうだしアジャイルもそういう感じだし、テスト駆動開発もそうだし、みたいな。

読んでてうなずける点が多いとてもよい本だった。

エンジニアとして

1人のおっさんエンジニアとして、どこまで何ができるのだろうか。と考えている。何が、というのは曖昧な表現だし漠然としてるのだけど。

Copyright (c) 2013-2017 Keiji Matsuzaki