« 人海戦術から「おひとりさま開発」の時代へ | トップページ | フィールド数のメトリクス »

2012.06.13

たったひとりで踊るために

 1人かごく少数の精鋭メンバーで業務システムを仕上げる。そのやり方を「おひとりさま開発」と呼んでいるわけだが、この手法が普及することで開発企業や技術者はさまざまな影響を受ける。それはソフトウエア技術の発展にともなう歴史的必然でもある。

 なお、「おひとりさま開発」の字面だけから、それでは工期が長くなりすぎると思われたかもしれない。100人月の仕事を1人でやれば100ヶ月かかる計算になるが、そういう話ではない。従来よりもはるかに少ない工数と人員でしのぐための工夫やリソースの整備が肝心、という話だ。

 すなわち、これまでも書いてきたように、無償か安価で手に入るモデルシステムのようなものを活用すれば、たった一人で生産管理システムを短期間でカスタマイズして納めることも可能である。このような工夫やリソースは今後、ほっといても進展してゆくだろう。こういうものを用意せずに丸腰で基幹システムをスクラッチ開発する――それがそもそも無謀だったのだ。

 さて、「おひとりさま開発」の特徴のひとつは、従来型の専門家が要らない点である。これまでのSIにおいて、たとえば上流工程やプロジェクト管理を担当してきたのは専任のエキスパートだった。SIビジネスの売上の多くの部分は、そこらへんの役務提供によって確保されてきた。

 ところが「おひとりさま開発」では彼らを起用する理由がない。なにしろ、データモデルも業務マニュアルも仕様書も出来上がっている段階からスタートするため、スコープも検討事項も明快である。またメンバーが極端に少ないので、洗練された管理手法をあやつるPMも要らない。さらに、クラウド提供されるゆえにインフラ設定の専任要員も要らないし、コード量が少ないのでプログラミングの専任要員も要らない。ようするに、これまで皆が目指してきた「特定作業の専門家」が個別受託案件では要らなくなる、というどうも困った話なのである。

 いっぽう、その種の専門家が要らない分、「おひとりさま」は多能工でなければならない。モデルシステムが起点になるとはいえ、仕様や実行環境を顧客に合わせてカスタマイズすることがどうしても求められるからだ。必要に応じてコンサルもデータモデリングもプログラミングもインフラ設定もそつなくこなせるようでなければならない。彼らはジェネラリストというよりは、業務システムというソフトウエア分野そのものに関する専門家である。従来の「専門分野」が狭すぎただけの話だ。

 「ひとりでがんばらなくても、作業項目毎の専門家を集めて開発すればいいじゃないか」と思われたとすれば、発想が古いし現場を理解していない。「メンバー数を出来る限り減らすこと」こそがソフト開発プロジェクトの成功率とアジリティを高めるコツであることを、現場の人間は知り抜いている。じぶんの専門以外のタスクでぼーっとされていては困るのだ。

 けっきょく従来のような分業・人海戦術体制は、生産性の低さゆえの必要悪だったのだろう。個々のソフトウエア分野で技術革新が進めば、より少ない工数と人員で個別受託案件を扱えるようになる。結果的に、従来であれば分業で手当てできていた多様な役務を、ひとりの要員が提供しなければいけなくなる。プロジェクトの少数精鋭化もメンバーの多能工化もプロセスのアジャイル化も、技術発展が要請する歴史的必然である。

 ただし、極端にメンバーが少ないため、アジャイラーが好きな「チーム指向」が通用しないことも覚悟しておいたほうがいい。適切にファシリテートされたチームの和気あいあいとした雰囲気や、チームで働くことによってもたらされる気づきや成長――そういった要素は「おひとりさま開発」の果実としては期待できない。顧客が見つめる殺風景な舞台に、たった一人で進み出て踊り始める。それは本当の技術力が試される厳しく孤独な道だが、圧倒的な生産性とやりがいと高い契約単価を見込めるすぐれた手法だ。

【特別セミナー@東京】
クラウド基幹システムを「おひとりさま開発」しよう
2012年6月22日(金) 19:30~

【勉強会@大阪/関西IT勉強宴会】
データ中心設計の基本とクラウド開発
2012年6月29日(金) 19:00~

|

« 人海戦術から「おひとりさま開発」の時代へ | トップページ | フィールド数のメトリクス »

コメント

渡辺 様

伊藤です。

・オーナーさん,
・アーキテクトさん,
・設計者さん,
・DEVOPS(Developer,Operater)さん(まだ日本にはいない?アメリカには?),
・ネットワーク屋さん,
・インフラ屋さん
・インストラクターさん,
・ライターさん,
・ルーキー,
・趣味さん,
・独習者さんなど、

私は会社員、派遣、学校、趣味などを通じて、これらの幾つかを経験しています。
それぞれの立場・立ち位置から感じた敷居の高さを下げるために、
素人ならではの緩めの”1パックで学べる君”を作成して公開したくなりました。

まず、触って慣れること、継続しながら少しづつ、知識を広げ、深め、育てる喜びを感じることができて、
インターネットで公開することで、擬似実務体験ができるような内容にしたいと思っています。
一度には多くは学べないので少しずつプロのテクニックを体験積み重ねて身に着けていくことができる仕組みが大切だとも思っています。

CONCEPTWAREにはない、オリジナルの実生活で役立つ設計書を作成して利用するつもりです。
学べる君がどんな物・内容にするべきかは思案中です。
幼稚な発想からの出発なので敷居は低くなると思っています。

ですが、XEADシリーズが無料配布されていることに、答えることになっている?と勝手に思っています。

また、”それぞれのプロフェショナルが交流し学べる君”も
専門家によって作成され、世の中に誕生してくればいいなと思っています。

最後に、今一番近い位置なのは設計者さん?かなと思っています。
なので、私も設計の勉強を渡辺さんの書籍を読み込みながら続け、アウトプットの”1パックで学べる君”を世の中に誕生させようと思っています。模倣してほしいので、情報も公開する予定です。

あちこち手を広げているので時期は未定です。

以上です。

投稿: 伊藤秀樹 | 2012.06.14 07:22

おお、遠大な野望ですね。がんばってください(^^)

これまで業務システム開発の業界では、設計ノウハウやモデルライブラリの公開がまるで進みませんでした。それは、それらがSIerの秘密のノウハウだからではなく、彼らに文書化されたノウハウがないからです。そもそも設計情報の様式を確立するレベルにも至っていないから、いまだにExcel方眼紙を使い続けている。

ですから、そういうリソースは私や伊藤さんのようなモノズキたちが率先して公開しなければいけません。ひどく稚拙で先駆者としては恥ずかしい思いをするわけですが、そうでもしないとこの業界はいつまでも経済界のお荷物ですからね(><)

投稿: わたなべ | 2012.06.14 09:32

「たったひとりで踊るために」という言葉は今の時代に合った語彙ですね。ソフト会社の技術者であろうと、ユーザーのシステム部門の技術者であろうと、最少人数で息の合った踊りができる構成に導かないと生き残れないないですよ。今の日本企業では特に。
幸三さんから教わったデータモデル(今は言い方が違ってる?)。当時は訳もわからず従っていましたが、20年を経た今、この手法なしに当社情報システム部は成り立たないくらいです。思い切ったのですが、細かな仕様書は捨て去り、サブシステム単位のデータモデルとデータフローのみでドキュメントとしています。
open系(今は言い方が違ってる?)の若い設計者の方々には判ってもらえないんですよねー、これが。
時代でしょうか?もしくは、私の考えが古いのでしょうか?幸三さんの20年前の2番弟子である yosiも同意見です。haruki

投稿: 20年前の2番弟子 | 2012.08.28 00:34

若い技術者たちは、何を判ってくれないということなのでしょう。「細かな仕様書は捨て去り、サブシステム単位のデータモデルとデータフローのみでドキュメント」とするやり方を判ってくれないということでしょうか。それは私もやめたほうがいいと思う。せめて機能毎の概要仕様だけでも管理したほうがいいですよ。とりあえず、XEAD Modelerの活用をご検討ください(^^)

投稿: わたなべ | 2012.08.28 09:11

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: たったひとりで踊るために:

« 人海戦術から「おひとりさま開発」の時代へ | トップページ | フィールド数のメトリクス »