イメージ画像

下ではなく上を照らせ 1/2

比叡山での生活は東京で普通に育って中学を卒業した私の想像をはるかに超える厳しい世界だった。それは肉体的にも精神的にも両面について言えることであった。

山に入ったのが春休みの時期だったのでまだ学校は始っておらず、毎日毎日かまどや風呂で使う薪にするための木を運ばされた。自分たちが生活している寺から徒歩20分くらいのところに木を切り出している山の斜面があり、ここから太さも長さも4、50センチに切りそろえた丸太を担いで行くのだが、乾いていない生木はものすごく重かった。これを1日中日が暮れるまで繰り返す。例えばそれが10往復で終わるのであれば自分なりにあと何回というように言い聞かせながらできるのであろうが、これをいつ終わるともなく延々とやらされていくと、一種の絶望感にとらわれるようになる。それまで、小学生の間は体操の教室に通い、中学でも陸上部に属して、人一倍体を酷使することには慣れていたつもりの私でも、あまりの辛さに自然と涙があふれ、先輩たちが傍らで一服しろと声をかけてくれても、その情けない顔を見せたくないので聞こえないふりして通り過ぎたりしたものである。

そもそも私は今でこそ180センチ近くの大柄な体格ではあるが、中学生までは前から2番目くらいの小さくて細っこい体をしていた。しかし寺の同輩、先輩たちはいずれもガタイが優れており、とても彼らの体力にはついていけなかった。

山での生活はとにかく重いものをよく持たされた。学校へはケーブルカーで通うのだが、そのケーブルカーの山頂の駅に着くと、たいがい寺で注文した野菜や米が置かれていた。店のほうではケーブルカーの麓の駅までは運んでくれるが、それを山頂の駅から寺まで運ぶのは我々の役目である。木でできた背負子が駅に置いてあるのでそれに米や野菜をくくりつけて背負って山道を歩く。普通に歩くと15分ほどの距離ではあるが、重い荷物を担いで行くと一歩一歩進むごとに重さがずんずんと増してくる。一度背負子を背負うと寺に着くまで下ろすことができない。なぜなら、いったん下ろすと重くて二度と立ち上がれなくなるからだ。途中に大きな石灯篭があって、そこでは立ったまま背負子を灯篭の段になったところにひっかけることができたのでそこが唯一の休憩地点であった。こんな調子であったから、荷物が重くて「もう死ぬ」と思うことが1日に1回はあった。

石原都知事が、子ども時代には苦しいことに耐えるという経験をさせないと、我慢ができないすぐにキレる人間になるというようなことを発言されていたが、それはその通りだと思う。しかしそれはなかなか進んでできることではない。

寺の食事は、肉魚は一切だめだし、牛乳や卵も我々は口にできなかった。毎日重いものをもった挙句にこのような食事だったので、普通に高校生活を送って高タンパク食品を摂っていればもう少し背が高くなったに違いないと思う。また、年を取ってから腰痛に苦しむ可能性も高いことであろう。

タグ

NPO活動での飛行機プロジェクト

今回はNPO活動の中の飛行機プロジェクトについて報告します。

私が参加しているNPO法人「大田ビジネス創造協議会」(以下OBK)では様々な活動を行っていますが、その中に飛行機に関するプロジェクトがあります。

昨年はNEDO「次世代ロボット実用化プロジェクト」において、携帯電話で制御をおこない、空中を自律的に飛行し、撮影データを受信できる高機能飛行ロボットを開発し、愛・地球博(愛知万博)で公開いたしました。

また、今年は飛行機に関するイベントを地元の大田区で開催いたしました。これは1月14日、15日(日)の2日間にわたって大田区産業プラザで行ったもので、初日は地元の小中学生を対象とした「折り紙ヒコーキ大会」、2日目は「第1回全日本学生室内飛行ロボットコンテスト」と銘打って、学生による飛行技術を競うコンテストを社団法人日本航空宇宙学会の主催、OBKが共催という形でとり行いました。

これら一連の飛行機プロジェクトは、東京大学航空宇宙工学専攻の鈴木真二先生、および鈴木・土屋研究室の皆さんに多大なるご協力をいただいております。

来年も第2回が予定されており、先週東大で打合せをしてきました。来年は3月24日、25日の2日間、今年と同様に大田区産業プラザで実施する予定です。

初日の「折り紙ヒコーキ大会」は、大田区の全小学校に呼びかけて参加者を募り、鈴木先生の飛行機に関する講演の後、実際に折り紙飛行機を作成して滞空時間を競うというものです。今年は上位入賞者にラジコン飛行機などの豪華賞品が贈られました。ところで、紙飛行機という呼び方のほうが一般的ですが、ここでいう折り紙ヒコーキには、「日本折り紙ヒコーキ協会」による明確な定義があります。それは、1枚の紙を折るだけで作る、切らないこと、ノリではらないこと、などがあります。

2日目は主に大学生による飛行ロボットコンテストです。飛行ロボットというくらいですから、本当はGPSなどを駆使した自動航行装置を積んだような飛行機が登場すべきでしょうが、現在のところはラジコン操作によるものがほとんどです。いずれこの大会が回を重ねていくうちに本格的な飛行ロボットが登場することを期待しています。

今年の飛行ロボットコンテストの様子は、その日のテレビニュースでも紹介されましたが、いずれメジャーなイベントになればいいなと思っています。

東大にて鈴木先生との写真
<鈴木先生と東大にて>

飛行ロボットコンテストについていくつか補足説明)

・飛行機のサイズ
重量制限が150gですから、ごく小さなラジコン飛行機となります。動力は電池で動くモーターになります。

・見学
会場がそれほど広くないのと、安全性を考慮して運営スタッフと出場チームしか会場には入れません。会場は透明な壁面で仕切られているので、外から大体の様子を見ることはできます

タグ

営業活動

我々の仕事は、どこかに善良なる庇護者がいてそれが自動的に仕事を回してくれるというようなものでは決してない。1つの仕事を取るためには目に見えない様々な苦労があるのである。千三つという言葉があるが、まさに千の苦労をしても報われるのはそのうちの三つだけというこの言葉通りのものがある。

5年ほど前、あるベンチャー企業の技術営業の手伝いをしたことがあった。P社はあるソリューションを武器に上場を計画しており、人、モノ、金という経営資源を投入して目標達成に邁進していた。そのような時、エンドユーザと技術グループとのブリッジをする人が欲しいということで、人の紹介でお手伝いすることになった。
もちろん自分の会社を持っているので、週に2、3日という前提でその会社に詰めることになった。

P社に行ってみると、私の席は7,8人のグループを見渡すような配置で用意されており(課長の机のようなレイアウト)、自由に使えるノートPCもその上に乗っていたので、ずいぶん期待されているのだなと思った。社内はベンチャー企業特有の雰囲気というのか、社員は寄せ集めで責任分担も明確ではなく、年中人が入れ替わっているようだったが勢いだけはあった。

社内ではさほどすることもなかったのだが、営業と一緒に大手家電メーカーなど数社へのプレゼンテーションや打合せに参加するようになった。私は毎日出社することはできなかったので、自分の予定は予めメールなどでマネージャに伝えるようにしていた。しかし、この会社は常にその場その場で物事が決まっていき、よく言えば臨機応変、悪く言えば行き当たりバッタリで営業活動を行っていたので、なかなかマネージャと私のスケジュール調整がうまく行かなかった。

出社してみてもいるはずのマネージャが外出しており、一日何をしてよいのか分からないことなどがあった。相手のマネージャも必要なときに私がいなくて困ったりしていたのであろう。手伝い始めて1ヶ月もしないうちに雲行きが怪しくなってきた。

P社は技術者が足りないとのことだったので、私の役割としてはまずP社で営業支援的なことを手助けしつつ、私を紹介した会社と連携してスキルの合う技術者を順次投入していくというもので、斬り込み隊長的なものである。そして切り出した仕事を自分の会社に持ってくるというのが本来の目的だったのである。ところが後から来るはずの技術者の応援がいくら催促してもさっぱり来ない。

昔「コンバット」というテレビ映画があり、そこでは主人公のサンダース軍曹が敵陣に突入するときに味方が必ず援護射撃をしてくれるというシーンがよくあった。これは戦場では当たり前のチームプレイであるが、私の場合は一人で敵陣に攻め入ったものの、援護射撃がまったくこずに孤立してしまったという図であった。

そのようなある日、出社してみると私の机の上の書類とPCが別の机の上に移動されていた。移動先の机は長机で、明らかに一時的な作業スペースであった。マネージャはいないし、周りの人間に聞いても要領を得ないので、また元の机に荷物を戻して作業をしてその日はそのまま帰った。そして次に出社したときにはまた荷物が移動されていたが、そのときは席をそちらに移動しろという伝言つきであった。なんだか陰湿ないじめに会っているようなとても嫌な気分になりつつ、その日は長机で仕事をした。

このような扱いをするところには長居は無用とばかり、紹介会社の責任者を交えて話し合って早々に契約を打ち切った。今でも思い出すと腹が立つ出来事である。ちなみにP社の上場計画は失敗してP社自体も今はもうない。

これに比べると、某製薬会社でのDBバージョンアップのプロジェクトリーダを請け負ったのは大変に有意義であった。P社のときと同じように週に何日か製薬会社の本社に通ってプロジェクトの旗振りをさせてもらったが、先方のCIOはじめ皆さん私にはきちんとした配慮をしてくださった。やはり礼を持って遇するということは大切なことであると思う。

仕事を持ってくるということはとても難しいことで、特にわが社の様に持ち帰り案件をものにするのは大変な苦労が伴う。会社を始めた最初のうちは自分に営業の能力が欠けているのだろうと思っていたが、何年もやっているうちにそれは誰がやっても同じであろうということがわかってきた。大会社の元営業マンとも一緒に営業したこともあるが、それほどうまく行かないし、むしろそれが普通なのである。

営業と技術の間には深い谷があるといわれるが、私はその両方を知っている。むちゃくちゃな条件の案件をとってくる営業の話もよく聞くが、技術の側も仕事を取ってきた人の苦労を慮って欲しいものである。私はよくライオンの親子のたとえ話をする。母ライオンが命懸けで獲物をしとめて子供に与えているのに、子ライオンの方はやれ骨だらけで食えないだの、今は満腹だから食えないだのと我儘を言うのと似ているのである。動物の世界でも、自分で獲物をとってくるようになって初めて一人前なのである。そうでないなら、せめて感謝の気持ちと敬意を表すべきであろう。

タグ

Price Value Cost

モノには値段つまりPriceがある。人はモノを買うときに、その価格が自分にとって納得いく価格かどうかを判断して購入するかどうかを決定する。
このときの判断基準が消費者にとっての価値、つまりCustomer Valueである。
市場で鰯が100円で売っていたとして、その鰯を自分が手に入れるのに100円を払う価値があるかどうかで購入するかどうかを決める。我々のように都市に住んでいて、普段釣りをすることもなければ、その鰯を手に入れるには釣竿を手に入れて海まで出かけなければならない。そして1日費やしたとしても鰯を1匹吊り上げられるかどうかは保証の限りではない。そうすると、我々が自分自身で鰯を1匹手に入れるということは100円をはるかに超えるコストを必要とするので、100円の鰯を買う価値があるのである。
しかし、漁師にとっては普段から網にかかってくる鰯に対して100円の価値を見出さないであろう。ひとたび海に出れば鰯は一網に100や200匹はかかってくると考えると、そのCustomer Valueは1円にも満たないかもしれない。

ここで、PriceとCustomer ValueとCostの関係を絵にしてみる。

※ 東京工科大学客員教授 矢作恒雄先生の授業より

これはどのような商売でも普遍的な原則である。もちろんソフトウェア開発のビジネスでも同様で、その開発を自社で行うときのコストと専門の業者に発注したときのPriceとの差がユーザにとっての満足度の重要な要素となる。
ここで注意したいのは、顧客にいい顔ばかりして自分たちのコストがPriceをオーバーしてしまうことである。

Price – Costが自社の利益となるのであるから、Cost>Priceとなれば、顧客価値がいくら上がっても自分たちは食えなくなるのは自明の理である。
大切なのは、自分たちの利益をきちんと確保しつつ顧客価値を上げることである。
これは、自分たちが売りにしたいと思っていることと、顧客が価値を感じることが必ずしも一致しないということに注意すべきである。あるポータルサイトの構築を依頼されたとして、それをJ2EEでスクラッチで開発し、仕様書をUMLで必要のあるなしに関わらずドキュメント化し、EJBを駆使して高度な実装を行ったところでそれが価格に反映された場合は顧客が必ずしも喜ぶとは限らないのである。
もしかすると顧客はUMLで書かれた仕様書など求めていないかもしれないし、PHPでありものを組み合わせてそこそこ性能の出るアプリケーションを早く安く仕上げた方が喜ぶかもしれない。ここのところは、技術者が独りよがりになってはいけないところである。

これは、AppleのiPodとSONYのNet Walkmanとの勝負に象徴される。
iPodには、以下のようにオーディオ屋からみるとタブーと思われる点がいくつかあるらしい。
・高級オーディオの世界では安っぽいとして敬遠される白色を採用したこと
・ボリューム調整を他の操作と一緒にしてホイールでコントロールすること
(これは誤って大音量に設定してしまうような操作ミスを招くのでオーディオ屋はこのような設計はしないらしい)
・左右同じ長さのイヤホンケーブル
・壊れやすいHDDを持ち運びにすること

しかし、IPodはITMSというコンテンツサービスとクールなデザインを印象付けるCMで市場を席巻することになった。これは、顧客から見たバリューと、オーディオ屋から見たこうあるべきという、ある意味職人気質とが乖離した結果である。
システム開発といってもそのユーザのもくろみは多種多様である。そのユーザの目的を汲み取って、最適なソリューション(解)を見つけるのが我々の仕事なので、自己満足、独りよがりなシステム作りは厳にいましむべきことである。

タグ

このページの先頭へ