エンジニアの未来サミットの斜め読み雑感
ちゃんと書くものないとただのアホになってしまうので。
でもあんまり推敲せずに勢いで書いてみる。
第二部について
省略。ほんとに情報不足。楽しそうな雰囲気は作ってたのだろうと思う。
賛否あるにせよ、楽しい雰囲気があるところにはある、というのはいいこと。
第一部のパネリストについて
事の発端としてはSI事業系の話が問題ぽいと思われるので、そういう意味では
メンバーは豪華だけどもベクトルが違うのではないか？と思えた。
その「泥」みたいな話に火がついているのは多重下請け構造の話になるはずで、
その話には進んでいたようだけど、それなら話す面子がちょっと違うんでない？
という。じゃあ誰が出ればよかったのか？具体名挙げてっていうと一部難しい
けど、例えば…
平鍋さん(永和システムマネジメント/チェンジビジョン)
倉貫さん(TIS)
公共系のマネジメントしてる方(NTTデータあたり)
金融・証券系のマネジメントしてる方(NRIあたり)
ひがさん
みたいな構成もありだったんじゃないのかな、とか。
学生さんに向けてという趣旨っぽいけど、プログラマは自己責任だ、仕事がつ
まらなきゃOSSに参加しようみたいな話って現場にいる人に向けてじゃないと
なんとなくぽかん、な気がするし、かつ本来そういう呼びかけとか、今この
時点で泥にまみれてというかデスマってる人たちに向けてだと思う。で、そん
な状態の人ってこういうの見たりも聞いたりもしてる余裕ないし。
アジャイル/XP系のコミュニティもリーチしたい、するべきなのはこういうと
こなんだろうけど、変えていくためにはトップダウンで押し切るか、じわじわ
とカイゼンさせていくか…みたいな。
どんな話だったらよかったのか
具体的な実情を話すしかなく。
まずSIの業界で残念なことは
・事例を話しづらい
この一点。ぼかして話すと全部汎化してしまってそんなabstract classなんざ
耳たこだぜって話になる。個別の愚痴/厳しさの吐露は2chのマ板とかにあふれ
ていた。今も？
ではなぜ話せないのか？
昔は交流というものがさほど意識されていなかった？今だとNDAがあるから。
あくまで本業の下支えのためと、コスト意識からその作業自体を分社化する
という流れのために、システム開発というものだけを仕事にする会社が生ま
れて現在に至るのが大筋の流れ。
本社業務の紹介とそれを下支えするシステムのご紹介、なんていうのがどれ
ほどあったのか。技術そのものとか、システム構築のノウハウなんてものは
社内/グループ標準の中に脈々とためこまれていて、大掛かりな変更という
のはなかなかされにくい。
最近だと自社サービスをやっているところは、それ自体の営業にもなるし、
技術力のアピールにもなるから発表しやすい土壌がある。
受託開発だと先方の業務自体を紹介していい/悪いがあるため、そういう
部分にも積極的に出してくれるところでないと発表それ自体が難しい。
例えばリクルートはLinux World EXPOで検索エンジンLucene/Solrを導入
した事例について発表をしていた。Luceneの導入については自身がコミッタ
でもあるロンウイットの関口さんが解説をされていたけれど、こういう形
をSIの事業紹介で出来るといいかもしれない。
でも裏方業務を紹介してうちの会社の事務処理が楽になりました、っていう
発表が出来るところってあるだろうか？それ聞いていいね、って思えるか
というところは疑問が残るかもしれない。
また、ものによってはビジネスプロセスの公開になってしまうため、それを
嫌うクライアントもいるかもしれない。
というところから、SIというものはこうまとめられるかもしれない。
システム開発とはあるビジネスプランを実行するための一連のプロダクトの提供行為である。
したがって、その内情はビジネスプランに直結するため、競争原理に即すと
非公開にしたいという欲求が非常に高い…と思われる。
じゃあどうする？
ここまで書いていてじゃあどうすんだ？とまじめに思った。
とりあえず仮想KPTしてみる。仮想主体は参加してた3〜5年目くらいの
エンジニア相当の人。学生はもっと別の視点があるはずなので。
Keep
・楽しくやれてるとこもあるよ、というアピール？
=>多分第二部の方々がやっていたこと、だと思う
Problem
・自分が登壇したとして、何を話せばいいかわからない
・（つまらない人は）何がつまらないかをはっきりさせられていない
・何か達成感に欠ける気がする
Try
・エンジニアはビジネスについてもっと知るようにする
・仮想の業務プロジェクトをオープンソースで作ってみる
・「受託開発の極意」「My Job Went to India」の2冊を読む
・広く交流の機会を持つよう、個人単位から行動を始める
まとまっていないけど最後に
上記2冊はSIやってる人なら必読じゃないかと思う。案外読まれていないの
かな、と思ったのは中国やインドは技術に対して云々みたいな言及が出て
いたこと。オフショア先とのトラブルなんかはよく聞く話だし、実際近く
で仕事をした経験のある人は言語障壁とかもあってコミュニケーションが
難しいとか、あるいは人によっては未経験なのにしっかり勉強してきた、
とにかく頑張ります、を連呼していて信用ならないなんて経験をしたかも
しれない。逆にこの人すげー、俺より日本語表現うます、仕事はやす、と
いう人にも会えるけど。
とりあえず、海外だからすごい、日本だめ、という図式はない。日本の
技術者は劣ってない。僕がだめってのはあったとしても平均値で負けてる
はずがない。そこだけは強く言う。日本の技術者は劣ってない。むしろ
いい方だ。大事なことだから2回略。
SI会社が海外で仕事しているかっていう話にならないのは日本全体の問題
で、第1外国語の頑張り率が低いせいだ。なんちゃっていんぐりっしゅで
いいからとにかく話す機会を作っていくことが必要になる。比較はそこか
ら始まる。まだ僕たちはそういうところに立つケースが非常に少ない。
また、システムは基本的にビジネスを動かすためのものだ。ビジネスの
なんたるかを知り、それに興味を持つことがSIでは必要になる。
コードが世界を変える前に、ビジネスが世界を変えていて、それを実現
するのがコードであり、実現プロセスがシステム開発だというそんな流れ
を意識するとつまらなさは少し軽減するかもしれない。
かえって不満が大きくなる可能性もある。というかないとおかしい。
その流れを意識出来ない理由が下請け構造にあるからだ。
作業を細分化するほどに全体を意識出来ない。単純な作業員においやら
れる。それを10年やって何がわかるっていうんだ？という感じにはなる
だろう。じゃあ下請けをなくすには？それって今この業界に存在してい
るビジネスプロセスを変更することになる。それには常時アクターとし
て「クライアント」という存在がいる。ユースケースにおいてこのアク
ターがでかい。クライアントが要求すればSIerが受託するために飲むと
いう構造があるのだから、クライアントにもっと意識してもらうように
していかないといけない。
ということで、僕の結論からすると外部要因で変わるしかないという
ところなんだけど…
クライアントはITと呼ばれるものがビジネスツールであるという認識を 強めて、もっとどうすればいいのかを知る機会を増やしてください。 ビジネスに直結する動きをするために、正しく対応するITパートナーを 選定していくか、自社に開発部門を作るようにしてください。 私たちはそのための協力は惜しみませんし、一緒によくしていけたらと 思っています。
海外にSIerがない、という風に言われる理由は自社で持ってるからに
過ぎない。アメリカではレイオフとかもあるし、結構自由に会社間を
動くから請け負うのを専門にしている会社という存在が（あったとし
ても）見えないのではないかと思っている。
でも請負というのがないはずはないんだよね。公共系ってそうじゃない？
そういう海外での受託事業の例とかも見ていくともう少し視点が変わっ
てくるんじゃないかなぁ。
やはりまとまらないけどとりあえず保存。
