マネジメント・リーダーシップ Archive

この話は至極もっとも。
ただし、例が極端すぎてネガティブな反応が多いのかなぁ。

従来のソフトウェア工学が決定的に間違っている点 - kwatchの日記

最後にもう一度。高度な仕事になるほど個人に依存するのは避けられないし、属人性を排除すべきではない。属人性を排除して各人の能力を均一化して扱おうとしたソフトウェア工学は根本的に間違っている。

プロジェクトで優秀（だと思われる人）にアーキテクトっぽい仕事を任せたり、共通部品を作らせたりして整備した後に、それ以外の人にサポート、例えばドキュメント作成や大量生産系の仕事を任せる、なんていうのは普通にプロジェクトマネジメントとして考えると思う。
逆にこれすら考えておらず、それでうまくいったプロジェクトを見てみたい。
うまくいったとかいっていても、実はOSSのプロダクトやフレームワークなどを活用していてそれで生産性があがっていたりして。それはOSSを作った優秀な人の仕事の上に成り立っているんだけどね。

とはいっても理想は遠く、本当に優秀な人をピックアップするのが難しかったり、本当に優秀な人は請負のソフトウェア開発などやらない人だったり、自動化で大量生産を行うことの難易度が高すぎたり（単純に能力が足りないのかも）ということはあるだろう。
それでも、以下のどちらの世界を目指すのが良いのか？というサジェスチョンが元ネタの議題ではないかと思う。

• できるだけ属人性を排除し、誰が入れ替わっても事業が存続していくようにしたい。
  そのためには、みんなが均一な能力を発揮し、誰が入れ替わってもうまくプロジェクトが進むような仕組みが必要
• できるだけすばらしい成果を出したい。
  そのために、優秀な人が最大限の力を発揮し、高度な成果を達成できるような体制が必要

このどちらが正しいと思うかは、ソフトウェア開発の仕事をどちらの仕事ととらえるかにかかっていると思う。

• 車の組み立て工程
• 車のコンセプト設計、デザイン

前者の仕事は、職人的な部分もマニュアル化し、流れ作業でスムーズに作業が進むようにする。多少の能力差も最終品質に影響を与えるほどではないという認識になりそう。
後者の仕事は、単純にマニュアル化できない。主査など主要なメンバーの能力に依存するが、どんな人物を大事な役割に登用できるかが鍵という認識になりそう。

これは、ここに書かれている話しと同じ。
まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - Slow Dance

コードが工業製品と勘違いされているために、「ソフトウェアの生産」は車の生産ラインのように扱われることがある。

しかし、ソフトウェアは本質的には情報なので、流れ作業は0に等しく、生産ラインのような作業はない。実は、ソフトウェアの生産は車の作業工程でいう「設計 = デザイン」の部分にあたる。車を設計する時には、原寸大の粘度を削って車の形にする。そして、それが美しいとか議論されて最終的なデザインに落ちる。

では、SIという仕事はどっちなのというと、どちらかというとまつもとさんの言っていることが近しいのではないのと思う。
それはソフトウェア開発（SI含む）は本来クリエイティブで高度な仕事であり、つまり属人性を排除しきれないことを意味し、kwatchさんの言っている方向は正しいと考えられる。
少なくも私はそう思う。

なんとなくもやもやして、この辺の考えを整理しようと思いながら放置してたんだけど、現実世界にあわせて実にうまく説明している文章を見た。この人の話しはいつもうまく整理されていて参考になる。

不確定性を受け入れ突出した人材の力を引き出せるのが良い組織 - アンカテ

つまり、これからの組織のマネジメントは、

1. 属人性を排除した組織としてのパフォーマンス(業者と折衝して2億円を8000万円くらいにできる組織)
2. 組織内の突出した人材を活用したパフォーマンス(超属人的なスキルで2億円を820万円にする個人を中心にしたチーム)

の組み合せになるのではないでしょうか。

このニュース（見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること：ITpro）の話しだけど、これはすごく納得できる。
このニュースに対する論争の中で一番しっくりきた。

若干違う趣旨のことを言っている気もするけど、kwatchさんのいっていることと近いのではないだろうか。

こういうマネジメントを考えられる組織は強くなるだろうな。

追記
元ネタではSIではなく、ソフトウェア開発の話しをしていたが、SI業界大手はソフトウェア工学好きに見えるし、反論もSIっぽいプロジェクトを意識したものが多そうだったのであえて混同して記述しています。

Manage It! 現場開発者のための達人式プロジェクトマネジメント

posted with amazlet at 08.10.15

Johanna Rothman
オーム社
売り上げランキング: 1364

Amazon.co.jp で詳細を見る

なんかよさそう。
今の仕事にも役立つかな。
とりあえず予約。

多くの人が、自分(の気持ち)に関心があるくせに、自分以外を変えようとする。

本来なら、自分の気持ちではなく、実現したいことや目的に関心を持ち、そのために自分を変えようとするべき。
それが結果的に自分も周りもハッピーになる。

最近自分自身も忘れがちだったので、改めて書いて戒めようと思った。

こういうのはダメ

「あいつ(あのチーム)が決めないから私(のチーム)の仕事が進まない」
「あいつ(あのチーム)がちゃんとやらないから私(のチーム)の仕事が増える」

仕事というのは別のことに置き換えても同じ。

こう考えるべき

「うまく進まないならこちらから案を提示しよう」
「今分かっている中で進められる方法を考えよう」
「あいつ(あのチーム)の手助けになることは何かできるだろうか」

それからこれもダメ(相当自戒の念が入る)

「あいつ(あのチーム)には無理」

こうしなきゃ

「できるように手助けしよう」
「信じよう」

自分以外を変えようと思っても変わらない。
自分で変えられるのは自分のみ。自分の影響の輪にもっと集中しなきゃいけない。

社会が悪いと悪態をついても、自分の影響の輪に入っていなければ意味が無い。
あいつが悪いと言っても、自分の影響の輪にはいっていなければ意味が無い。
自分なら自分の意志だけで変えられる。
そして気持ちではなくちゃんと行動を変えなければいけない。

自分以外が悪いと思ったときは、自分を変える＝向上させるチャンスのはず。

私自身、どちらかというと主体的に前向きに考えられるようになってきた気がする・・・というか考えなきゃいけないと思っているが、入社間もない頃に読んだ「七つの習慣」の影響が大きい。
読み始めは宗教臭くて読みにくい本だなーと思っていたが、第一の習慣＝「主体性を発揮する」まで読んだところで相当衝撃を受けた。
自分の行動が変わるのを感じた。

それから、七つの習慣でも変わらなかった、他人と会話していて”いらつく”部分も、「自分の小さな箱から脱出する方法」を読んで変わらなきゃと思うようになった。実際、家族との仲が(もとから仲良かったけど)さらに良くなった気がする。

というわけでこの二冊を読み直そうと思う。他の人にもお勧め本です。

7つの習慣―成功には原則があった!

posted with amazlet at 08.07.17

スティーブン・R. コヴィー ジェームス スキナー
キングベアー出版
売り上げランキング: 28

おすすめ度の平均:

いつも手元に置いておきたい人生の教科書
極めて根源的な自己革新を促し、自らの習慣を転換するために、繰り返し読みたい。
すごいパワーを持った本です
生きて、導かれていく私
ビジネス書としては全世界の歴史上最高の売り上げを誇っている実績のある本

Amazon.co.jp で詳細を見る

自分の小さな「箱」から脱出する方法

posted with amazlet at 08.07.17

アービンジャー インスティチュート 金森 重樹 冨永 星
大和書房
売り上げランキング: 351

おすすめ度の平均:

人生観が変わります！
小さな箱とは
万人にオススメしたい１冊
「箱」というメタファー：シンプルで奥の深い一冊
人間関係でつらいこと、苦しんでいることを見事に直してくれます。

Amazon.co.jp で詳細を見る

ひがさんの「ITゼネコンをぶっつぶせ」講演を聞いてきた。
内容は最近のひがさんのブログなどで語られている「Programming First Development」のこと。

で、感想＋会場の雰囲気から感じた課題感をつらつらと書いてみる。

内容には激しく同意。
できるようになれば、そしてできる人材が育てば、SIerも生き延びるチャンスがあるかなと思う。
（このままだと死ぬと思っているかどうかによって、「生き延びる」という表現に違和感がでるかな？）

もちろん、課題はまだまだある。
契約形態、テストに対する考え方、どこまでドキュメントを書くか、そんな人材ほんとに育つのか？
まだまだ経験を積みながら考えなければならないことは多い。
でも、枝葉末節にこだわらず、本質的なメッセージをとらえば明るい未来が見える良い内容。

ここからは、会場の雰囲気から感じた課題感。

インタラクティブにやりたいという冒頭のひがさんの言葉通り質問や意見が飛び交う
ただし、質問の内容がどちらかと否定的な見方や穴を探すような見方が多かったのが気になる。
（SIerの得意な態度だけど）

こういうセッションに参加するというのは、どちらかというと課題意識の高い人たちだと思うから、もっと響くと思ったんだけどな。
今までのSIerのやり方を真っ向から批判しすぎて拒否反応がでるのかな？
話題を集める目的では過激な方が良いが、啓蒙という観点から考えるともう少し別のやり方を考えた方がよいのかもしれない。

LLな人たちの考え方や態度とは、かなり隔たりがあるのを感じた。
LLな人からすると、こんなの当たり前じゃない？って思う話も多いかなーと。

どちらにしても、現場の開発者、SIerの偉い人たち、発注者の三者を啓蒙していかなければ、取り組みは成功しない。

それぞれに対するメッセージはこんな感じかな？

1.現場の開発者
・楽しく開発できる、成長できる。
・上流から下流まで全部それなりにできるようにしよう
・現場の人たちは啓蒙しやすいと思う

2.SIerの偉い人、(PM|上流)だけやればいいと思っている人
・売り上げのガサは減るかもしれないけど、利益は確保できる
・このままのやり方では、今後10年以内で破綻する

3.発注者（お客様）
・もっと安く早く、しかも良いシステムができる
・そのかわり、もっとシステム検討＋開発にコミットしてね

とりとめなく書いてしまったが、現在のSIerのやり方になれてしまった2,3の人たちをどう啓蒙するかが鍵。
一番は、ケーススタディーをたくさん作ることだと思う。

幸い、今業務でやっているところでは、お客様が乗り気で開発形態をひがさんの言っているような形態に変えようとしている。
これは、我々SIerにとってはかなりチャンス。
利益さえ確保できれば、少なくとも今の私の上司も納得するだろう。
金融のどでかいプロジェクトにくらべたらすごく小さい規模かもしれないが、それでも世の中に発信して注目を集める程度の規模と知名度はある。
今のプロジェクトが、SI業界を変えていく一つの要素になるようにしたい。

設計する人がプログラミングできないなんて正気の沙汰ではない。
ひがさんのエントリーはすごくいい。
浜口さんに贈るSI業界を良くする方法
プログラミングできない元請けがプログラム設計書をレビューするという矛盾
業界として改善しなければいけない。

アプリケーション開発になると、お客様と要件を検討する人が、そのまま設計・プログラミングできれば最高。
難しいのは、両方をきっちりこなす人間をどう育てるかってこと。
難しいけど、こういう人材を育てるスキームができると、SI業界はかなり変わると思う。

昨日のエントリ「[SIer]開発チームを強くする方法」で書いた、「強い個人」はこの要件・プログラミングの両方が高い次元でできる人のイメージだった。

そういう人たちが集まったプロジェクトはすごく楽しいだろうなー。

SIer、特に一定規模以上の会社になると、自社にしかないノウハウとか、開発標準とか、マネジメント手法とか大好き。

逆に、「SIerは人が資本？」にも書いたけど、個人を強くするという発想が弱いのでは？
（こんなことを中の人〜自分もだけど〜に言うと、個人の成長を一番に考えてるって言うだろうけど、実際にはあまりそうなってないよね）

チーム運営のノウハウがあるからチームが強くなるというのも、まー分かる。
でも、やっぱり個人個人で勝負できるようにならないと、本当の意味で強いチームにはならないんじゃないか？

中の人にも実は優秀な人がたくさんいると思う。でもなぜか個人にスポットライトをあてて、強い個人をどんどん作っていこうという姿勢が少ない気がする。もったいない。

これからは、とんがった力を身につけた個人をどんどん育て、強い個人が有機的に結びついてチームが強くなっていくというアプローチも、もっと真剣に考えて取り組んでいかないといけない。

今までそんなことを思っていたけど、まさに同じように考えているお客様と新しいスキームを作ろうと考えて動き出している。ぜひ成功させて楽しいSIerを実現できるようにしたいな。

何となく違和感を感じた。

発注者ビュー検討会 | NTTデータ

実践的アプローチに基づく要求仕様の発注者ビュー検討会（略称　発注者ビュー検討会）は、情報システムにおける「仕様」について、お客様にわかりやすい記述方法および合意方法を共同検討することを目的に国内主要SI事業者が結集した検討会です。

• 「お客様視点でわかりやすい」、かつ
• 「現場で使える」ベストプラクティス作り

を行い、IT産業界への浸透を目指すとともに、日本のIT産業全体のレベルアップを図ります。

どういった設計書で発注者とやり取りするのかについて分かりやすく業界標準を作る･･･というのが悪いわけではない。
各社、もしくは各プロジェクトごとに設計書（要件定義書や基本 or 外部設計所）の仕様を決めているため、記述レベルや結果的な品質のばらつきがあるのは確かだ。
発注者への確認･･･と言う意味での仕様書も、曖昧になっているプロジェクトが多いのかもしれない。

では何が違和感なのかというと、この目的が「より良いシステムを作るためではない」ということなんだろうと思う。

このプロジェクトは以下の観点が抜けているのではないかと思う。

• どんなに設計書で合意しても、実際にシステムを使ってみないと分からない要件がある
• 内部設計や実装を行う過程で、外部設計や仕様の改善点を思いつく場合が多い
• 外部設計までのスケジュール・予算が厳しく、細かい仕様まですべてチェックしきれない場合が多い

ではこのプロジェクトの目的は何なのか？
言葉は悪いかもしれないが、受注者側の防御のためだと思う。もしくは請負で開発を投げて終わりにしてしまいたい発注者側、特にシステム部門の防御にもなるだろう。

発注者「実際見てみると、この辺はおかしいなぁ」
受注者「でもこの設計書で合意しています」

下流担当「ここは、仕様が統一されてないから、こうしたほうがいいのでは？」
受注者「でもこの設計書でお客様と合意しているから」

こんな会話のタネにしかならなかったらやだな。
全てが一つのウォーターフォールでしか考えられず、しかもこの設計書を書く人はシステムの内部まで分からない人だったりしたら･･･多分こういう会話が飛び交うんだろうな。

うがった見方の意見を述べてしまったが、この発注者ビュー検討会のような取り組みが必要なことは分かる。
でも発注者と受注者のコミュニケーションが上手く行かないのを改善するのに、こんなプロジェクトがあってそこそこ注目されるんだと思うと、この業界（請負開発、SI）のレベルが低いんだろうなーと感じてしまう。
発注者にも開発側にも分かる仕様書なんていうのは普通のことで、その上でよりよいシステムを作るためにはどうすれば良いのかという議論が普通にできる業界になればいいなぁ。

参考：
Japan.internet.com Webビジネス - NTT データなど9社、発注者と開発者の認識のズレを防ぐガイドラインを公開
デスマーチ撲滅への「飛躍」なるか–大手SI事業者、外部設計書の記述を標準化:ニュース - ZDNet Japan

「ユーザーはこんなことを思っていて、こういうサービスがあれば嬉しいはずだ」
と企画を考えて、なぜその企画がよいのか論理的な説明も付いて、一見良さそうに見える。
実現可能性も高そうだ。

でも、そこでちょっと振り返って考えた方がいい。

なぜなら、それはサービス提供側の都合でしかない場合があるから。

バカの壁じゃないけど、サービス提供側の論理とユーザーの論理にはかなり違いがある。
例えばオンラインで買った本をオンラインで読めるサービスがあったとする。
本好きのあなたはオンラインで読みますか？

例えばAmazonがそういう企画を思いついたとして、「オンラインで読めるのはすばらしく便利」「流通コストも削減されて一石二鳥」なんて考えたとしても、実際にはオンラインで提供した方がAmazonが嬉しいというだけで、ユーザーはそれほど嬉しくないはず。
頭をフラットにして、自分がユーザーだったらどう思うの、というのを企画を懐疑的な目で見ながら検証するのが大事。

当たり前のことだけど、様々な企画を検討している最中で、ついこの落とし穴にはまる事例が多いので注意が必要。

最速配信研究会 - ミスとかトラブルとか
身に染みて同意。
ミスやトラブルに対する取り組み方も、根性論に走っては行けないという考え方もすばらしい。

開発者側の人間はもちろんこれを理解する必要があるんだけど、開発には直接関わらない企画者や経営者、委託開発をお願いする発注者も理解する必要がある。

なぜなら、品質やサービスレベルと密接に関係するミス防止策は、コストに直接跳ね返ってくるから。
発注側も品質とコストのトレードオフを同じ目線で考えなければならない。

ここで、「それは開発の問題だろ」と感じた人がいたら、ミス防止策のコストは認めず、それでいてトラブルがあったときには激しく怒り、必然的に開発者に根性を要求するようになる可能性があるので注意が必要。
回避するために適当に品質向上策をを人月単価に上乗せすると、品質の差など全く関係なしに、単価の安い人員でも言い出す可能性がある。

ただ、それほど大きくコストは変わらないのに、同じような品質を作り込める人がいる。それは優秀なプログラマーだったり、優秀なプロマネだったり、優秀な運用設計担当だったりする。
逆に同じコストでもひどい結果にしかならない場合もある。

普通に考えたらこれはおかしい。なんで同じコストなのにできたりできなかったりするのか。
そりゃ発注側だって文句の一つも言いたくなるだろう。
この辺も人月ビジネスのひずみだよなー。

うちの会社も人が資本とよく言ってる。
自社でインフラを持たず、人が提供するサービスでお金を稼いでいるのだから「人が資本」というのはそりゃそうだろう。

その割には人にフォーカスした強化策が不十分な気がする。同業他社も似たような状況だったりしそう。

会社としての取り組みは、「組織的開発力の強化」とか「外注管理の強化」とかそんな話が多い。
人が資本というなら、「採用強化」とか「個人の能力を最大限発揮させる施策」とかそんな話がもっと増えてもいいのに不十分な気がする。

「資本をどう使うか？」は重視されているし結果も見えやすいけど、「資本をどう強化するか？」を考えるのは難しいし成果もわかりづらいから、曖昧にしておいた方が楽なんだろうな。

SIerも現在の乱立状態からそのうち徐々に淘汰されていくと思うけど、そもそもの人の能力を強くするという意識を強くしておかないと取り残されそう。
会社としても個人としても。