自由課題

学んだり、考えたり、試したりしたこと。

自ら一歩踏み出すために: 書籍「カイゼン・ジャーニー」レビュー

本書の位置づけ

本書は、主にソフトウェア開発者を対象に、"現場のカイゼン"を行なっていく方法を解説した書籍である。

本書によると、主に

特にソフトウェア開発について経験が浅い方

を想定しているとのことであるが、紹介されている手法が多様であるためそれなりの経験がある読者にとっても学びがあるのではないかと思う。

本書の概要

本書は3部から構成されている。

第1部は主に自分自身で取り組める範囲の価値・原則・プラクティスが紹介されている。プラクティスとしては例えば以下のようなものである。

  • タスクボード
  • 朝会
  • KPT

第2部はチームの内部で取り組む価値・原則・プラクティスが紹介されている。例えば以下のプラクティスが紹介されている。

第3部ではチームの外部のメンバーと取り組むものであり、例えば以下が紹介されている。

もちろん途中から読むこともできるとは思うが、上記に限らず様々なプラクティスが紹介されているため、個人的には知っている部分は斜め読み気味でもよいので最初から読んだほうが良いように思う。

感想

毎日必死にプログラムは書いてリリースはしている、でも何かがおかしいと思う。 何がおかしいのか、どうしたらこの状況を変えられるのだろう、と考えはするのだが、具体的に行動が起こせない開発者は少なくないのではないかと思う。

本書はフィクションの形をとりつつ、開発者が目の当たりにする壁と、これらの壁にどのような方法論で向かっていけば良いのかが、かなりのリアリティを持って提示されている。

開発手法を説明するためにフィクションを用いること自体は 、技術書でもそれほど珍しくはないと思う*1が、私がリアリティがあると感じたのは、主人公である江島にとって「乗り越えるべき高い壁」がきちんと書かれている点である。

社内勉強会の開催とその後の顛末や、請負契約にまつわる苦しみのエピソードは、「そうそう、実際そうなるよなあ…」と遠い目になるほど絶望感が伝わってくる。それでも、周りの助けも借りながら腐らずに*2なんとか乗り越えていく姿は、単なる手法の紹介ではなく、開発者が持つべきメンタリティ・価値観をも示しているように思える。

「様々な制限がある中でどのように価値あるソフトウェアを開発していけるのか」というテーマを取り扱っている点では、前回のポストで紹介した「エンジニアリング組織論への招待」と重なる部分もあるが、視点が大きく異なる。

具体的には、本書が一貫して一開発者の目線で主体的に書かれ、開発者の共感が得やすいスタイルになっているのに対して、「エンジニアリング組織論への招待」は、チームリーダーもしくは管理職クラスの目線で開発・管理手法や組織設計を記述しているように思う。 この点は書籍としての読者のターゲティングの問題であり、書籍としてどちらが良いということはないので、現在チームの中でどういう立場であるかにより選べばよいのではないかと思っている。印象としては、(文体のせいか)なぜそのような手法が生まれてきたか・どういうものかは「エンジニアリング組織論への招待」のほうが詳しく、どうやってその手法を運用するかについては「カイゼン・ジャーニー」のほうがイメージしやすかった。

個人的にも、結構前にはなるが第1部に相当する取り組み*3を行なった後、チーム内で開発スタイルをある程度確立するところ(本書でいうとおおむね第2部くらい)の取り組みを行なってきたので共感できる部分は大きい。しかし、第3部に相当するチームを取り巻くステークホルダーに対する取り組みはほとんどできていないのが実情*4なので、本書を改めて読みながらカイゼンを考えていきたいと思った。

そういえば、この記事を書いている最中に思い出したのだけれど、屋台骨としてフィクションを採用しつつテクニカルな手法を説明するという意味では、書籍「ザ・ゴール」「ザ・ゴール2」とも類似点があると思った。 アジャイル開発手法と同じくTPSを源流にしているという意味でも似ている。改めてあわせて読み返すのも面白いかも知れない。

ザ・ゴール

ザ・ゴール

ザ・ゴール2

ザ・ゴール2

関連書籍

これだけ! KPT 【これだけ!シリーズ】

これだけ! KPT 【これだけ!シリーズ】

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

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

カンバン仕事術

カンバン仕事術

エッセンシャル スクラム

エッセンシャル スクラム

*1:とはいえ、知っている限りではこの手法は洋書で用いられているケースが圧倒的に多いという印象

*2:実際「腐る」ケースもそれなりにあるように思えるし、本書でもそのような人物が登場する

*3:もっとも、時代や当時の個人的な趣向のせいか、GTDなど必ずしも本書に直接マップできるものではない

*4:業界の特性もあるので厳しい面はある

我々はいかにして不確実な環境下で成果を出すのか: 書籍レビュー"エンジニアリング組織論への招待"

まえがき

少し前は業務外でもコードを書いたり、某サイトに翻訳記事を提供したりしていたのだけれど、公私ともにばたついていることもありしばらくアウトプットができずにいました。それでも書籍は時間を見つけて読んではいるので、気軽なアウトプットの形態として書籍レビューを書いてみてはどうかと思いたちました。

本書の位置づけ

本書は、(ソフトウェア)開発、もしくは開発を遂行する組織に関する様々な課題、及びその解決策を、「不確実性に向き合う」という観点を通して列挙した書籍です。

従って、入社すぐの新人のソフトウェアエンジニアよりは、少なくともプロジェクトを1つまたはいくつか経験し、
「いかにきれいなプログラムを書くのか、ということが唯一絶対の課題ではない
ということを実感したあとに読むのが良さそうに思います。

また、本書では(設計・プログラミングといった)具体的ソフトウェア作成手法よりも、上流工程も含めてソフトウェア開発という行為が本質的にどのような問題を含んでいるのか、これらの問題を踏まえてソフトウェア開発行為そのものをどう設計・改善するかということの説明に力点が置かれています。

(一応補足しておくと、「いかにきれいなプログラムを書くのか」ということは、「きれい」が何を意味するのかということも含めソフトウェアエンジニアとして真っ先に考えるべき事項であり、もちろん軽視すべきではありません)

本書の概要

本書は5つのChapterから構成されています。

"Chapter 1 思考のリファクタリング"では、そもそも不確実性やエンジニアリングとは何か、これらに関連する人間の認知・思考パターンが紹介されています。

本書によると、

エンジニアリングとは、つまるところ、「実現」していくための科学分野

であり、この「実現」の過程で効率よく

「曖昧さ」を減らし、「具体性・明確さ」を増やす行為

を行うことが求められます。

エンジニアリングとの関係を抜きにすると、この章の内容は経験主義・仮説思考・システム思考・ベーコンのイドラといった、哲学・心理学や意思決定の方法論をはじめとした一般のビジネス書でもカバーされている範囲の事柄も多いです。

Chapter 1 における「人間(自分)の認知・思考」に関する解説に続き、これを踏まえて、"Chapter 2 メンタリングの技術"で、コードレビューやペアプログラミングといった場面での開発チームのメンバー、つまり他者との接しかたについて触れています。メンタリングのゴールとして、効率よく成果を上げるためにチームメンバーが「自ら考える人材」となることが挙げられています。コーチングの内容を多分に含まれているのではないでしょうか。

これに続き、「自ら考える人材」から構成される「自己組織化」された開発チーム("Chapter 3 アジャイルなチームの原理")や、このような開発チームのタスク・スケジュール等の管理("Chapter 4 学習するチームと不確実性マネジメント")が解説されています。いわゆるアジャイルとかスクラムの解説ですね。

最期の章である"Chapter 5 技術組織の力学とアーキテクチャ"では、開発チームを含む複数の部門からなる組織の設計・運営の方法論を「生産性」を軸に解説しています。この章では、不確実な状況においては、単に決められた成果物を効率よく作成する能力(「労働生産性」)ではなく、不完全な情報しかない中でいかに効率よく仮説検証を繰り返せるかという能力(組織としての「情報処理能力」)が重要であるとしています。また、OKRといった目標管理の手法や技術的負債に関する解説もこの章で行われています。

感想

様々なソフトウェア開発ツール・環境が以前とは比較にならないほど低コストで入手できる時代になり、ソフトウェアを実装するためのハードルは下がってきている現状を踏まえると、決められた内容のソフトウェアを「どう実装するか」というのと同等以上に、「どんなソフトウェア/システムが価値を持つのか」を見定めるために不確実な状況下で試行を繰り返し、価値規準の変化に合わせてソフトウェアを進化させていくことが重要になっていると思います。

本書はこのような観点から現代のソフトウェア開発に必要な考え方・概念が幅広く列挙されており、少し各内容間のつながりがわかりにくい点があるものの、必要に応じて関連書籍を読み進める出発点となる、総合カタログ的な使い方ができるのではないかと思います。例えば以下のような単語について、ちょっと気になっていた(/なった)のであればまとめて概要を理解することができるでしょう。

また、個人的には技術的負債に関してそれなりの紙面を割いて議論している点が興味深かったです。ここまで詳細に対応方法も含めて書いてある書籍は読んだことがありませんでした。

あと、コンウェイの法則やマイクロサービスに関しても触れてあり、以前苦労してマイクロサービスに関するマーティン・ファウラーのブログ記事を翻訳したことを思い出しました。もう4年近く前か...懐かしい。

関連書籍

電子版で読んだせいかわかりませんが、参考文献が書籍内にきちんとまとまっていなかったので、知っている範囲で列挙しておきます。何か参考になれば。

仮説思考・システム思考など

学習する組織 ― システム思考で未来を創造する

学習する組織 ― システム思考で未来を創造する

戦略思考コンプリートブック

戦略思考コンプリートブック

アジャイルスクラム・リーンなど

アジャイルサムライ――達人開発者への道

アジャイルサムライ――達人開発者への道

これだけ! KPT 【これだけ!シリーズ】

これだけ! KPT 【これだけ!シリーズ】

トヨタ生産方式

トヨタ生産方式

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

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

組織設計・運営など

サーバントリーダーシップ

サーバントリーダーシップ

組織パターン

組織パターン

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

YosemiteのIntelliJ IDEA CE上でGradleプロジェクトを作成するまで

もろもろの環境が少し落ち着いたので、前から気になっていたReactive Streamsを 試してみようと思ったのだけれど、そもそも自分のMBPにはソフトウェアの開発環境が全く入っていないことに気がついた。

ということで、まずは開発環境の整備から、と思ったのだが、断片的にしか資料が見つからなかったので2015/08/30時点の 作業手順を備忘録としてメモしておく。

続きを読む

2015上半期に読んだ書籍まとめ

基本的に活字中毒なので、時間が空けばほぼ何らかの活字を読んでいる。思いつき以上のものはないのだが、ここ半年のAmazonの購入履歴の中からソフトウェア開発・ビジネス書について印象の強いものをまとめてみた。なお、それぞれのカテゴリ中の並びは購入順である。

続きを読む

The NoTCP Manifesto 日本語訳

はじめに

インターネット通信の高速化については個人的に結構前から興味があって、確か2012年か2013年時点でGoogleがQUICに取り組んでいたことはなんとなく覚えているのだけれど、インフラの話も絡んでくることもあり、なんとなく誰にでも検討できるものでもないんだろうなという印象を当時持った気がする。

(NoTCPという名前から連想される)NoSQLのように、現在当たり前に使用しているインフラを疑ってみるというのは発想として面白いと思うが、ネットワークのような全世界共通のインフラに対して何ができるかという点(例えばTCP輻輳制御における公平性の議論など)に関しては検討が必要な点も多いと思う。いずれにしろ興味深い分野なので引き続きウォッチしたい。

なお、本文書の原文はThe NoTCP Manifestoであり、ライセンスはCreative Commons Attribution-ShareAlike 4.0 International Licenseである。

続きを読む

NetBeansにおけるアーキテクチャの質問(日本語訳)

はじめに

インターフェイスを設計するために読んだ技術書まとめ - 自由課題 の記事でも紹介した書籍

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

APIデザインの極意 Java/NetBeansアーキテクト探究ノート

内に、NetBeansコンポーネントを設計・実装する際のアーキテクチャの質問(チェックリスト)のURLが紹介されていました。興味があったので実際確認したのですが、ぱっと見面白そうだったのですが日本語訳がないようだったので訳してみました。基本的にはJavaを基盤に構築されたNetBeansに対する質問なのですが、NetBeansJavaでなくても参考になる質問も多数含まれています。

お堅くいうとISO/IEC9126もしくは25010の品質特性に包含される話なのだと思いますが、インターフェイスの設計・実装に特化したもっとカジュアル/わかりやすいチェックリストとして活用できそうです。

続きを読む