投稿

イノベーションのジレンマとか、ブルーオーシャンとかも考えている。これらも、結果を分析してのことで、大事なのは、顧客のニーズと社会の変化をうまく掴むこと。結果として、イノベーションと呼ばれるかもしれない。

プログラマがキャリアの一番上にくるシステム開発会社をつくろうと思う。

これまでのワークスタイルは、属人性を廃し人を固定しない代わりに働く場所と時間を固定して生産性を上げていた。ソーシャルメディア時代のワークスタイルは、働く場所と時間にしばられない代わりに、信頼できる人を固定することで、多様な価値を産み出せるようになると思う。

システム開発業界におけるLCCのようなビジネスモデル、つまりLow Cost Vendor(LCV)をやる。その為には、今までのシステム開発の慣習を見直し、徹底的なコスト管理を行う。多重請負による無駄、データセンター保持の無駄、品質保証による無駄などの見直しから。

起業で得られるノウハウやネットワークは暗黙知であり、属人的。それ自体は良いが、そのチャレンジした個人が一度きりで終わってしまうのが、成功の出にくい状況だと思う。初めて起業して、初回で成功しないといけないのは、リスクというより無謀。では、どうするか。

システム開発の市場自体がシュリンクしてるのは皆感じているが、これまでが異常で、正常に戻りつつあると考えた方が良いかも。売上規模は下がったとしても、利益率の高い市場に変えれれば、生き残れるのでは。

雇用が流動的である社会の方が良いかどうかは、わからない。日本的な雇用の形が評価された時代もあった。メリットデメリットある。日本人のメンタリティにあっているかどうかもある。古臭いかもしれんけど。

SIerと企業システム開発は同じように思われるけど、多重請負のSIerのビジネスは確かに終焉に近付いてるように思うけど、システム開発自体はなくならない筈だ。アメリカほど全てが内製化されるほど、まだ日本は雇用が流動的な社会ではない。

IT投資の判断のための予算計画、でも年間予算は、そもそもその企業の企業体力や方針によって決まってくるのでは。その範囲内でスモールスタートする戦略を採れないのは何故。

企業向けのシステムでも、顧客のニーズとしてシステムをスモールスタートして、少しずつ改善していきたい、というのはあると思う。それを妨げてるのは誰で何か。

企業向けのシステム開発でも、開発ベンダ内のの役割分担を無くし、プログラマが個人として顧客と直接に対話していく方がうまくいきそうだ。その場合の顧客とは情報システム部門でなく、事業部門。ダイレクトにつなぐ。

アジャイルソフトウェア開発的には、早めのイテレーションで小さく失敗しておくことは、後々の致命的な失敗を防ぐことに繋がる。経験することは何にも替えがたいもの。もし失敗しても優秀な人たちこそ、次に活かすことが出来る筈だ。

期限を決めて頑張ってみるというのは良いリスクのとりかたかもしれないな。ただ、そこで得た経験を活かすというなら、一度でなく、何度も挑戦してこそ成功に近づくように思う。

ズルいと言われるビジネスモデルは、割と良いのではないだろうか。ズルくもなく、ただ決死の覚悟でやるのは、リスクと言えない。ズルいにしてもリスクはあるのだし。

ビジネスモデルとワークスタイル。経営が考えるのは前者で、現場が望むのは後者。役割が違うだけで、双方が同じ方向を向いて取り組まないと実現できない。必要なのは共通のビジョン。

日本人のメンタリティなのか、エンジニアのそれなのか、わからないけれど、なるべく地道に努力するようなビジネスモデルの方が共感を得られやすいとしたら、世界とは戦いにくいかな。なるべく努力しないでも儲かる仕組みを作る方が大事だと思う。

開発方法論がいろいろあるのは良いと思うのだけど、方法論がビジネスモデルやコンテキストを置き去りにしてしまっている印象もあるなぁ。方法論ありきで開発するのでなく、仕事にあわせた方法を考えないとよくないよね。

システム開発会社では、属人性は悪とされがち。それは何故か？プログラマによっては、とてつもない生産性の違いがあるのに。そこにも、この業界のギャップが隠れていそう。