システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?
を読んだので書くことにした。
8/27のイベントに先立ち、事前に自分の頭の中を整理しておきましょうって感じで。
もう1本目の記事はこっち。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル - 部屋とアジャイルと私(仮称)
最近、SIビジネスが曲がり角に来ている話題はなかなかホットトピックスで、自分自身もSIビジネスに携わるものとして、また新しい価値を生み出すITサービスを実現するためにも、この話題はとても興味深いところ。
「SIの闇」に光を当てたい!
システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?
- 作者: 斎藤昌義
- 出版社/メーカー: 技術評論社
- 発売日: 2014/06/05
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
ビジネス環境変化に対して「SIビジネスも変わらなきゃいけない」理由から、では「具体的にどういうアクションが重要か」という提案までが、読みやすく簡潔にまとまっていたと感じる。特に、「変わらなきゃいけないけど、でもどうやって・・・」と認識している人を対象にしている印象。
終盤に書かれている、既存SIを進めながら新しいSI事業(文中は"ポストSIビジネス"と表現)を作り上げる、部分については、同じことを考えている人は多いはず。顧客(情報システム部門とかの発注側)とSIer(ベンダーなど受注側)の両視点で整理されており、SIビジネスの「創造的破壊」を起こす側に向けたメッセージと言えよう。(この議論を発展させると、市場のIT利用者(ユーザー)の視点ももっと加えていく必要あり!)
このポストSIビジネスを成功させるためには以下の5つシフトが必要とのこと。(各論の感想は後述)
サービスビジネス
クラウドビジネス
OSS活用
グローバル対応
新しい存在意義・新しい役割
それぞれのテーマがとても深い話題であるが、SIビジネス全体を俯瞰して整理し「では、どうするか?」のきっかけになる良書であろう。次のSIビジネスにチャレンジしたいと思っている仲間や上司にも薦めたい。
なお、1点だけ違和感を感じたのは、事例に出てきた方の言葉かもしれないが「受託開発が嫌い」「受託開発を止める」など、労働集約的工数積算モデルと受注開発を同義に書いてあった部分。従来多かった一点モノ(フルオーダーメイド)のシステム開発は無くなったとしても、企業の競争力の源泉(つまり他社との差別化)にITを有効活用することが今まで以上に求められているので。
※んー、まー、言葉の問題かなー
1.サービスビジネスの例が3つ紹介されている(月額定額モデルとしてソニックガーデン「納品のない受託開発」、レベニューシェア(成功報酬型)として日本ユニシス、取引量に応じた月額金額としてNTTデータのANA基幹システム)。初期投資を押さえての月額支払(定額もしくは変動)は、発注側と受注側の関係性を変え、Win-Winに向かいやすいだろう。
2.クラウド利用への流れは止まらないことも、月額支払モデルを後押ししているため、クラウドが一括請負を淘汰していく流れと言えよう。クラウドサービスは層構造で成り立つので、SIerはどのレベルのサービスを誰に提供するか、が重要。
3.OSS活用も止まらない流れ。OSSに関連する技術者は会社を超えたコミュニティに積極的に出ていった方がよいし、実際にインターネット上で情報発信することを奨励している会社は増えてきている。とはいいつつ、Githubひとつとってもハードルに感じるところはまだまだ多いだろう。
4.グローバル化について、日本と欧米の文化の違いの話は外せない。ITサービス展開のグローバル化と組織や開発チームのグローバル化は分けて掘り下げる必要あり。後者については人材流動性(横のキャリアパス)のジレンマ・・・
5.SIビジネス事業者が、顧客のCIOになれ的発想は大賛成。アジャイル開発の本質は「全部を作らないこと」というのはソニックガーデン倉貫氏と同じ主張。また、アジャイルは開発手法ではなく「働き方」というのも、自分の中では納得できた言葉であった。
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
今現在、既存SIで人が足りない・足りないという話を身近でも聞く。従来型の労働集約的なSIを明日から捨てることはあり得ない。放っといてもSIビジネスはある程度緩やかに変わるだろう。でも、生き残るのは変化する市場に対応して変われた組織であり、変われた人たちだけであろう。今、自分は、そのことにチャレンジできる環境に居る。
8/27のイベントが更に楽しみになった。著者である斎藤昌義氏とはお会いしたことがないが、この「システム・インテグレーション」について、とても熱い想いをビジビジ感じ、読む前よりもいっそう、直接話をお聞きしてみたくなった!
受託開発ビジネスはどうなるのか、どうすべきか | Peatix
・
・
・
あ!
「納品をなくせばうまくいく」はまだブログに書いてなかった!(´・ω・`)
書いたつもりになってた自分・・・orz
転職おめでとう!
酒飲んだ後ブログ書くのは初めてか?
ま、書きたくて仕方ないので、書くことにする。結構個人的な想い満載だが、それほど本当に今宵は嬉しい夜だったから。
同士が転職すると、さっき聞いた。
失礼ながらちょっと意外だったが、でも本人が自分の実力を試したい環境を見つけられたことはとてもいいことで、素直に嬉しい。目の前を考えると同士が辞めるというのは寂しいけど、これは健全なことだし、そういう判断を出来た同士をオレは尊敬する。
オレは新卒からとあるSIerにずーっといる訳で、去年ぐらいから、社外に出ての活動を本格化させ、ブログもはじめ、twitterもちゃんと見るようになり、有志のアジャイル系社内コミュニティがちょうど1周年になるいま、このタイミングだったから余計に衝撃も大きい訳だが、正直な話。
でも、オレは会社に雇われているけど飼われている訳ではないし、SI崩壊とかSIの闇が騒がれる今だからこそ、オレは今の環境でチャレンジしたいことがある。ディフェンシブという言葉がぴったりなSIビジネスだが、受託開発の喜びは言葉にできない素晴らしいものだし、だからこそ今の環境を変える試みに引き続きチャレンジし続けたいとおもっている。その同士だった親友が自分の人生の岐路を判断して新しい道に進むことは素晴らしいことで、お世辞でもなくオレは応援している。
「夢」を叶えるのは会社というステージではなくで、「人生」というステージの上である!!
俺の中で いっしょに仕事してみたいマネージャ一位は10年前から変わらず @ryohei_nakazawa だ。その機会がないのが残念でならない。 / @ryohei_nakazawa: チームメンバが活き活きしている、あの感動を思い出した
#natsumiB3
— ますごん (@ymasuda_) 2014, 8月 1
だから、お互いの環境は変わっても、「夢」の実現はできる。
そうだろ?
一緒に仕事をすることもその「夢」の一部かな〜
嬉しい言葉をありがとう。
お互い頑張ろう(・∀・)!!
夏サミ2014に行ってきました!
※講演資料やまとめへのリンク先を更新(2014/8/2)
今日は月末恒例、パケット上限での帯域制限を喰らっている日。こんな日はwifi環境が整備されているところがマジデ天国デス!!(・∀・) 東京五輪といわず、wifi充実はもっともっと加速度的に進んでほしいな。
さて、今日は久しぶりに御茶ノ水に行ってきました。
初めての夏サミ参加でテンション真夏。
Developers Summit 2014 Summer [Enterprise] #natsumi
SI終末論を良く耳にする今日この頃。
この問題は長らく言われ続けていて、アジャイル開発とともにユーザー企業の内製化は進み、クラウドの普及で自前システム不要からの情報システム部門不要や、納品のない受託開発の成功とか、色々な話がごった煮で如何せん整理するのが大変。
でも、次のSIの形を模索する自分としては、得るもの多く、とても刺激になる話が多かった1日でした。
今日の一番の収穫は、受託開発ならではの「喜び」に気付き直せたこと。
これは、[B-3]セッションGxP・商工リサーチの事例、および[B-5]セッション倉貫さんのお話がメインから。
商工リサーチの300人月の再構築では、8割ウォーターフォールで作って、残り2割をアジャイル型でテスト・改善の繰り返しという進め方で成功したということだが、(GxPの鈴木さん・和智さんが)プレゼン内容でフォーカスしていたのは、受託開発として最も基本的な顧客とSIerの「信頼関係」部分。確かに、顧客と二人三脚でプロジェクトを進めるってSIer側としては理想的で、本当にそれが出来た(お客さんが認めてくれた)時の喜びは、言葉にできないぐらい感動的なもの。
倉貫さんは「納品の無い受託開発」のダイジェスト話の中で、ネタを振りまきながらソフトウェア開発がナレッジワークであることや働くエンジニアの満足度を大事にしながら、その上で、顧客から信頼してもらえて仕事が続くという受託開発ならではの「喜び」に言及されていた。倉貫さんの初リアルプレゼン、沢山笑わせて頂きました(・∀・)
この2点は、顧客向けの受託開発プロジェクトを少し離れている自分に、大切なものを思い出させてくれた。共通するのは顧客とシステムサイドが同じ目的を目指している形。これらの話を聞いてて、自分の中では、いくつかのプロジェクトの場面がスナップショット的にリフレイン。お客さんと一緒にリリースを喜び、道玄坂を転げ落ちてスーツを破いたあの日や、納品日のチーム解散のふりかえりで、メンバ12人とお互い涙を流したあの日とか、色々なシーンがリアルに甦ってきて、1人で遠い眼をしてしまった・・・
技術がどんどん進歩し、新しいビジネスモデルができたり、働く場所がオフィスだけでなくなったり、仲間との国境がなくなったり・・・・そんな劇的な変化が起きている今だからこそ、B2Cでグロースハックもいいけど、「人と人」が「感動」できる『受託開発』はやっぱりいいな、と。
SIの形が変わっても、この「喜び」は変わらないのではないでしょうか。
とても大きなヒントを頂きました。
あ、あと、世間様からSIerは「業者さん』って呼ばれないようにもっと変わりたいぞ
[B-1]のKDDIの話は聞けずに残念。でも色んな方のTweetに感謝。まとめでみてます。
夏サミ2014【B-1】KDDIのAgile&DevOpsへの挑戦と戦果 #natsumiB1 - Togetterまとめ
あと、Twitterやブログで知っている有名な方々と名刺交換とかご挨拶できたのも、本日の収穫♪♪♪
SNSやブログでも今後ともヨロシクお願いしますm(_ _)m
これは、モノにつられて・・・頂いちゃった本。パクえ吉田さんありがとうございます! もっと勉強しますw
しかし、中指が使えないと、タイピングが遅くてイライラ・・・ しかも包帯グルグルだから、タッチパッドでのスクロールが人差し指と薬指は厳ちぃぃぃorz
明日の仕事が思いやられるわ😭
・講演資料とTogetterまとめ
エンタープライズIT版のデブサミ「夏サミ2014」開催、講演関連資料のまとめ:CodeZine
・参加した他の方の記事・ブログ
夏サミ2014で確認したユーザー企業と開発ベンダーの姿 #devsumi #natsumi #natsumiB1 #natsumiB3
夏サミ 2014 『KDDIのAgile&DevOpsへの挑戦と戦果』聴講メモ #natsumi - べにやまぶろぐ
Agile Conference Tokyo 2014 に行ってきた!!
梅雨明け、そして熱帯夜・・・ (;´∀`)フゥ
皆様いかがお過ごしですか?(;´∀`)フゥ
先日久しぶりに外部セミナーに行ってきました。品川シーサイドは1年ぶりかな。しかし、朝から疲れた〜 あの通勤ピーク帯、ここのたった一駅移動で消耗するHPはマジ計り知れず・・・なんか去年よりも人が更に増えたような・・・(;´Д`)フゥ
※ってこの写真、全然人がいないやん!!
先月のAgile Japan は残念ながら業務で行けなかったのですが、今回は抽選に当たって(?)行くことができました。
Agile Conference Tokyo 2014という、テクノロジックアート社主催。
去年は「KANBAN」がテーマで、今年は「継続的デリバリーとDevOps」がテーマ。
特にThoughtWorks社のお二人の話が面白かった!
1.エンタープライズDevOps: 開発とIT運用間の障壁を取り除くには
ー Jez Humble氏 (ThoughtWorks Inc.)
2.アジャイルなプロダクト計画策定と分析手法
ー 藤井 拓氏 (株式会社 オージス総研)
3.アジャイル開発を支えるコード品質とリスク解析
ー JUNG Sang Hun氏 (コベリティジャパン 株式会社)
4.Thoughtworks社による海外導入事例
ー Xiaoshen Wang氏 (ThoughtWorks Inc.)
5.継続的デリバリーの実現へ!
ー 江木 典之氏 (日本IBM)
ー 英 繁雄氏 (日立ソリューションズ)
ー 岡下 浩明氏 (RedHat)
- DevOpsの言葉の定義が大分、広義になってきたようである。ソフトウェアの開発と運用の障壁を取っ払っていきましょいって元々言っていたが(狭義のDevOps)、ビジネスとITの融合まで含んでDevOpsという言い方をほとんどの人がしていた。ま、確かにそれはそうなんだけど、コンテキストによってさす範囲の意味が変わってくるから気をつけないとね。(※後述)
- オーストラリアの保険会社における分散アジャイル開発(thoughtworks事例)は、ソフトウェア開発の事例というよりも、業務とITの融合を含めた新しいビジネス創出の事例。例えば、スーパーマーケットでバーコードをスマホでスキャンし、その場でPayしてレジに並ぶ必要がないアイディアとか、あ、これは保険会社の商品ではないか。言葉は違えどリーンスタートアップの思想に考え方は近い。ITでマーケティングの常識が変わってきた話とも取れた。
- Jez Humble氏(Continuous Deliveryの著者)曰く、アジャイル開発はまだまだ、ウォーター・スクラム・フォール開発である、との認識のようだ。つまり、本質的なアジャイル開発はまだまだってこと?
- 継続的デリバリーはCI等の自動化必須だが、それは作業効率化だけでなく、どれだけ効果的に学べるか(Feedbackを受けることができるか)に繋がってくる。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (51件) を見る
今日のテーマはDevOps(と継続的デリバリー)。そもそもDevOpsってなんだっけ?
前にも書いたように「アジャイル」って言葉も同じことが言えるのだが、「アジャイル開発」がだんだん、ビジネスや経営レベルを含めた広義な意味でもつかわれるようになったように、DevOpsにも同じことが言えるというのが、今日、複数の登壇者に共通していえることのひとつ。
つまり、開発だけでなくて、運用も含めて、(DevelopmentとOperationの)障壁を無くしてうまくやりましょって狭義のDevOpsが、ITと製品戦略・マーケティングとビジネスモデルそのもの全部をうまく回していきましょって広義になってきたってことを再認識した訳です。
ん?それってリーンスタートアップじゃん?って言う人がいても同じで、結局、「広義のアジャイル」「広義のDevOps」「リーンスタートアップ」の意味することが近づいてきちゃって、人によってはますます混乱する・・・的な。
プログラマのためのリーン・スタートアップ入門(最終回):リーン・スタートアップの実践――ソニックガーデンは2度ピボットした - @IT
にもあるとおり、
リーンスタートアップ = マーケティング + DevOps(開発はアジャイル)
という整理が一番しっくりくるので良いのですが、この辺の言葉の定義の境目がもう曖昧になってきたってことですね!
今回のセミナーでもそうでしたが、自動テスト〜継続的インテグレーション〜継続的デリバリーをまとめている絵がいろいろありますが、どれも間違っていないとはおもうのですが、まとめる人の意図によって(若干)異なる。当然。
DevOps、アジャイル、リーンスタートアップ・・・同じ視点に立てばどれも考え方は共通であるため、そのベースを共有した上で、議論すれば言葉に惑わされることはないかな、なんて思いました。
あ、今月は夏サミにもいけそう♪( ^ω^)ワクワク
(おまけ)
会場で質問できなかったので、Jez Humble氏にTwitterで質問したら、凄いスピードでレスが帰ってきたw
Feedbackが早いって素敵☆
アジャイルって何だ? 〜今だからもう一度整理し直してみる〜
[2014/5/29]スライド内の誤字を修正し再UP、一部追記
1ヶ月ぶりの投稿です・・・
サボり癖がついてしまうとホント悪循環。この1ヶ月間、書きかけた記事3本(未だ編集中)。これは本当にいかん!
よし、言い訳はしない。
「今回こそは!」必ず書き切る。
今日のテーマは、「アジャイル」「Agile」という言葉・単語・keyword。
自分が初めて「アジャイル開発」を知って、たぶん10年ちょっとが過ぎた。
最初はXPのプラクティスやプロジェクトファシリテーション的なことを、自チームに取り込んでみたり、であったが、当時社内(自チーム外)でアジャイルの話をすることは殆どなかった(ような気がする)。
時は経ち、「アジャイル開発」はソフトウェア製品開発では当たり前となり、2、3年前ぐらいから徐々に、企業向け大規模SIの領域にも「アジャイル」は徐々に浸透してきた。そして最近では、結局「アジャイル」って何なの?という声を良く聞くようになってきた。昨年「アジャイル」と銘打つ社内コミュニティを立ち上げたことも影響あるのかもしれない。
特に今、自分は、「アジャイル」を整理して説明することが求められているケースが増えつつある。
確かに、記事タイトルやプレゼン資料で踊る「アジャイル」「Agile」というkeywordにはいろいろな意味が含まれている。
客観的に見ながら結局、何なの?という意見が出るのも分かる。
そんな今だからこそ、自分なりに整理してみる必要を感じた。
整理すると2つの軸がある。よこ軸とたて軸。
絵にするとこんな感じ。
ざっくり言うと・・・
[よこ軸]
アジャイル開発におけるコミュニケーション面とエンジニアリング面
これはシステム開発・ソフトウェア開発のシーンにおいて、分野が異なる。しかも「アジャイル開発」とは言わず「アジャイル」と言うことが多いので、次の縦軸を踏まえると、聞き手によっては混乱を招くことがある。
[たて軸]
変化の中で継続的に成長するという、ビジネスの本質的な側面
これはレイヤーが異なる。マーケティング的な意味も含めた組織活動そのもの、と、(プロジェクト・チームの)開発活動に限定した使い方である。後者(a)についてのみ、よこ軸がある。
「グロースハッカー」に象徴される、昨今のビジネス成果とエンジニアリングを密接に考えなければいけない傾向が、このレイヤーの混乱も招くことがある。
ちなみに、これは平鍋氏の言うアジャイルのライトウィング・レフトウィングにも繋がっている。というかヒントにさせていただいた。パクリとも言う。(しかし、この整理は素晴らしい!!初めて見たときマジ感動した!!)
[2014/5/29]追記
それからアジャイル開発とフォーターフォール開発の違いについては倉貫氏がblogで分かりやすく解説されている。
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
以下、先日の勉強会で発表した資料。
[2014/5/29]スライド内の誤字を修正し再UP
個別のプラクティスをさして「アジャイル」とも呼ぶし、もっと広い範囲で「アジャイル」と呼ぶこともあり、その意味はコンテキストによって微妙に変わってくる。
想像してほしい。コミュニケーション上で、お互いの認識がkeywordレベルで噛み合っていないときほど、辛いことが多くないだろうか。
おそらく、そんな時の会話では、言葉の意味する範囲を自分の都合のいいように変えながら話していることが多いのではないだろうか。(自戒を込めて・・・)
しかし、言葉の定義という意味では、そんなものなのかもしれない。
新しい言葉というのはどれもそういう側面を持っているし、新しければ新しいほど、keywordの定義も発展途上であることがおおく、このような整理を都度都度繰り返していかなければいけないだろう。
投資家、経営陣、コンシュマー・・・。
お金をPayする人が「アジャイル」「Agile」を理解しているとは限らない。むしろ、このような方の専門はシステム開発・ソフトウェア開発ではないことが多い。投資してもらうためにも説明責任はこちらにある。説明して納得してもらえなければ、どんなに素晴らしいチャレンジでも投資してもらえないのだから・・・
よし、書き切ったwww
第4回Quesにいってきた
オバマ大領領を接待となると、銀座の寿司屋も三ツ星なのですね。うらやま。
さてさて今回は、初めてTwitterで誘われたイベントに行ってきました。
その名も第4回Ques(イケテルQAエンジニアの集い)@渋谷ヒカリエDeNA社。
@ryohei_nakazawa はじめましてQues運営スタッフです。4/22に第4回開催決定いたしましたので、是非ご参加おまちしています! http://t.co/yn2Fx0e31M
— イケテルQAエンジニアの集い Ques (@Ques_staff) March 14, 2014
なんてお誘い頂いちゃったり。
中の方、ありがとうございました!
現在の業務が、ソフトウェアの品質保証にモロ近いところにいるということから、自分がイケテルかどうか確認しにいったのですが・・・
自分があの集まりでおそらく唯一のネクタイキャラだったため、ある意味、イケテなかったかもorz
確かに自分は、ちょっと前までQAとQCの違いを人に説明することもできず、基本的にはプロセスベースの品質保証の方がメインなので、ちょっと場違いな感も。
でも、面白い話が沢山聞けて、交流会でも普段お会いできない方々と情報交換できて、大満足♪♪♪
テーマ:テスト自動化について
講演内容:●機械学習分野におけるテストの自動化(小宮氏、ALBERT)
■機械学習分野におけるテストの自動化
・機械学習の応用例としては、AmazonのReccomendやスパムメールフィルタリング。
・機械学習アルゴリズムのアプトプット(テスト結果)が期待する結果と同じかどうかを検証するのが難しい。(=期待する結果を定義しにくい)
→ codeレベルのテストの重要性
・レイヤーに分けてテストするとか、機械学習機能ソフトとはいえ、普通のソフトウェアのテストと考え方は通じるところ多し。
→ 機械学習アルゴリズムの検証と、ビジネスロジック検証、End2Endでの機能検証を分けて考えるとか
・自分が目指すのはデータサイエンティストではないものの、そっち系の勉強がまだまだ足りないな
■ Mobageオープンプラットフォームでのテスト自動化
・SoftWare Engineer in Testを略してSWET
・SWETグループは、組織として独立したテスト専門部隊(googleのSET+TEイメージ)
・SWETグループの技術者は各プロジェクトに散って入り込んでいて、朝はプロジェクトのスタンドアップ、昼はSWETのスタンドアップ
・テストを自動化しても、機能が増えれば増えるほどテストコードも増えてくる。そこでCI。
・Webブラウザとスマホブラウザの両方(マルチプラットフォーム)を同じようにテストするため、SeleniumとAppiumを利用し(テストコードの共通化が結構できる)、テスト自動化を実現。
・実機でのテストと、実機レステストは使い分ける。
・SWETグループのモチベーションを保つための工夫。自分たちはエンジニアである。テストをすることが目的ではない。テストはあくまで手段。リリースし続けることに自分たちの価値があるなど。
最後に。
技術的な話にはだいぶついていけていなかった自分ですが、自分の知っているQAの世界よりも相当広い感じだなーっていうのが一番印象深かったです。
でも、例えばWebサービスに代表される開発がアジャイル的なソフトウェアの品質をどうやって保証(担保)するか、これはとっても大事なテーマであることはわかってるつもり。
第5回もあったら行きたいな〜〜〜(・∀・)
「失敗の本質」を読んで共有・議論してみた
今日の夜は、毎月開催している社内勉強会。
実はMacbook Airでのプレゼンデビュー♪♪♪
いままで自分が知らなかっただけなのですが、keynote(OfficeパワポのMac標準版)のスライドショー機能がホント感動的。単に手元で次スライドも見えて、かつ時間が表示されてるだけなのですが・・・
今回のお題は2つ。後者が自分発表。
・ スクラムの起原を追う「失敗の本質」より
そういえば、結果的にみごとアジャイルのライトウィングとレフトウィングになってるじゃないですかwww
いつもに増して、議論は多方面かつノンストップに盛り上がり・・・
まずは発表したスライド。
ちなみに、本を読んだ直後のblogはこちらで、それを共有用にまとめた感じ。
失敗の本質―日本軍の組織論的研究 - 部屋とアジャイルと私(仮称)
結構みんな食い付きがよく、議論も白熱。
「沈黙は美」とか「あうんの呼吸」とか「水に流す」とか日本人独特のでも脈々と遺伝子に刷り込まれているような文化的に思い当たる節がみんなある模様。たとえば、知識よりも経験ベースで物事を判断しがちで、システム保守プロジェクトなどのドキュメント化もされない秘伝のノウハウが脈々と受け継がれるか、本当にあるある。
ナレッジマネジメントの重要性はは組織の経営側はどこも感じることだろうし、でも知識の集約と再利用には、どこも悩みを抱えていると仮定して、その理由は当時の日本軍にも日本の企業組織にも共通しているという視点は、いろいろと視野を広げる。
ただ、
今回だけの話では、アジャイル開発におけるスクラムとのつながりにはたどり着かず、その点は、自分も含めて消化不要。
今後の継続テーマでもある。
そういえば、今回に限らず、グローバル化というキーワードはいつでもでてくるのだが、その中ではよく「日本と諸外国の違い」が話題に出る。具体的な違いを単純化するのは難しいが、ビジネスとITの今後を考えるうえで、日本の文化や特徴を勉強することはとても価値があるとおもう。
というか、
自分が歴史(特に日本史)大好き人間なだけかもしれないがwww
しかし、また読みたい本がまた増えて、読むペースが追いつかない・・・orz