ソフトウェア産業の実情と将来についての一技術者の考察 ~ ソフトウェア業界を目指す全ての学生さんに ~

表題に関連するminejiro氏の一連のtweetをまとめました。 私(しがない情報系専攻の大学院生)のように、「入りやすく出にくい」ソフトウェア産業に片足を突っ込みつつある方、もう両足を突っ込んでいて抜け出せない方に読んでほしい事実の一側面です。 素晴らしきソフトウェア産業に従事することを夢見ている方、あるいは否が応でも将来を考えなくてはならなくなった方、そして私のように将来のことなんか何も考えていない方には、少々刺激的かもしれません。 続きを読む
13
みねじろ! @minejiro
ソフトウェアは個人で作るもの、作った人を持て囃す風潮は、産業ではない、故障や労働災害を生む土壌に成っていると思うので、個人的には反対です。最低でも、要求者、利用者、作成者の3視点で話しをする、各車の利益を想像してみてください。脳内会議でもよいですよ。
みねじろ! @minejiro
結局、本質論のように見えて、鶏、卵の問題なのだな。現状維持がよいと言っているわけではないですよ。銀の弾丸やここさえ抑えておけばOKみたいな、一見広い視野のように見えて部分最適な意見は落とし穴ということです。とはいえ、改善自体はMustです。
みねじろ! @minejiro
よりよいソフトウェア開発方法論を考えるか、普通の人が普通に関わるソフトウェア開発環境論を考えるか、視点は違うけど、問題点が存在することについては、全く同意できるお話。
みねじろ! @minejiro
あぁ、ソフトウェア開発には比較的年寄りが入りにくいという問題点もあるな。割と自由にできる代わりに、最初から責任がのしかかってくる。先日私がつぶやいた、(4)低給功責任、の状態になりやすいです。査定も仕様も不確実で、業務の核や軸が持ちにくいのですよ。で、気がついたら行き詰ることも。
みねじろ! @minejiro
「わかっちゃいるけどやめられない」これが今の日本のソフトウェア開発産業の最大にして解決しないままに来ている問題点だ、というのが私の見解です。俯瞰する視点を若者に持たせるのであれば、経済全体のグローバル化といった一般論や、人格形成の精神論でなく、この事実、実態を俯瞰させるべきです。
みねじろ! @minejiro
ソフトウェア開発の現場にいるものとしては、そりゃ優秀な若者はいくらでもほしいです。騙してでも連れてきたいくらいに。でも、結局、後からこの業界構造の問題に気づいた者、それも早く気づく優秀な者ほど、シラケの状態になりやすい例を多々見てきました。これほど不幸で不健全なことはありません。
みねじろ! @minejiro
多くのソフトウェア開発の現場は、経営者から見ると、よくわからないのに人物金を吸い取られる不愉快なものとなっています。半世紀経った今も産業として未成熟な証拠です。しかも技術者出身の経営者でもハードウェア経験のある人は反って、科学的でない技術的でないという視点で懐疑心を抱いています。
みねじろ! @minejiro
ソフトウェア開発が産業として未成熟である例を挙げると、Windowsが「事実上の」スタンダードOSであったり、IEEEの「勧告」が「事実上の」規約である点などです。パーマネントなものはなく、それでも30年、40年前のシステムや言語がインフラ稼動しているヌエのような産業実態です。
みねじろ! @minejiro
ゆえに、私自身はソフトウェア産業に身を投じようとする若者には、何もしなければ5年、10年後に早くもロートルになるかもしれない世界で30年、40年、弛まず学習努力する意思と努力と時間を作り出す覚悟をもてていますか?を最大の問いかけとしたいです。スキルやセンスは正直、後からでもいい。
みねじろ! @minejiro
ただ、年寄りにはわかって、若者がなかなか気づかないのは、意思、努力、時間の中で、一番難しいのが「時間」の作り方だということ。「よく学び、よく遊べ」は本当に至言だと、年を重ねるに連れて、じっくりとわかるようになりました。だから、私は毎日、大喜利をするのですw
みねじろ! @minejiro
とは、言ったものの「スキルやセンスは正直、後からでもいい。」だけを取り出すと、ソフトウェア産業の構造を悪化させる現状そのものなので、迂闊に言えない。職業教育、ラダー型の職務教育の段階的発展が必要だと思います。詳しくは、ちくま新書、本田由紀著『教育の職業的意義』が参考になります。
みねじろ! @minejiro
今日、私がつぶやいたことは、多くのソフトウェア開発の現場や教育に携わる方がよくご存知のことで、ユニークでも新しいものでもありません。私よりよほど真剣にこの問題に取り組む、解決できると信じておられる方が沢山います。それでもまだ解決していない。そこを学生さんに伝えたくて書きました。
みねじろ! @minejiro
今日は珍しく、専門のことについて真面目につぶやいてしまいました。ホソフトウェア開発以外にも当てはまる部分もあると思います。もし、読んでくれた学生さん、若い人(いや、第一線の方も)から、ご感想などいただけると、ものすごく嬉しかったりします。質問、反論もぜひ、どうぞ。
みねじろ! @minejiro
結局、ソフトウェア産業が属人的になるのは「かけがえのない自分」「ナンバーワンよりオンリーワン」という考え方が、ゴキブリホイホイのように若者を吸い込んでいくから、背負い込まされている部分があるよね。これ、教育やCMのふりした洗脳キャンペーンなんじゃないだろうか?
みねじろ! @minejiro
ソフトウェア産業の考察。 @J_A_Y_G さんとの開発者資質の話、 @sohbunshu さんのmanagementの訳語の不適切さ話から、1人の有能者のビジョンを叶えるために多数の普通の人が支える仕組みでしか成功しない世界を実感。この成功はQOL、WLB、CSR等を全て包含。
みねじろ! @minejiro
(承前)だからこそ、日本人もソフトウェア産業が最大の価値創造産業であること、ビジョンを持ったリーダーが必要であることを、無意識に理解しているのだと思う。 @masason さんや @takapon_jp さんが持て囃される理由もこれ。願わくば、彼らが珍しくない社会にしていきたい。
みねじろ! @minejiro
(承前)ソフトウェア産業が特別だとか特殊だとか言うつもりはないのです。ただ、あまりにも効率化、生産性、開発技法、心構えといった個人やチームに関わる話ばかりで、大規模ソフトウェア開発企業の経営の仕方についてが疎かにされていると思います。失礼ながら「ソフトウェア」も「経営」も不十分。
みねじろ! @minejiro
(承前)ソフトウェア産業に対する技術経営/Management of Technologyはそれに対する答えの一つだと思いますが、この手法は「技術のわかる経営者」と「経営のわかる技術者」を作る2つの側面を持ちます。が、現実は後者が流行りで前者は大企業ほど黙りです。社畜養成講座に。
みねじろ! @minejiro
(承前)ゲイツやジョブズは何を実現するための経営か、そのために部下をどう扱うかを本能的に理解しています。労働環境もよいのは、そのためだと思います。日本のソフトウェア関連の大企業(総合メーカー含む)の経営者は上(政府、放棄)と横(社内外のライバル)だけを見る「経営もどき」です。
みねじろ! @minejiro
(承前)では1人の天才ソフトウェア技術者が道を示し、多数がそれを助ける仕組みがベストというわけでもないと思います。ジョブズは何度もその地位を追われました。ソフトウェア「産業」と言うからには、継続的に事業活動が進み、社会や従業員らのステークホルダーが幸せになれる仕組みが必要です。
みねじろ! @minejiro
(承前)従って、多数の普通の人がいる中で少数の天才が活躍する場をもてる。トップでも部下でも。こういう企業構造がソフトウェア産業の未来を作るのではないかと思っています。どうすればを言えるほど私には知恵も経験も少ないのですが、ロールモデルの例は @masanork さんだと思います。
みねじろ! @minejiro
以上、ソフトウェア産業の実情と将来についての一技術者の個人的な見解でした。
みねじろ! @minejiro
より、社会と個人を幸せにするソフトウェア産業を!
みねじろ! @minejiro
ここまでの私のソフトウェア産業についての考察は、コード数が1000万行を越すような大企業、大規模ソフトウェア開発を念頭においたものです。志あるソフトウェア技術者が中小、ベンチャーで状況をよくするために頑張っている姿に心から賛同するとともに応援しています。間違っているのは大手です。
みねじろ! @minejiro
昨日、ソフトウェア開発現場を経営者がどう見ているかを書き、2つ例をあげました。技術がわからない経営者とハードウェア出身の経営者です。もう一つ忘れていました。ソフトウェア出身の経営者です。大企業ではこれが一番問題です。現場の問題を指摘する=自分の経歴を否定することになるからです。
残りを読む(8)

コメント

みねじろ! @minejiro 2010年6月27日
プリウスのリコールでトヨタの佐々木副社長が「車両というシステム自体の試験は抜けていたと指摘をされても仕方がない」という発言をしました。ソフトウェア屋はこれを聞いて、わかってない!とショックを受けました。その裏側を学生さんにご紹介します。
みねじろ! @minejiro 2010年6月27日
現代のソフトウェアシステム全体は、人間には把握しきれない規模に膨れ上がっています。それゆえ、コーディング技術などの手法やテストといった後付でなく、いかに仕組みを作るかが非常に大事なのです。学生さんにはそれを知って欲しい。
みねじろ! @minejiro 2010年6月27日
ただ、ソフトウェアはハードウェアと違い、純粋に「人の創りだした物」です。だから人の力だけでよくすることが、きっとできるハズ。それを一緒に追究してくれる若者と一緒に働けることを、心から楽しみにしています。ぜひ、あきらめないでソフトウェア産業に入ってきてください。
みねじろ! @minejiro 2010年6月27日
また、経営者の方々には、社会インフラ、事業の柱、輸出産業としても、これだけ発展した大規模ソフトウェア開発について、これまでのハードウェア中心のパラダイムで漫然と経営するのでなく、ぜひ肌で体感してみてください。きっと活路が見えてくるハズ。
みねじろ! @minejiro 2010年6月29日
この内容に興味をもった方は、今日(6/29)の朝日朝刊をぜひ読んでください。13面「記者有論」に組み込み系のソフトウェア開発の問題と取り組みについて記述されています。9万人の技術者不足に対し78人ですが育成。地道な努力です。
みねじろ! @minejiro 2010年6月29日
なぜ、不足人材が日本人である必要があるかというと、仕様が日本語で書かれているからです。日本人あるいは日本語を理解する外国人でないと携わることができない。じゃ、英語で仕様を書けばいいじゃないかという発想が浮かびますが、組み込み系の場合はIT系よりこれが難しい理由があります。
みねじろ! @minejiro 2010年6月29日
組み込み系の場合、ソフトウェア技術者の他に、ハードウェア技術者、サプライヤー、生産技術者、サポート技術者などなど、多くの職種のコングロマリットな体制になっています。学歴も中卒から博士まで幅広く。これをソフトウェアだけ英語化しても事業が回らないのです。
みねじろ! @minejiro 2010年6月29日
では、外国人技術者はという選択が出てきます。が、彼らが日本語を解する場合、母国語>英語>日本語の順で学びます。英語と技術力だけで欧米企業で働けるのであれば、日本語など不要です。よって日本語を解する外国人技術者は、よっぽど日本に思い入れがある場合に限られてきます。
みねじろ! @minejiro 2010年6月29日
これを長い目で見た場合、2つの弊害があります。1つは英語圏では力が出し切れないために日本語を覚えた2流の人材、下手をすれば日本語さえできれば誰でもいいという人材が入り込み、商品、事業開発力が落ちていくこと。
みねじろ! @minejiro 2010年6月29日
2つ目は、優秀かつ日本語を学びたい人材の動機となる、マンガ、アニメといったソフトパワーや、SONYのような世界ブランドの力頼みであり、これらが廃れた場合の挽回策がないこと。
みねじろ! @minejiro 2010年6月29日
従って、悪名高い某都条例案などは、長い目で見た場合にソフトパワーを損ない、日本の組み込み系開発現場を破壊するという結果を産む土壌に成りかねません。案外「都条例がSONYを潰した」なんて言われる日が来るかもしれませんよ。そう、遠くない未来に。
みねじろ! @minejiro 2010年6月29日
もし、そうなった場合、ある日から私たちは、インドで開発された自動車で通勤し、韓国で開発されたプリンターで仕事を進め、中国で開発された電子レンジで夕食を温めることになるのかもしれません。それはそれで構わないというのであれば、よいでしょう。
みねじろ! @minejiro 2010年6月29日
ただ、その場合、資源、技術、ソフトパワーの何もかも失った日本は、おそらく国際化に組み込まれた金融産業と、変わることなく効率の悪い第一次産業を残して、人口減のままに衰退していくでしょう。
みねじろ! @minejiro 2010年6月29日
その衰退も自分が死んだ後なら構わないという選択もありでしょう。個人の人生は個人が決めてかまわないものです。ただし、そういう人間が考えも無しに楽観主義で他人を騙して金をかき集めたり、国粋主義者を気取って隣国をバッシングに興ずるのであれば、滅亡を早めることになるので、おとなしくしていてほしいなとも思う次第です。
みねじろ! @minejiro 2010年6月29日
ソフトウェア産業は「入りやすく出にくい」と書きました。組み込み系だけでも3年前の時点で9万人の技術者が不足しています。これも書きましたが、日本人の組み込み系技術者は絶対に必要です。
みねじろ! @minejiro 2010年6月29日
前にも書いたように、スキルより学習姿勢が必要な資質です。ソフトウェアの勉強を一切してこなかった人でも構いません。ロジカル・シンキングはよほどのブラック企業でない限り、就職すれば、イヤでも身につきます。
みねじろ! @minejiro 2010年6月29日
また、組み込み系は、IT系のような一人で一発逆転は絶対に起きえない、チームワークの必要な開発現場です。不自由さや制約さもたくさんあります。しかし、それ故に助け合いの精神が働きます。困った時に助け合える先輩や同僚にきっと恵まれるはずです(ただしブラック企業を除く)。
みねじろ! @minejiro 2010年6月29日
iPadは日本企業でもできると言ったアホな経営者がいましたが、あれは技術はあるが商品化出来ない、ダメ経営者ですと自白しているわけです。組み込み系のソフトウェア技術者に限らず、企画、販売、サポート、諸々全ての人材が不足しているのが実態です(まともな経営者が一番足りてませんが)。
みねじろ! @minejiro 2010年6月29日
ゆえに、ソフトウェア「産業」=コーディングではなく、それを軸にした色々な業種がソフトウェア産業には存在します。コードが書けたり読めたりしなくても構いません。むしろ癖がつくのを嫌う先輩もいるでしょう。
みねじろ! @minejiro 2010年6月29日
ここまでソフトウェア産業、特に組み込み系のひどさを書いてきましたが、組み込み系は「世界で初めての素晴らしい『モノ』」を自分の手で生み出す夢と魅力がある世界です。今やハードウェア単独では世界で初めての○○なぞ、作り尽くしてしまいました。
みねじろ! @minejiro 2010年6月29日
ソフトウェア×ハードウェア(足し算でなく掛け算です)で実現するからこそ、新しい魅力が生み出される。この組み込み系の世界自体は、決して悪いものではありません。悪いのはそれを進める開発プロセスと人材供給する教育システムと古い頭の経営者です。
みねじろ! @minejiro 2010年6月29日
コードが書けなくて構わない。新しい何かを自分の手で生み出したい。もっと色んなことを知りたい。そういう若い人を、ソフトウェア産業は強く、強く求めています。実態の悲惨さにひるむことなく、本質を見抜き、そこに近づくために一緒に働ける人、面接会場で待ってます(いつどこでかは言いませんが)。
みねじろ! @minejiro 2010年6月30日
組み込み系のソフトウェア技術者が9万人足りないと言っても、いまいちピンとこないですよね。具体例をあげましょう。40代後半から50代で肩書きは主任や係長で、くコーディング「も」している人がゴロゴロしています。みんな、入社時には想像もしていなかった職場環境です。
みねじろ! @minejiro 2010年6月30日
組み込み系のソフトウェア技術者が9万人足りない求人事例その2、(1)日本人、元SE、50歳、(2)中国人(日本語OK)、小規模のPG経験あり、40歳、(3)インド人(英語のみ)、PMP、30歳、さぁ、この中から貴方なら誰を自分のチームに向かい入れますか?という世界。
みねじろ! @minejiro 2010年6月30日
(1)は年功序列型の日本型開発の中で浮く。(2)は実力が足りずフォローでかえって大変になる。(3)は1プロジェクトでさっさとおさらばされる。その結果残るのは、また一つ増えた中途半端な製品のお守り仕事と、次の同じ三択採用問題。ね、救いようがないでしょ。。。
みねじろ! @minejiro 2010年6月30日
ちなみに組み込み系の大手の人材確保方法には3タイプあります。(a)育てる、(b)買う、(c)借りる、(a)は比較的商品数が少ない業種、(b)は成長業種、(c)は成熟業種に見られる形態です。あ、ここで言う「借りる」は直接対価払いませんよ(マジ)。ジャイアニズムです。
みねじろ! @minejiro 2010年6月30日
昔は(a)>(b)>(c)でしたが、今は(c)>(b)>(a)です。何も考えずに入り込むと(c)の形で、最初はバグ取り奴隷かコーディング奴隷として働き始めることにになります。就業形態が正社員か派遣か委託かはあまり関係ありません。
みねじろ! @minejiro 2010年6月30日
しばらくして、少し使えると思われると、おめでとう本籍会社でない有名な会社の名刺を持たされコーディング以外の仕事を、コーディング奴隷並の本籍会社の給料でできるようになります。名はとって実はない。素晴らしい経営ですね!
みねじろ! @minejiro 2010年6月30日
で、ちょっとうまく立ちまわって大手に最初から就職できたとします。さぁ、優秀な貴方の仕事は誰よりも早くコーディングすることでしょうか?それとも画期的なアイデアの改善提案でしょうか?
みねじろ! @minejiro 2010年6月30日
いいえ、最初はコーディング奴隷に混じって仕事の基礎を覚えさせられます。奴隷たちからは仲間扱いされないか、将来を見越して仲良くしてくるか、あるいは永久就職を狙ってくることもあるでしょう。
みねじろ! @minejiro 2010年6月30日
しばらく奴隷修行を続けた次に待っているのは何かわかりますか?そう、奴隷監督です。あなたはコーディングから開放されました。おめでとう!前任の奴隷監督だった先輩も新しい職場に移り喜んでいます。みんなが幸せ、素晴らしいですね!
みねじろ! @minejiro 2010年6月30日
しかし、奴隷監督はしばらくすると悩み始めます。コーディング奴隷たちは自分のことを本当は嫌いなんじゃないか?先輩は仕事を自分に押し付けて逃げたんじゃないか?答え、その通り!ご名答!
みねじろ! @minejiro 2010年6月30日
かくして、大手に就職できても、組み込み系の世界ではものすごく歪んだ業務実態が存在するわけです。どことはいいませんが、ジャイアニズムを駆使して、大きな不祥事と赤字を帳消しにした魔術師がいる超大手があったような、なかったような。
みねじろ! @minejiro 2010年6月30日
ちょっと学生さんを脅しすぎてしまいましたが、見方を変えれば、色々な立場で仕事を経験し、スキルを積むことができると言えなくもないわけです。ただし、これは後から気づいたのでは遅い。経験した時に何の目的に繋がるかを体得するために、就職した時点で十分理解しておかないとダメです。
みねじろ! @minejiro 2010年6月30日
今日の組み込み系の話は、IT系も基本的には同じですね。。。「人月の神話」で指摘された問題点から脱却できている、大規模ソフトウェア開発は少なくとも日本には存在しません。
みねじろ! @minejiro 2010年6月30日
読み直すと、コーディング技術不要とも取れる内容だったので、ちょっと補足。コーディングの技術、経験自体は非常に有効です。直接コーディングしない場合において特に。
みねじろ! @minejiro 2010年6月30日
大規模ソフトウェア開発はチーム作業、また人間はミスを犯すもの、故にどのチームにも誤りを正すためのルールが存在します。ですがルール通りにやっても、実際にはミスが残るわけです。なぜでしょう?
みねじろ! @minejiro 2010年6月30日
たとえば、コードレビューを例に取ります。これは他人が書いたコードを読み解くあるいは作成者の説明を聞く作業です。あなたの役目はそこに間違いが存在しないかを確認する、あるいは間違いを見つけ指摘することです。
みねじろ! @minejiro 2010年6月30日
コードを読めないとコーディングミスの指摘はできませんね。従ってそういう間違いを見つけるためには、コーディング技術が役に立ちます。ところが、全然違うスキルもまた、ここでは役に立つのです。
みねじろ! @minejiro 2010年6月30日
例えば、アイツ自信あり気に説明してるけど本当は自信がなくて動揺してるなといった人間観察力や、作成者が想像もできないようなとんでもない動作を思いつくといった能力です。これもレビューでは非常に有用です。
みねじろ! @minejiro 2010年6月30日
レビューがルールとしてあれば、ルール通りにやるレビュアーが最低1人でもいればよいことになりますよね?でも実際には多くの人数をかけ、新人も集団にない発想で指摘を求められます。そう、個人力が必要な場なんです。
みねじろ! @minejiro 2010年6月30日
その個人力の一つとして、コーディング技術はいくつになっても役に立つものだったりします(修羅場でロートルが引っ張り出される際にも役に、ゲフンゲフン)。要は自分のユニークで役に立つ得意技を見つけ、もっておけばよいのです。
みねじろ! @minejiro 2010年6月30日
つまり、組織のルール+個人力で、互いのミスを克服していくのが、大規模ソフトウェア開発の進め方ということです。組織のルールは組織に属してから学べばよいので、学生のうちは個人力を伸ばす「よく学び、よく遊べ」です。
みねじろ! @minejiro 2010年6月30日
さて、もう少し目端の効く学生さんは、いわゆる開発者(ライン)でなく、補佐役(スタッフ)の仕事を目指す人もいるでしょう。総務、法務、ネットワーク管理者などなど。これらもソフトウェア開発には欠かせない大事な仕事です。
みねじろ! @minejiro 2010年6月30日
が、スタッフ業務につく者には絶対に忘れてはならない一つの原則があります。「スタッフの究極の目的はそのスタッフ業務をなくすこと」です。例をあげると、算盤の得意な人が電子計算機の登場で職を失ったなどがあります。
みねじろ! @minejiro 2010年6月30日
よって、スタッフ業務を選ぶ、あるいはスタッフ業務を命ぜられた場合は、その瞬間から、その業務、担当者、自分がいなくても、ソフトウェア開発(ライン)がスムーズに動くためにはどうすればよいかを、常時考えることが求められます。
みねじろ! @minejiro 2010年6月30日
もちろん、日中はスタッフとして手と頭を動かして、ラインを助けるわけですから、昼はがんばりを肯定し、夜はがんばりを否定するという二律背反な立場を取ることになります。え?なくならないって?明日の算盤おじさんのあなたかもしれませんよ!
みねじろ! @minejiro 2010年7月1日
組み込み系とIT系の違いは、そうだなぁ。組み込み系はスキルがその会社、業種に偏りがちですが、同じ業種の組み込み系やIT系への転職はしやすい。異業種の組み込み系にはしにくい。IT系はIT系の中では転職しやすいけど、組み込み系には転職しにくい。こんなところかなぁ。
みねじろ! @minejiro 2010年7月1日
なので、卒業時点で明確にやりたい事業や職種がない場合は、組み込み系のできるだけ開発規模の大きい(事業規模じゃないよ!)ところに就職し、合っていればその世界で、合わなければIT系や別業種へ移るキャリアプランもありだと思います。
みねじろ! @minejiro 2010年7月1日
その時に大事なことは「ここの常識はよその非常識」この言葉を常に忘れないこと。これは転職するしない、いずれの場合にも自分を窮地に追い込まないために、絶対に必要な視点です。自分と自分の職場を客観視しろってことですね。
みねじろ! @minejiro 2010年7月2日
昨日の内容を読み直すと、学生さんだけでなく、入社まもない人にも呼んでもらいたい内容になっていましたね。ちょっとそのあたりも考慮してm追記していこうと思います。また、昨日はちょっと脅かしすぎましたね(^^;
みねじろ! @minejiro 2010年7月2日
組み込み系ソフトウェア開発の世界をもう少し詳しく説明しましょう。ソフトウェア技術者以外にも多くの人が関係するという話を前にしました。今日はその人達との関係について。
みねじろ! @minejiro 2010年7月2日
まず、結論から言うと、経営者やお客様、ハードウェア技術者、生産技術者、サポート技術者、スタッフ、その他もろもろの関係者の中で、ソフトウェア技術者はたいていの場合、ヒエラルキーの最下層です(^^;
みねじろ! @minejiro 2010年7月2日
経営者から「ヒト・モノ・カネばっかり使って、さっぱり効率が上がらない上に製品のバグでお客様にご迷惑をおかけしてるじゃないか!今すぐ、なんとかしろ!」
みねじろ! @minejiro 2010年7月2日
ハードウェア技術者から「確かにハードの問題だが、今更、ハードや型(金型などの部品を作るに必要なもの)を変えると納期に間に合わないし、莫大なお金がかかる、だからソフトで何とかしてくれ!」
みねじろ! @minejiro 2010年7月2日
生産技術者「バグのせいで工場を止める気か!今すぐ直せ!今すぐ何とかしろ!」
みねじろ! @minejiro 2010年7月2日
サポート技術者「こんなに改修のバージョンアップで手間がかかって仕方がない、もっと回数を減らすか、簡単にしてくれないと人件費ばかりかかって仕方がない!」
みねじろ! @minejiro 2010年7月2日
お客様「(便利な機能を足すと)難しすぎて使い方がわからない!」「(簡素化すると)あれができなくなった、これができなくなった、困る!」「マニュアル?読まないよ、そんなもの」「契約事項?知らない」
みねじろ! @minejiro 2010年7月2日
営業「(オレの)顧客が要るって言ってるんだ!(他の営業なんてどうでもいいからオレの)顧客のためにこの仕様変更しろ!」「(オレに製品の使い方なんてわかるわけないから)開発者が出てきて説明しろ!」
みねじろ! @minejiro 2010年7月2日
法務「他社特許の侵害で被った被害はそちらの部門の予算で賄ってください」「自社特許の出しそびれによる損失利益はあなたたちの責任です」「(技術のことはわからないので)わかるようにその技術のポイントを説明してください」
みねじろ! @minejiro 2010年7月2日
人事「残業が多すぎるのに、何をしているかがさっぱりわからない。何を基準に上司が部下を査定しているかわからない。本当にちゃんとやっているのか!?」
みねじろ! @minejiro 2010年7月2日
経理「本当に必要でないものばかり買っている癖に、固定資産の紛失だけはどこよりも多いなんて、困った人たちですね!」
みねじろ! @minejiro 2010年7月2日
調達「効率化のため、この標準PC/ネットワーク機材しかウチでは購入しないことになったので、例外申請をして自分と見積りして調達してくださいね!」
みねじろ! @minejiro 2010年7月2日
代表電話「お客様からの技術的なお問い合わせについてですが、こちらでは答えられない内容なので、直接対応をしてください」
みねじろ! @minejiro 2010年7月2日
A国担当「B国のことなんて知らん!A国はこれじゃなきゃダメなんだ!」 B国担当「A国(以下同文)」 C国担当「どうしてA国、B国には特別対応してくれて、C国にはしてくれないんだ!不公平だ!」 D国担当「A国、B国、C国には必要でもD国には不要な機能を入れないでくれ!価格が上がって、発売が遅れるじゃないか!」
みねじろ! @minejiro 2010年7月2日
派遣社員「試作機のテストって事務機器操作業務じゃないと思います(ごもっとも)」
みねじろ! @minejiro 2010年7月2日
要求者「(電話で)これこれをやってほしい。追加予算はいくら(人数×月数×単価)かかる?」そんなこと派遣社員もいる職場で電話で答えられるか!
みねじろ! @minejiro 2010年7月2日
……と、まぁ、こんなところが、大規模組み込み系ソフトウェア開発の実態だったりします。一番厳しいのは生産技術者からのツッコミですね。彼らも命張ってやってますから。
みねじろ! @minejiro 2010年7月2日
ただ、生産技術者には、何万点もある部品の1個に過ぎない部品であるソフトウェア(ROMやチップ)ごときが、生産ラインを止める原因になるのが、これまでの感覚ではどうしても理解できないようです。
みねじろ! @minejiro 2010年7月2日
また、ハードウェア技術者は製造しやすい設計や生産ライン立ち上げの支援などで、比較的生産技術者と日頃から交流があるのですが、ソフトウェア技術者はそんなに繋がりがないので、どうしても立場が弱くなります。
みねじろ! @minejiro 2010年7月2日
しかし!今や組み込み系ソフトウェア技術者がいなければ、ハードウェア技術者は型で組んだパーツの試作試験すらできず、生産ラインは組み立てても出荷検査すらできず、営業はデモも販売もできなくなっているのです!
みねじろ! @minejiro 2010年7月2日
つまり、現在の大型組み込み系ソフトウェア開発は、ソフトウェア中心でなければ開発、生産計画を守ることすらできないということになります。しかしながら、この変革を達成できている企業はまだごくわずかです。
みねじろ! @minejiro 2010年7月2日
勘の言い方はお気づきだと思いますが、このソフトウェア中心の開発方式、かの有名な「カンバン方式」じゃないですよね?そう、あれもう時代遅れなんです。
みねじろ! @minejiro 2010年7月2日
かの会社が他社に指導して周り、各社が有難がって信奉している方式は、既にかの会社の中では旧Ver.であり、彼ら自身は既にもっと新しい方式で開発、生産をしているハズです。
みねじろ! @minejiro 2010年7月2日
それなのに、その新しいノウハウをコンサルティングに出さずに抱え込んでいたハズの会社が、あれだけ大きなリコールを起こした上に、品質担当の副社長が「わかってない」発言をしたために、組み込み系ソフトウェア開発者たちは驚愕したというのが去年のことでした。
みねじろ! @minejiro 2010年7月2日
日本人は比較的、ロボットや機械に抵抗がないのに対し、欧米人は本質的な警戒感(フランケンシュタイン・コンプレックス)を持っていると言われています。実は今は、この警戒感は現実のものです。
みねじろ! @minejiro 2010年7月2日
大規模ソフトウェア(組み込み系、IT系共に)は、既に誰にも全体が見通せず、完璧に管理することなどできないフランケンシュタインとなってしまいました。しかもその怪物に私たちは生活、事業、政府運営を委ねています。
みねじろ! @minejiro 2010年7月2日
ある意味、核兵器より身近で危険な存在になってしまった大規模ソフトウェア。これを何とかして維持、管理、改良していかない限り、私たちの社会はいつか、東証ハング、プリウス暴走を遥かに超える災厄に見まわれ、大きな損害を被ることでしょう。
みねじろ! @minejiro 2010年7月2日
これを怖い、関係ないといって、頭から布団を被って無視するのも一つの生き方です。否定はしません。しかしながら、これを杞憂だという一部の「専門家」の方には断固として「貴方は間違っている」と、現場から言いたい。
みねじろ! @minejiro 2010年7月2日
また、問題だけを指摘し、どうすればよいかに向けての動き出しをしない一部の報道機関や、問題に気づきつつも日常に流されているソフトウェア技術者には、ぜひ、自分と家族を守るために、何を変えるべきかを考えて一歩を踏み出して欲しい。
みねじろ! @minejiro 2010年7月2日
そして、ソフトウェア業界を目指す若き学生さんたちには、ソフトウェア産業の置かれている状況がどれだけ大きな問題を抱えているか、解決しなければならないかを少しでも理解してもらった上で、ぜひ一緒によくしていくために入ってきてください。一技術者として心からお願いします。
みねじろ! @minejiro 2010年7月3日
(主に組み込み系の)大規模ソフトウェア開発者が不遇(笑)なことはわかった。でも、何がそんなに難しいの?という疑問をお持ちの方がおられると思います。今日はそれについて話をしたいと思います。IT系にも通ずる話です。
みねじろ! @minejiro 2010年7月3日
従来のハードウェアを中心とした開発では、いわゆるウォーターフォール型、モデル型の開発を行って来ました。これは部品や製品全体を試作とテストを繰り返しながら、だんだん完成度を上げていく方法です。
みねじろ! @minejiro 2010年7月3日
ソフトウェアにもこれに似た考え方は存在します。例えばアジャイル型、テスト駆動型など。ただし、これらはいずれも小規模ソフトウェア開発に適した手法であり、大規模開発にはあまり適していません。
みねじろ! @minejiro 2010年7月3日
ハードウェアの開発はパーツごとに、丸いもの、四角いもの、尖ったものなどをそれぞれ試作し、組み合わせて動かしてみて(ここ、昔はハードだけでできましたが、今はソフトなしではもうできません)、悪いところを改良しながら仕上げていくというやり方です。今では3DCAD(三次元製図ツール)や、シミュレーションなどを活用して、試作回数を減らす方法が一般的です。
みねじろ! @minejiro 2010年7月3日
ところが、ソフトウェア開発ではこの手法が通用しません。ソフトウェアもハードウェアと同じく、モジュールと言われる機能ごとのソフトウェアの塊に分けて別々に造られます。ここで2つの問題が生じます。
みねじろ! @minejiro 2010年7月3日
一つめの問題は、組み込み系の場合、ハードウェアと組み合わせることになるので、試作ないし完成品がないとテストができないことです。ソフトとハードのでき具合が相手に依存しあっているため、作っているものが正しいか、間違っているかなかなかわからないことです。
みねじろ! @minejiro 2010年7月3日
しかも、試作回数を減らすのが主流ですから、実際のハードウェアと組み合わせる機会はどんどん減ってきています。ちなみに試作機は量産機の数倍から数万倍の費用を必要とします。しかも商品にはならないので、できるだけ作りたくないものだったりします。
みねじろ! @minejiro 2010年7月3日
2つ目は、ソフトウェアのモジュールの形(インターフェース)が、丸いのか、四角いのか、尖っているのか、見た目ではわからないということです。ハードウェアならあきらかに折れている部品も、ソフトウェアはコードの羅列のどこかが間違っていてもパッと見にはわかりません。
みねじろ! @minejiro 2010年7月3日
ゆえに、ソフトウェアでは複数のモジュール(画面表示するソフト、入力を受け付けるソフト、ランプを光らせるソフトなど機能ごとの塊だと思ってください)が、どんな形をしているか、繋げてみるまでわからない、手探りになってしまいます。
みねじろ! @minejiro 2010年7月3日
もっとも、ソフトウェアモジュールも、私は丸い(画面表示)です。私は四角い(入力受付)です。と宣言して作ってはいるのです。でも、本当に丸いのか、四角いのか、自己申告をそのまま信じると大変な目(バグ)にあいます。。。
みねじろ! @minejiro 2010年7月3日
これらの問題を防ぐ、減らす方法は業種の枠を越えて大勢のソフトウェア技術者たちが考え、改良、共有しあって発展させています。けれども、開発規模(コード量)の増大に追いついていないというのが現状です。
みねじろ! @minejiro 2010年7月3日
また、前に組み込み系のハードウェアとソフトウェアの組み合わせは足し算でなく掛け算だと書きました。これは部品数とコード量が増えることによって、動作の組み合わせが増える。システムとしての複雑度を増すことを意味しています。いや、掛け算ですらなく指数関数かもしれない。まさにフランケンシュタインの怪物です。
みねじろ! @minejiro 2010年7月3日
上記の話はIT系の大規模システムにも同じことが言えると思います。こちらは専門でないので、あまりハッキリとしたことは言えないのですが。
みねじろ! @minejiro 2010年7月3日
2つ目の問題を先に解説してしまいました。ここは、どんなに作った当人が丸だと言い張っても、本人も他人も気づいていないところで亀裂が入った真円でないかもしれないという前提でソフトウェアを造らないと行けないというくらいに理解をしておいてください。
みねじろ! @minejiro 2010年7月3日
1つ目の問題に戻ります。組み込み系ではソフトウェアとハードウェアはそれぞれ相手がないと動作確認ができないという話をしました。しかも試作はできるだけ減らしたいという話もしました。これはソフトとハードを組み合わせて動作確認をする機会が減ることを意味します。
みねじろ! @minejiro 2010年7月3日
実際には、以前の製品や、完成度の低い最初の試作品、シミュレータを使って動作確認を行うわけですが、お客様にお届けする商品である以上、ソフトウェアもハードウェアも最終品(完成品)での動作確認をしないままに出荷、販売することはできません。
みねじろ! @minejiro 2010年7月3日
ここに、試作回数の削減と、先に書き忘れましたが開発期間の短縮が重なるとどういうことが起きるか。開発の最後の最後で今まで、シミュレーションや少ない動作確認回数では見つからなかった問題、それも商品の根底を覆すような大問題が発覚することが非常に多く起きてしまうのです。
みねじろ! @minejiro 2010年7月3日
専門用語でいうと、システムテストという段階で大きな問題が見つかるということになります。以前、某社の品質担当の副社長が「システム視点が足りない」と言った発言をソフトウェア技術者が「わかっていない」と呆然とした理由はここです。
みねじろ! @minejiro 2010年7月3日
システム視点でのテストを増やすためにはどうしたらよいか?昔のように開発期間を延ばし商品モデルの更新サイクルを減らすのか?試作をたくさんつくって莫大な金をかけるのか?全く新しいシステム視点の動作確認方法を開発(発明)してバグや故障を減らすのか?
みねじろ! @minejiro 2010年7月3日
どれもすぐにできることではありません。しかも事業として見た場合、あ、まりにも非現実的な案です。それを副社長という経営トップが口にした、そのことに私たちは愕然としたのです(某社の開発スタイルについて知っている部分を重ねあわせたバイアスもかかっていますが。。。)。
みねじろ! @minejiro 2010年7月3日
しかし、あれだけ注目されている事件で世界一の企業のトップが発言したことは世界中の人間が、なるほど、これから「すぐに」もっとシステム視点で見た商品を売りだしていくんだなとと思ったことでしょう。
みねじろ! @minejiro 2010年7月3日
すぐに?今の人数で?今の人材(能力)で?現業務をこなしながら?無理だ!というのが、ソフトウェア技術者の本音です。もちろん、いつかはこうなるとフランケンシュタインの怪物の反乱はみんな予想していました。それを防げなかった落ち度は、一番大きくは私たちソフトウェア技術者自身にあります。
みねじろ! @minejiro 2010年7月3日
でも、それだけに安易に言質を取られる発言を佐々木氏がしたことに対しては、怒りに近い感情をもっています。では、それを実現するためのリソース(人物金)をいつ、どれだけ出すのかと。
みねじろ! @minejiro 2010年7月3日
また、トップ企業の約束したことは必ず業界や業界の枠を越えて、暗黙のうちにお客様から企業側に要求されます。これは厄介な宿題をもらったぞとソフトウェア技術者たちは頭を抱えてしまいました。
みねじろ! @minejiro 2010年7月3日
組み込み系開発では英語化の例をとって、ソフトウェア開発だけの改良は難しいという話を前にしました。つまり佐々木氏のいうことを実現するためには、関係する全員が問題点を把握し、方策を立て、「同時に」実行することが必要になってきます。
みねじろ! @minejiro 2010年7月3日
そんな大変なこと、誰が指揮しますか?数百人、数千人、数万人が開発には携わっています。企業トップしかいませんよね?そのトップがソフトウェア開発をどう見ているかは以前に書きました。「やっていることがわからないのに、人物金ばかり食う」です。
みねじろ! @minejiro 2010年7月3日
「わかっていない」経営者が「やります」を口にした。これがどういうことになるか。下に押し付けるが正解です。これは階層を通って再下段まで続きます。上がやるなら自分も。です。ここでもまた3つの問題がおきます。
みねじろ! @minejiro 2010年7月3日
1つ目は部分最適化の罠です。本来、システムというからには全体を見て、全体最適化をすべきところを、上が下に押し付けることによって各人が自分のわかる範囲だけをよくしようとします。これが部分最適化を産み、部分最適同士を組み合わせると、全体としては前をより、かえって悪くなったという、笑えない話が起きたりします。。。
みねじろ! @minejiro 2010年7月3日
2つ目はシステム視点を強化するためにかかる時間です。現状、ソフトウェア開発者とハードウェア開発者は互いに、相手が自分の欲しい時期にものを渡してくれないとイライラしながら仕事をしています。時間の流れ、ポイント、チェックする視点がそれぞれ違うためです。
みねじろ! @minejiro 2010年7月3日
これをシステム全体最適に合わせるためには、開発構造全体を変える必要があります。しかも、事業ですから現在の商品開発は続けながらです。これはかなり難しいです。例えるなら、サッカーで利き足中心で本番の試合のしながら、利き足でない方の足を利き足以上にうまく使えるようにするというようなことになります。
みねじろ! @minejiro 2010年7月3日
こんなこと、号令や優先順位付けができるのはトップ経営者しかいません。が、繰り返しになりますが「わかっていない」のです。技術者の絶望がどれだけ深いかおわかりいただけますでしょうか?しかも失敗したら、次は経営者は「オレがもうしないと約束したのに、またやった、これはお前らの責任だ」と言い出すのです。。。
みねじろ! @minejiro 2010年7月3日
3つ目はどういう変え方をすればよいか、誰にもわからないことです。研究や勉強はあちこちでされています。ただし企業秘密の壁や、いい案が思いついても、実際に試すにはあまりにも開発規模が大きすぎるために、なかなか実行に移せません。失敗できない実験をやるようなものです。
みねじろ! @minejiro 2010年7月3日
NASAが世界最高の技術者と時間と金額をかけて作ったスペースシャトルが、たった一個の+と-を間違えただけで、空中爆発の悲劇を起こしたことを思い出してください。いかに難しいことを企業単位で求められているか、少しはおわかりいただけるのではないかと思います。
みねじろ! @minejiro 2010年7月3日
従って、本件全体の大きな問題の一つは「わかっていない経営者」にあるという、先の結論に至ります。即刻引退などと不穏当な発言には、こういう考察が裏にあるのです。
みねじろ! @minejiro 2010年7月3日
しかし、経営者も一人の人間です。わからないから経営してはいけないということは、もちろんありません。問題はわかっているフリをして、真の問題解決から遠ざかっていることです。
みねじろ! @minejiro 2010年7月3日
また、フランケンシュタインの怪物を日々世に放ちつつ、その暴走を防ぐための試みを部下や業種を越えた研究会(勝手連)に任せ、経営者自身が学習も自分の手を使った問題解決に取り組まないことです。
みねじろ! @minejiro 2010年7月3日
さて、組み込み系の話をしてきましたが、IT系にも言えると書きました。大規模なIT系開発でも、最後の最後まで動作確認ができないという点では、全く同じ課題を抱えています。詳しい内情を私は知らないので、そのあたりは割愛します。
みねじろ! @minejiro 2010年7月3日
これらの現状を打破し、怪物に脅かされることがない生活を人々が送れるよう、組み込み系やIT系のソフトウェア開発の世界により多くの意志をもった若い人が入ってきてくれることを期待しています。お願いします。ソフトウェア開発は地球を救う!冗談じゃなく、これを一緒に追いかけましょう!
みねじろ! @minejiro 2010年7月3日
文中、例にあげたトヨタ自動車株式会社の佐々木眞一副社長についてのコメントは氏の能力や人格を否定するものではなく、氏のある特定の発言に限って、残念ながら不適切なものであったということを指摘したものだとご理解いただけますよう、お願いいたします。
みねじろ! @minejiro 2010年7月3日
組み込み系ソフトウェアの大規模開発は、自動車、デジタル複合機、カーナビ、携帯電話、大別すると4種類くらいですね。前2つがハードウェア部品の点数と可動部分が多く、後2つが少ないという特色があります。それぞれ、アナロジーとして比較しあうことが多いです。IT系はそれこそインフラだから千差万別。案件単位。
みねじろ! @minejiro 2010年7月4日
なんだか、組み込み系の悪いことばかり書いたので、少しはよい話もしましょうか。結構細分化が進んでいるので、自分の専門分野を見つけると、割と簡単に第一人者になれます。セキュリティ、ドライバ、セーフティ、ユーザビリティなどなど。
みねじろ! @minejiro 2010年7月4日
業界団体、同業他社間交流も比較的盛んです。特に通信系は相互更新試験などで、かなり突っ込んだやりとりを競合相手ともしますね。この腹のさぐり合いは、意外と楽しかったりします。
みねじろ! @minejiro 2010年7月4日
しかし、絶対に逆らえない神様企業が存在するのも事実です。自動車やカーナビなら車メーカーには逆らえません。通信系ならNTTに逆らえず。まぁ、最近はかなり態度がどちら軟化しつつありますが。
みねじろ! @minejiro 2010年7月4日
しかし、組み込み系のIT系も勝ち組企業連合が確実に構築されつつあります。学生さんも、今、就職予定している会社が来年には、どことくっついているかわからない。従って担当業務も大きく変わることがあるということは、予想していてください。
みねじろ! @minejiro 2010年7月4日
これは、仕事の幅や視点を広げるチャンスでもあるんですけどね。大規模ソフトウェア開発では、どうしても細分化、部分最適化が進みがちなので、気がついたら、その技術しかできなくなっていて、しかもその技術はもう時代遅れ、なんてことがよく起こりえます。しかもその速度がどんどん増している。
みねじろ! @minejiro 2010年7月4日
リバースオークションや、政府、軍関係のセキュリティ重視により、求められる機能や品質が高度化しているのも、また大規模ソフトウェア開発の実態です。これに対抗するためには、常に最新技術と動向を把握しておくことが、なにより大事です。IT系のニュースサイトの流し読みでも構いません。ただし、毎日することと、自分なりの判断をそこですることが肝要。
みねじろ! @minejiro 2010年7月4日
また、ソフトウェア開発の利点としては、これらの要求高度化にハードウェアより対応が比較的容易という点があげられます。いろいろとハードウェア技術者に「貸し」を作るわけですね。ただ、相手が「借り」だと認識してくれないのが悩みの種ですが。。。
みねじろ! @minejiro 2010年7月4日
あえて喧嘩を売るような書き方をすると、ハードウェア設計は力学、電磁気学、その他諸々の物理現象による大きな制約があります。これらをブレイクスルーした時の発展はものすごいのですが、そうそういつも起こせるものではない。
みねじろ! @minejiro 2010年7月4日
従って、デザインやブランド変更でお茶を濁すことが昔からありましたが、最近、だんだん増えてきています。好きな工業製品をよく見てください。季節モデルでの変化が大してなくなってきてるでしょう?
みねじろ! @minejiro 2010年7月4日
しかも、ちょっとでも、新しい飯の種になりそうなハードウェア技術に飛びついて必死です。悪い例をあげます。3D TV。マスコミに金を出し、販促費をバンバン使ってますが、あれ、私の予想では大コケします。少なくとももう一段階機能アップして、裸眼視できない限りは。
みねじろ! @minejiro 2010年7月4日
あ、また、同業者に刺されそうなことを書いてしまった。でも、藁にもすがる思いで、必死に新商品を出している皆様には敬意を評します。本音のところ、あんまり作って楽しくないでしょ?正直な気持ちとして。ハード、ソフトの両技術者もノウハウを身につけるための実験台と割りきって作ってるでしょ?
みねじろ! @minejiro 2010年7月4日
こう書くと、生産と物流と販売サイドから刺されそうですが、誰が落ち着いてTVを見たい時にメガネをわざわざかけるかってことです。バーチャルボーイをナショナルブランド企業が作ってどうするんだって話。
みねじろ! @minejiro 2010年7月4日
余談になりますが、なんとか1000mg配合と同じことや、なんとかウォッシャーをナショナルブランド級の企業が始めた日本の製造業はかなりヤバいと思っています。これを変える気力のある若い人に来て欲しい。でも、染まっちゃう安定志向はソルジャー扱いで使いますので覚悟のほどを。
みねじろ! @minejiro 2010年7月4日
これも繰り返しになりますが、iPadは日本でも作れるといいつつ、こんな商品を出している経営者はハッキリ言って阿呆の極みです。黙ってれば給料分の損で済むところを。なんてことを抜かすのかと思います。こんなのが1億くらい貰ってるのかと思うと、ゴーンの9億の方がはるかに有効です。いや、ゴーンに9億がいいか別の話しとして。
みねじろ! @minejiro 2010年7月4日
ちょっと、今日は脱線が多かったですが、今の組み込み系ソフトウェア開発現場はちょっとオカシイ。この感覚を持った上で参加してくれる若い人を私たちは歓迎します。IT系は昔からIT系土方と言われるくらいオカシイのでノーコメントw
みねじろ! @minejiro 2010年7月4日
あ、そうそう。私が執拗に経営者をバカにしてるのには理由があります。彼らは例えば3D TVが大コケしてもおそらく退任しません。ここが欧米企業と違うところです。なのに1億以上はグローバルとかギャグぬかすなってことです。連結赤字で2億近く貰ってる、某HDのあなた、特にオカシイですよ。
みねじろ! @minejiro 2010年7月4日
と、言いながらも組み込み系大規模ソフトウェア開発の場に残り、学生さんにメッセージを発信し続けているのは、1人では決して実行できないチーム作業であることと、新しい発想と継承が必要だと強く感じているからです。ぜひ、一緒に働きましょう。
みねじろ! @minejiro 2010年7月4日
私と同じ思いを持っているソフトウェア開発者はたくさんいます。そういう人は必ず、新人となる貴方に間違った道や迷路に迷い込まないよう、導いてくれることでしょう。そういう人と出会える就職活動をぜひ、進めてください。
みねじろ! @minejiro 2010年7月4日
願わくば、そのうちの1人でも私自身と一緒に仕事ができますように。七夕飾りに書いておこうかしらw
みねじろ! @minejiro 2010年7月4日
あ、そうだ。学生さん向けのアドバイスとしては、役員面接なるものがあったら、しっかり役員さんの自分流の品定めをするのを忘れないでください。なんとなく、でよいです。この感覚でハズレがあると、どんなによい企業でも就職してから違和感を感じてしまうハズです。
みねじろ! @minejiro 2010年7月5日
組み込み系ソフトウェア開発の問題がまた一つ、大きく報じられました。CNET Japanのこのニュース http://bit.ly/9VI1YY iPhone4のアンテナの受信感度判定を間違えていたというものですが、これ、おそらく中身は非常に単純なソフトウェアのミス(バグ)です。
みねじろ! @minejiro 2010年7月5日
iPhone4のアンテナの件、内容的には詳細設計か、せめてコードレビューの段階で見つけておくべきトラブルです。もしも、そこを逃しても実機で動作確認をすれば見つかっていた可能性がかなり高いトラブルです。
みねじろ! @minejiro 2010年7月5日
iPhone4は確かSAMSUNGが作っていたと思いますが(違っていたらゴメンナサイ)、世界有数の組み込み系開発(家電からオフィス器具まで色々作ってます)企業ですら、こんなミスをやらかす。いわんや他の企業もです。
みねじろ! @minejiro 2010年7月5日
ここからは私の推測になりますが、iPhone4のアンテナ問題には大きくわけて5つの問題があります。これからソフトウェア産業に入る人たちにも、ぜひ心に留めおいてほしいことを書きます。
みねじろ! @minejiro 2010年7月5日
一つめは、iPhone4はAppleが要求しSAMSUNGが開発製造する、いわゆるODM形態の商品だったことです。この手の開発形態では責任が曖昧になり、問題が見逃されやすくなります。
みねじろ! @minejiro 2010年7月5日
個人的には両者のどちらがどれだけの改修コストをもつのかとても興味がありますが、企業シークレットのハズなので多分、公表はされないでしょう。
みねじろ! @minejiro 2010年7月5日
二つ目は、短期開発です。iPhone4はApple(というかジョブズ)のやり方として、新商品の発表から発売までが非常に短い企業です。こういう場合、発表後に見つかった問題をどうするかはとても大きな問題になります。
みねじろ! @minejiro 2010年7月5日
個人的には、両者あるいはSAMSUNGがはこのiPhone4のアンテナ問題に事前に気づいていたのではないかと思います。問題になってからの原因究明と対策発表が少し早過ぎるように感じるからです。
みねじろ! @minejiro 2010年7月5日
さらに、AppleもiPhone4のアンテナの問題を分かっていた上で、予定通り発売し、すぐに改修を発表することで、禍転じて福となすを、最初から狙っていたんじゃないかという線も疑っています。
みねじろ! @minejiro 2010年7月5日
三つめは、iPhone4の開発に関わった技術者自身のスキルレベルの問題です。基本設計段階では、この手の間違いは起こりません。詳細設計、レビュー、ホワイトボックステスト、ブラックボックステストなど、担当者個人に渡ってから仕込まれるバグです。
みねじろ! @minejiro 2010年7月5日
これも個人的な感想ですが、「日本人のできませんは実はできる。韓国人のできますは実はできない。中国人のできましたは実はできていない」という格言がこの場合は働いたのではないかと推測しています。
みねじろ! @minejiro 2010年7月5日
先の発言に、人種差別の意図はないです。これは技術者間でよく使われるジョークです(本気でこうなって洒落になってならないことは日常茶飯事ですが……)。
みねじろ! @minejiro 2010年7月5日
iPhone4の開発は、SAMSUNGがでなくLGだというご指摘をいただきました。スミマセン。本論には関係しないので、上記コメントはそのまま残して続けます。
みねじろ! @minejiro 2010年7月5日
四つめは、iPhone4の開発チェック体制の不備です。もちろん詳しくはわからないのですが、一つめと二つめの関係で、十分なプロセスを踏むリソース(人物金)がなかった。あるいは、最初からプロセスがなかった可能性があります。
みねじろ! @minejiro 2010年7月5日
残念ながら、私自身は韓国の組み込み系ソフトウェア開発をやっている企業と直接の関わりがないので、よく知らないのですが、割と一点豪華主義で、ポイント(だと思うところ)を押さえたら、あとは任せる型のスタイルだと思っています。
みねじろ! @minejiro 2010年7月5日
従って、アンテナではない部分、液晶(これも問題を起こしていますが、これは開発より製造、部品の問題だと思うので割愛)やOSなどの「売り」の部分に注力し、アンテナは手をかけていなかったのではないかと推測しています。
みねじろ! @minejiro 2010年7月5日
とはいえ、何でも念入りにやりすぎる日本企業のスタイルは、それはそれで問題だらけだとも思うのですが。。。難しいですね、このあたりは組み込み系の技術者はみんな試行錯誤の毎日です。
みねじろ! @minejiro 2010年7月5日
五つめは、例外処理や異状処理についての感度の鈍さです。これは、三つめと四つめと絡むのですが、担当技術者が右手でiPhone4をもつ癖があって、左手で持つことがない人だとしたら、それだけでもバグが仕込まれる要因になります。
みねじろ! @minejiro 2010年7月5日
この例外処理、異状処理は、痛い思い(スペースシャトル爆発のような大トラブル)をして、修練で積み重ねていく部分と、センスが問われる部分です。落とし穴とかイタズラが好きなタイプの人、向いてますよ。いや、ホントに。
みねじろ! @minejiro 2010年7月5日
某ブレーキ事故の話に少しそれますが「(ブレーキの効きが悪くても)もっと踏めば止まる」と発言したアホな経営者がいました。この人、あるいはこの人にそれを伝えた部下は、例外処理、異状処理に弱いタイプです。
みねじろ! @minejiro 2010年7月5日
ブレーキを踏んだら効かなかった場合、全員がもっと踏むとしか想像しない、発想の貧困さはもう犯罪級です。間違ったペダルを踏んだかと思って足を外す人がいることを全く想定していない。アホどころでは済まない発言でした。私はTVで見て、口をあんぐり開けたことを覚えています。
みねじろ! @minejiro 2010年7月5日
さて、iPhone4の話に戻しましょう。本来なら詳細設計やコーディングの段階で見つけるべき単純なバグですが、もし仕込んでしまった場合は、売りに出す前に何とかして見つけなければなりません。
みねじろ! @minejiro 2010年7月5日
この方法の一つがテストです。シミュレータでも実際の機械でも構いません。考え方の問題がここにあります。見つけ方には大きく分けて二種類のアプローチがあります。
みねじろ! @minejiro 2010年7月5日
一種類目は、経験則です。痛い思いをして、例外処理、異状処理に詳しい人に開発チームに入ってもらうことです。あるいは、痛い思いをたくさん共有し、データベース化やプロセス、ルール化して、同じ、似た過ちを繰り返さないようにする方法。
みねじろ! @minejiro 2010年7月5日
二種類目は、総当りで考えつく限り全ての操作パターンを試すことです。ここは割と研究が盛んな分野で、農業実験などからヒントを得た方法などで、できるだけ少ない組み合わせで全部の操作パターンを押さえる方法などがあります。本も色々あるので、詳しくは検索してみてください。
みねじろ! @minejiro 2010年7月5日
個人的には、この二種類の方法を組み合わせて、全体をカバーしつつ、突拍子も無い問題が起きないようにするのが、現時点では一番よい方法だと思っているのですが、なかなかこれで十分と思えない、度胸がいる分野だったりします。若い人たち、一緒にバンジージャンプしましょうw
みねじろ! @minejiro 2010年7月5日
余談ですが、力学や電磁気学などに裏打ちされないソフトウェア開発は、ここまでやったから大丈夫という安心が、どうしても得られないのが、結構ストレスの種だったりします。「5年間無故障で動きます」なんて、少なくとも私には絶対言えない。。。
みねじろ! @minejiro 2010年7月5日
さて、ここで五つめの問題が一つめの問題に関わってきます。iPhone4の最終的な品質確認は、AppleとLG(SAMSUNG?)のどちらにあったのでしょうか?
みねじろ! @minejiro 2010年7月5日
トラブルの内容的には開発した側のチョンボなので、そもそも仕込むべきでなかった責任が開発企業側にあると思います。ただし、バグのないソフトウェアリリースはありません。だから、問題になるのです。
みねじろ! @minejiro 2010年7月5日
この手のODM契約の場合、最終確認や問題が起きた場合の責任、対応は通常、必ず契約で取り決められます。ここ、組み込み系やソフトウェアに限らず、開発企業で働く人はみんな関係するポイントですよ!w
みねじろ! @minejiro 2010年7月5日
ODMには、商品の最終責任まで開発企業に全部任せる場合、共同開発に近い形で要求企業が入り込む場合、最終確認か途中から最後までの確認は要求企業が担当する場合、契約の種類だけ形があります。
みねじろ! @minejiro 2010年7月5日
残念ながら今回のケースでは、Appleがどういう契約を結んでいたのか(かなりAppleに都合がよい契約だと思っていますが)、わからないので、これ以上のことは言えないのですが、ここに関わる問題を両社が打ち合わせていることは間違いないです。
みねじろ! @minejiro 2010年7月5日
さぁ、ここで経営者を散々アホ呼ばわりしてきた一技術者から、学生さんへの大事なアドバイスを一つ。上の人はわかりません。また組み込み系は細分化が進んで専門家になりやすいと書きました。では、どういうことになるでしょう?
みねじろ! @minejiro 2010年7月5日
答えは、トップ会談クラスの打ち合わせに、ペーペーの担当者が同席して説明させれることがありうる、です。どうせ、自分しかわからないからオレの時間だ!とこれを面白いと取る人もいれば、ストレスにやられる人もいます。自分の性格をよく考えてみてくださいね。
みねじろ! @minejiro 2010年7月5日
今回のiPhone4のアンテナトラブルを通して、学生さんたちに私が伝えたかったことは、組み込み系でも何でも就職して担当分野を持ったら、その企業を代表して、自分が相手にわかるように自分の仕事内容や結果を説明することが求められるということです。
みねじろ! @minejiro 2010年7月5日
よって、よく最初のうちは何でもメモを取れと言われますが、あれはメモを取って覚えることだけが目的なのではなく、緊急事態に自分の担当のことをを今すぐ答えろ!と求められた時に、即応できる準備をしておくための練習なのです。ここ、本当に大事なポイント。絶対役に立ちます。オッサン嘘つかないw
みねじろ! @minejiro 2010年7月5日
ということで、問題解決のため、行きたくもない出張に出かけている隙間時間を見つけた、組み込み系ソフトウェア開発に携わる一技術者からの、今回のiPhone4アンテナトラブル問題をネタにした、学生さんへのお伝えしたいことでした。
みねじろ! @minejiro 2010年7月5日
言うまでもないことかもしれませんが、私個人の思い込みや誤認を除いて、ここに書いてあることは全て、ソフトウェア産業の実態であり、今の問題であり、私が危惧している将来像です。
みねじろ! @minejiro 2010年7月5日
少なくとも自分で手を動かしているソフトウェア技術者なら、多くの方(全てとは言いません)は、どれか一つ以上は思い当たる節があることを書いたつもりです。
みねじろ! @minejiro 2010年7月5日
ソフトウェア産業に属する企業で、就職用のパンフレットに綺麗事を書いて騙そうと(暴言)している人事担当者、経営者の方には憎々しいことを、おもいっきりぶっちゃけています。
みねじろ! @minejiro 2010年7月5日
それでも、騙されて就職して挫折されるより、実態を知った上で、ソフトウェア産業の必要性と、働くためにもっておいた方がよい資質、知っておくと役に立つことを覚えておいてもらった方が、絶対にいい。
みねじろ! @minejiro 2010年7月5日
また、直接、間接を問わず、ソフトウェア技術者と関わりを持って仕事をされている方、ソフトウェアを利用して生活されている方(ほとんど全員やね)に、実態と問題を知ってほしいと願っています。
みねじろ! @minejiro 2010年7月5日
二度と宇宙船が爆発しない。二度と証券取引が止まらない。二度と車のブレーキが効かなくなったりしない。そんな日はひょっとしたら永遠に来ないかもしれない。
みねじろ! @minejiro 2010年7月5日
それでも、その問題が実際に起きるのを一日でも先に延ばすために、私たちソフトウェア技術者は毎日、力を尽くしています(時々、遊んでますがw)。これから、この世界に入ってくる学生さんたちと志を同じくして、進んでいけたら、これほど嬉しいことはないです。
みねじろ! @minejiro 2010年7月8日
ここまでソフトウェア産業の実態と予想する将来像について、ずっと書いてきましたが、質問などありましたら遠慮無くどうぞ。ちゃんと定義を説明してない単語もいくつかあったりするので。。。
みねじろ! @minejiro 2010年7月8日
また、就職や進学を控えたお子さんや学生さんをお持ちの大人の方には、この内容を自由に見せていただいたり、プリントや引用していただいて構わないので、ぜひ活用してくださいませ。
みねじろ! @minejiro 2010年7月15日
ソフトウェア開発は品質=完成形からそれを達成するプロセス=開発形態を考えるべきです。そこでチェックアイテムを2冊追加しました。
みねじろ! @minejiro 2010年7月15日
一冊目は『ソフトウェア品質保証入門―高品質を実現する考え方とマネジメントの要点』です。学生さんにはこれをお勧めします。もちろんプロの方にも。
みねじろ! @minejiro 2010年7月15日
二冊目は一冊目の原著である『ソフトウェアの検査と品質保証』です。こっちは学生さんならソフトウェア品質保証自体の研究をしている方でなければ、一冊目だけで十分かなと思いますが、詳細度は入門編よりこちらが上です。
みねじろ! @minejiro 2010年7月15日
私は、学生さんなら今回紹介した一冊目を読んで頭の中に大規模ソフトウェア開発のイメージを自分なりに構築するなりしてから、凡多(失礼)の他の本を手法として読むのがよいと思いますよ。
みねじろ! @minejiro 2010年7月15日
いきなりソフトウェア開発「技法」の本を読むと、その「楽しさ」に負けて「仕事」にうまく活かせない危険があると思っています。言語や開発方法なんて何でもよいんです。大事なのは「産業」として、どう開発プロセスを構築する、回す、改善し、儲けるかなのだから。
みねじろ! @minejiro 2010年7月15日
どのくらいのおすすめ度かと言うと、他のチェックアイテムが星五つなのに対して、私が紹介したのは四つと四つ半ですが、じっくり読み込まれたソフトウェア開発のプロ方の評価としての深さを備えての四つだと思います。
みねじろ! @minejiro 2010年7月15日
どのくらいオススメするかというと、もし一冊目を「わからない」「不要」「読みたくない」と言うソフトウェア開発者がいたら、私はその方とは一緒に仕事をしたくないくらいにオススメします。
みねじろ! @minejiro 2010年7月15日
大規模ソフトウェア開発の現場に入ると、どうしても大量の業務量やトラブル対策に忙殺されたり、その開発現場独自の「文化」に慣れて考えなくなってしまいがちです。
みねじろ! @minejiro 2010年7月15日
今回オススメした両書は、ソフトウェア開発を体系的に捉えるための良書中の良書です。タコツボ化してダメ開発者に陥らないためにも、買って損なしです。ぜひ読んでみてください。
みねじろ! @minejiro 2010年7月16日
ソフトウェア関連の教育は、今は大学院で実験計画法を習うところもあると @jinmensou さんに教えてもらって、かなり学習、研究内容も進化したなぁと思います。
みねじろ! @minejiro 2010年7月16日
私の時代は日立の6809なんて化石を使ってたっけ(^^;
みねじろ! @minejiro 2010年7月16日
ただ、プログラミング技法や理論にどうしても偏りがちに見えるので、プロジェクトマネジメント的な要素も加えた、グループワークがあってもよいかなと思います。
みねじろ! @minejiro 2010年7月16日
ロボットコンテスト、あれいいですよね。ただ、自発的にやりたいメンバーが参加する形なので、教育研究にも組み込むことで、実社会(要は真面目にやる気のない人もいるチーム)を作るのもよいかもしれない。
みねじろ! @minejiro 2010年7月16日
もし私がロボットコンテストを使った講義をするなら、設計仕様書と操作手順書付きで作成するルールにします。
みねじろ! @minejiro 2010年7月16日
で、1回目の対戦では操作は他のチームが「操作手順書」を読んで実施する。作成チームは質問対応と修理対応だけを行い、操作は実施しない。
みねじろ! @minejiro 2010年7月16日
この入れ替えを行うことで、産業としてのソフトウェアは、作成者と使用者が違うことを実体験してもらうわけです。
みねじろ! @minejiro 2010年7月16日
そして、操作手順書だけでは、実際に操作したチームに伝わらなかった部分を直す作業を入れます。で、また今度は、さらに違う3チーム目に使ってもらう。2チーム目は慣れているのでダメ。
みねじろ! @minejiro 2010年7月16日
これは、実際のソフトウェアは使用者が複数いることを想定してのものです。また違う意見が出てきたら、さらに操作手順書のアップデートを行ないます。
みねじろ! @minejiro 2010年7月16日
ソフトウェアに限らず、実務に付かれている方はご承知かと思いますが、PDCAを回すわけですね。Pが実際のロボットと操作手順書の作成、Dが別のチームのロボット使用、Cが手順書の改良、Aが3チーム目がまた使うにあたります。
みねじろ! @minejiro 2010年7月16日
この手法はロボットでなくソフトウェアだけでも通用する手法なのですが、私自身はロボットなど組み込みソフトウェアでやるのがよいと思っています。
みねじろ! @minejiro 2010年7月16日
その理由の一つは、ハードウェアは「壊れる」こと。組み込み系では特にこの視点が大事です。破壊、故障、暴走、発火などに備えた作り込みがどれだけできるかを実体験してもらう。
みねじろ! @minejiro 2010年7月16日
また、運悪く(笑)それらの「壊れる」が起きた場合、自分が作ったわけではない操作者に怒られることになります。実際の業務でクレームを受けた場合、またクレームを付ける側になった場合のよい訓練になると思う次第です。
みねじろ! @minejiro 2010年7月16日
人間、自分のミスには甘いけど、他人のミスには厳しい。これをぜひ実体験してみましょう。学生のうちに。
みねじろ! @minejiro 2010年7月16日
クレームには、思いもよらぬ改善提案が含まれていることがあります。これを対応するかしないかを検討する。これもまたよい練習です。2チーム目からの指摘は3チーム目にとって有用かの視点が必要になってきます。
みねじろ! @minejiro 2010年7月16日
さらに、実際のロボットを改良すれば、それに合わせた操作手順書と設計仕様書の改訂作業も行われることになります。これはとてもよい修練になるハズです。
みねじろ! @minejiro 2010年7月16日
ここまでで一つのPDCAが回ります。でも、もう一つ大きなPDCAを回すことがこの課題設定では可能です。設計仕様書を軸としたPDCAです。
みねじろ! @minejiro 2010年7月16日
操作手順書で別のチームにロボット操作をしてもらったのと同様に、設計仕様書を元に別のチームに同じものを作成してもらうのです。
みねじろ! @minejiro 2010年7月16日
これは、かなり難しい課題になるハズです。ただし組み込み系の場合は、試作と量産の違いについて知るよい訓練になります。IT系の場合は、似たような案件をどれだけ楽にできるかの訓練になります。
みねじろ! @minejiro 2010年7月16日
実際にこれをやるとしたら、操作手順書のPDCAは1~3ヶ月サイクルで、設計仕様書のPDCAは半年から1年サイクルでやる形になるでしょう。いい、講座になりそうだな。うん。
みねじろ! @minejiro 2010年7月16日
これに似たようなことは、高専、大学、大学院でも行われていると思いますが、私が知る限りでは「一品物」で「先輩から後輩への伝承」の形であり、産業的な構造ではないと思っています。
みねじろ! @minejiro 2010年7月16日
「研究」「サークル」という視点では、もちろんそれは正しいアプローチなのですが、職業教育の観点から見た場合、私が指摘したような2つのPDCAで、開発者と使用者、開発者と生産者の視点を養うことも、取り入れてほしいなと思います。
みねじろ! @minejiro 2010年7月16日
大学院でなくとも、企業の新人研修でこれをやるのもよいですね。
みねじろ! @minejiro 2010年7月16日
と、飯の種になりそうなことをタダで公開してしまいましたが、ソフトウェア「産業」をよりよくするために、どこかの大学、大学院で教えて居られる方、また企業の新人教育担当の方がおられましたら、ぜひ採用を検討してみてくださいませ。
みねじろ! @minejiro 2010年7月16日
もし、似たようなことをやったことがある、やっている、やろうと思っている方がおられましたら、お知らせください。ぜひ、一緒にやりましょう。もっとも宮仕えの身ゆえ、専念はできませぬが。。。
みねじろ! @minejiro 2010年7月18日
商品としてのソフトウェアのバグはどんな呼び方をしようと、以下の5つのカテゴリに集約されます。「今すぐ直せ」「次のリリースで直せ」「商品化までに直せ」「直せるなら直せ」「直せません」
みねじろ! @minejiro 2010年7月18日
だから、どんなソフトウェア産業の職に付いたとしても、この読み替えテーブルを自分の頭の中に構築することが大事です。よく陥るのは原因系で区分けしてしまうこと。バグを悪影響の大きさでなく、技術的な難しさで考えると、商売として大失敗します。
みねじろ! @minejiro 2010年7月18日
これは、実際にコーディングするプログラマだけでなく、関係する全ての人が理解している必要があります。この認識が共有できている開発組織は色々な意味で「強い」ですよ。
みねじろ! @minejiro 2010年7月18日
ただ、悪影響の大きさを考える際、売り先、顧客の重要度との掛け算が難しい問題になってきます。IT系は一品物が多いので、お得意様重視で済むことが多いのですが、組み込み系だと大量生産している商品が、このジレンマに陥ります。
みねじろ! @minejiro 2010年7月18日
「重要顧客だから」「主力商品だから」「人体に危険があるから」など、「今すぐ直せ」になる理由がいくつも絡み合ってきます。正直、正解は各社、各組織ごとに違うので標準的な解はおそらくありません。
みねじろ! @minejiro 2010年7月18日
標準的な解がない重要な判断、意思決定は組織を束ねる者の仕事です。もし、先にあげた3つの理由による「今すぐ直せ」のトラブルが同時に起きた場合、どれから順に対処するか?これは非常に難しい判断を迫られることになります。
みねじろ! @minejiro 2010年7月18日
小さい組織、ソフトウェアでは、技術者が最上位の判断者を兼ねていることが多いため、この問題に答えることが比較的容易なのですが、大規模な組み込み系ソフトウェア開発では、組織階層のどこかで理解の断絶が発生しがちです。
みねじろ! @minejiro 2010年7月18日
私が「間違っているのは大企業」と先日述べた理由の一つがこれです。最終的には社長あるいは社長から判断権限を移譲された者が、判断決定を迫られるケースがあります。
みねじろ! @minejiro 2010年7月18日
ちょっと組織論に流れたので、ソフトウェアに話を戻すと、(ソフトウェアが)わからないのに。どうやって経営者が判断するのか?という命題に辿り着きます。
みねじろ! @minejiro 2010年7月18日
技術担当の重役を置く、品質保証部門を社長直轄にする、開発プロジェクトリーダーが全権限を持つ、形は色々あると思います。標準的な解はないというのは、こういう意味です。
みねじろ! @minejiro 2010年7月18日
従って、バグの5区分を理解した次に、新人にとって大事になってくるのは、バグ対応の優先順位を最終的に決定するのは誰であるかを、把握することです。
みねじろ! @minejiro 2010年7月18日
つまり、誰がどういう判断を下すかを予想して、その想定に元に自分ができることをやる。ここがポイントです。特に技術的に優れている必要も、コーディングが早い、上手である必要もありません。
みねじろ! @minejiro 2010年7月18日
指示待ちになるな、ということの言い換えなのですが、じゃあ具体的にどうすれば、指示待ちにならずに大規模なソフトウェア開発の中で動けるようになるか、2つのポイントでした。
みねじろ! @minejiro 2010年7月18日
もう一つコツを。きょうび正社員だけの大規模開発をやっている国内企業はほとんどないと思います。もし、あなたが正社員で先輩上司でなく派遣社員や委託契約先の人の動くをよく見てみましょう。
みねじろ! @minejiro 2010年7月18日
彼らは雇用の不安定さというリスクを回避するために、優先順位と権限を誰が持っているかを、見抜くことに長けています(不幸にも必要に迫られてですが。。。)。びっくりするくらい正確に把握していますよ。
みねじろ! @minejiro 2010年7月18日
もし、あなたが派遣社員や委託契約で大規模ソフトウェア開発に関わる場合は、この2つのポイントは生死に関わる問題になってきます。何よりも先に見抜けるようになりましょう。
みねじろ! @minejiro 2010年7月18日
もし、あなたが判断する権限を持っている場合は、、、わざわざ私が言うまでもないですよね。悩むのが最悪で、たとえ間違っていても、とにかく決断をして動き出すだけです。
みねじろ! @minejiro 2010年7月18日
実際、どんなにエレガントに見える会社であっても、大規模ソフトウェア開発の現場は、どこもこのジレンマに追われていて、判断ミスも大量にしています。それでも何とか食っているという世界。
みねじろ! @minejiro 2010年7月18日
勘のいい方はお気づきだと思いますが、日本のホワイトカラーの生産性が低い理由とこれは相関があります(笑)。判断すべき人が判断しないか、判断が間違っているか、判断する人がいないので、無駄な仕事が生まれるのです。
みねじろ! @minejiro 2010年7月18日
あまりにもよい題材なので、iPhone4をまたネタにしますが、この件はジョブズが最終決定者です。また、彼は発売前から知っていた上で「発売は予定通りする」「ありふれた問題であると宣言する」「一番安く確実なケース配布で解決する」という判断をしています。
みねじろ! @minejiro 2010年7月18日
彼の判断が道義的に正しいかは他の方の判断に委ねるとして、事態収拾のためのトップの判断としては実に鮮やかです。対策チームもかなり動きやすかったであろうことが想像できます。
みねじろ! @minejiro 2010年7月18日
でもね、せいぜいボヤで済む程度の組み込み系商品だからこれで済むのであって、自動車やロボットなどを作っている経営者が、これと同じことをしたら死人だらけに。。。難しいです。やっぱり。
みねじろ! @minejiro 2010年7月18日
ソフトウェア産業を目指す学生の皆さんには、上記2つのポイントをよく理解した上で、できるだけ判断が早いか正しいかの条件に合った職場に配属されますように。。。
みねじろ! @minejiro 2010年7月22日
ソフトウェア産業のウツ病患者が多い理由の一つは、全て論理で作ったものが、論理で説明できない動作(未解明のバグ)をすること。それまでのハードウェアの鉄則であるバスタブ曲線が通用しない。
みねじろ! @minejiro 2010年7月22日
ソフトウェアの非常に稀なトラブルが、たとえ発生確率を推計できたとしても、最初に電源を入れた瞬間に起きるかもしれないし、商品寿命まで起こらないかもしれない。
みねじろ! @minejiro 2010年7月22日
ソフトウェア屋は、自分の書いたコードや作った製品が「絶対に壊れないか?」と聞かれて「Yes」と絶対に言えない。個人的には上司やクライアントはこれを聞くべきではないと思う。
みねじろ! @minejiro 2010年7月22日
もし、これをYesというソフトウェア屋がいたら詐欺師です。学生さんが就職面接で「私は絶対バグを作らないようにがんばります」なんて答えをしたら、私が面接官なら即、落としますからねw
みねじろ! @minejiro 2010年7月22日
また、ハードウェアとソフトウェアのトラブルの出方が違うことがわからないで喚く経営者やクライアントがいたら、バスタブ曲線でなく、リアルにバスタブに沈めてやりたいw
みねじろ! @minejiro 2010年7月22日
この事実は、ソフトウェアはハードウェアとは異なるトラブル対処、言い換えればリスクコントロールをする必要がある産業ということなのですが、これも正解はまだありません。
みねじろ! @minejiro 2010年7月22日
リスクコントロールの例をいくつか上げてみましょう。Microsoft Update、これはバグがあることを前提に定期的に更新し、さらに情報開示を行うスタイルです。
みねじろ! @minejiro 2010年7月22日
このMS型のスタイルもまた「事実上」のスタンダードですね。オープンの世界でもUbuntuなどはスタイルを真似ていますし、組み込み系でもサービスマンが「点検」時にUpdateしていたり。
みねじろ! @minejiro 2010年7月22日
このスタイルが通るのは「(オフィスユースの)Windowsのバグで人が死んだことがあるか?」という質問に対する答えでもあるのですが、組み込み系の場合(Embedded Windows...)は、ねぇ(^^;
みねじろ! @minejiro 2010年7月22日
また、アプリのインストール時に聞かれる使用許諾書に、既知の未修正バグを全て列記した上で、それでも買いますか?というスタイルも存在します。これは自分の用途にそのバグが影響するかをユーザーに判断させるわけですね。
みねじろ! @minejiro 2010年7月22日
例示は2つだけにしておきます。方法はビジネスモデルの数だけあるので。ここで言いたいのは、ソフトウェアトラブルのリスクコントロールは作成者だけでなく使用者も主体的に関わってくるということです。
みねじろ! @minejiro 2010年7月22日
ただし、残念なことに現在のPL法を始めとする各種法律や判例は、ソフトウェアに適したものとはなっていません。パブリックコメントなどもあまり盛り上がらないような。。。
みねじろ! @minejiro 2010年7月22日
こういう場合、人間は似たもの、近くにあるものを「真似る」習性がある生き物です。とりあえずハードウェアのトラブル対処法を基準にして、合わない部分をソフトウェアに合わせて変えていく。
みねじろ! @minejiro 2010年7月22日
とは、行ったものの、トラブルが起きるのが今この瞬間なのか、1万年と2千年後なのかわからないわけですから、このハードウェアの「真似」は、ほぼ間違いなく最初の商品からつまづきます。。。
みねじろ! @minejiro 2010年7月22日
IT系でゼネコンの開発形態を(悪習含めて)真似たのと、組み込み系がハードウェアの開発形態を真似たのと、対比構造にあると言って差し支えないと思います。
みねじろ! @minejiro 2010年7月22日
学生さんへのアドバイスとしては、既存の仕組みの中で働きたい場合、建設型か機械型のどちらが自分に合っているかでIT/組み込みを選択するのがよいかなと思います。
みねじろ! @minejiro 2010年7月22日
ただ、どちらの仕組みも不十分であり、十分なものに進化させるには時間(権力を握るまで出世しないと何も変えられないですよ)が必要です。だったらベンチャーを立ち上げる、これもありだと思います。
みねじろ! @minejiro 2010年7月22日
ただし、日本社会は失敗に厳しく、メーカーには未だにハードウェア神話が存在するのも事実です。中小は、下請けか派遣か委託か、ITと組み込みの悪いところ取りですし。うーん、アドバイスにならなくなってきた。
みねじろ! @minejiro 2010年7月22日
無理矢理にまとめると、ソフトウェア産業に入る場合に、IT系、組み込み系、起業、どの道を選ぶとしても、リスクコントロール(技術者から見て一番代表的なのは品質保証/品質管理)の視点で自分の適正を考えてみてください。
みねじろ! @minejiro 2010年7月22日
大体、起業パンフレットや説明会なんて、よいことしか書いていませんし、先輩も学生ごときに自分の仕事がわかってたまるかと言わんばかりに、せいぜい残業自慢をされるあたりが相場でしょうw
みねじろ! @minejiro 2010年7月22日
でも、幸運にもこのツイートを見ている奇特なアナタ!騙されて悲惨な就職をしないために、スコスでも役に立つ内容を300個以上も書いてある、これを活用してください。
みねじろ! @minejiro 2010年7月22日
仕事は、うまく行っている時はほっておいても勝手に回ります。マズイことが起きた場合に何とかするのが「人間」が仕事に付いている理由です。これはソフトウェアに限らず。だから、どういうマズイ問題と対処に仕方があるかを学び、適正を選んでみてくださいね。
みねじろ! @minejiro 2010年7月22日
あと、既存の大規模ソフトウェア産業にあまり向いてないタイプを2つ紹介しておきます。自分は絶対バグなどしないという唯我独尊タイプ。バグが、明日起きるかも、明後日起きるかと心配しすぎる杞憂タイプ。
みねじろ! @minejiro 2010年7月22日
でも、レビューの仕方でも書いたように、同じタイプで揃わない方がトラブルは見つかりやすいので、こういうタイプが「不要」じゃないですよ。むしろ、居てくれないと困ります。
みねじろ! @minejiro 2010年7月22日
あぁ、また混乱させるような書き方をしてしまったな。適度なトラブルへの心配の仕方は就職してから自分の中に構築すればよいのです。自分の実生活でのトラブル対処法を思い出して、向き不向きを考える。あと、職場に過剰に適応しすぎないよう心がけること。この2つが今日のお話のポイントかな?
みねじろ! @minejiro 2010年7月28日
たばこ自販機の抜け穴問題が報じられているので、今日はこれを題材に学生さん向けのソフトウェア産業の考察をしてみようと思います。
みねじろ! @minejiro 2010年7月28日
本来、タバコ自販機ではTASPOというカードが必要でしたが、顔認証自動販売機ではカードなしでも購入できるというのが特色でした。ミラーに映る顔を成人か未成年か見極めるという仕組みで実現しています。
みねじろ! @minejiro 2010年7月28日
この顔認証自販機は、3つの機能から成り立っています。(1)購入者の顔を撮影する機能、(2)撮影した顔写真から年齢を示す特徴を抜き出す機能、(3)抜き出した特徴から成人か未成年かを判別する機能、この3つです。
みねじろ! @minejiro 2010年7月28日
ここで、私が3つの「機能」と書いたことに注意してください。これは、ソフトウェア、ハードウェア、人間(タバコ屋のおばちゃん)のどれであっても実現が可能だからです。
みねじろ! @minejiro 2010年7月28日
本件のような組み込み系では、ソフトウェアは要素技術の一つであり、IT系のようにソフトウェアであらねばならないものではない、というのがポイントの一つとなります。
みねじろ! @minejiro 2010年7月28日
これはつまり、組み込み系ではソフトウェアが原因の問題であっても、ソフトウェアを直す以外の対策アプローチがあるということになります。例えばTASPO型の自販機に入れ替えたり、対面販売に戻すなども可能な策です。
みねじろ! @minejiro 2010年7月28日
ただし、多くの場合は組み込み系であっても、IT系と同様にソフトウェアの修正という対策が取られがちです。なぜでしょう?というのが今日のテーマです。
みねじろ! @minejiro 2010年7月28日
答えの一つは「コスト」です。今回のケースも非常に一般的な例で、自販機の入れ替え(ハードウェア)>対面販売(人海戦術)>ソフトウェア書き換え(ソフトウェア)、という優劣によりソフトウェアの問題として主に報じられています。
みねじろ! @minejiro 2010年7月28日
ところが、報道の内容をよく見聞きすると「タバコ販売店からは自動販売機をTASPO必要なものに換えたい」という声があります。あれ?それってソフトウェア直す必要なくないですか?と思ったアナタ、そのセンスを大事にしてください。
みねじろ! @minejiro 2010年7月28日
トラブル対策には先に上げた「コスト」以外にも「時間」「契約」など、色々な判断要素があるわけなのですが、これを「ソフト不具合」と単純化して報道する記者のリテラシー不足は、傍論なので割愛。
みねじろ! @minejiro 2010年7月28日
さて、今回のケースでは中学生がしかめっ面をしたらタバコが買えたということですから、3つの機能のうち(1)の撮影でなく、(2)の年齢要素抜き出しか、(3)の成人判断のどちらかの処理部分に問題があったことになります。
みねじろ! @minejiro 2010年7月28日
メーカーはソフトウェアを更新したら起きなくなると主張し、約78%の該当自販機でソフトウェア更新が先月までに済んだとのことですが、今度は53歳の店主が未成年判定されたとのことです。
みねじろ! @minejiro 2010年7月28日
ということは、おそらく(2)の要素抜き出しではなく(3)の成人判別の部分の処理部分を変更し、より判定基準を厳しくしたものと推測できます。
みねじろ! @minejiro 2010年7月28日
さて、私はここで「修正」とせず「変更」と書きました。結果として、ソフトウェアの「変更」により、大本の問題が解決していないからです。
みねじろ! @minejiro 2010年7月28日
つまり、要素技術とした顔認識による年齢識別がまだ未成熟の技術で、完成していないものを商品化した故にソフトウェアの「変更」程度で解決しない問題だということを意味しています。
みねじろ! @minejiro 2010年7月28日
未完成の技術を商品化したメーカーの「モラル」、鵜呑みにして許可し問題が起きたら対応を「要請」した財務省の無策は、別の問題なのでここでは割愛します。ソフトウェア技術者またはその卵が、本件から学ぶべきことは何でしょうか?
みねじろ! @minejiro 2010年7月28日
先日、私は全てのソフトウェアトラブルは五つに分類されると書きました。「今すぐ直せ」「次のリリースで直せ」「商品化までに直せ」「直せるなら直せ」「直せません」
みねじろ! @minejiro 2010年7月28日
本件は、財務省からの「要請」なる事実上の「命令」があったわけですから、「今すぐ直せ」となるトラブルです。未成年を喫煙の害から守る意味でも、もちろんそれ自体は正しい判断です。
みねじろ! @minejiro 2010年7月28日
ただし、書き換えたソフトウェアは53歳を未成年と認識しました。トラブルの本質として「直せません」であることが、わかってしまったけです。さぁ「今すぐ直せ」なのに技術的には「直せません」、この状況はソフトウェア技術者には(残念ながら)よくあるジレンマです。
みねじろ! @minejiro 2010年7月28日
しかも、これはおそらく、ほとんどの学生さんがソフトウェア産業に入れば3年以内には経験するであろうケースです。下手するといきなり。こういう時にどうしたらよいか、オッサンはこれからそれを語ります。
みねじろ! @minejiro 2010年7月28日
まず、分かりやすくするために問題を2つに切り分けます。個人(技術者)と会社(組織)です。学生さんが興味を持ちそうな、個人の方から話をしましょうか。
みねじろ! @minejiro 2010年7月28日
おそらく、今回の問題は「仕様通り」に作成し「仕様通り」に動作をしたにも関わらず、しかめっ面という「例外処理」部分の判定ミスが起きているので、例外処理部分の仕様の修正と、その例外処理部分の再テストが必要になります。
みねじろ! @minejiro 2010年7月28日
ここのポイントは2つ。仕様(あるべき形)とテスト(あるべき動作)は必ずセットであるということです。片方だけを直す、あるいは互いに別々に連絡を取らずに動くのは下策中の下策です。
みねじろ! @minejiro 2010年7月28日
セットにして動くようにするのは、本来、上司、先輩、対策責任者なので、一ソフトウェア技術者となるアナタは、そのどちらか、あるいは両方をやれと命ぜられる立場にあるでしょう。その時、どう動くべきか。
みねじろ! @minejiro 2010年7月28日
仕様(とコード)を直す側に回った場合、指示があればそれに従い、もし指示がない場合は自発的に、動作確認する担当にこの直し方でよいか、抜け漏れはないかを聞きにいってください。角度を変えた視点をもらうことはとても重要です。
みねじろ! @minejiro 2010年7月28日
動作確認をする側に回った場合は、先の逆をやればよいわけです。確認内容がこれで十分かを聞くようにしてください。そして、両方共自分でやる場合、これが一番危険です。上司、先輩、同僚、誰かを捕まえて、相談しましょう。「報連相(報告・連絡・相談)」が大事です。
みねじろ! @minejiro 2010年7月28日
これら、3つのケースを上記したように対応できれば、ソフトウェア技術者としての責任(最低限ですが)は果たしたことになります。逆にこれをやらないなら、それはアナタの責任です。もし、クビになったとしても当然のことです。
みねじろ! @minejiro 2010年7月28日
仕事はうまく行く時はほっておいてもうまく行くと、前に書きました。問題が起きた場合にやるべきことをやらないのが、一番悪いことです。仕様書、コード、テスト、どこに漏れがあったにせよ、そこにくよくよしている暇があったら、上記のやるべきことをやりぬきましょう。
みねじろ! @minejiro 2010年7月28日
じゃあ、そもそも顔認識なんて未完成の技術を使ったのがいけないんじゃないという話に移りましょうか。ここは組織(経営)判断の部分なので、少し端折りながら、できるだけ学生さん向けに書いてみます。
みねじろ! @minejiro 2010年7月28日
まず、最初に言えることは、残念ながら判断社、リーダー、経営者は「アホ」です。よっぽどの小組織でもない限り、ペーペーもアナタより、作った内容をよく知っているということは絶対にありません。
みねじろ! @minejiro 2010年7月28日
ソフトウェア技術者としては、相手が「アホ」であることを前提に、自分の仕事の内容や成果を説明すること(アカウンタビリティ)が必要です。仕様書だったり、報告書だったり、レビューだったり、形は色々ですが、ある分野、モジュール、関数、なんでもよいから担当を持った瞬間に、アナタには説明責任があることを絶対に忘れないでください。
みねじろ! @minejiro 2010年7月28日
上記したように「今すぐ直せ」の問題が起きた場合、嫌でもペーペーでも説明に駆り出されるわけですが、本当ならもっと前にできることがあったハズです。本件の担当者はおそらくそれをやっていません。(もしフォロワーさんに関係者がいたらゴメンナサイ。置かれている立場は重々承知しているつもりです)
みねじろ! @minejiro 2010年7月28日
(3)の成人判別がまだ技術的に未完成なのではないか?という私の疑問を正しいものと前提にします。説明責任を持つアナタはこの技術、ソフトウェアの完成具合を説明する責任を持っています。が、実際には設置してから問題が起きました。さて、なぜでしょう?
みねじろ! @minejiro 2010年7月28日
(a)知っていたけど黙っていた。技術者として最悪です。私なら徹底的に再教育します。(b)知っていたし報告したけど上司なり経営者がゴーサインを出した。アナタは最低限の正しさを果たしましたが、上がアホでバクチに負けました。一緒に負け分を払いましょう。ただし、一番悪いのは自分ではないことを忘れずに。
みねじろ! @minejiro 2010年7月28日
(c)知らなかった。意外かもしれませんが、実はこれが一番大きい問題です。個人と組織の両方で。組み込み系もIT系も同じですが、ソフトウェアを介して社会機能の一部を担い、その対価を貰う以上、十分起きうる問題を知っておく必要があります。(メキシコ湾のBPがまさにこの状況)
みねじろ! @minejiro 2010年7月28日
ゆえに、もし知らなかった場合は、知った時点で二度と同じ過ちを起こさないよう再発防止をする。また類似や本件をヒントに想像される他の例外を未然防止することが、ソフトウェア技術者の重要な役割となってきます。
みねじろ! @minejiro 2010年7月28日
バグは結果系で見て判断して動くと上記しましたが、これはどちらかと言うと組織の視点です。ソフトウェア技術者個人としては、原因系から次を起こさないように、日々考える、勉強する、修練することが大事です。
みねじろ! @minejiro 2010年7月28日
(余談)ホワイトカラーエグゼンプションが導入されると、直接の研究開発製造の効率化を求められるのに呼応して、このような再発防止や未然防止に使う時間が「個々人の判断」で削られて、技術力低下を産むと思うので「一律」導入には反対です。(導入したらよい仕事をする「天才」もいるんですけどね)
みねじろ! @minejiro 2010年7月28日
再発防止や未然防止については、工学系の研究や書籍、企業の改善事例が山ほどあるので、ここでは紹介しません。自分で探すか、教官、先輩、上司から教わってください。(頼まないでも教えこまれると思いますが)
みねじろ! @minejiro 2010年7月28日
ちなみに、未然防止の例としては、今回の件でメーカーもとっくにやっているかもしれないのですが、カメラ部分にヒゲ、ゴルゴ13、バカボンのパパの顔などをマジック書きした上で、動作を試してみるなんてのも、一つあるかと思います。
みねじろ! @minejiro 2010年7月28日
(d)知っていた。前にもやった。またやった。。。これは終わってます。アナタの報連相不足による場合、アナタはソフトウェアに限らず技術者に向いていません。転職をお勧めします。組織レベルでやらかした場合なら、トップを変えるか潰すべきです。どちらの傾向も見られないようなら、技術者としての転職をお勧めします。。。
みねじろ! @minejiro 2010年7月28日
以上、顔認識タバコ自販機トラブルに見る、ソフトウェア技術者を目指す学生さんへのアドバイスでした。けっど、これは相当マヌケなトラブルには違いないんだけど、ソフト、ソフトと騒ぎ立てるマスコミもヒドイな。もしかしたら(1)のレンズ精度の問題で、それをソフトで必死に画像処理でゴマカしているのかもしれないよ。
みねじろ! @minejiro 2010年7月28日
もう一回まとめると、トラブルが起きた場合の、ソフトウェア技術者自身のやることとスタンスは、組織や上位の判断やスタンスと違って当たり前だということを、常に忘れずに説明責任の本分を果たすこと。また、組織や上位の判断ミスが起きないよう、日々努めること。技術論はそれからで構いません。
みねじろ! @minejiro 2010年7月28日
あ、今日のテーマには「なぜ仕様通りに作ったのに問題になったのか?」の疑問を生みますね。答えは仕様の決め方と、仕様が妥当であるかの確認方法のどちらか、あるいは両方が間違っているからです。キーワードはV字モデル、W字モデル。あとは自分で検索してみてください。
AlwaysLightning @AlwaysLightning 2010年7月29日
RT @minejiro: で、彼らは揃って言うわけです。「イノベーション」「ソリューション」はぁ?数字でしか部下の職場を見ないで、お客様の課題をどうやって解決する技術や手法ができるんですか?てめぇのケツも拭けないままに他人様のケツを拭かせていただいて対価をください。そういうことを事業化するんですか?恥だ。
みねじろ! @minejiro 2010年8月2日
今日は流行りの「インターンシップ」について、ソフトウェア産業での使いこなし方の話でもしましょうか。
みねじろ! @minejiro 2010年8月2日
インターンシップには「見学型」「体験型」「実践型」「グループワーク型」「専門分野特化型」「講演・レクチャー型」などがあると、今日の朝日朝刊教育面に書いてありました。が、これらは全てたただの『包装』です。中身は決して見えません。
みねじろ! @minejiro 2010年8月2日
なぜなら「うまく行くこと」か「失敗は受け入れ先の人が解決してくれる」からです。例えば1週間のインターンシップで失敗があって、その解決のために期間が3週間に延びた。これなら参加する価値がありますが、そんな会社は寡聞にして知りません。
みねじろ! @minejiro 2010年8月2日
なので、インターンシップするくらいなら、責任が軽い上にお金までもらえるアルバイト、短期派遣労働、清掃業者などで潜り込んでみる方がよっぽどマシです。
みねじろ! @minejiro 2010年8月2日
では、インターンシップの意義はどこにあるのか?上記の金がもらえる方法では入れない企業、場所に入れること。これにつきます。インターンシップでやる内容なんて、お中元のギフトカタログみたいなものなので、無視してよろし。
みねじろ! @minejiro 2010年8月2日
つまり、インターンシップとして潜り込み、バイトや清掃業者の視点で職場を見てくる。これが最大にして最高の参加目的です。ここを勘違いして、インターンシップで用意されたオママゴトの何かで達成感を得たところで、役に立つことはまずありません。
みねじろ! @minejiro 2010年8月2日
インターンシップで入り込んだ職場で必ずすべきことは、壁の張り紙や掲示板、社員の机の上、トイレ、喫煙所、給湯室などを一通り見てくることです。これらの共通点は企業がどこか緊張を緩めている、油断がある部分。本音が見えるところだからです。
みねじろ! @minejiro 2010年8月2日
残念ながら、セキュリティ関係でインターンシップではそういった場所に入れないケースもあると思います。ここからはちょっと危険なアドバイスをします。その場合、間違えたフリをしてアラームなり叱責を覚悟で何とか見てみようとするのが効果があります。
みねじろ! @minejiro 2010年8月2日
効果は2つあって「仕事がうまく行かない場合のために人間がいる」について、その会社の対応方法、処理速度、ルールが見えること。また、自分自身もなぜ禁止事項に触れたか「うまく行かなかった」ことを対応する訓練になるからです。
みねじろ! @minejiro 2010年8月2日
一見、どこにでもある平然と働いているように見える職場でも、イレギュラーが起きた場合に、どんな対応をするかを知ることはとても大事です。これは、ソフトウェアの例外処理、異状処理を考えることがとても大事であることとのアナロジーですね。
みねじろ! @minejiro 2010年8月2日
あと、危険なアドバイスと言ったのは、バイトや出入り業者がやるとクビか出禁になる事項だからですが、学生だけは「若さゆえの過ち」が許されます。せいぜい、その会社がヘソを曲げて雇ってくれなくなるくらいで済みます。実にローリスクハイリターンですw
みねじろ! @minejiro 2010年8月2日
ソフトウェア産業のインターンシップはどの形態でやっても実態が見えにくいという弱点が他の産業に比べてあります。多分、ソフトウェア産業の人事部の採用担当は他業種よりかなり苦労してるハズ。
みねじろ! @minejiro 2010年8月2日
ソフトウェア産業の職場実態はだいたい3つです。(1)みんなが机でコンピュータにしがみついている。(2)朝から夜まで会議続き。(3)派遣、出向、客先に出払っていて電話番くらいしか部屋にいないw
みねじろ! @minejiro 2010年8月2日
これらのソフトウェア産業の職場に共通しているのは、忙しそうか、ゆったりしてそうかに関わらず、非常に安定した職場環境にあるということです。なので、正常系を見てもサッパリ得るものがない。
みねじろ! @minejiro 2010年8月2日
なので、繰り返しますが例外、異状系を何とかして見極めることが大事です。運良く(運悪く?)重大なトラブルが発生し、インターンシップの受け入れどころではなくなった場合、チャンスだと思ってください。働いている人たちがどう動くか、処理するか、許される範囲で徹底的に見聞きしましょう。
みねじろ! @minejiro 2010年8月2日
もし、インターンシップにも手を借りるようなトラブル対応なら、新人の扱いもそうなる総力戦型、帰れと言われるなら対策チーム型だとわかります。このスタイルは自分の就こうとする仕事との相性と非常に密接な関係にあります。ぜひ、問題が起きることを期待して参加しましょうw
みねじろ! @minejiro 2010年8月2日
で、(大抵そうですが)何もおきなそうだったら、間違えて会議室に入り込んだりして、人工的に例外、異状状態を引き起こしてみるということ。これが今日のアドバイスのポイントです。
みねじろ! @minejiro 2010年8月2日
この禁じ手を使った場合、絶対に避けるべきソフトウェア企業の種類を1つだけ教えます。実際にそこで働いている人から、無視、無関心、放置、お咎めなしで何も起きない場合です。
みねじろ! @minejiro 2010年8月2日
その企業では働いている人がヘトヘトか、助け合いがないか、モチベーションが著しく低くなっている可能性が非常に高いです。そう、皆さんが大嫌いなブラック企業です。
みねじろ! @minejiro 2010年8月2日
これを読んで、企業のインターンシップ担当者が裏の裏をかいて、より有意義なインターンシップを実施してくれますようにw
みねじろ! @minejiro 2010年8月16日
どうせ学部で英語とプログラムを一般教養でやるなら、一緒にして英語で仕様書やコメントを書いてレビューさせる授業をしてくれたら企業はかなり助かるなぁ。コーディングなんて英語を書くようなものだし、相性よいと思いますよ。
みねじろ! @minejiro 2010年8月17日
また、興味深い記事が出てきました。「ゆうちょ銀障害の原因判明 IBM製HDDに欠陥」http://headlines.yahoo.co.jp/hl?a=20100817-00000503-san-bus_all
みねじろ! @minejiro 2010年8月17日
「7月12日に発生した民営化後最大のシステム障害は、米IBM製磁気ディスク装置(HDD)内の制御装置のバグ(プログラムの欠陥)が原因だった」とあります。割と詳しいですね。
みねじろ! @minejiro 2010年8月17日
冗長性(2つのシステム)を持ち、片方が壊れても全体が止まらないようにする仕組みにミスがあったということです。
みねじろ! @minejiro 2010年8月17日
これも、一見HDDなんてハードウェアの塊に見えて、実は複数のハードウェアをソフトウェアで制御していることがよくわかる記事です。
みねじろ! @minejiro 2010年8月17日
しかし、本当の問題点はここではありません。「ゆうちょ銀は現在、IBMの保守要員常駐と24時間監視の下で旧HDDを使用している」ここです。ハード+ソフト+人力で、やっとシステムが稼働している。
みねじろ! @minejiro 2010年8月17日
システム構成要素であるハード、ソフト、人のどれが壊れても社会インフラが破綻するということです。本来はこのシステム全体の構築の仕方の問題なのですが、対策にもコストの原理が働くので、前述のように「ソフトウェアのバグ」という報道がされてしまいます。。。
みねじろ! @minejiro 2010年8月17日
ソフトウェアの問題ということにしておけば、問題はそんなに大きくないですよー、ソフトウェア技術者が悪いんで、彼らに直させますから待っていてくださいねー、という言い訳が成り立つからです。。。
みねじろ! @minejiro 2010年8月17日
こうして作られた「ソフトウェアの問題」は対処療法であり、根治しません。学生時代にはぜひ「システム工学」を少しでも齧っておくと少しは、この手の「ハメられた!」から救われるかもしれない。。。
みねじろ! @minejiro 2010年8月17日
まとめると、問題が起きた時、その直接の原因がソフトウェアかハードウェアかだけではなく、人(利用者、管理者、要求社)を加えたシステムを俯瞰する問題視点が持てていることが大切ということです。
みねじろ! @minejiro 2010年8月17日
これは、対策がデスマーチ(どうしてもそうなることはあります)になった場合でも、自分の責任範囲はここまでだけど、ここまでは踏込してやるというモチベーション構築や、落ち込まない「強さ」を自分に持つことにも繋がります。
みねじろ! @minejiro 2010年8月17日
残念なことに、メディア、学者、利用者のステークホルダーにこの視点を持てている人は多くありません。自分は困っていない(他人事)か、困りすぎて考えられなくなっているからです。
みねじろ! @minejiro 2010年8月17日
従って、技術者(ソフトウェアもハードウェアも)自身が、このシステム全体を俯瞰する視点と、自分が手をつける細部を分けて把握して対処する必要があります。
みねじろ! @minejiro 2010年8月17日
大きな問題が起きた時に、それを対処しても褒められない、報われないかもしれない。でも、自分は正しくやり遂げたという達成感は。その技術者にしか持てません。それが技術者の矜持であり報酬だと私自身は思います。
みねじろ! @minejiro 2010年8月17日
「技法」でなく「技術」を学び、技術者として悔いのない生き方をしよう!
みねじろ! @minejiro 2010年9月4日
三菱電機インフォメーションシステムズ(MDIS)の図書館情報検索システムの一件、畑違いのIT系だから様子見していましたが、実際の図書を触れる点で組み込み系の支援システムの視点で見れるなと気付きました。
みねじろ! @minejiro 2010年9月4日
MDIS社の公式コメント。 http://www.mdis.co.jp/news/topics/2010/0903.html 読まれた方も多いと思いますが、こういう文章は書いてあることより、書いていないことの方が大事です。これ、コードレビューの応用w
みねじろ! @minejiro 2010年9月4日
何が書いてないかというと、まず結果「直った/直る/直す」がない。次に現象の詳細と原因がない。つまり、何が悪いか確定していないハズ。多分、担当者はデスマーチ真っ最中。最後に前2つがないと書けないハズだから期日がない。
みねじろ! @minejiro 2010年9月4日
要は、お騒がせしてゴメンナサイ以上のことは言ってないわけです。当然、このコメントは社のトップアナウンスですから経営者の公式見解です。本文は代筆だとしても。
みねじろ! @minejiro 2010年9月4日
さて、次にMDISがどの程度の企業か。 http://itpro.nikkeibp.co.jp/article/Research/20070919/282339/ インフラ系「ベスト5」の一角だそうです。大手ですね。
みねじろ! @minejiro 2010年9月4日
MDISでもトップが「わかってない」が発生し、あのようなアナウンスになってしまうのだなぁという構図は、このtogetterの上の方に書いてある通りです。いやはや。
みねじろ! @minejiro 2010年9月4日
末端では電子書籍が大流行ですが、「売る」方はAmazonや色々な企業が垂直統合で力技をしかけてきています。では水平展開である電子図書館は?MDISのような企業が構築するのではないでしょうか。
みねじろ! @minejiro 2010年9月4日
おっと、学生さん向けのアドバイスになることを書いていなかった。大きな問題が起きた場合、原因と対策に正面から取り組む(時には回り道して)も大事ですが、ちょっと離れて垂直、水平、両方の方向から、この問題が何に繋がるかを考えてみることも大事だよということです。
みねじろ! @minejiro 2010年9月4日
うまくすれば、電子図書館システムで独立して一旗揚げることができるかもしれないし、知らず知らずのうちに腐った受注システムの建て直しに巻き込まれてデスマーチになっているかもしれない。
みねじろ! @minejiro 2010年9月4日
5手も10手も先を読む天才のようなことは無理でも、1手、2手くらいなら、普通の人にも考えられるという例と、そういう視点でニュースを見てみようよという、お話でした。今日はこの辺で一旦終わり。MDIS問題で進展あれば、また何か書くかも。書かないかも。
みねじろ! @minejiro 2010年9月28日
残念ながらMDISの問題には続きがありました。<岡崎市立中央図書館>利用者情報163人流出 http://j.mp/dd9ZD3 これはよっぽどヒドイ業務プロセスでないと起きないような問題。。。ただの流出とはちょっと違います。
みねじろ! @minejiro 2010年9月28日
通常の個人情報漏洩は、そのデータを正当に所有しているあるいは預っている会社なりサイトから漏れるわけですが、本件は所有すべきでないベンダーから漏れてます。一番、信用を失うパターンです。これかなりヤバイんじゃないの?会社として。
みねじろ! @minejiro 2010年9月28日
疑問1、顧客の持つ情報を預かる権利(契約)をMDISは有していたか。疑問2、顧客の持つ情報管理をMSDISはどのように行っていたか。疑問3、ソースとデータの分離をMDISははきちんと行なっていたか。とにかく、まともな開発プロセスなら「ありえない」事件だけに疑問が幾つも湧いてきます。
みねじろ! @minejiro 2010年9月28日
今の時点で、学生さん向けにアドバイスをするとすれば、自分の書いたコードやテスト用の仮データと、同僚や上司、顧客から預かった情報(コードもデータも)は、わけて管理しましょうということ。でないと、こういう時に説明ができなくなり、最悪、責任を押し付けられます。。。
みねじろ! @minejiro 2010年9月28日
なんで、自他区別の重要性を強調するかというと例えばメール。添付ファイルやメールシートの情報がメーラーという同じ環境上で混在しやすいから。しかも会社が業務プロセスとしてその仕組を提供しているから。。。せいぜい「不要なメールは捨てろ」くらいしか言われないでしょう。仕方がないので何が不要かを考えるいい機会と思いましょう。
みねじろ! @minejiro 2010年9月28日
と、言っても1000通/日を越えるメール量を捌くソフトウェア開発環境もあるわけで難しいな。捨てるかどうかの判断をする時間すらない。うーん。ダメだ、今日はこれ以上の知恵が出ないです。また後日。スミマセン。
ログインして広告を非表示にする
ログインして広告を非表示にする