えっと、最近以下の本を大変興味深く読ませていただきましたので、
今回はその感想を書いてみます。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
http://www.amazon.co.jp/dp/4534051948
この辺、以前からちょくちょく考える事ありまして、
要は「ソフトウェアを作る事自体が目的化していないか」とか、
「時給制だと、スキル高い場合に必ずしも得しない」とか、
「仕様変更に対して、どういうスタンスで対応していけば良いのか」とか、
様々なテーマがあるかと思うんですけど、本の中からちょくちょく抜粋しつつ書いてみたいと思います。
１．納品するという罠
そもそも、「どうしてソフトウェアを作るのか？」という事を考えた時に、
ビジネス上の目的（勿論、ココは各案件によってバラバラ）を達成する為に、ソフトウェアを作るのであって、
ソフトウェアを作る事自体が目的ではないんじゃないかと。
なんですけど、これ僕も下請けでやっていて、納期とかリリース予定時期とかあって、
で、そういったスケジュールがあると、「締め切りまでに間に合わせなければ」という意識になりやすく、
結果として、「ソフトウェアを作って、ビジネス上の目的を達成する」から、
「納期までにソフトウェアを作る」に、目的がすり替わってる様に感じますね。
なので、「納品」とか「納期」という言葉が、
仕事の進め方への意識に悪影響を与えているというのが、あるのではないかと思いますね。
でも、そうじゃないでしょうよと。
で、この辺の考えって、結構「システムの作り」に影響出るんじゃないかと思ってまして、
特に「保守性」に影響出やすい印象です。
勿論、ビジネス上の目的が不明とか、
開発スケジュール自体がそもそも破綻しているとかは別としまして。
というより、時間を切り捨てれば、いわゆる「プロジェクトの４つの変数」的に、
コストが跳ね上がり、スコープや品質が切り捨てられるだけなんですけど。
あと、なんで納期を定めるのかという部分には、勿論ビジネス上の事情の場合もあるかと思いますけど、
「納期を定めないと、ダラダラ仕事して、いつまで経っても終わらないから」というのも、
何となくですけど、ある気しますけどね。
多分、「何を持ってダラダラしていると見なすか」っていう、
「ダラダラ」の定義がポイントな気がしますけど。
ずっと椅子に座っていて、何日立ってもアウトプットが出てこないなら、さすがに「ダラダラ」だと思いますし、
一方で、新しいものを作る為に「調査・検証」しているのは、別にダラダラではないと思いますし。
２．仕様変更に備えて、見積もり時にバッファを積む
この問題は、本のP22に書かれている内容は内容で確かに同意ですけど、
別のルートで、「バッファ積んだ分の作業が発生しなかったら、元の金額に戻せば良い」という話も聞いてまして、
どうだろうなという印象でした。
ただ、上記の手法も、実践したことがないので、ハッキリは言えないですけどね。
３．人月とエンジニアの時給の問題
本のP25に書かれている内容自体は、話として当たり前で同意ではありますけど、
ただ、最近は、こういった事例はあんまり見ないですね。
以前よりも、エンジニアの評価基準というものが、確立されてきているからだと思いますけど。
どっちかというと、以前に書いたコチラ http://kitoku1.blog129.fc2.com/blog-entry-167.html の方が気になりますね。
実際、「作業を終えて早く帰る人は無能」という価値観といいますか、
そういったものは、まだまだ色濃く残っている様に感じますし。
勿論、「早く帰ってはいるものの、品質グダグダ」とか、
「早く帰る事が目的になってしまっている」のは別としましても、
「必要な作業をした上で、早く帰るのは全く問題ない」と思いますし、
むしろ、「早く終わらせる事が出来る人なら、それを評価して昇給させたり権限与えた方が良い」と思いますけどね。
単純に、その方がビジネスとして上手くいくと思いますから。
４．エンジニアの評価の難しさ
P37に書かれていますけど、非エンジニアがエンジニアを評価するのは難しいってのは、
確かにそうだと思ってまして、
なので、こういうの http://www.slideshare.net/kitoku_magic/php-40141964 を書いてみたんですけどね。
このスライド、どっちかというと、非エンジニア向けですから。
で、じゃあエンジニア間なら大丈夫かというと、実は必ずしもそうでもなくて、
意外と、エンジニアによってプログラムの書き方が違ってたりします。
あと、業務上のプログラムだと、外に出せない事もありますし、
あと、現場に合わせたプログラムの書き方なのか、自分のプログラムの書き方なのかの判断が出来ないので、
どんなプログラムでも良いから、プライベートで書いたプログラムが一番参考になると思いますね。
という事から、GitHubは役に立つと思います。
５．ビジネスにおける信頼関係
P71にありますけど、確かに「本当は」契約で縛りたくはないですよね（苦笑）
アジャイルソフトウェア開発宣言 http://www.agilemanifesto.org/iso/ja/ にも書かれている通りだと思います。
契約書はリスクヘッジでしかないってのは、契約を交わしていて確かにそうだと思いますけど、
契約書って「対話で解決出来なかった時の対策」であって、
対話で解決出来るなら、少なくともガッチガッチに縛る必要はないとは思いますから。
６．銀の弾丸はないについて
P73にありますけど、もういい加減飽きたというか（苦笑）
人月の神話 http://www.amazon.co.jp/dp/4621066080 は、
もう言うまでもないですけど、
個人的には、この辺 http://www.slideshare.net/kitoku_magic/ss-26184970 の考えと特に変わってないですし。
あと、類似品で、「この機能を作って挽回する」とかも同じかなと。
「挽回」じゃないんだったら、アリだとは思うんですけど、
「挽回」したい場合は、不振の原因分析の方が大切じゃないかと思いましてね。
話を戻して、で、この本のビジネスモデルも銀の弾丸ではないと書かれていまして、
これも確かにそうだと思います。
組み込み系の様な、「物理的に納品が必要なソフトウェア」も存在しますし、
あと、この記事のやり方 http://d.hatena.ne.jp/gallu/20110225/p2 だとダメなのかってのもありますね。
まだ、整理出来てませんけど。
なので、万能の薬ではないとは思いますけど、
とはいえ一考に価するビジネスモデルだとは思いましたね。
７．エンジニアサイドの作り方の変化
P144にありますけど、
「バグが出てもすぐに直せるようにする」は、もう少し細かくすると、
「バグが出た事を検出しやすくして、バグが出てもすぐに直せるようにする」かなと。
エラーで「Noticeも出す」なんかは、検出がしやすくなるんじゃないかと思いますし。
あと、「あらかじめ作るよりも必要になるまで作らない」は、結構陥りやすい罠じゃないかと思いまして。
例えば、「最初から共通化する」とか「仕様変更に対応する為に、事前に仕込んでおく」とか。
でも、これって、システムが肥大化しやすく、いわゆる技術的負債が増えるとは思うんですよね。
ちなみに、「仕様変更が問題」という声も結構あるんじゃないかと思うんですけど、
正確には、「仕様変更したけど、締め切りが変わらなく、結果として品質などが切り捨てられるのが問題」って事だと思いますね。
仕様変更自体は、少なくすることは出来ても、ゼロにすることが出来るイメージは、ちょっと僕にはわかないですし。
８．属人性の排除について
P166辺りから書いてありまして、これはこれで分かるのと別の話として、
「属人性は徹底的に排除したい」というのは、やっぱりありますね（苦笑）
多分、ココは絶対に譲らないかもしれません（苦笑）
というのも、属人性って「徹底的に排除しても、いくつかは必ず残る」と思ってまして。
まず、「他の人が真似しようとしても、真似できない」というのがあると思います。
例えば、僕の特徴として「モチベーションが下がっても、しばらくすると再び上がる」ってのがあるかなと思いまして、
まぁ、そこかよって気もするんですけど（苦笑）
でも、真似出来ない（少ないとは思います）と思いますけどね。
そんなに難しい話でもなくて、真っ黒い話とか聞いてモチベーションが下がる事は下がって、
で、下がると「何もする気がしなくなって、実際何もしなくなる（実際にはゲームをやっている事が多いw）」んですけど、
でも、そのままだと、しばらくしたら詰むなと思い始めて、
モチベーションが再び上がる（正確には、正常に戻る）という。
だから、下がったまま再び上がらない方が、僕には不思議に感じますね。
というのと、あと「自分自身」というのは、完全に自分に属していると思いますから、
仮に上記が真似出来ても、自分自身は無理じゃないかと思いますね。
で、排除するには、教育するのが本質だと思いますけど、
だから、教育にも興味ありますね。
９．メンター制について
P192にありますけど、ココは結構議論になる部分なんじゃないかと思いまして。
個人的には、「メンター制自体は良いが、メンターに依存しない様にする為に、
複数のメンターを持ち、各メンターへの依存度を下げる様にする事と、
メンター毎に異なる部分を、上手に吸収出来るようにする」ってのが良いかなと思ってますけどね。
メンターが「一人」だと、偏ってしまいがち（メンターにもよりますけど）ですし、
かといって、メンターが「沢山」だと、言ってることがバラバラで模倣するのが難しくなると思いますし。
１０．会社の規模の差異について
まず、「小さな会社の方が、幸せを感じやすい」は、
「個人にフォーカスがあたりやすいから」じゃないかと思いますね。
マズロー的には、「所属・承認欲求」辺りに該当する様に感じますけど。
別に、大企業でも無理ではないと思うんですけど、
単純に人数が多い分、浸透させるのが難しいんじゃないかと。
会社の規模で一番違うと感じるのは、
「大企業の方が、多方面に事業が行うことが出来る」じゃないかと。
小さい企業だと、さすがにそれは難しいというか、一人でそれらは出来ないと思いますし。
で、作ったものの品質には、差異は出ないと思いますけどね。
大企業の方が、人数が多いことからマネジメントが難しくなり、
結果として品質が下がったというのはあるかもしれませんけど、
でも、それはマネジメントの問題であって、大企業という規模の問題とは別じゃないかと。
色々書いてきましたし、まだまだ本には色々書かれていますけど。
とりあえず、本のタイトルについて思う事としては、本質的には納品の有無ではない様にも感じてまして。
というのも、「何の為に、そのソフトウェアを作るのか」という目的があって、
そして、目的が達成され始めるのは、ソフトウェアを作った「後」からであって、
それは、納品があってもなくても変わらないんじゃないかと思いまして。
そんな感想を抱いた次第でした。
