ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守(アプリ方面)のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

部下への指示の仕方とそのジレンマ

今日、下記の記事を読んでいた。

あなたは、どう考えるの? : タイム・コンサルタントの日誌から

この方の文書は示唆に富んでいるのでRSSで購読している。今回の内容はというと、部下が上司に何か聞きに来ても、すぐに答えを出してあげるのではなくて「あなたは、どう考えるの?」と思考することを促す、それによって部下に一段上の視点を持たせる、というもの。

至極もっともだと思いつつ、昨日友人とほぼ同じ話題についてもう少し突っ込んで話していたのでそれをまとめておきたい。

部下の4分類

「もう少し突っ込んで」というのは、「いつでも『あなたは、どう考えるの?』という聞き方が最善だとは限らない」ということだ。

僕は、接する部下によって指示の仕方は変えるほうが良いと思っている。その部下の分類の仕方の1つとして、以下の「頭が良い・悪い」、「ガッツがある・ない」という身も蓋もないやり方が考えられる。

f:id:hnishim:20140928223100p:plain

 

まず右上、頭も良くガッツもある部下。期待通りにアウトプットをしてくれ、少し無理をお願いしても難なくやってくれる頼りがいのある部下だ。しかし当然ながらそのような部下に恵まれることは少ない「貴重な人材」だ。

左上は頭は良いがガッツがない部下。自分の仕事が出来ていれば問題ないだろうと勤怠も悪い。下手をすると「その仕事なんで僕がやらないといけないんですか?」と突っかかってくる危険な存在、「ひねくれ者」だ。

右下は頭は良くないがガッツのある部下。頑張っているのは目に見えて分かるがイマイチ成果に結びつかない、だけど何故か憎めない「愛されキャラ」。

最後の左下は頭も良くなくガッツもない部下。上司がどうしたもんか、と頭を抱えてしまう「残念な子」である。きっと他の場所に彼(彼女)が活きるところがあるに違いない。

考えさせ方

先ほどのマトリクスにそれぞれの類型の部下たちに適切な指示の仕方をマップしてみた。

f:id:hnishim:20140928230204p:plain

「貴重な人材」は自分で考える能力もあるし、それを実際に行う気概もある。それに対してあまり多くを言ってもモチベーションを下げるだけである。「あなたは、どう考えるの?」と言わずとも考え始めるようにそれとなく仕向けてあげるほうが良い。最低限の指示を出して好きなように動いてもらう、途中での軌道修正も必要な時だけにしてやれば順調に事を進めてくれるだろう。そして、進めていく中で自ら教訓を学び取っていく。

「ひねくれ者」に対しても、「あなたは、どう考えるの?」と言うのは少しリスキーかも知れない。プライドの高い彼らは自分がバカにされたと勘違いしてモチベーションを大きく下げる可能性がある。彼らに対しては「僕は○○だと思うんだけど、どうかな?」と先に自分の意見を伝えて意見を求めてしまったほうが良いように思う。考える能力はあるし自分の頭の良さを示したい欲求もあるので、それに対して自分なりの意見を伝えてくれるだろう。そこにまだ若手なりの拙さがあれば、それを論理的かつやんわりと指摘して向かうべき方向に誘導していくほうが彼らは育てやすい。

「愛されキャラ」には前述の「あなたは、どう考えるの?」が有効だろう。彼らはまだ考えるクセがついていないが、仕向けてみればちゃんとやってくれるバイタリティはある。彼らを指示待ち人間にせずに戦力にするには上記の問いかけを根気強く行って自分で考えるクセをつけさせなければいけない。ただし、言い方によってはパワハラになる可能性が高いので気をつける点でもある。

「残念な子」に対しては残念ながら基本的にどうしようもない。「あなたは、どう考えるの?」という問いかけは彼(彼女)らには響かず、仕事が遅々として進まなくなるだけだ。そもそもそんな子が長く居続ける可能性も薄いので、育てる労力も無駄になってしまう可能性も高い。それであれば単純な労働力と見て、細かい部分まで上司から指示を出して動いてもらうほうがいいだろう。また、仕事とは別の場所でどうにかモチベーションを上げてあげるような対策を打ったほうがいいかも知れない。(ただそれは先に「ひねくれ者」に対して行うべきだが。)

ジレンマ、実践出来ない理由

といった感じで、それぞれの部下の類型によって採るべき指示出し方法を変えた方が彼らのパフォーマンス、また彼らの成長度合いは変わるはずだ。ではそれぞれに合わせてやり方を変えればいいかと言うと、これがまた難しい。

何故なら、自分の下に別々の類型の部下がいる場合に如実に接し方を変えてしまうと差別しているように見えてしまうからだ。「AさんはBさんに対しては丁寧に教えているのに自分には何も教えてくれずに突き放される」という風に。それが分かっているので、接し方を変えたほうが良いことが分かっていても出来ない、ジレンマが発生する。

これを克服するのは難しいが、ひとつの方法はそのように感じさせない程度に接し方を変える度合いを薄めるか、あるいは接し方を変えている背景を部下に個人的に伝えてみるというのもひとつの方法だろう。これに対しては僕はまだ正解が分かっていない。もっといい方法もあるはずなので引き続き考えながら接していきたい。

スケジュールのあいまいさへの立ち向かい方:『アート・オブ・プロジェクトマネジメント』を読んで

数週間前になるがScott Berkunの『アート・オブ・プロジェクトマネジメント―マイクロソフトで培われた実践手法』を読んだので書評しておく。

邦副題にもある通り、著者はマイクロソフトでの経験を基にこの400ページ超の分厚いプロジェクトマネジメント本を執筆している。その内容は、PMBOK系の理路整然としたプロジェクトマネジメント本(『世界一わかりやすいプロジェクト・マネジメント』などもその類だと思う)と、アジャイル系の管理手法を折衷した、現実的なものとなっている。

スケジュールとは確率なり

本書の白眉はほぼ最初の第2章「スケジュールの真実」の部分だと思う。ここで著者は「スケジュールとは確率なり」、すなわちスケジュールはある時点で立てられた予測でしかなく、その時点がスケジュールの日付から遠ければ遠いほどそれが正確である確率は低い、といっている。

人間はしばしば、きめ細やかさと正確さを取り違えるという過ちを犯します。特定の日時が書き込まれた(きめ細かい)見た目のよいスケジュールが、現実を正しく(正確さ)反映しているわけではないのです。きめ細かくするのは簡単ですが、精度を上げるのはとても難しいことなのです。

これは単なる予測でしかありません。どれだけ正確に書かれており、どれだけ説得力があったとしても、それは小さな見積もりの寄せ集めにしか過ぎず、それぞれの見積もりにはさまざまな種類の予測できない見落としや問題が含まれているのです。

人間の性として、特定の日付が記載されているとそれは絶対的に真の値であるものとして扱ってしまいがちである。そして一度出した日付や工数の数字は「一人歩き」を始める。だからこそプログラマやエンジニアなどの作業者は具体的な数字を伴う見積を出したがらないものだ。

ただ、この文章で「正確さ」と「精度」が同じ意味で使われていることには注意が必要だ。統計学や品質管理の領域などでは両者は明確に異なる意味を持つ。「正確さ」は本当に正しい値にどれだけ近いかという概念であり、「精度」は複数の値にどれだけばらつきがないかを表す概念である。この2つの概念は分けて考えるとまた見えてくるものもあるので気をつけたい。手近なところで正確度と精度 - Wikipediaなどを参照。

見積もりに対する自信を定量化する

この確率というあいまいさに対して著者が用意した答えのひとつが「あいまいさを可視化する」ことである。

「この締め切りを実現できる可能性はどのくらいだろうか?」という疑問を持つことが有効でしょう。

正確さという観点で見た場合、例えば、推測であれば40%、優れた見積もりであるという自信があれば70%、詳細かつ綿密な分析であれば90%といった確率になります。

このあいまいさの定量化・可視化というのは実はこの本を読む前から個人的に考えていた、しかしこれまで読んできた本や記事などで言及されたことがほとんどなかった内容だったので、「そう、そうだよ!」と思った反面、先に書かれた、、とちょっと落胆するところだった。とはいえプロジェクトを進める上でのあいまいさのマネジメントはスケジュールだけの話でもなく、まだ十分に議論し尽くされている領域ではないので、今後掘り下げていきたい。

一方、もちろんあいまいさの定量化だけが唯一の対処法ではない。あいまいなものをあいまいなまま受け止める、というのもひとつの手段である。(スケジュールではなく工数についてではあるが)この思い違いに立ち向かうプラクティスとして、アジャイル開発手法にはプランニングポーカーが存在する。工数の単位を実際的な単位(人月)ではなくポイントにして抽象性を持たせ、またその数字の刻みを大まかにすることによって精度は限定的であることを暗示させる。これにより工数見積が不当に正確・高精度なものとして扱われることを防いでいる。

アート?

最後に題名について。何度か言及しているミンツバーグの『マネジャーの実像』ではマネジメントを3つのスタイルに分類している。「慎重で分析的」なサイエンス、「アイディアとビジョンを重視し直感的」なアート、「経験を重視」するクラフトである。

上記の3分類からすると、本書はアートというよりクラフトの強いように思える。 (特にサイエンス的なプロジェクトマネジメント手法であるPMBOKのような管理手法を採った場合に)経験的に陥りがちな失敗をどのように回避するか、に重きを置いている。そのため、『クラフト・オブ・プロジェクトマネジメント』のほうが本書の内容を適切に言い表していると思う。

 

A Guide to the Project Management Body of Knowledge: Official Japanese Translation(プロジェクトマネジメント 知識体系ガイド PMBOKガイド)

A Guide to the Project Management Body of Knowledge: Official Japanese Translation(プロジェクトマネジメント 知識体系ガイド PMBOKガイド)

 

 

世界一わかりやすいプロジェクト・マネジメント【第3版】

世界一わかりやすいプロジェクト・マネジメント【第3版】

  • 作者: G.マイケルキャンベル,サニーベーカー,G.Michael Campbell,Sunny Baker,中嶋秀隆
  • 出版社/メーカー: 総合法令出版
  • 発売日: 2011/07/21
  • メディア: 単行本(ソフトカバー)
  • 購入: 10人 クリック: 65回
  • この商品を含むブログ (5件) を見る
 

 

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

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

 

 

アジャイルプロジェクトマネジメント

アジャイルプロジェクトマネジメント

 

 

マネジャーの実像

マネジャーの実像

 

 

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

 

 

Slideshareに社内勉強会資料「『仕事の流儀』第1回基本編」を公開

以前「プロマネが声をかけるとき作業を邪魔してませんか? - ぷろまねさん」というのを記事にしたが、この中で言及した通り僕主導で社内、というかプロジェクト内勉強会を開始した。先日ようやく、めでたく第1回の開催をすることが出来、その場に30人超、電話でのバーチャル参加も20人以上と予想以上に参加してくれ大盛況だった。その後実施したアンケートでも概ね好評だったのでやってよかった、と心底思っているところ。

ということで、その第1回資料を公開した。社内の先輩方にレビューは頂いたものの、僕が作成した資料なので僕の名前で公開させていただく。

仕事の流儀 Vol1 基本編_ver1.1_外部公開ver

優れた仕事の条件

前半は「優れた仕事の条件とは?」というのがメインテーマになっている。僕が所属している会社はIT(+経営)コンサルティング会社だけあってバリュー(価値)の有無・大小ということに非常に重きを置いている。すなわち、「優れた仕事の条件」とは僕の会社では「バリューの高い」仕事と同じ意味だと思っている。

このバリューを生み出すのってなんだろう?と僕が僕なりに考えた答えがこの資料に記載した「QCDとスコープのバランス」と「リスクの最小化」である。QCD (Quality, Cost, Delivery) とスコープを重視するというのは以前から頭の中にあったことだけれど、それを「バランス」させるという概念はここ最近アジャイル開発についての知識に触れることで確立されたように思う(例えばアジャイルサムライなどで4つのトレードオフを考えるということが言及されている)。

補足:SQERTモデル

社内資料の引用を使用していたので上記Slideshareに公開した資料からは省いてしまったけれども、このQCDとスコープ、およびリスクという5つの要素をまとめてSQERT (Scope, Quarity, Effort, Risk, Time) モデルという場合もある。

Project Management Model – SQERT | RAPIDBI

僕の会社のプロジェクトマネジメントに関する研修ではこのモデルが紹介されていたのだが、個人的にはこの呼び方は好きではない。今回の資料で説明している通り、QCDとスコープは最適な分量を見極めて4者をバランスさせるべきもので、リスクはそれら4つを考えたときに明確化されるものであり、それは最小化させるべきものである*1

にも関わらず、SQERTモデルではR(リスク)を5つ中4つ目に位置させており、他の4者と同じ立ち位置に置いている。他の4者とリスクは本質的に異なるので、本モデルには熟慮が足りない、と思っている。

コミュニケーションの基礎

この第1回基本編の後の第2回以降は「コミュニケーション」と「文書の書き方」ということをメインテーマにしている。そのためその導入部として「コミュニケーションの基礎」を説明している。

良いコミュニケーションをするにはどうすれば良いかということを説明するに当たり、「受け取り方」「考え方」「伝え方」という3つのプロセスに分けるというやり方を採ってみた。実はこれは僕の会社が作った他の資料から拝借しているフレームワークだったりする。一般化するとIPO (Input, Process, Output)と同じフレームワークな訳だけども、コミュニケーションを説明するのに良い分け方だなと思っている。

特に若手エンジニア向けに行った勉強会ということもあって、主要メッセージは「相手のことを考えてコミュニケーションしよう」ということだ。PMOやプロマネをずっとやってきた僕は、ひたすら人とコミュニケーションすることがほとんどの仕事であるのでいつの間にかまともなコミュニケーションが出来ている(と思っている)のだけれど、エンジニアの場合そういかない場合も多い。相手がシステムに疎かろうとテーブル名やシステム用語で語ったり、相手の理解度を考慮せずに自分の頭の中のフローそのままに喋ったりといったことがどうしても散見される*2。そういった彼らがコミュニケーションで損しないためにはどうすれば良いか、ということを今回まとめてみたつもり。

 

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

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

 

  

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

 

 

*1:というと誤解がある場合もある。リスクを取らなければ相応の対価を得ることも出来ない、という場合だ。今回の議題の場合はそういった価値創造の場というよりは、もっとオペレーショナルな状況を想定しているため、リスクは最小化すべきものとして語っている。このあたりのリスクとの向き合い方はまた別途議題にしたい。

*2:この辺りが気になってしまうのは、僕自身がそのように喋られても理解できないということもあるのだけれど。

『シンギュラリティは近い』を読んだ人のための『スピリチュアル・マシーン』

今回読んだ本はレイ・カーツワイルの1999年の著書『スピリチュアル・マシーン』。カーツワイルといえば2005年の著書『シンギュラリティは近い』(先に出た紙の本の邦題は『ポスト・ヒューマン誕生』)はもっとも最近邦訳されているもので、かなり話題になったので読んだ方も多いと思う。

僕も『シンギュラリティは近い』を遅ればせながら昨年くらいに読んで、すっかりカーツワイル親派になってしまった。「人間以上の知能を得た機械」、「ナノボットにより姿形をいくらでも変えられる人間」、そして「永遠の命」と、SFでしかお目にかかったことのない「夢のテクノロジ」の数々がクソ真面目に、つまり現実味を持って語られている。

これが唯の物書きが語っているだけであれば信憑性もないだろう(とはいえ、文面だけでも、そこに依拠するデータとロジックの数々が十分な説得力を持っているのだが)。しかし氏の経歴を調べてみるとコンピュータによる作曲やOCR、シンセサイザなど数多くの発明品を生み出し*1、またそれらを世に出すための会社を次々に作っては売っていくという、発明家・事業家の両面を持った人物だということが分かる。

そして氏は2012年末からGoogleでディレクタ職を務めているという。2010年台に、これほど「未来」を期待させる(そして危惧させる)タッグはないだろう。

さて、前置きが長くなってしまったので本題に入ろう。

『シンギュラリティは近い』と同じところ

本書『スピリチュアル・マシーン』を読み始めて、「あ。ほぼ『シンギュラリティは近い』と同じだ」と思った。「ムーアの法則」から「収穫加速の法則」が語られ、21世紀にはこれまでには比較にならないほどのテクノロジの進化が見込まれる、というのが大筋であり、これは『シンギュラリティは近い』でもほぼ同じである。

そういった意味で『シンギュラリティは近い』を読んだ人であれば、本書を(わざわざ絶版本を探してまで*2読む必要はないだろう(笑)

しかし逆に言えば、2005年に書かれ、2013年に僕が読んだ時点でも衝撃的だった内容を、1999年にすでにほとんど言い切っているということだ。そのことを知るというだけでも価値があったと思う。

また、カーツワイルとモーリーによる掛け合い漫才は本書ですでに成立している(笑)このモーリーという名前の由来は何なんだろう?娘の名前とかなのかな、と思ったがちょっと調べても分からず。

『シンギュラリティは近い』と違うところ

『シンギュラリティは近い』で新しく加わった概念は大きく2つかなと思う。1つ目は書名の通り「シンギュラリティ(技術的特異点)」の概念だ。『シンギュラリティは近い』では2045年を目安にシンギュラリティ、すなわち指数関数的に加速するテクノロジ進化の臨界点に到達するとしているが、本書では特にシンギュラリティの点には触れていない。第3部「・・・そして未来」の章も「2009年」、「2019年」、「2029年」の章が来て、次に「2099年」の未来予測をしているところから見ても、2045年周辺に特別な注意を払っていなかったことが分かる。

一方『シンギュラリティは近い』ではそれほど語られておらず、本書で語られている点で面白いのは宇宙の歴史とテクノロジの進化の関連性の部分だろう。

宇宙の歴史を紐解いていくと、宇宙が誕生してすぐの一瞬のうちに重力の発生、物質(電子・クオーク)・反物質の発生が起こり、そこからしばらくして電子・原子が誕生し、だんだんスピードを落として星雲、星の誕生と、宇宙的に大きなパラダイム・シフトの速度はどんどん遅くなっているというのだ。そしてこの数十億年単位で、宇宙的には「大したことは起きていない」のだという。つまり、宇宙的には時間の流れがどんどんゆっくりになっている。

一方、『シンギュラリティは近い』でも語られている通り、地球上の生物、そしてその中でもテクノロジを手にした人間の進化はどんどんスピードアップしている。単細胞生物から多細胞生物、そこから哺乳動物、霊長類への進化、そしてホモ・サピエンスと進化する時間はどんどん短縮しており、その後テクノロジを手にした人間は指数関数的進化を続けている。

宇宙はどんどんスローダウンしているのに、進化はスピードアップし続けている。氏はこれを「カオス」と「秩序」によって説明している。それが以下の「時間とカオスの法則」と「カオス増大の法則」だ。

時間とカオスの法則―あるプロセスにおいて新たに大きな出来事(つまり、そのプロセスの特質を変化させたり、そのプロセスの将来に重要な影響を及ぼすような出来事)が起きるまでの時間の間隔は、カオスの量とともに拡大したり縮小したりする

カオス増大の法則―カオスが指数関数的に増大すると、時間は指数関数的に遅くなる(つまり、新たに大きな出来事が起きるまでの時間間隔は時間の経過とともに長くなる)。

 宇宙は誕生からどんどん大きくなっているわけであるので、カオスは増大し続けている。したがって、カオス増大の法則により時間は遅く、スローダウンしている。そして逆に進化は「収穫加速の法則」によって秩序(=反カオス)の増大によって時間が早く、スピードアップしている。

こうして宇宙と進化の時間について1つの法則(「時間とカオスの法則」)で説明されてしまう。ここまで快感な議論はなかなかお目にかかれないだろう。

カーツワイル、つくづく痛快な人物だ。是非お目にかかりたい。いや、きっといつかお目にかかれるだろう、なぜならもうすぐ我々は永遠の命を得られるのだから。

スピリチュアル・マシーン―コンピュータに魂が宿るとき

スピリチュアル・マシーン―コンピュータに魂が宿るとき

 

 

*1:日本だと「発明家」というとドクター中松や、テレビにたまに出る変わり者おじさんのイメージが強い。これは日本から革新性を持った製品を送り出す妨げになっているんじゃないだろうか。

*2:しかし、Amazonマーケットプレイスで絶版本でも2日程度で非常に手軽に手に入れられるようになった。もちろん電子書籍であれば配送TATさえ気にしなくて済む。僕が新入社員だった7年前くらいにはまだまったく形もなかったようなサービスが現在当たり前になっている。これこそが氏の説に信憑性を持たせている最大のだと感じる。

XP祭り2014に参加してきました。

9/6(土)に実施されたeXtreme Programming (XP)中心のイベントに初めて参加してみました。

f:id:hnishim:20140907002840j:plain

 
非常に面白かったので、ざっくりまとめておきます。

10:00-11:00 オープニング

アジャイル仙人」らしい小井土さん、福井さんによるXP入門、といいつつほぼ雑談。本イベントのユルい感じが非常に伝わった 笑
ただ、「Context(文脈)に合わせてツール技法を使う」だったり、「変化を受け入れて状況に合わせていく」というのはその通りだよなあ、と。

11:00-12:00 基調講演「XPの俺」関将俊さん

事務局の方からの事務連絡+αを挟んで本日の基調講演。Ruby界隈の人らしい。
まったく聞く側を考えているとは思えない話し方に内容を相まってまったく伝える気が感じられないw
とはいえなかなか面白いこと言ってたと思う。

減らすほうが大変

「導入したプラクティスなどを減らすことのほうが、増やすことよりも大変」というのはなるほどなと。これまでやってきたことを否定することになるので難しい。
オープニングであった「変化を受け入れ状況に合わせていく」という話や、クリステンセンの「創造的破壊」にもつながる話。

問題への向き合い方

XP以前の問題への向き合い方は「問題が起きないように先回りする」やり方であったが、XPでは「問題は起きるものであり、早く見つけて早く直す」ことで「細かく失敗することで、大失敗をしない」ことを目指しているとのこと。
これはベロシティとイテレーションによって「要望全部を期日どおりには出来ないんで、ここまでにこれだけやりましょう」というのと同様に、完璧を求めすぎて息が詰まる感じだった既存のシステム開発を、現実的なラインで手を打ちましょう。そのほうがお互いハッピーですよね?ということであり、これがXPやアジャイルのエッセンスなんだと思う。

TDDの本質

テストを先に書く=テストファーストがTDDの本質ではなく、「テストによって完了を知る(何を以って完了かを事前に明確に定義出来る)」ことがTDDの本質だという話だった。これは聞いてる最中はなるほどと思った気になってたが、これって別に普通に設計して、開発して、テスト書いて、テストして、の場合でもそうなんじゃないか?先にテスト仕様(テストコード)があることで、開発とそのテストが完了したかどうかが前もって定義されている、ということかな?
あと、忍者式テスト=手動で毎日リグレッションテストの話は初めて聞いた。ストイックすぎるだろ、、と思いながら聞いていたが、ホントに出来るのかそんなこと?

13:00-14:30 E-4 ワークショップ「己の中の曖昧さに向き合うが良い」

「曖昧さ」というキーワードだけで参加したところ、中身はTOC (Theory of Constraints, 制約条件の理論)の思考プロセスについてだった。
講師の長身長髪やせ型のお兄さんがメイド服を着て講義をしていたけどご愛嬌。
 
TOCというと『ザ・ゴール』程度しか読んだことがないので、基本的に生産の話という風に思っていた。その後思考プロセスにまで拡張されたというのは何となく知ってはいたのだけど、実際に触れるのは今回が初めてな気がする。
 
内容的には「ロジカル/クリティカルシンキング」関連でやるお話と基本的に同じ。なので個人的にはあまり新鮮味は感じなかった。ボトルネックスループットを重視するTOCの管理理論と直接結びつかなかったので、TOCの思考プロセスってこういう話だっけ?という印象。たぶん違う気がするので近々『ザ・ゴール2』読んでみようかな。

15:00-15:45 A-6 講演「価値創造契約」木下史彦さん

永和システムマネジメント、アジャイル事業部長の木下さんの講演。同事業部では「価値創造契約」と謳い、システム導入費用は0円、解約手数料も0円でサービス利用料で回収する受託開発を3年ほど前からやっているとのこと。
で、その結果は?ということだが「上手くいかないっす」とのこと 笑
その失敗の原因についてがメイントピックだったが、非常に面白かった。今回の中で一番面白かったと思う。

解約手数料0円は顧客のメリットにならない

一番衝撃的だったのはこちら。解約するに際しての手数料を0円にすることで顧客はリスクフリー(その分開発元企業がリスク負担をする)なので普通に考えればこれは大きなメリットなはず。ただし、実際にはそうではないという。
理由は、顧客側も失敗前提でシステムを導入しないから、「入れてみてイケてなくてもタダで解約出来ますから」なんてことは社内で説明することは出来ないから。また、実際解約する場合も再び発注先を見つけなければいけないということで本当にコスト負担がゼロというわけでもないので結局失敗したときのメリットというのは考えらないという。

良い物を作れば長く使ってもらえる、とは限らない

価値創造契約で導入したものの、3ヶ月後に経営方針が変わりERPに入れ替えることになって解約になったケースがあるとのこと。「良い物を作れば長く使ってもらえる」というクライアントファーストな考え方は、恐らく長期的・マクロ的には正しいのだろうが、こういったケースが発生しないわけではないということだろう。

顧客の担当者変更

導入後顧客側の担当者が変更になり、新しい担当者にはその契約形態が理解されにくいという。これは新しい製品やサービス、ビジネスモデルの場合はどうしてもつきまとってしまう問題だろう。

サービス利用料に対する対価

構築費用を取らずにサービス利用料に上乗せで回収しているため、運用保守に充てる工数よりも多くの金額を月々払ってもらうことになる。そのような契約形態だということを顧客側が分かっていたとしても、サービス利用料に対するエンジニアの稼働(=人月)を求められてしまうとのこと。感情的には分かるが、こんなこと言ってくる顧客いるのか。。
 
上記以外にも失敗原因ひとつひとつ面白かったのだけれど割愛。以前に少し真剣に同様なビジネスモデルを考えていたので非常に良い先進事例として聞くことが出来た。

16:00-16:45 B-7 講演「なぜアジャイル開発はうまくいかないのか?」倉貫義人さん

「納品をなくせばうまくいく」の倉貫さんの講演。狭い部屋ながら非常に多くの聴講者がいて大盛況という感じ。
メッセージをひと言で言うと「ビジョンとミッションを明確にすることが大事」。
 
人(のマインドセット)は他者が何か言っても直接はなかなか変えられない。一方で、会社の仕組みを変えてしまえば、大半の人(真面目な日本人)の振る舞いは自動的に変わってくるというのはその通りだなと。
僕も、何かを変えるときには各メンバに直接指示するのではなくて、「こうルールを変えます」というやり方で舵を切る方法を多用している。そのほうがメンバの心的な抵抗感も抑えられ、結果としてレバレッジ(変える努力に対して得られる効果)が効く。
 
また、「会社とは何か?」という話では、従来の会社の役割と、倉貫さんの思う新しい会社の役割を以下のように対比させていた。
  • 従来の会社:ビジネス活動に必要な職能を寄せ集めることで効率性を求める
  • 倉貫さんの思う新しい会社の役割:ビジョンを共有する
こういった会社の役割といった議論は経営学周辺では良く聞く話だし、会社の役割はビジョンの共有だというのもまったく新規な発想ではないのだけれど、こういうことがプログラマ・エンジニア出身の方から出てくるというのは凄いなと。 
「納品」をなくせばうまくいく

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

 
 

17:00-18:30 A-8 LT祭り

Lighting Talk、通称LT。5分の発表+1分の転換時間で合計14組(≒人)?が次々にプレゼンを行う。雷のように速いからLighting、なんだよね?
どんどん話題が変わるし、5分のプレゼンだからみんな早口だし、すごく脳みそを消耗する90分でした 笑
しかしどれも個性も強く、内容も濃く、かなり刺激的な時間でした。これは次回やってみたい!

18:30-19:15 A-9 クロージング

クロージングという名の書籍プレゼント大会。初回参加ということで最初に選ばせていただき、『アジャイルプラクティス』を頂いてきました。近々書評あげます!

f:id:hnishim:20140907002924j:plain

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

 

 ということで以上。非常に面白かったし、為になったと思うので、次回も是非行きたいと思います。 

 

Extreme Programming Explained: Embrace Change, 2/e

Extreme Programming Explained: Embrace Change, 2/e

 

  

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

 

 

スパイラルモデルとウォーターフォールモデル、そしてアジャイルモデル

以前Slideshareにあげたことをブログでも紹介したが、アジャイル開発について僕のチーム内の勉強会で紹介をした。

アジャイル開発についてパワーポイント(英語)を作成してみた - ぷろまねさん

 

この勉強会の中で「アジャイルモデルとスパイラルモデルの違いって何?」という質問をもらい、ちょうど僕も頭の中で整理出来ていたことなので以下のように図を書きながら説明したので残しておきたい。

スパイラルモデル

f:id:hnishim:20140824004515p:plain

まずは図の説明から。「品質」と「スコープ(機能充足性)」の2軸をとっている。これに対し矢印が時間だ。

スパイラルモデルのキーワードは「プロトタイピング」だ。ソフトウェアのプロトタイプ、つまり品質が高くない状態(網羅的なテストを行わず、バグも多く存在している「とりあえず動いている」状態)のものを顧客・ユーザに見せ、ソフトウェアがどのように動くかをプロジェクトの早い段階からイメージを共有する。

プロトタイピングの最初期であればソフトウェア自体を作る前段階として、画面イメージを図形描画ソフトやパワーポイントなどで作成して紙芝居形式で見せる場合もあるだろう。(僕の前のプロジェクトではこれを"コラージュ"と呼んだ。俗称"アイコラ"。)これは建築業などで模型を作る過程に似ている。

ウォーターフォールモデル

スパイラルモデルの利点や欠点を考えるにあたり先にウォーターフォールモデルの図を示しておこう。

f:id:hnishim:20140824010214p:plain

話の流れで言えばウォーターフォールモデルの図を先に示すべきなのだが、見てもらえれば逆にした理由が分かるだろう。ウォーターフォールモデルの図だけでは意味が分からないのだ。

ウォーターフォールモデルは、スパイラルモデルとは違い顧客・ユーザの目に触れる最初の段階で高い品質まで保証する。同時に要件定義したフルスコープの機能についても一度に用意するため、図の全体を覆ったものを一気に開発する。

スパイラルモデルの利点と欠点

この2つの図を見比べるとスパイラルモデルの利点と欠点が理解出来るだろう。

利点は、プロトタイピングの時点で顧客は挙動のイメージが大きく異なれば開発チームにフィードバックすることが出来るため、大きな手戻りが発生しにくくなること。そしてそれにより最終的な要求適合度はある程度高いものになる。

一方欠点は上述の利点の裏返しにある。早期に顧客・ユーザとイメージを共有するため、顧客・ユーザに「思ったものと違う」と言わせてしまう"余地"を与えてしまうのだ。システム開発受託会社(SIer)やIT部門としては遅くとも要件定義完了時点ですでにソフトウェア開発予算は確定してしまっているはずだ。ウォーターフォールモデルであればその完成形を見せるのはユーザ受入テスト(UAT)の段階、つまり本番リリース直前の段階であり、この段階で「思ったものと違う」と言われても大方の予算は使い果たしており後戻りは出来ない。後戻りが出来ないことと、「要件定義通りに作った」ことを盾に、ウォーターフォールモデルでのSIer、IT部門は顧客・ユーザにとって価値の無いソフトウェアをそのままリリースしてきたのである。それに対してスパイラルモデルでは上述の通り早期にフィードバックする余地が顧客・ユーザにあるため、その段階であれば軌道修正出来てしまう。これが経営層まで論理的・合理的に理解されれば軌道修正に見合った追加予算の獲得なども可能であろうが、現実は往々にしてそうはいかない。ユーザの要望に合ったものを予算内で作れと言われ終わることになるだろう。

こういった政治的駆け引きの難しさが大きな利点を有しながらもスパイラルモデルが流行らない理由だと思っている。

アジャイルモデル

f:id:hnishim:20140824002833p:plain

一方、アジャイルモデルの場合はこの動きが縦横逆になる。

つまり第一に、アジャイルモデルの場合は一定の品質というのは常に保証していると考えている。ストーリーカードという形で顧客の要件をまとめ、顧客自身が要件の出し元としてチームに動員される。顧客とプロジェクトマネージャ、そして開発者が密連携してプロジェクトを推進することによってひとつひとつの要件に対しての品質は高いものがアウトプットされる。

そしてそれを可能にしているのはスコープを絞っているからである。いくらアジャイル的なフレームワークを使用したとしても、フルスコープの機能を同時に相手にしてしまっては顧客・プロジェクトマネージャ・開発者が蜜連携して事にあたる余裕はなくなってしまう。したがってアジャイルモデルでは「イテレーション」(XPの場合はスプリント)に区切って必須度の高い機能から定義・開発していく。

そのため最初のイテレーション終了後にリリースされるソフトウェアはバグなどはあまり存在せず仕様に耐えうる品質ではあるが、便利機能などは省かれた必要最低限の機能のみのものとなる。これに対して後続のイテレーションで前のイテレーションで省かれた機能のうち優先度の高いものから追加していく、という形でソフトウェアを成長させていくというのがアジャイルモデルだ。

アジャイルモデルの利点は2つ。1点目は最低限の機能ではあるが使用可能なソフトウェアを早期にリリース出来る点。2点目は優先度の低い開発を後続のイテレーションに後回しに出来るため、時間が経過し要件の変更・入れ替えが発生しても手戻りが発生しにくいこと。

一方欠点としては一度完成されたソフトウェアに対して後続イテレーションで手を入れる必要があるということだ。これはつまりリグレッション、またはデグレードと呼ばれる「新しい機能追加改修を行ったことによって、これまで正常に動いていた機能に不具合が発生する」ということがイテレーションの度に懸念される。

これを回避するためにはソフトウェア全体に対してリグレッションテスト(回帰テスト)を実施する必要があるが、これをイテレーションの度に人の手で行っていては膨大な追加工数が必要となってしまう。それを避けるためにテスト自動化、継続的インテグレーション(CI)といった手法がアジャイルモデルに組み込まれたと考えるべきだろう。

スパイラルモデルで問題となった点がアジャイルモデルでも問題となるケースはある、というより多いだろう。つまり後続イテレーションで際限なく追加機能要望が発生するけれども予算は限られている、という状態だ。しかしそれを諦める、出来るところまでしかしないというのがアジャイルの本質だ。結局その本質を顧客・ユーザ側、経営層側とも認識一致させることがアジャイルでの成功・不成功を決めるはずだ。

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

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

 

 

 

ブログを書く目的

長かった、といっても1週間強の夏休みも明日で終わってしまう。その夏休みを使って毎日連続更新出来るのも今日で最後だろうから、いつもとはちょっと違う話題でいこう。

ということでこのブログを書く目的をまとめておく。

インプット過多

「インプットばかりしていてアウトプットが出来ていない」

そう思ったのがブログを書こうと思ったきっかけだった。ちょっと前、といっても2−3年前までは音楽を作っていた。作曲活動によってある程度アウトプットが出来ていたのであまり気にならなかったのだろう。

それもしなくなり、仕事以外の時間の使い方というと、人と接する時間というのを除き、文章を読むこと、映像作品を見ること、音楽を聴くことにほぼ集約されていた。「趣味」と呼ばれるものはインプットの趣味とアウトプットの趣味に分けられるが、これらはどれもインプットの趣味だ。

自分が仕事以外でアウトプットしていないという状況を理解すると愕然とした。インプットは将来の自分への投資であるか、もしくは快楽の享受だ。一方アウトプットは自己の顕示であるとともに社会への価値還元である。比較的「投資」になるようなインプットを多くしているつもりではあったが、それを永遠にアウトプットしなければそれは人間として価値はないんじゃないか。もちろん仕事を通してアウトプット、すなわち価値還元を行ってはいるのだが、それだけに甘んじられるかは人それぞれだと思う。

ということで、仕事以外の場でインプット対アウトプット比を変える、というのが始めたきっかけになっている。

不特定多数にアウトプットをする練習

とはいえもう少し具体的な目的が必要だ。ブログという場所で文章を書くということはどういうことか。もちろん日々の仕事で文章を書いたり資料を作成することはある、というかほぼそれしかしていないので、文章を書く機会自体には困っていない。しかし、日々の仕事の中で書く文章は、(僕の仕事が不特定多数に向けた仕事ではないため)それを読む人の顔が見えている状態のものしかほとんどない。

文章を読む相手が分かっていると、どういう単語や言い回しを使えばいいかは分かりやすい。もちろん相手に出来るだけ伝わりやすい表現を選ぶということは常に気をつけているのだが、日頃使っている言葉をそのまま使えばいいし、どれだけ略していいか、どのくらいのテンションであれば引かれないかなど、あまり考えずにアウトプット出来てしまう。

一方でこういったネット上で誰でも閲覧可能な場所であればそうも言っていられない。相手の「顔」が見えないので、ある程度仮想読者(いわゆるペルソナ)を思い描きながらどのような表現をしたほうがいいかを考える必要が出てくる。例えば、外資系企業特有の英語が入り混じった文章では読みづらいだろうか、とかあまり堅すぎる論文調な表現でもうざったいか、とか。

自己ブランディング

そしてどんどん副次的な目的になっていくのだけれど、「会社以外で評価される機会」を作っておきたいということだ。打算的に言えば転職するときに使えるネタになればいいな、と思っている。今転職活動をしているわけでも、考えているわけでもないのだけれど、まったく考えずに同じ会社にいつまででもいられると思って仕事をしているのとそうでないとではその会社で出せるアウトプットも変わってくるはずだ。

とはいってもブログ自体でどうこう、という訳ではないのでSEO対策だったりということをするつもりはない。あくまで品質の高い文章をアウトプットすることが目的なので、それで文章の品質を下げていては元も子もないからだ。

それでもアクセスログは頻繁に確認してしまう、というのが人間の性。

いつか本を書くための書き溜め

いつか本を書く。

これは大学院のときから思っていることだし、今でも思っていること。そのときのネタ出しという意味も込めて書いていきたい。このブログで書いていることは書かなければ文章にならず過ぎ去ってしまうようなことも多いので、どこかで書き留めておかなければなかなか堆積させられないなと。

ただ、個人的には「パーツパーツを繋ぎあわせて再利用する」というのが苦手だ。パーツパーツを寄せ集めてみても、そのときには気分が変わって全部書き直したくなってしまう。まぁそのときに思い出すトリガにさえなればいいかな。

しかし、昨今デジタルパブリッシングが出来るようになってきているので、単純に本を出す、ということだけであればいつでも出来る時代にいるのだ。

実験として、アフィリエイト

以上がこのブログの目的なのだけれど、ついで、という意味でAmazonアソシエイトを付けている。正直このブログで収益化を目指そうという気概はさらさらなくて、せっかくなのでどんな感じなのかやってみよう、という感じ。どのくらい見られるとどのくらいの収入になるとか、やっぱりやってみたいと分からないので経験と思って。

蛇足だが、個人的には「価値あるものをタダで頒布して、アフィリエイトで儲ける」という昨今のITビジネスモデルには違和感がある。価値あるものに対してその分の対価を支払、受け取れるようなビジネスモデルをIT業界で考えたいなぁ。