マネジメントに必要なIT知見を鍛えるためには

質問

私はこれまで、戦略系のコンサルティング会社で企業の戦略立案をお手伝いする仕事を
してきましたが、近日、とあるネット系の会社に転職をすることとなりました。そこでは、これまでの経験を活かし、小さな事業の責任者的立場で戦略・計画の策定や日々のマネジメントを行なっていくこととなっております。開発の責任者自体は別途いらっしゃるものの、計画・予算を握る立場としては、日々の細かい開発予算まで含めて開発の人と話をし、経営陣に交渉しに行かなくてはいけないと思っております。

実際、マネジメントと言っても「エラい人」という訳では全くなく、小さな事業ですので現場レベルの細かい話も扱っていく必要があります。

しかし、正直なところネットビジネス及び開発に関しては未だ知見がありません。ネットビジネス自体については、これまでもコンサルティングの仕事の中で、様々な業界のお客様の業界知識に負けないよう、プロジェクト毎に短期間でキャッチアップしてきましたので、やや特殊な業界ではあると思いますがなんとかなるようには思います。

問題としては、開発に関わる部分の会話についていけるかを心配しております。自分でコードを書くわけではないものの、用語は確実に把握できておく必要がありますし、開発側に丸投げという態度では信頼も得られないと考えております。

このような状況下、一日も早いキャッチアップのために、成すべきことについてご教示頂けませんでしょうか。実際の業務の中で身に付けるのが一番かとは思いますが、独力でなんとか出来る分については休日もフル活用して頑張りたいと考えております。勉強するべき分野、読むべき本などについて教えて頂けますと幸いです。

ご参考までに、私は31才で、知識レベルは以下の通りです。
・一般のPC操作レベルにアレルギーはなく、簡単なExcel VBA程度は作成可能
・趣味でHP作成をしており、超簡単なHTML、CSS程度は作成可能
・一方で、いわゆるプラグラミングと言われるレベルについては、興味はあるものの触れたことはなく、用語も理解していない
・また、「開発」という仕事が実際にどのように進められているものなのかについての肌感覚すらない

私としては、以下の勉強が必要かと考えておりますが、如何でしょうか。優先度や、具体的な方法・読むべき本、この他に必要なこと等をお伺いしたく。

・ネット業界、ネットビジネスに関する一般知識習得
⇨がむしゃらに本を読み、ニュースを仕入れ、考察したりなどし、こちらは業務で肌感覚に触れればあと少しで一般レベルに追いつけそうです
・基本情報技術者、応用情報技術者の資格取得
・データベースに関する技術習得
・プログラミングの技術習得
⇨上司になる人からは「不要」と言われていますが、現場の作業レベルで事業を理解し、仲間の信頼を得るためにも、概念レベルで分かっておく必要があるのでは？と考えております。かねてより興味もあったので、やってみたいという気持ちもあります。

なお、ネット系の中でも特にECビジネスです。何卒宜しくお願い致します。

回答No.2

kirakirasmaily · ベストアンサー

戦略系というのは主に「お金が入ってくる仕組み」を考える人たちのことだと思います。
それに対して、それをどうやって作るかを考えるのは開発の仕事です。

逆に、戦略系の人たちが開発の視点で「これがホントに作れるのか？」という視点で物事を考えてしまうと、一番大事な「ホントに必要とされてるものは何か？」という発想が出てこない可能性があります。

だから、質問者様の上司になる人が「不要」と言ったのも、ある程度はうなずけます。

おそらく、質問者様が開発の現場とやり取りするとしても、開発責任者レベルとのやり取りになると思います。
現場の担当者と直接やり取りすることはおそらくないと思います。
ですから、とりあえずは開発責任者とコミュニケーションをとるのに必要な知識、具体的にはプロジェクトマネジメントに関する一般知識があれば十分だと思います。

ただし、どこまでが戦略系で、どこからが開発の仕事とするかは会社によってもそれぞれだと思いますので、余力があるなら、開発の現場にも顔を出しながら、勉強していくのが良いと思われます。

優先度としては、

＞ネット業界、ネットビジネスに関する一般知識習得

↑明らかにこれが最優先事項ですよね？
戦略系なら、一般知識レベルではダメだと思いますよ。
誰にも負けないバリバリの業界スペシャリストを目指すべきだと思います。

＞基本情報技術者、応用情報技術者の資格取得

↑資格の取得は一番後回しで良いと思います。
今から勉強するならそれより上のITストラテジスとかじゃないですか？

＞データベースに関する技術習得
＞プログラミングの技術習得

↑これも業務ですぐに必要になるとも思えませんので、余力があればで良いと思います。

お礼

ありがとうございます。まずは自分が一番バリューの出せる戦略立案部分で価値を発揮すべきとのご指摘と理解致しました。丁寧にご説明頂き、気が楽になる部分もありました。とはいえ、「戦略で掲げたユーザビリティ・価値訴求ができていない」⇨「これこれこうした追加開発が必要」⇨「5,000万円かかるが、他の追加開発案件とどちらを優先すべきか」といった判断に納得感を持った上で携わるには、開発責任者レベルと概念レベルででも対等に会話できる知識を身につけるべきとも理解致しました。心よりお礼申し上げます。

回答No.4

畑山 隆志（@deltalon）

あなたがその会社に転職できたのなぜでしょう。
　当然、会社側があなたが会社の利益獲得に役立つと思われたからです。ではどの辺りに貢献できるでしょうか。

　現在の会社はECビジネス。商品を販売するためのシステムでしょうか。どんなにすばらしい商品でも、市場に対応できなければ利益以前に消失してしまいます。つまり、開発用の技術者はいるのですから、あなたの場合は市場への商品の投入場面で腕を振るってもらうことになります。そのときにあなたご自身の値打ちが決まります。
　ですから、開発の心配ではなく、市場とのインターフェイス部分に気を配っていくことが肝要でしょう。つまり完成品が市場に受け入れられる商品かどうか、ということです。

　あえて学習してきたいのであれば、UMLをやってみてください。現在顧客の要件を分析し、システムを組み立てる初期段階に使われている表記法です。あまり知られていませんが、現実を理解し、なお他者とコミュニケーションをとるための重要な道具になります。

参考URL：

http://www.shinchosha.co.jp/book/610510/

お礼

ご丁寧にありがとうございました。

回答No.3

lv4u

No.2さんの回答に同感ですね。

ちょっと前に「IT業界の中小独立系企業について」
http://okwave.jp/qa/q8026760.html
で回答したのですが、質問者さんは、この質問の中の、大手のメーカのＰＭさんに相当する立場だと思います。
そして、現場で開発する技術者さんは、中小のＩＴ企業のＳＥ，ＰＧさんです。

大手ＳＩerで働くＰＭ，ＳＥさんは、開発現場の実際の仕事についての知識・経験や「肌感覚」なんて不要なんですよ。
「開発側に丸投げ」でいいと思います。
そして、質問者さんは、技術面での「信頼」は期待されていないでしょう。
それだからこそ、コンピュータサイエンスを全く知らない文系卒の方が大手ＳＩerにＰＭやＳＥになるために入社できるわけなんです。
（ある方も、日本最大のＳＩerでもある某社のお偉いさんとの雑談の中で「そんな知識は不要」と言われたらしいです。）

>>小さな事業の責任者的立場で戦略・計画の策定や日々のマネジメントを行なっていくこととなっております。

と書かれていますが、それをしっかりと行っていくことが大切なんだと思います。
質問者さんの「信頼」は開発途中に、顧客から影響度の大きな要件定義変更をなんとか抑えるとか、現場で働く人たちの「技術系以外」の問題点を解決することだと思います。いわゆる「コミュ力」って部分でしょうか？

例えば、住宅メーカでは、営業が顧客である施主さんの要望を聞いて、建物の注文を取ります。でも、顧客の要望は、「建築基準法、民法から無理！」「構造的に無理！」「技術的に無理！」ってものがあるわけです。で、宅建の資格が必要になったりしますが、全ての建築営業マンが宅建の資格が必要とはされません。まして、一級建築士の資格も不要ですし、建築現場の肌感覚も不要です。もっと違う面が営業には期待されているわけですが、それと同様だと思います。

お礼

ご丁寧にありがとうございました。

回答No.1

root139

まずは、規模の大きいソフトウェア開発プロジェクトは負け戦になる可能性が非常に高いことを知っておいた方が良いでしょう。
下記の書籍などが参考になると思います。特に「人月の神話」と「デスマーチ」は著名な本ですので押さえておいた方が良いかと。

■ 人月の神話
http://www.amazon.co.jp/dp/4864010056/

■ デスマーチ
http://www.amazon.co.jp/dp/4822282716/

■ プログラマーのジレンマ
http://www.amazon.co.jp/dp/4822283801/

■ 動かないコンピューター
http://www.amazon.co.jp/dp/4822207846/

さて、今までにシステム開発と係わりが無く、開発マネージャーになった人にアドバイスするなら、下記の様なことが挙げられます。

1. ソフトウェア開発は驚くほどコストが掛かる。
2. ソフトウェア開発は規模の経済性が成り立たない。
　(ソフトの利用や販売については如実に成り立つが)
3. えてして、初期開発よりも運用・保守のコストの方が大きくなる。
4. 画面を見みても、進捗・品質はほとんど分からない。
　(ただし、分かったような錯覚には陥る)

1,2に関しては↓の書籍が参考になります。
http://www.amazon.co.jp/dp/489100522X
コストの感覚については、Officeソフトレベルのリテラシーのある人の方がむしろズレが激しいです。Excel などを使ってすぐ出来ることなら簡単に開発できそうに思えますが、システムの規模や制約によっては相当のコストが掛かる事も有るからです。
規模の経済性が成り立たないというのは、規模の大きなシステムになればなる程、プログラム行数や機能ポイント単位のコストは上昇するということです。人に関してもプログラムモジュールに関しても、数が増えるほどコミュニケーションパスが2乗ペースで増えるからです。
また、1人の人間が把握できるプログラムコードには限界が有りますから、システムの規模がそれを超えれば、開発メンバーは部分理解で作業をやらざるを得ません。1人の人間が把握できる範囲は1～2万ステップと言われますから、よほど小さなシステム以外は超える事になります。
ですから、小さなシステムに大きな変更を施すのと、大きなシステムに軽微な変更を加えるのでは、後者の方が何倍もコストが掛かるケースが多いです。
4については↓のページが分かり易いです。
http://local.joelonsoftware.com/mediawiki/index.php/%E6%B0%B7%E5%B1%B1%E3%81%AE%E7%A7%98%E5%AF%86%E3%80%81%E6%98%8E%E3%82%89%E3%81%8B%E3%81%AB

それから、プログラミングの技の習得についてですが、実際に自分で経験してみるのは良い事だと思いますが、その際の数百行程度のプログラムの延長として実際の業務プログラムを考えない方が良いです。50m走の経験でマラソンを考える様なものです。
数百行程度であればその限られた範囲で文法的・論理的に正しいかどうかだけが問題ですが、業務プログラムは文法的・論理的に正しいのはもちろんの事、必要とする機能・性能・柔軟性・セキュリティを確保しながら、重複を排除し、複雑性を押さえて分かりやすいものにしつつ、納期までに作成しなければなりません。また、開発後半や保守フェーズになれば、既に存在する大量のコードとの整合性を保ちながら、変更や新規の機能を加えなければなりません。

他にも参考になりそうな本・サイトを挙げておきます。

■ Manage It!
http://www.amazon.co.jp/dp/4274067297/

■ ピープルウエア 第2版
http://www.amazon.co.jp/dp/4822281108/

■ 新しいソフトウエア開発手法
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html

■ ソフトウェア開発201の鉄則
http://www.amazon.co.jp/dp/4822290026/

■ Clean Coder (プログラマ向けの本ですが、開発者から見たマネージャー像が参考になるかと)
http://www.amazon.co.jp/dp/4048860690/

■ ITmedia エンタープライズ
http://www.itmedia.co.jp/enterprise/

お礼

具体的に色々な本をご紹介頂きましてありがとうございました。私の転職する会社は内部にも開発者を抱えつつも、基本的にユーザーサイドではありますが、ご指摘のような観点や知識は身につけていけるよう努力して参りたいと思います。