読者です 読者をやめる 読者になる 読者になる

イノベーションカフェに行って来た

DevLOVE

はじめに

DevLOVE@papandaさんから、「イノベーションカフェってモノをやりたい」っていう声に対して、あんまり何も考えずに「行きます」と手を上げて行ってみました。

内容のベースは、@papandaさんがDevLOVEのYammerにて書かれた以下の投稿です。

・これからのソフトウェア開発
・イノベーティブな組織
・ビジネスモデル(サービス、SI問わず)
を軸に、クリエイティブにディスカッションする時間を 定期的に設けたいなと思っています。
これからのSIはどこを目指すのか?
その時の開発はどうで、ビジネスモデルはどうで。 人の琴線に触れるサービスは何か?
その時の開発はどうで、ビジネスモデルはどうで。 イノベーションを生む組織とは?組織の中での活動とは?
等々。
ここでの議論を、それぞれの持場に持って帰ってもらう。 会社だったり、コミュニティだったり。こういう議論を重ねていくと、これからの時代、働き方も変わっていく 気がします。

4月20日に話したテーマは

  • 組織の課題
  • ビジネスモデルの課題

の2点。

組織の課題について

一人で出来ることは限られているし、複數の人が一緒にソフトウェア開発を行っているのがここで言う組織。でも、複數の人が集まると、必ず出てくるのが「あの人とは合わないな」という感覚。平たくいえば、「アイツのこと嫌い」。
なんだけど、結局平日の8時間以上の時間を共有するわけで、考えが合わない人ともやっとしたまま過ごしたくないのが本音。それに対して、どのようにしているのかを参加者と話し合いました。

  • 何時間か話してみて、合う・合わない人を判断する

とか、

  • そもそもそこに力を注がない。合わない人は絶対数居るはずなので、それに対して一つ一つ対処していっても時間が勿体無い。

という意見が出ました。

個人的な意見と感想

個人的には、「力を注がない」というのは新鮮な考え方と感じました。そうだよな、どうしても合う人・合わない人が出てくるんだよなと妙に納得。

ただ、合わない人とも仕事をしなくてはいけなくて、その人と仕事をするためには、どうすべきか。例えば、「プログラマが知るべき97のこと」にて、関将俊さんが記されている「ロールプレイングゲーム」がいい手ではないかと感じました。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

「だって、仕事でしょ。」って言葉がすべてを物語っていますが、プライベートでも関わるわけではないし、ゲームと考えれば、ちょっとは気が楽かも。

ビジネスモデルの課題について

次は、SIerのビジネスモデルについて、意見を交換することに。私が常々思っている

パートナにモノづくりを出して、利ざやで儲け、トラブル発生時にも結局はパートナーにモノを出すだけ。結局、モノも作れず人が多いだけのSIerってこれから先は無いんじゃねぇの?

という疑問をぶつけてみることに。

会話の中では、次のような意見が出てきました。

  • 実際にモノを作る人たちに発注すれば、目先のコストは抑えられるが、SIerのパートナーは資金体力がないところも多く、「納品まではお金払いません」という仕事は受け入れられないのが現実
  • SIerに頼むのは保険料という意味で高い金を払っているというお客さんもいる。例えば、トラブったときにも最終的には仕上げてくれるのがSIer
  • 今後、SIerがやってきたような「ソフトウェアの提供」というビジネスはパイ(市場規模)が減っていくのではないか。内製化やコストを抑える方向に持って行きたいという顧客ニーズはある。
  • 実際、大手のSIerが小さな案件を取りに行っている
  • だとすると、今後SIerレイオフが始まるのではないか。大人数でやっていく必要が特に無く、市場規模も小さくなっていくとなると、人は要らないのではないか?
個人的な意見と感想

SIerに居るものとして、未だ持って「ソフトウェアの提供」が価値の提供と考えているSIerなら、もう、この先は無いなと直感的に感じた。それが、今年なのか、来年なのか、10年後なのかは分からないけど。

ソフトウェアがもたらす価値の提供っていうとモヤッとするけど、Appleが提供しているエコシステムのようなものをこれからのSIerも提供すべき。そのためには大前提として、「ソフトウェアの提供」が確実にできるように成らなければいけない。

プロジェクトをマネジメントすることに注力してもいいんだけど、それだと大人数はいらない。自分はプロジェクトをマネジメント出来るってことに自信は全く無いので(^^;、生き残る為に行動しよう。

例えば、「実践アジャイルテスト」だったり、「ドメイン駆動設計」があったりするんだけど、それらの詳細は叉の機会に。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)


エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

長い時間話して、いろんな立場の人がそれぞれの意見を話しあえていい刺激になり、イロイロ考えました。一回で答えが出るわけではないし、どうしてもモヤッとするんだけど、それでも、考えるきっかけになって、それで明日が変われば、幸せになれると信じています。