プロマネの価値を発揮できる場所
最近、PMBOKの再勉強していたらすっかりブログの更新を怠ってました。
ちょっと前に読んだ記事ですけど、自分なりの考えを書きたいなって思ってたんですよね。
元記事はプラントの話でソフトウェア開発とは若干違うのですが、感じるところがあったのでちょっとだけ。
プロジェクトは順調で在り続けられるのか
最初から最後まで順調な仕事では、プロジェクト・マネジメントなんて、ほとんど何もすることがないはずなのだ
コレは全く疑うことがないことで、順調な局面はプロマネのすることなど何もないです。言い方を変えれば、順調な局面に抑えることができなければプロマネの忙しさはうなぎのぼりであり、ときとして過労死寸前の生活が当たり前という過酷な状況となることもしばしばです。
システム開発の現場では、何もしなくても最初から最後まで順調で在り続けられるというのはかなり難しいと感じてます。
小規模で要件も明確、誰もが同じコンセンサスで活動可能な案件であれば、最初から最後まで順調というのは難しくない反面、ちょっとでも規模が大きくなると、開発が進むにつれてアヤシイ状況が発生することもしばしばです。
こういう問題が生じるのは、案件規模が大きくなればなるほど、ステークホルダーが増えてきて、それぞれ目する「プロジェクトの目標・あり方」、つまりプロジェクトの姿が異なることにほかならないかと思います。
知的活動としてのシステム開発とプロマネ技術
では、なぜステークホルダーが増えるとプロジェクトの姿の見え方が変わるのか。
これは、システム開発が知識集約的な仕事*1だからにほかならないかと思ってます。
要は、システム開発の現場が顧客の考えた要望、アーキテクトの考えた理解、SEの考えた判断、プログラマの考えた発想といった知的活動に支えられているから。
作業手順書を作れば仕事ができるわけでもなく、また、ITやツールや機械によって自動化される仕事でもなく、人間の考えが必要な仕事だから。
で、それらの知的活動を行う人間を作り上げた経験、学習履歴といった土台が異なるがゆえに、向いている方向がバラバラになってしまうと。
そういったコンセンサスは、関わる人間が少ない小規模開発案件であれば発散しづらい反面、関わる人間が膨大となる大規模開発案件であれば、四方八方に発散してしまうと。
で、それらの人間がきちんと同じ目標に向けて活動できるようにするためには、個々人の考え、思いをきちんと整理し、動機づけを行い、組織としての活動に転換できる技術としてプロジェクトマネジメント技術が必要になるんだろうと思うわけです。
※これだけだと、プロマネ技術中のステークホルダーマネジメントだけですけど。。。
補足：SIが「労働集約」と呼ばれること
ときおり「SI産業は人月商売だから労働集約産業である」なんて言説を時折見かけるのですが。。。
他にも知識産業と呼ばれるコンサルや研究産業だって、準委任契約結べば立派な人月商売になってしまうオチなんですよね。
※「産業」ではなく「収益構造」ということなのかな。であれば理解できるんですけど。。。
元々、知識集約産業が通産省構造審議会で規定された時「知識集約型産業は労働集約型産業である」という言葉で語られてました。
要は、「知識を発揮するのが人間である以上は、労働集約に必ずなる。労働集約と知識集約産業を分けるのは単純労働か知的労働かの差である」と規定されてました。
「知識集約型産業」の言葉の定義に照らし合わせれば、受託開発は「知識労働集約型産業」となり、サービス開発は「知識資本集約型産業」と呼ぶのが正解かな。
まあ、本当にSIの現場が単純労働的な労働集約的ならば、さっさと仕事のやり方マニュアル化して、それこそ誰にでもできるような仕事にして儲かるようにできるんですけどね。
まとめ
誰しもがマニュアルに従って動く労働集約の仕事や、機械が動き続ける資本集約の仕事の中でプロマネ技術が活きることは無いでしょう。
そういった現場で必要となるのは、また別の管理技術。
繰り返しとなってしまいますが、プロジェクトマネジメント技術が価値を発揮できる局面は、「（本来の定義の）知識集約」の仕事の中でこそだと思います。
以上
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2014/02/15
- メディア: ペーパーバック
- この商品を含むブログを見る
*1:参照 ： 知識労働集約型産業としての視点から
ICTイノベーションを競う「global ICT awards」で日本企業がわりと活躍している話
「TRUE TELLER」が「世界情報サービス産業機構 IT賞」を受賞 | 野村総合研究所(NRI)
世界情報サービス産業機構（World Information Technology and Services Alliance、WITSA((Witsa | World Information Technology And Services Alliance、世界70カ国以上のITサービス業界団体により構成される国際組織」）主催の世界情報技術産業会議（WCIT）にて「global ICT awards」という賞があるのですが、6年ぶりに日本企業が受賞したとのこと。
「global ICT awards」って何？
global ICT awardsというのは、公共分野ITユーザ、民間ITユーザ、デジタル格差解消を促すITユーザ、審査員グランプリの4分野で評価されるコンテストです。
世界最大級のITサービスカンファレンスである世界情報技術産業会議（WCIT）にて、隔年で審議、投票された受賞企業が発表されてます。
ICT技術を用いて、企業の競争力、顧客満足度を高めるといったイノベーションを発揮した企業に贈られる賞となります。ITイノベーションを用いて業務革新を行っている企業を称える賞というわけです。
日本では過去4社1団体が受賞してます。
| 受賞年 | ユーザ企業・サービス | 開発ベンダー |
| 2000 | セブン-イレブン ジャパン「第5次総合情報システム」 | NRI，NECなど |
| 2004 | JR東日本「Suica」 | JR東日本情報システムなど |
| 2004 | 横須賀市 「電子入札システム」 | NTTコミュニケーションズなど |
| 2006 | KDDI 「固定系事業システムの構造改革」 | DIRなど |
| 2008 | JFEスチール 「新統合システム（J-Smile）」 | ＪＦＥシステムズ、エクサ |
NRIはベンダの立場としては、2度めの受賞となるわけですね。
日本だと業務システムを中心に受賞している感じですが、海外だと教育系ウェブサービス（ギリシャ）、クレジットカード決済サービス（カナダ）や、クラウド構築のためのアプライアンスサーバ（台湾）等で受賞していたりもします。
ユーザ企業で有名なのは、フィンランド航空やアジアエアラインなど、受賞しております。
公共機関では、電子政府や保険などを達成できた団体が受賞してます。電子政府を構築したことで有名な韓国も受賞してます。
オバマ大統領の「Open Government Initiative」が受賞してたりも。
日本は受賞数２位
毎年６～７企業、団体が受賞する「global ICT awards」ですが、2000年を初めにおおよそ５０企業、団体が受賞しております。
2014年版の受賞企業の一覧がまだ見つからなかったので、2000年から2012年までのTOP10まで集計してみると、以下のようになります。
| 順位 | 国 | 受賞数 |
| 1 | アメリカ | 9 |
| 2 | スペイン | 5 |
| 2 | 日本 | 5 |
| 4 | マレーシア | 4 |
| 4 | 香港 | 4 |
| 4 | 台湾 | 4 |
| 7 | ギリシア | 3 |
| 7 | 韓国 | 3 |
| 9 | カナダ | 2 |
| 9 | シンガポール | 2 |
| 9 | フィンランド | 2 |
ICT技術なので、ダントツのトップはいつもどおりアメリカなのですね。
ドイツやフランスといった欧州各国が少ないですね。オランダが次点としてノミネートしていた年があったので全くエントリしてないわけではなさそうですが、あまり評価されるようなシステムはないのかな。
日本はアメリカに続いての2位です（スペインと同順）。
世界的に見ても日本はICTイノベーションをトップクラスで達成できている国ってわけなんですよね。
まとめ
ITProあたりで「日本のSI構造ではイノベーションが生まれない」なんて散々言われているわけですが、実際蓋を開けて見れば、世界的に日本発のシステムがイノベーティブとして評価されているわけで。
GoogleやAmazonみたいなBtoCのわかりやすいイノベーションじゃ無いから、日本のユーザ企業とベンダのイノベーションに気づいてないだけじゃないかな。
まあ、ユーザ企業の挑戦と、SIerの技術が合わされば世界的に評価されるイノベーション生み出せるっていう証左かな、なんて思います。
余談
ただ、この話ってSIerの海外営業売上高比率が低いっていう事実と照らしあわせてみれば、「世界で評価されるイノベーションを作れる技術力はあるが、それを海外に売ることができる営業力、販路、売り方に難がある」っなるわけですよね。。。
これはこれで問題だよなあ。
以上
ITロードマップ2014年版: 情報通信技術は5年後こう変わる!
- 作者: 野村総合研究所先端ITイノベーション部
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2013/12/20
- メディア: 単行本
- この商品を含むブログ (3件) を見る
ベネッセから個人情報流出に関するお詫びの品の手紙がきた
この前書いたベネッセの件の続報です。
ベネッセからお詫びの品選択の手紙が届いた
前回のベネッセのお詫びの手紙からはや3ヶ月。
ベネッセのお詫びの品選択の手紙が届きました。
ずっと連絡が来なかったので、もしかしたら個人情報は流出してなかったのかな～みたいな淡い期待をしていたのですが、お詫びの品のご連絡が来てしまいました。。。
ま、しかたない。
気になる手紙の内容
まず気になったのは流出情報。
結局のところ流出したのは
- サービス利用者本人の名前、性別、生年月日
- 保護者、家族の名前、性別、生年月日
- 郵便番号
- 住所
- 電話番号、FAX番号
- 出産予定日（たぶん、ウィメンズパーク利用者かな）
- メールアドレス
とのこと。ダダ漏れですね。
次に気になるのははお詫びの品。
なんかニュースなどでも流れてましたが、以下のモノがお詫びの品として選択できるようになってます。
- 選べる電子マネーギフト
- 全国共通図書カード
- ベネッセこども基金への寄付
ちなみに、追加の選択肢で「個人状況を消去する」なんて選択肢もありました。
個人情報の削除対象は、ベネッセ関連の全サービス。
こどもちゃれんじだけでなく、ウィメンズパーク等のサービスの登録情報もまとめて削除するようですね。
同じ顧客マスタなのかな。。。
細かく気になったところ
気になるのは上記画像の左側。QRコードで個人識別を行っている模様。
ウェブサイト*1からも受付を行っているのですが、その「ご登録用コード」（ログインID）で紐付けるようにしているみたいですね。
さすがに、返信用ハガキに名前を書いて返信させたら、「更に個人情報ばらまく気か！」みたいな感じになるので、配慮の結果でしょう。
ウェブサイトについては、ログイン後も徹底して個人情報は表示されませんでした。じつは、登録用コードが数字だけだったため、逆ブルートフォースアタックでもやられたらまずいんじゃね？なんて思ったのですけど、そういった攻撃に対しても配慮しているみたいですね。
ちょっと気になったのは個人情報が流出した被害者が引っ越しした場合。
今回のお詫びの手紙、ウェブサイトの登録全体で個人情報を入力させないようにしてます。ということは、流出後、住所情報などが変更となった場合に反映するための手立てがないんですよね。
そもそも、お詫びの手紙自体「転送不要」で送ってきているので、引っ越しした場合は届かないわけですが。
多分、住所の所在確認を兼ねての配慮だとは思いますが、ただ、住所が変わり電話番号も変わってしまった被害者への連絡手段がなくなってしまうわけで。。。
そういった被害者に保証は不要ともで考えたのでは、と穿った見方をされそうな気もします。
※住所が変わったんだし、個人情報もリセットされたんだろ、なんて言われたら怒る人もいそうですけどね。
まとめ
今回のベネッセからの手紙を見て、ウチの奥様、個人情報流出したことを思い出した模様で、お怒りになってました。
丁度、神戸女児不明:自宅近く草むらのポリ袋に子供の切断遺体 - 毎日新聞 
まあ、「500円いらんから、流出した個人情報全部消してこい！」なんて言っても解決しようもない状況でしょうし、落とし所として仕方が無いのかもしれませんけど。。。
まあ、釈然としないモノが残るのは確かですね。
余談
以上
「価値創造契約」は対価の設定が問題では無いだろうか
以前、「納品のない受託開発」って厳しいのではみたいな記事*1を書いた都合上、上記スライドについてもコメントしておきたいな、と思います。
永和さんは新しい契約を掲げたものの、顧客獲得につながらなかったとあります。その敗因についてです。
最大のミス ユーザ企業の望む「所有から利用」の意味の取り違い
最近のシステム業界、日本も欧米でも、ITOやBPOといったシステムアウトソーシングが活況だったりして所有から利用がトレンドなのは正しいです。
ただし、ユーザが求めているのって別にシステムを所有しないことではないんですよね。
よく言われることとして、
- 費用明細の明確化
- 無駄払いの無い必要に応じた従量課金 → 固定費の削減
と言った感じで、要はコストが明確となり、無駄なコストを払ってないことがクリアになることが重要なんですよね。
AWSなどをユーザが選択する理由だって、クラウドで開発するため所有してないことではなく、需要に合わせた従量課金となることだったりするわけで。
「案件ごとの一時払い削減よりも継続的な固定費削減」の方がニーズが強いんですよね。
「受託開発」って、お客からしたら「システム開発が必要な場合に都度開発リソースが使える」と考えられている面もあり、開発リソースの「所有から利用」という観点で見られたりする場合もあるんですよね。
なので、今回の永和さんの取り組みは上記取り組みに逆行した「一時払いを減らし、固定費不明瞭化（保守と一次費用である開発の混在）」となるわけで、お客さんからしたら受け入れられづらいのは当然じゃあないかな、と思います。
開発リソースの固定費化ではなく、利用従量制へ
ほんとうの意味で、「所有から利用」を徹底するのであれば、「月額固定費」ではなく、例えば「取引量課金」や「利用アカウント課金」、「画面アクセス課金」等の課金体系であれば上手く言った可能性はあるんじゃないかな、と思います。
つまり、お客さんがビジネスでシステムをどれほど利用したのか、と言った観点で課金するわけです。
こういった契約は、SIerが提供するSaaS/ASPでは古くから見かける課金形態で、業務システムでも適応事例があります。
※とはいえ、ASPでは柔軟なカスタマイズに対応している事例も結構あったりしますが、個社システムで適応事例はさほど見たこと無いんですけどね。。。
ぶっちゃけ、前述のとおり、今の契約ってお客さんから見れば「システムの価値はそのシステムがどれだけ長く使われたかではかれる」という仮説を満たすものではなく、「開発リソースの固定費化。開発リソースの利用から所有へ」と受け止められているだろうと思うわけで、それをひっくり返せば良いと。
このような形態で契約するためには、「顧客の価値」が何なのかをきちんと理解しなければ料金設定できません。
価値創造契約をうたうのであれば、顧客の価値をきちんと掌握することは必須じゃないのかな、と思います。
※とはいえ、epsode6で業務知識がなかったと吐露されているので、ちょっと厳しいのかなと思いますが。。。
まとめ
今回のスライドで挙げられたepisodeって、ほとんどが契約後上手くいかなかった話であり、顧客を獲得できなかった理由じゃ無いんですよね。
とは言え、episodeで挙げられた事由をきちんと解消しなければ、信頼獲得の継続と契約の継続、ひいては顧客獲得の継続につながらないワケで解消することは必要なのは変わらないです。
ただ、現在のepisodeを解消しても、新規顧客獲得につなげるのは厳しいでしょう。
というわけで、色々書きましたが今回顧客が獲得できなかった最大の敗因は契約設定、課金体系設定ではないか、というのがオッサンの意見です。
お客を納得させる「システムの価値」に対する契約、料金体系を設定しないと厳しいんじゃないかなと思います。
以上
業界批判を正しく行うためには正しい資料の分析から
IT業界の『多重下請け構造』は社会悪になりつつある - paiza開発日誌
多重請負がないとされるアメリカで、流動性の高いITエンジニアの大量解雇が社会問題となり、大統領選挙の論点までなったことを知った上での意見かな？
色々突っ込みドコロがあるものの、細かくツッコむとITproの「極言暴論」への指摘とおんなじとなり、ワンパターンになってしまうので、こちらの記事オリジナルで間違っている部分を指摘。
※というか、SIerの問題点が「極言暴論」と同じなので、多分参考にしているんじゃあないだろうか。。。あの暴論をエンジニアがうのみにするのはいかがなものかと思うのですが。。。
資料はきちんと読もう
一方で経済産業省発表の「情報サービス産業の現状」によると、Webビジネス市場は2011年の11兆円から20年の47兆円まで、約4.5倍に拡大すると予測されており、Webエンジニアの人材不足は今後も加速していく事が予測されるため、そうそうに転向してしまったほうが良いかもしれません。
上記内容は、おそらく以下の資料を参考に書かれたものでしょう。
情報サービス産業の現状
http://www.meti.go.jp/committee/sankoushin/jouhoukeizai/jinzai/001_s01_00.pdf
でもね、資料の読み方が根本的に間違っている。。。
上記市場には「拡張領域」、つまり従来型企業がウェブビジネスに拡張したビジネス規模も含まれてるんですね。
例えば、小売業のネット進出であるセブンネットショッピングなども含まれており、元記事で指すWEBエンジニア企業の対象範囲は、上記の資料中のウェブネイティブ企業の領域です。2010時点では34.2％だったシェアが、43.5％へ伸びた、ということがポイント。
残り、65.8％は既存ビジネスの延長であり、SIerで構築する部分も大きい。うちでもやっているし。
つまり、元資料をきちんと読むと、ここで語りたいことは「ウェブ企業の成長は、従来のITサービス業を凌駕するほど伸びる」ということではなく「ウェブビジネスにおいて、ウェブネイティブ企業のシェアが２割増し」ぐらいに読むのが正解です。
ま、ウェブビジネスの専業であるウェブネイティブ企業が、SIerよりも伸びが小さいんであれば存在意義を問われると思うのですが。。。
上記資料より、ウェブビジネスの伸びは大きく、ウェブネイティブ企業が１６兆円相当、従来型企業が２０兆円相当の伸びを示しております。率ベースではウェブネイティブ企業の増加が多い反面、額ベースでは従来よりSIerの担当する部分はウェブネイティブ企業以上に十分成長している、結果としてSIerでもエンジニア需要が高まると読むのが自然かと思うのですが。。。
同じ理由で
それと同時に、今後ITが企業戦略の中でなくてはならい中心的役割を果たすようになっていくと、ユーザー企業内でも少なくとも元請けぐらいの能力の内製化が進むと考えられます。この流れによりSIのニーズは徐々に減っていくと考えられます。
コレも。
上記の経産省の資料でも似たような記載がありますが、元資料ではITサービス業の市場成長率を「3.0％」とよんでいるんですよね。
ガートナーなどの資料を読むとわかるのですけど、アメリカや欧州諸国、日本ではITO（ITアウトソーシング）、BPO（業務アウトソーシング）の伸びが活発です。そういった影響もあり、実際のところ市場は拡張傾向を示してます。
SIerの仕事がSI＝受託開発だけなら減少するかもしれませんが、SIerとしての仕事は拡大方向になるのが実情。
そこら辺の情報はきちんと抑えたほうが良いかと思います。
まとめ
以前、paiza記事への反論*1を書いた時も思ったのですが。。。
ちょっと、資料の参照の仕方として都合の良い部分だけを抜き出して書き過ぎじゃあないかな、と思うんですよね。
「情報サービス産業の現状」の引用もそう。自説に沿った「ウェブビジネスの拡大」は引用するものの、「ITサービス業の市場成長」については引用しないとか。
業界を変えたい、と思うなら、まずは正しい分析が行えなきゃいけないと思います。
そういった意味でも、自分の意見だけに固執するのではなく、客観的な資料の見方が必要じゃないかな。
恣意的な資料の取捨選択は、自説の信ぴょう性を損なうだけじゃあないかなと思いますよ。
以上
- 作者: 独立行政法人情報処理推進機構,IT人材白書2014の表紙
- 出版社/メーカー: 独立行政法人 情報処理推進機構
- 発売日: 2014/04/25
- メディア: 単行本
- この商品を含むブログ (1件) を見る
問題に合わせてアジャイル、ウォーターフォールを工夫することが肝要だよね
上記の記事を読んでいて少し考えるところがあったので。
SOAとウォーターフォール開発
とあるシステムの話です。
社会規模と呼ばれる様な巨大なサイズのシステムであり、そのデカイ図体を支えるためにSOA（Service Oriented Architecture）の考え方をベースとしたシステムで構築されてます。
それぞれのサービスは、サブシステムにより構築されるわけですが、サービス間の整合性や機能重複など、サービスとして効率的に開発するためには、アーキテクチャ設計をきちんと考えることが必要だったりして、トップダウン設計の色が濃い面があったりもします。きちんとしたドメイン設計を行わないと恐ろしいことになります。
で、こういった構造のシステムだったりすると複数の分散した機能を改修したりするわけで、全体整合性を保つ都合上、テストタイミングを揃えて一貫性のあるテストをしなければならない。
つまり、オッサンの経験の範囲ではあるのですが、SOA開発では、ウォーターフォール型開発をきちんと適応しないとうまくいかない場合がしばし発生するんですよね。
もうちょい言うと、ここでいうウォーターフォールも、古きよきガントチャートを使った進捗率片手にガリガリ進めるタイプ、と言うよりか、各サービスは自由に開発しながらも設計、テスト等の要所で同期を取る様なタイプになっていたりもします。
イメージにするとこんな感じ。
上記の開発手法（パラレルウォーターフォール*1）は、単一システム開発で適応するとかなり恐ろしいことになるんですけど、SOAみたいな形態だと綺麗にまとまるのが、システム開発では面白いところですね。
※まあ、業務ドメインを分割している都合上、上記のような開発スタイルを取らざるを得ないのが実情かなとは思いますが。。。
SOAとmicroservice、ウォーターフォールとアジャイル
さて、ここまで書いてふと思い出したのが、数日前見た以下の記事。
類似する技術が流行ってきた起点を考えれば、多分SIerが抱える問題と同じような問題にウェブ業界の世界もぶつかったんだろうな、と思ってます。
さて、ここで元記事の話に戻るのですが。。。
ところで、SOAってSIerでは枯れてきた技術ではあるわけで、発生した問題についてもある程度見えたりもしてます。
前述のような、全体整合性を保つアーキテクチャ設計やテストが必要なため、ウォーターフォールが見直された、みたいな話もそう。
ということは、microservicesはSOAと類似した部分も多いことから、開発の中で抱える問題も似たようなものが今後発生するんじゃないのかな、なんて思うわけです。
つまり、microservicesの現場でも、ウォーターフォールも見直されるのだろうか？microservicesが巨大化したシステム、サービスを効率的に開発するために必要とされた背景で導入されたのであれば、SOAと同じくウォーターフォールが必要な場面が出てくるんじゃないだろうか？あるいは、ウォーターフォールと類似の概念が異なる言葉で語られるようになるのではないか？なんて思うわけです。
今回の記事を見て、ふと上記のような感想を思い出したわけです。
オマケ１：microservicesとSOAの相似性
上記の記事を含めて、microservicesが語られるとき、SOAとは違う、みたいな記載がありますけど。。。
実装例を見るに、10年以上前に構築された事例だとSOAミドルウェアを使わずに、MQとAPI（SOAPやWSDLなど）だけでESB作ってSOA構築するなんて構築例ありますし。メーカ系SIer以外では、自前で作る例が結構あるんじゃあないのかな。
SOAって実装例、開発方法が様々なんですよね。なので、構造や組織論などの枝葉を見ると同じだ、違うって話が出やすいんでしょう。
実際 Microservices にあるmicroservicesアーキテクチャの特徴をみるに、SOA型のシステムのうち、重厚なミドルウェアが売り出される前にSIerオリジナル技術で構築されたSOAが備える特徴と一致しているのですね。アーキテクチャだけでなく、開発スタイルみたいな組織論としても、この手のSIerでは、独立したサービスを独立したチームが開発するみたいな感じの開発スタイルを取っており、一致してたりもするわけで。
SIerでもエンプラシステムが肥大化しすぎた結果、解決方法として分散型のアーキテクチャが必要となった背景より、上記のようなSOAを導入した経緯があります。
問題が似ていれば解決方法も似てくるわけで、SIerかWEB系か起点が違うだけの収斂進化みたいなもんだと思ってます。
オマケ２：SOA後のエンプラ技術の進化
SOAが導入されると、SIerでもより効率的な開発を目指して工夫を追加したりするんですよね。
例えば、従来型の３層アーキテクチャだと開発しづらい場面があるので、プレゼンテーション層、フロントアプリケーション層、データベース層にバックアプリケーション層、データバス層を追加した５層アーキテクチャに変えてみたりとか。
こういった技術についても、そのうち広がっていくか、もしくはSIerは技術情報をあまりオープンしないので、前述のように収斂進化の形で開発されるんじゃないかな、なんて思ってます。
違う方向に進化したら面白いので、引き続き技術動向は追っていきたいな、なんて思ってますね。
まとめ
まあ、だらだらと書きましたが、結局のところ、技術って問題を解決するための手段であり、類似する問題があれば類似した技術が必要になるってのが重要なんじゃないかなと思います。
前記とは視点を変えてみると、SOAにより分割された小ドメインのオンライン中心のサービスは、特定業務ドメインに特化した小さなモノリシックなWEBシステムと見ることもできるわけで、そういったシステム特性があるのであればアジャイルが楽となる場面も多い。
そういった点では、以前の記事*2で紹介したハイブリッドアジャイルみたいな、ウォーターフォールとアジャイルの良いと取りを目指した開発手法などが有効だったりもする場面も多いです。
※オッサンも愛用してます。
というわけで、一番重要なことは何かといえば、問題に合わせてありとあらゆる工夫することが肝要だろうなあと思うわけです。
以上
SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針
- 作者: カール・バンク,ディルク・スラマ,山下眞澄,ディルク・クラフツィック
- 出版社/メーカー: 日経BP社
- 発売日: 2005/11/23
- メディア: 単行本
- 購入: 4人 クリック: 37回
- この商品を含むブログ (22件) を見る
excel業務管理ツールの使いどころ
エクセルをデータベースとして使うには、こうすればいいと思うのだけど、なぜ誰もやらないのかな？ - Excel 職人のつぶやき
いや～、面白かったです。
excelで業務ツール作る例は結構ありますけど、ここまで徹底しているのは昨今見かけなかったので興味深く見てましたね。さすがのexcel職人さんですね。
業務規模とexcelツール
昔似たような記事*1でも触れてましたが、excelって本格的な業務システムを導入するまでの簡易な業務ツールとして利用すること結構あるんですよね。
個人的な経験ですけど、ある程度の規模まではexcelツールで業務がまかなえる反面、ある程度の規模となるとexcelの業務ツールではおっつかなくなり、本格的な基幹システムが必要になる事例をよく見かけます。
大まかには
- excelツール ： 1～数名程度の人がデータを管理し、他の人は参照する業務
- スタンドアロンの部門基幹システム ： 受発注業務などで多数の人がデータを作成、更新、参照する業務
- 全社基幹システム ： 受発注業務や会計業務などの業務を全社で結合し、タイムリーな意思決定が必要な規模の業務
みたいな感じで、要は業務の管理者の目が届く範囲により必要となる業務ツールが変わっているイメージですね。
元の記事でも中小企業向けと記載がありますけど、
ワークシートのサイズは、最大1,048,576 行、16,384 列なので、どんなに増えても大丈夫です。 しかし、取扱うデータ量としては１万件以下のデータだと思います。
まあ確かに１万件超のデータ、日に50件超のデータを扱うのであれば、更新や参照で利用者間のコリジョンが発生して使いづらくなってくるかと思います。
ある程度、企業として成長したらexcelツールは卒業し、基幹システムの導入を検討したほうがいいんじゃないかな、と思われます。
excelツールはセキュリティに注意
ところで、excelツールって便利なんですけど、使い方には注意が必要です。
基幹系システムみたいにデータと機能が分離されているシステムと異なり、excelツールはデータと機能が一体化してしまってます。
ということは、気をつけないとカンタンに情報流出を招いしてしまうんですね。
excelツールは、セキュリティ脆弱性の原因になりかねないんです。
お客さんへダイレクトメールを送るために作成した差し込み印刷のexcelツールを営業員に配布したら、ツールごとお客さんデータを名簿屋に売却された、なんてなったらたまったもんじゃあないですし。
なので、ある程度の規模の企業ではこれらのexcelなどを利用した勝手ツール（EUC:End User Computing）を統制する場合もあるので注意が必要かと。
まとめ
まあ、ブコメ欄なんかみると、excelのツールと聞いて身構える人も結構いるかと思いますが、上記のように業務規模と使い方次第ではアリじゃないかな、と思います。
とはいえ、セキュリティや更新時の衝突の問題など、多人数が利用する場合にexcelツールは使い勝手が低下するので、あくまで簡易ツール、サポートツールと割り切るのがいいんじゃあないかなと。
結局は、excelもハサミも使いようってわけですね。
以上
できる Excel データベース データ活用・業務効率化に役立つ本 2013/2010/2007対応 (できるシリーズ)
- 作者: 早坂清志,できるシリーズ編集部
- 出版社/メーカー: インプレス
- 発売日: 2014/08/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
