ものづくりベンチャー経営に必要なたったひとつのこと

8月 27th, 2017 | Posted by admin in 長橋のつぶやき - (ものづくりベンチャー経営に必要なたったひとつのこと はコメントを受け付けていません。)

 つねづね、自分はハードウェアベンチャー(ものづくりベンチャー)のマネジメントは、結構、難しいと思っています。そして、先日、ある方とお話しているうちに、この仮説をさらに止揚するきっかけとなったので、シェアしてみます。なお、これはあくまで一般的であって、特定の話ではありません、かつ、自分の所属している組織の見解を示すものでもありません、あしからず。

 なぜ、ものづくりベンチャーは難しいのか? 自分は理解では、当たり前だけど、ハードウエアを作るから。そして、ファイナンスの観点からみると、企業のバランスシート(貸借対照表)の左側(資産サイド)には、現金があり、ハードウエアをつくるということは、その現金を使って、ハードウエアの部品・組み立て等など加工して、それを同じく左側の在庫として計上する。すなわち、仕訳的には現金が在庫に振りかえる処理をする(現金→在庫)。

 その在庫が最終的にお客さんとの売買が成立して、在庫がはけるかわりに、現金が入ってくる、このビジネスサイクルであれば、全く問題ない。でも、意外とこれが難しい。とくに、”ベンチャー”の場合、コンセプトはあっても、そのコンセプトがハードウエアにキチンと繁栄されていないケースが多い。設計図をもとに発注したけど、違ったものができたのでやり直しというケースは結構ある。そして、その旅に、現金が在庫になり、反古になったものは在庫のまま使われず、死蔵在庫になりがち。そして、その在庫から現金を回収できずに、どんどん現金がでていくという負のスパイラルに陥るケースもある。

 ソフトウェアの場合、こうした現金→在庫サイクルについては、ハードウエアにくらべて圧倒的にリスクは低い。会計上、ソフトウェアを資産化するケースもあるけど、よほど外注をつかわない限り、基本は内部の人件費だし、やり直すのも、最初からやり直しというケースはなきにしもあらずだけど、基本はコードの修正で対応できる。だから、リスクという点ではソフトウェア・サービスの方が圧倒的に低い。

 こうなれば、いっそのこそベンチャーはソフトウェア・サービスでいいじゃんと思うかもしれない。自分はそれを否定しないけど、ハードウエアにもメリットはある。こうした、現金→在庫のループをぬけて、ハードウェアがお客さんに納入された場合、モノによるけど、比較的安定的に供給できる。ソフトウェア・サービスの場合、すぐに陳腐化する可能性はあるけど、ハードウェアをすぐにマネ、納入するのは、敷居が高い。中国などにマネされるリスクはあるだろうけど、そこまでいけば御の字ではないでしょうか。

 というわけで結論、ものづくりベンチャーのマネジメントにおいて必要なたった一つのこと、それは現金→在庫バランスでしょう。とくに、エンジニアが強い会社のばあい、カネに糸目をつけず、はやく次の試作をすべし、みたいに、現金→在庫べランスをあまり考慮しないケースも多い。もちろん、次へつなげる試作も重要だけど、おカネは企業の血液、現金がなくては会社生きていけない、この現金→在庫バランスをキチンと考えることが大事と思うのです。

会計ソフトと関心を持つこと

4月 7th, 2016 | Posted by admin in テクノロジー | 経営 | 長橋のつぶやき - (会計ソフトと関心を持つこと はコメントを受け付けていません。)

 先日、ある方とお話しして、なるほど、と思ったことです。

 その昔、アナリストをやっていて気が付いたのは、会計ソフトを開発・販売している会社は利益率が高くて、景気にあまり変動なく業績が安定している。で、それはなぜだろうというのが、前からの疑問でした。

 で、その方いわく、会計ソフトが変更が多い。たとえば、消費税は本当であれば昨年の10月から10%になる予定だったけど、いまのところ、8%、さらには今後も変わる可能性がある。くわえて、今後は軽減税率で、品目によって消費税が変わる可能性もあると。

 というわけで、ソフトを使っている方にとっては、やはり、こうしたイベントが起きると更新せざるをえない。そして、重要なのは、こうした更新というイベントにおいて、要所要所でコミュニケーションがあること。

 まあ、オンラインであればアップデートだけでいいけど、たとえば、営業が「消費税が上がるのでアップデートお願いします」という動機ができて、そっから、芋づる式にお客さんのニーズに応えていくと。

 マザーテレサはこう言ってます。「愛の反対は憎しみではなく無関心です」と。ソフトを入れっぱなしで、おカネだけもらって、その後、無関心の放置プレーだったら、やっぱり、お客さんとしては、もういいや、となってしまう。でも、消費税が変わるタイミングでセールストークを仕込んで、お客さんに関心をもつ、これが会計ソフトの高い利益率、業績の安定につながるのかなあと。ただ、これって会計だけではなくて、お客さんに関心をもつ、これが大事なんだと思いました。
 

オークランドの中心でアジャイルを叫ぶ

9月 3rd, 2015 | Posted by admin in 経営 | 長橋のつぶやき - (オークランドの中心でアジャイルを叫ぶ はコメントを受け付けていません。)

 9月第1週は夏休みをいただいてニュージーランドを旅しました。ATAMAIワインの小山さんとの出会い、一日一組限定のThe Sounds Retreat のすばらしいおもてなし、など、すばらしい経験をすることができました。ありがとうございました。感謝です。

 NZ,最後の夜はDepotです。 Aucklandのど真ん中にあるレストランで、 AucklandでもいつもTop10に入るレストラン。味、サービス、まったくもって申し分ありません、惚れ惚れするすばらしいレストランです。

 最初に訪問した2年前にも思ったのですが、このレストラン、わりと自分の経営の理想形があるように思います。このレストランの収容人数はだいたい120名くらい(ま、いつも並んでいますが)。一方、スタッフは10名以下。あたりまえだけど、一人が焼き方専門、野菜専門、ウェイター専門とやっていたら、全然、回らない。だから、このレストランは、あるスタッフが、貝をさばきながらも、焼き方に人が足りないとあれば、焼き方を担当。一人で複数の役割を受け持つ。スタッフのキビキビした動作が心地よく、見ているだけでもこのレストランに行く価値があります。

 で、1年くらい前になりますが、アジャイル開発の本を書きました。簡単に言えば、アジャイル開発はシステム開発の方法論で、ひとりがプログラミング、設計、テストなど複数の役割を担うことで、アジャイル(迅速)にシステムを仕上げる。このレストラン、アジャイルそのものだと思います。

 そして、このアジャイルを成立させるためには、1.仕組み(メニューはできるだけシンプル、複雑なことはしない)、2.優秀なスタッフ、に尽きると思います。経営もこれと同じだなあと。 Aucklandにお立ち寄りの際は、ぜひ、立ち寄ってみてください。

IMG_1821

IMG_1822

http://www.eatatdepot.co.nz/

世界ハイテクウオッチ ラックスペース

8月 27th, 2015 | Posted by admin in イノベーション | テクノロジー | 長橋のつぶやき - (世界ハイテクウオッチ ラックスペース はコメントを受け付けていません。)

http://www.sbbit.jp/article/cont1/30098?ref=150827bit

連載中の米国ハイテク企業ウオッチにラックスペースの記事を寄稿させていただきました。

【連載】米国ハイテク企業ウォッチ
ラックスペースは、なぜアマゾンAWSやマイクロソフトAzureと「互角に」戦えているのか
http://www.sbbit.jp/article/cont1/30098?ref=150827bit

システム思考と全体最適

5月 31st, 2015 | Posted by admin in 日々の思い | 長橋のつぶやき - (システム思考と全体最適 はコメントを受け付けていません。)

先日、ある方と話していて、発見があったので、シェア。

 これまで「システム思考」という言葉を耳にしたけど、いまいち、腑に落ちなった。システム思考とは、定義によれば、「システム全体で考えること」。で、腑に落ちなかったのが、何がシステムで何がシステムじゃないかよくわからなったというのもあると思う。

 その時、話していたのは、企業の情報システム。そこそこの規模の企業の情報システムは、製造、経理・財務、マーケティングなどのユーザ部門が自分たちの業務に合うシステムとかツールを入れて、その運用はシステム部門というケースが多い。 

 で、その問題点は、「個別最適」になってしまうこと。製造部門で入れていたシステムと似たシステムが別ベンダーによって導入されているというケースは結構あって、統一すればコストは安くなるものの、いままでと操作方法がちょっと違うなどの論理で結局、個別最適になるケースが多い。それで、個別最適を繰り返した結果、企業の情報システムとしてつぎはぎだらけになってしまう。ゲーム理論で言えば、「囚人のジレンマ」的な状態といえるかもしれない。

  そういう状況において、おそらく必要なのは、システム全体を鳥瞰して、「全体最適」をすること。で、そのシステム全体から全体最適をする考え方がシステム思考なんだと思う。自分の経験上、情報システムの多くの場合は、個別最適するよりも全体最適した方がコスト的に安いケースが多い。

 とはいうものの、全体最適することは簡単なようで結構難しい。たとえば、製造部門が全体を俯瞰して全体最適することはなかなかできない。自部門の論理が優先される。こうした全体をみながら、リソースを配分するのは、たぶん、経営の役割だと思う。

 というわけで、おそらく、情報システム以外にも個別最適の論理が蔓延り、全体最適になっていないケースはいっぱいあると思う。それをシステムとして捉えて、全体最適する、これはとても重要なことなんだなあと思ったのでした。

ベトナムベンチャー企業訪問記2 AKBソフトウェア

1月 8th, 2014 | Posted by admin in 長橋のつぶやき - (ベトナムベンチャー企業訪問記2 AKBソフトウェア はコメントを受け付けていません。)

AKBソフトウェア
 AKBソフトウェアは、日本の久保工業株式会社、そのシステム子会社のKBソフトウェア、そして、ベトナムIT企業大手のAIC Groupの合弁で2008年に設立されたIT企業です。

 代表の末続宣彦社長は、金融系のシステムエンジニアを経て、2000年代からネットでのプロモーションを先駆けて展開、プロモーションビジネスを奥様に任せ、2012年からハノイに移住。ベトナムと日本との架け橋となるべく奮闘されておられます。

 同社のメインのビジネスは、KBソフトウェアからのオフショア開発。長崎に本拠を置くKBソフトウェアは、三菱重工からの受注の一部をオフショアとして同社に委託。日本語が話せるベトナム人がブリッジとなり、かつ、定期的に日本で研修を受けていることもあり、オフショア開発にありがちな、指示した要件とできあがったモノが全然違うという、ボタンの掛け違いは起きないと末続氏は指摘します。

 日本からの受託開発にくわえて、強化しているのは、ベトナム向けビジネス。ベトナムIT企業大手のAIC Groupとのアライアンスにより、ベトナム企業ならびに政府系からのシステム開発の受注を強化。受託にくわえて、自社サービスも強化。
家系図作成が盛んなベトナムのニーズを踏まえた家系図作成ソフト販売の実施、ならびに、検討段階ながらも懸賞サイトによるデータベースマーケティングを今後自社事業として展開予定です。

AKBソフトウェア http://akb.com.vn/jp/index.html

末続宣彦AKBソフトウェア代表

ベトナムベンチャー企業訪問記1 ベトナム

1月 8th, 2014 | Posted by admin in 長橋のつぶやき - (ベトナムベンチャー企業訪問記1 ベトナム はコメントを受け付けていません。)

はじめに

 2013年12月16日~18日にかけて、ベトナム社会主義共和国ハノイ市に訪問し、ハノイ市のIT企業の経営者に会う機会を得ました。ここでは、ベトナムハノイIT企業訪問記として、実際に訪問させていただいた会社の状況、ひいては、ベトナムIT動向を記したものです。当社としては、こうした試みが、ベトナムベンチャー企業の活性化、日本からのベトナムへのアテンションの増加に繋がることができれば幸いです。なお、本文は当事者のヒアリングに基づいた内容に基づいており、一般統計と整合性が取れない可能性がある点、ご留意ください。

ベトナムのIT企業の状況

 ベトナムの都市構成としては、経済の中心はホーチミンであり、政治の中心はハノイ。同2都市が政治・経済の中心を担っています。都市部から離れると、田園風景が広がっており、ヒアリングによれば、“ベトナムのほとんどの層が農業で生計を立てている。ただし、最近ではハノイ、ホーチミンへの移住が急増している”とのこと。

 (独)労働政策研究・研修機構によれば、ベトナムにおける都市部人口が全人口に占める割合は1989年の20%から2024年にかけて35%まで拡大の見通し(*1)。実際、ハノイでもバイク・車が街中にあふれており、何度も渋滞に遭遇しました。ハノイ市でも、人口急増に対応するために都市部の拡張を計画しており、将来的には、道路敷設によってハノイとその衛星都市を繋げるとのこと(*2)。

 農村部からの人口が都市部に急速に流入するのは、1950~60年代の日本と似ているのかもしれませんが、ITという点では他のアジア諸国には引けを取らない印象を受けました。ハノイの街中、さらには、ヒアリングによれば、農村部においても、アンドロイド端末を保有し、電話・メッセージ・アプリを利用しており、総務省のデータによれば携帯電話の普及率は143.4%(*3)とプリペイドが中心ながらも広く普及しています。

 こうした誰もが使う携帯電話向けにビジネスを展開しようとする企業も多く、今回訪問したIT企業の多くも携帯電話向けのサービスを提供しており、新規にスタートアップする企業も増えています。

そのスタートアップを支えるベンチャーキャピタルも活発で、今回訪問したIT Hub(クラウドファンディング形式でスタートアップ企業をサポート)はその一例であり、それ以外の大手VCとしてIDGベンチャーズ(*4)、VI Group(*5)などがあります。

 なお、日本のVCの場合、IPO(新規株式公開)が一つのイクジットとして成立しますが、ベトナムの場合、ホーチミン証券取引所ならびにハノイ証券取引所ともに歴史が浅いこと、ならびに、上場企業の業種が銀行・製造業などが主でありIT企業はほとんどないことから、IPOによるイクジットは現実的ではなく、VCによる企業統合、他社もしくは他国(シンガポール、日本など)への売却が一般的となっています。

 ベンチャー企業が増える一方で、国有企業あるいは元国有企業の規模も大きく、たとえば、IT企業では、もともと科学技術省傘下で2002年株式会社化されたFPTベトナムは、モバイル、ソリューション、オフショア開発など総合的に手掛けており、高い市場占有率を持ちます。

(*1)http://www.jil.go.jp/foreign/jihou/2003_11/vietnam_01.htm
(*2) http://www.hotnam.com/news/100316020957.html
(*3) http://www.soumu.go.jp/g-ict/country/vietnam/detail.html
(*4) http://idgvv.com.vn/en/
(*5) http://www.vigroup.com/en/index.htm

ハノイの風景

「プログラミングなんて必修にしなくていい論」への反論

10月 20th, 2013 | Posted by admin in テクノロジー | プログラミングを考える | 経営 - (「プログラミングなんて必修にしなくていい論」への反論 はコメントを受け付けていません。)

直接のご面識はないのですが、クレイア・コンサルティングの調 祐介さんが、ブログ記事「プログラミングなんて必修にしなくていい論」に、かつてこのブログに投稿したプログラミング科目を必須にすべき3つの理由をご紹介いただきました。どうした形であっても、取り上げていただけることは歓迎すべきことですので、まずは、御礼申し上げます。

 とはいうものの、タイトルは、”プログラミングなんて必修にしなくていい論”、以前、投稿した内容は、プログラミング科目を必須にすべきという主張なので、こちらと真逆の主張です。ただ、重要なのは、弁証法的というか、お互いの主張をぶつけることで、さらに議論を深めていくのは重要と思うので、あえて、”反論”したいと思います。

「プログラミングなんて必修にしなくていい論」

調さんの記事は、No–You Don’t Need To Learn To Code を基にしていて、とてもよく日本語にまとまっています。

このオリジナルの主張をかいつまむと、

・プログラミングすることは楽しい、でも、一人前になるためには、10年くらいかかるし、常に勉強しなくてはいけない。

・プログラミングは問題解決の道具に過ぎない。そして、プログラミングをマスターしたからといって、世の中のすべての問題を解決できるわけではない。もっとも大きな問題は人間の内部に根差した予測できない問題であることが多く、これはプログラミングでは解決することはできない。

・それでも、プログラミングに興味があるのであれば、かわって、プログラマーを理解すべき。プログラマーは、ビジネスミーティングなど”邪魔”されるのが何より苦手。だから、彼らを理解する、あるいは、ビジネスの言葉を彼らにわかりやすく翻訳することは大切。

・むしろ、プログラミング時代を学ぶより、ソフトウェア、ネットワークがどのようにして動いているのかをしることが大事。車の設計を知らなくても運転はできるけど、車の構造を知るとより深く対応ができるのと同じ。パイソンのコードなんか書くよりは仕組みを知ることのほうが重要。

・人生は短い、モノづくりはたくさんある、プログラミングだけがモノづくりじゃない、文章を書いたり、音楽を演奏したり、などやることはいっぱいある。何をすべきか賢く選択すべき。




職業としてのプログラマ

 筆者の主張はだいたい共感できるし、なるほど、と思われるところもそれなりにある。

ただ、筆者のスタート地点と自分のスタート地点は違っていると思う。そして、彼女のスタート地点は、”職業としてのプログラマー”ということだと思う。

 世の中には、プログラムを書いて、収入を得る、職業としてのプログラマが多数存在する。結局のところ、システムを作るうえで、プログラマは必須であり、インド・中国にアウトソーシングしているところもあるけど、日本国内においてもプログラマとして生活をしている人はたくさんいる。そして、自分の知ってるプログラマも、彼女が指摘するように、邪魔されるのを何よりも嫌うし、視野が狭いといわれたら、そうかもしれない。

プログラマというキャリア

結局のところ、これはプログラマとしてのキャリアはどうあるべきか、という話なのかもしれない。よく言われるのは、プログラマ35歳定年説。システム会社に新卒で入って10年くらいはプログラマをやるけど、10年くらい経過して、1.管理職へのシフト、2.新しい技術のキャッチアップの限界、3.体力的な限界、などで35歳がプログラマーの限界といわれている(ただ、これは前から言われていて、かつ、最近では、管理職はともかくとして、技術、体力はあまり関係ないようにも思われる)。

  35歳限界説はともかく、一生の仕事として、職業プログラマーができるか?という話だと思う。

自分の理解では、プログラマーとして生涯のキャリアを過ごせるかといえば、できるけど、すごく大変。たとえば、社会保険のシステムを作ったり、銀行のシステムを作ったり、大規模なシステムを作るにはプログラミングが当然必要。ただ、これは一人ではできない、だから、ゼネコンのように大きな会社が元請をして、2次、3次、場合によっては、4次くらいまで下請け(外注)を導入して、その下請けがプロジェクトの一部分だけのプログラミングを請け負う。こうしたスキームの場合、人月単価などから、生涯現役モデルは妥当ではないと思う。

 むしろ、生涯現役プログラマーモデルは、誰も正解がわからないものにチャレンジすることに価値があるように思う。かつて、自分が学生のころ、学術目的でIPv6のアドレス配布をやっていたことがあった。そのときに、いとぢゅんさんというIPv6を開発している天才プログラマーがいました。今でこそ、IPv6はそれなりに使われつつあるものの、当時(1998~2000年くらい)は、まだ実装も、ラフに決めた仕様書(RFC)があったくらい。そうした”未知”がたくさんあるなかで、彼は自分で一番シンプルな解法を探して、それを実装して、国際コミュニティに提案して、IPv6開発をリードしてきました。

 たしかに、マネジメントとかCEOとか関係ないし、プログラムですべてを解決することはできない、でも、未知のものをプログラムで形にしていく、そういう職業プログラマーはやっぱり必要だと思う。

プログラミングは必須にすべき?

 で、長くなったけど、本題。プログラミングは必須にすべきか?自分の意見は前と同じで必須にすべきだと思う。たしかに、職業プログラマーとしてやっていくのは、すごく大変。だけど、1.目に見えないシステムを理解すること、2.プログラミングのすそ野を広げること、そして、3.問題の切り分け能力を涵養すること、これはプログラミングから学ぶことも多いと思います。

という意味で、「プログラミングなんて必修にしなくてもいい論」の話に即すると、プログラミングを学習することで、システム、ネットワークといった仕組みを理解する手助けになると思う。そして、それがもとで未知の問題を切り開くプログラマーがでてくれば、日本にとってもとても良い話と思うのです。

インプットとアウトプットのバランス

8月 17th, 2013 | Posted by admin in イノベーション | 経営 - (インプットとアウトプットのバランス はコメントを受け付けていません。)

かつて証券会社でアナリストをやっていたときの話。

アナリスト(野村証券、みずほ証券などのような株を売る側、通称、セルサイド)は、基本エクイティセールス(以下、営業)とタッグを組んで、顧客(機関投資家、XX信託銀行、XXアセットマネジメントなど)に株を推奨する。

それで、アナリスト当時、苦労していたのは、インプットとアウトプットのバランス。

アナリストのインプットは、自分の担当業界(IT業界など)の会社に足しげく通って、取材して、カバー(将来の収益予想モデルをつくって、メンテする)する。電話で確認する場合もあったけど、実際に訪問すると、微妙なニュアンスを感じ取れたりするので、基本、足で稼ぐことが大切。

アウトプットは、足で稼いだ情報を、レポートとして提出し、その内容をミーティングなどで機関投資家に伝える。その情報に従って、投資すると、リターンを取れる場合もあるし、そうでもない場合もある。

それで、難しいのは、インプットとアウトプットのバランス。インプットばっかりで、なんもアウトプットしてないと、”ちゃんと仕事してんの?”となってしまう。一方で、インプットなしでアウトプットだけだと、上っ面をさらっただけでアウトプットの深みがなくなる。


ちなみに、この図式、IT業界でもかなりよくある。営業と技術の関係は営業とアナリストのそれと全く同じだ。

営業は、その名の通り、自社の製品(サーバ、パソコン、ルータ)などを売るのが仕事。

でも、営業がすべてお客さんのところに行って、お客さんでの契約を受注できるとは限らない。

たとえば、お客さんのところの技術担当者が”技術を呼んでよ”となり、技術を呼んで、その技術が、お客さんに対して、説得できる説明であれば、お客さんは発注する。

ただし、技術もずっとお客さんのところにいってアウトプットしては、製品についてのインプットがなくなり、気がついたら、自社の最新製品を知らなかった、というのは結構多い。

アナリストと営業、技術と営業、結局のところ、重要なのはバランスなんだと思う。インプットとアウトプットのバランスをとる、これは楽なようで難しい、でも、それをやらなくてはいけないってことだと思う。

プログラミング科目を必須にすべき3つの理由

4月 7th, 2013 | Posted by admin in テクノロジー | プログラミングを考える | 経営 - (プログラミング科目を必須にすべき3つの理由 はコメントを受け付けていません。)

プログラミングを高校・大学の必須科目にすべきという話があるけど、自分はこれにもろ手を挙げて賛成です。

もちろん、高校・大学でちょっとプログラミングを勉強したところで、すぐに企業に入って役に立つというわけでもないけど、次の3つの理由からとても大事と思います。

必須にすべき理由その1:目に見えないシステムを理解する

 システムを作る作業は基本的には建築現場の土木工事に似ている。まず、どんな建物ができるかきちんと設計し、予算を割り当てて、リソース(自社ですべてできる場合は少ないので、場合によっては外注)を確保して、スケジュール通りに仕上げる。ただし、土木工事と違う点は、土木工事は目の前の建物が建っているのはわかるのに対して、システムの場合は、目に見えないこと。そして、目に見えないから、”こんなシステムすぐできるだろう”のように無茶をいう経営者もそれなりにいる。もちろん、あえてシステムを知らないことで自由な発想を生み出すことができるのも事実だけど、目に見えないシステムをプログラミングを通じて理解するのはとても重要だと思う。

必須にすべき理由その2:プログラミングの裾野を広げる

 高校・大学でプログラミングをやったからといって、全員がシステム会社に就職するわけでない。たとえば、自分は大学時代、慶応湘南藤沢キャンパスで6年間過ごして、最初の1年は情報処理のクラスでプログラミング(C言語)が全員必須だった。そして、SFC生全員がシステム会社に入ったかというと、もちろん、そんなことなく、銀行にいったり、公務員になったり、商社にいったり、プログラミングと全く縁遠い業界に入った卒業生も無数にいる。でも、かつて、裾野の広さと500 startupsというエントリで書いたように、ニュージーランドのラグビーのようにプログラミングの裾野を広げることは、次の新しいベンチャー、産業を生みだす点で大切。

必須にすべき理由その3:問題切り分け力をつける

 当たり前だけど、コンピュータは人間が指示したことしか実行しない。そして、プログラミングは、やや抽象的な言い方だけど、”コンピュータに指示する手続き”ともいえる。そして、コンピュータにプログラミングによって”指示”しても、自分の思い通りに行かないことが多々ある、いわゆる、”バグ”だ。それで、どうやって、バグを見つけて、正しい動作にするか、それが”問題切り分け力”だと思う。不具合の原因をあらゆる可能性から検討して、問題解決のあたりをつけて、そして、修正する。自分も最近コンサル案件でプログラミングの手伝いをすることがあるけど、結局、プログラミングとは、問題切り分け作業の連続だと思う。そして、言うまでもなく、この問題切り分け力は、プログラミングだけではなくて、営業、製造、管理、経営などあらゆる場面に応用が効く力で、こうした力はプログラミングによって涵養される要素が大きいと思う。

最後に

 これまでシステムエンジニアの採用を経験したことがあって、そこからわかったこと。それはシステムエンジニアには2つのタイプがある。一つは、あるプログラミング言語に特化して、それを極めるタイプ、今だと、Javaのフレームワークなどそれなりに需要があるので、特化タイプもマーケットはある。一方で、プログラミング言は、言語体系は違えど、考え方(制御構造、データの持ち方、アルゴリズムなど)は同じなので、あるプログラミング言語をマスターして、それを別のプログラミング言語に応用できるタイプ。企業とくに小さい企業では、後者の方が柔軟性があるので、こっちの方がニーズがある。そして、プログラミング科目必須になって、後者のような柔軟に応用ができるタイプがたくさん育てば、これほど日本全体にとってプラスなことはないと思う。