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

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

個人でサービスを作るときに、一番時間のかかること

答えは簡単。
「やる気を出すまでの時間」
「やろうと思ってるんだけど、他のことをする時間」

作業時間は実はたいしたこと無い。
今日は色々疲れたから飲んでしまおうと思ってしまう日、朝起きようと思ったけど何となく眠いと思う日、仕事が忙しかったと言い訳する日。

これは、サービスを作るだけではなく、いろいろな言い訳に使われることだと思う。

意識だけで解決できる問題が多い。
趣味だけではなく仕事でも上記の課題を解消するだけで相当なレベルアップになりそう。

難しいことではなく、当たり前で簡単なことを一つずつ積み重ねるのって意外と難しくって、しかも差別化につながるんだろうなあ。

自分の現在の価値や目指す価値、それに足りないものを考える人は少ない

とある部署間の連携を強化する目的でタスクチームを立ち上げてセッションを持った。
なかなか難しいなと思った。

普通そういう時はセクショナリズムとかが問題になりそうだけど、そんなわけでもない。

そもそも自分(たち)の現在の価値とか目指す価値、足りないものなんかを真剣に考えたことがある人が少ないんじゃないかと思う。

だから、自分に足りないものを補う、お互いの価値をあわせてさらに高い価値を目指す・・・という発想が少ない。
自分を高めることはあまり考えず、今困っていることを単純に相手に求めることしかない。

今の客先でも同じ状況があるな。
自分たちに足りないものを直視せず、外部環境のせいにする。
自分たちが何をしているかはともかく、過度な期待を相手に持つ。
他の人はそれを見てイライラしてるのに、イライラしてる人も自分は省みない。

もしかして自分もそうなってるのか?

前述のタスクチームも、今の状況と欲しいものの議論をするだけではなく、もっと視点を上げて価値を高めていけるように持っていきたいな。
まずは、自分の発揮すべき価値は何なのか、自分がしたいことは何なのか、自分は何をするのか・・・を徹底的に考えるところから始めたい。

抽象的でちらしの裏になってしまった。

アジャイル導入も難しいけど、要件定義ですべてを決めろはもっと難しいかな。

おととい「アジャイルな要求管理って難しそうだな」というエントリーを書いたが、それを実感するような記事があった。
「こんな状況確かによくあるよな」という内容。

定まらない要件、ユーザーからのむちゃな要求 - @IT自分戦略研究所

(2ページ目)予算が決まった後からできるだけ多くの要求を出し、少しでも多くの機能を実装させようというポリシーの持ち主だったのです。「これも当然やってくれるんですよね?」というひと言に、これまでも多くのメンバーが泣かされていました。

開発者の視点から書いてあるので一方的な物言いではあるが、確かにこういう顧客担当者はいるだろう。
そしてこれに対する対応は、要求のあるべき姿を考えて実際には必要ないということを顧客担当者に分かってもらった・・・というものだ。

もし、本当に必要なものだったらどうしたんだろう?
予算や品質とのトレードオフを突きつけて、ここまでやらないほうがお客様にとっても良い方向になる・・・なんて話をするのが目に浮かぶ。

使う前から、本当に必要になるかどうかをどう判断するんだろう。
システム化+新業務フローをほぼ同時にスタートさせたいときなど、事前の要件定義ですべてを最良の形で決めきれるとはとても思えない。
もちろんベストエフォートで、それなりに良いシステムができるように要件定義するんだけど。

この筆者の場合は、顧客の立場から本当に必要なものを判断していいシステムを作ったのだろうけど、やっぱり構造的に無理があるよな。

実際の開発現場では大きなウォーターフォールが未だに多く、こういう状況は日常茶飯事だと思う。
これを意識改革して、アジャイルなどの新たな考え方に持っていくのは、難しいのが分かっていても取り組んでいくべきだと再認識した。

@ITの記事の趣旨とは違う感想だと思うけど。

アジャイルな要求管理って難しそうだな

JavaWorld Day 2007 - アジャイル開発の伝道師が明かす、プロジェクト成功の秘訣 | マイコミジャーナルを読んだ。
参考になる話が書いてあったが、このままじゃ実現は難しいなあと感じたことを書いてみる。

何が難しいかってこれ。

アジャイルな要求管理(Agile Software Requirements Management)

アジャイル開発では、個々の要求に優先順位を付け、優先度の高い順に開発に取り組んでいく。開発の初期段階ですべての要求をモデリングするウォーターフォール型プロセスとは異なり、情報が揃った段階で分析ができるため作業を効率的に進められる。「要求の変化に柔軟に対応できるため、競合優位性につながる」(Ambler氏)という。

これを実現させるためには、顧客の継続的なコミットが必ず必要。要件を決めたら自分の役目は終わり、あとはシステム屋さんが作るだけと思っている顧客じゃ難しい。
常に要求の優先順位付けを行いながら、出来上がったもののチェックをしてさらに改善案を検討して・・・というのを継続しなきゃいけないわけだ。
アジャイルではないけど似たような開発スキームを取り入れた例で、開発側とシステム部門は「忙しさは通常のウォーターフォールと変わらない or 楽になった」と言っているのに対して、要求の出し元は「明らかに大変になった」と答えていたのも聞いたことがある。

現在のSIなどの受託開発に構造的問題があるというのは分かるが、それに慣れてシステム開発を自分たちのものだと感じていない発注側の意識改革も当然必要になる。
アジャイル開発導入にあたって、一番高いハードルはここなんじゃないかと思う。

開発側の人が顧客(システム部門じゃなく要求の出し元)に非常に近い位置に入り、顧客の視点・立場でプロジェクトを引っ張るくらいになれればこのハードルも越えられるのかな。

技術からビジネスは産まれるか?

あるところで、こんな質問をされた。
「技術からビジネスは産まれるか?」
「技術が先かビジネスが先か?」

技術が目的になり楽しい技術を追求していたら、たまたま上手いことヒットするビジネスが産まれるなんて、そんなのは宝くじ。
たとえ技術ベンチャーだとしても、その技術がどういったマーケットに受け入れられるかor創造するかとかいうビジネス視点が上位概念にあるはずだし。

私なりに考えると、実は質問そのものが間違っていて
「技術者がその知見を生かしてビジネスを企画できるか?」
「ビジネスを考える人と技術が分かる人が一体になって企画できるか?」
というのが正しい質問なんじゃないかと思う。たぶん。

だったら答えはYesだし、特にWebにおいてスピード感をもって企画するには必須なことだと思う。

表題の質問をした人は
「技術は知らないんだけど、面白そうな技術をつまんでビジネス作ったら儲かる?たとえばWeb2.0とか(※)」
という感じで言ってそうだから、考えを正しておかないとなぁ。

※こういう人には、そもそもWeb2.0って本質的には技術じゃねー、という話も理解されずらいのです。

「人月の神話 狼人間を撃つ銀の弾はない」を読んだ、やっぱり名著

仕事で、開発期間の「大幅な」圧縮とか生産性の「大幅な」向上とかが大きな話題になっていたので、人月の神話を読んだ。
今までなんとなく読まずに来てしまっていたので。

人月の神話―狼人間を撃つ銀の弾はない
フレデリック・P,Jr. ブルックス Frederick Phillips,Jr. Brooks 滝沢 徹 富沢 昇 牧野 祐子
アジソンウェスレイパブリッシャーズジャパン (1996/02)
売り上げランキング: 25105
おすすめ度の平均: 4.0

4 マネジメントに関わる人間にとって示唆に富む本
4 ソフトウェアエンジニア必読のスーパー古典!
4 情報システムの仕事に関わっている方には是非お勧め

プロジェクト、それもそこそこの規模でマネージメントに関わって・・・という経験が無いとなかなか理解しづらい部分が多いと思うが(訳が悪いからかも?)、かなりオススメ。
小手先の(マネジメント)テクニックの本を読むなら、この本を何度か読み直したほうがいいかなぁと思った。

「銀の弾はない」を読めば、「RailsとかDjangoとか最新フレームワークさえ入れれば生産性劇的向上」なんて単純には言えないのが良くわかるはず。

「人月の神話」はプロジェクトマネジメントに関わるなら常識的だけど、「銀の弾はない」は打ち崩せるという魔法を信じちゃう人が多い気がする。(「人月の神話」もついつい忘れて中途半端に人を増やす場面がよくあるかも?)
この話を理解した上でじっくり考えれば、的確な打ち手と現実的な効果を検討できると思う。
逆に理解していないと幻想を抱いた提案しかできずに、あっさり却下されるか期待通りの効果がでないかどちらかになるだろう。

この本で自分の頭を整理でき、具体的な開発期間圧縮とか生産性向上を提案する素晴らしい材料になった。

企画者と開発者の距離

近ければ近いほど生産性が高くなる。

究極の形は一体型。Web2.0企業(←そろそろ死語?)などの企画から開発まですべて技術者がやるパターン。それも一人プロジェクトだったら最高の生産性。

最悪の形は、別会社への開発委託型。
しかも企画者と開発者の間にシステム部門なんか挟まっていたら最低。

こうやってまったく異なる体制のプロジェクトの生産性を比較しても無意味だと思う。
しかし、体制のメリット/デメリットをきちんと把握した上で、プロジェクトの進め方と生産性のバランスをどうとるのかという議論は有効だと思う。

委託型の場合でも、できるだけ企画者と近い位置で会話を続けながらすばやく実装に落とすというのが、もっとも生産性が高くなるのは分かりきっていると思う。
アジャイル開発の根本はここなのかな。

企画立案におけるマネジメント

ITmedia エンタープライズ:「ハズレ上等企画」の山でイライラするのは終わりにしよう (1/2)

 「(1)背景・経緯、(2)現状の課題、(3)課題改善の可能性、(4)目標、(5)目標達成のためのアクションプラン、(6)経済性、(7)他に与える影響。この7つは、企画を立案するときのプロセス順に並んでいます」

このテンプレートは使える。
当たり前っちゃー当たり前かもしれないけど、実直にそれをやるのは大事。

そして、その企画内容をプロジェクト憲章(たとえ後工程の開発プロジェクトだったとしても)にも盛り込むべきだな。
参考:そのプロジェクトの目的は何ですか?

優秀な技術者に頼ってはいけない3つの理由

プロジェクトにおいて、優秀な技術者に先導してもらって最新の素晴らしいアーキテクチャーを取り入れたり、素晴らしい設計を取り入れたりすることは当たり前に大事なことだけど、頼りすぎると問題もあるんだよなぁと最近感じることがある。もちろんどのプロジェクトにおいても優秀な人は必要だけど、必要以上に幻想を抱いて頼りすぎるとまずい。
なんて考えていることを備忘録としてまとめてみる。

1.その人がいなくなったらプロジェクトが立ち行かなくなる
プロジェクトが人に依存するようになる。
リリースまではうまくいったとしても、継続が難しい。保守フェーズなど。せっかくの綺麗なアーキテクチャーだってすぐにぼろぼろになる。
技術にコミットしていないユーザー企業が外部に委託して行うプロジェクトなどでは特に起こり易い問題。

2.納期や費用の試算が難しい
要件定義時に、費用や納期を計算しづらい。
全体の生産性が劇的に向上するようなメタプログラミングを行ったり、アーキテクチャーを設計したりするかもしれないが、設計前にどの程度の生産性になるのかを計算できない。
優秀ではあっても超天才的な技術者は雇えないプロジェクト(←つまりほとんどのプロジェクト)では、優秀な技術者の素晴らしい設計に頼るよりも、設計はまずくても実直に積み上げて開発してしまったほうが、PMとしては計算しやすい。

3.一人(or 少数精鋭部隊)ではこなしきれない規模×納期の大規模開発
少数精鋭部隊でこなすには、作業量が多すぎるようなプロジェクトもある。
とくに要件が多岐にわたるようなエンタープライズのシステムの場合。
優秀な技術者に頼りすぎていると、いつかそこがボトルネックがやってくる可能性がある。

上記の問題を踏まえつつ、優秀な技術者をプロジェクトの中で最大限生かす方法を考えるのが大事なんだろうけど、個人的には難しくて悩む。
中途半端に優秀なのではなく、上記も踏まえて素晴らしい働きをしてくれるスーパーな人がありふれていればいいんだけど、そんな人がいつもいてくれるわけじゃないからな。
自分がなれるように努力しろというのは棚に上げてるけど。

そのプロジェクトの目的は何ですか?

プロジェクトの一番最初にやることは何か?
WBSを作ってタスクを洗い出して、マスタースケジュールを作って・・・とついついやりたくなってしまうけど、これだと上手く行かないと思う。上流工程だと特に上手く行かない。

大事なのは、プロジェクトの目的は何か、成果物は何か、迷ったときの優先順位は何か、誰が決裁者なのか、そういった当たり前のことをはっきりとさせることだと思う。
日本のその辺のITプロジェクトだとイマイチ浸透度が低いけど、PMBOKでいうところのプロジェクト憲章というやつが大事。

Web上のサービスなどを短期開発するときでも、このプロジェクト憲章がしっかりしていないとみんなが路頭に迷う。
要件をMUSTとWANTに分ける
何を大事にするか決める
などなど当たり前に言われていることではあるけど、実際に明文化されていることは少ないし、明文化されていても曖昧なコンセプトだけ書かれていて、よくわからないものが多い。

「そのプロジェクトの目的は何ですか?」
と聞いてみて、返答が無かったり、下手するとムッとされたり(逆切れ?)されたりするようなときは、注意が必要。
ちゃんと突っ込んで話をしたほうがいいと思う。

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

Search
Feeds
Meta

Return to page top