カテゴリー「開発業務」の記事

2017年5月 4日 (木)

マジメと本気の違い

 NRI楠真 強いITはココが違う - 成功するPMと失敗するPMは何が違うのか:ITproの記事は、面白い視点である。マジメに開発していても、本気でなければ、開発の問題は解決できない、ということである。
 マジメな開発者は多い。というよりも、ほとんどの開発者はマジメである。マジメな開発者を本気にするのはいったい何なんだろう?自分の経験からも、全ての開発でマジメに仕事をしたと断言できるが、全ての開発で本気だったとは言え ない。マジメと本気というキーワードで、自分の開発を振り返り、その差がどこ から出てきたのかを分析してみようと思った。

2017年4月19日 (水)

開発プロジェクトに突然襲い掛かる難問:身につまされる

 脱出! 暗闇プロジェクト - 「対策を立てろ」は無能なマネジャーの常套句:ITproで、いきなり降りかかってくる想定していなかった難問として取り上げられている例を引用する。

  • 要件定義をまとめるのに100時間を要した。ところが「儀式」のはずの承認の場で、理事長の一言により、ひっくり返る
  • どこから着手すればいいのか、皆目、見当が付かない。アウトプットがゼロのまま、数週間が経過する
  • 最先端のソフトウエア製品を開発し、リリース間近。その段階で、無名のメーカーが同じ機能を持ち、より優れた製品を発表し、業界の話題をさらう
  • 以前にけんか別れした元同僚が、ユーザー側のコンサルタントを務めている「やりたいようにやれ」「結果は気にするな」と言っていた上司が、突然「数字」を要求し始める
  • 想定していなかった作業が発覚し、数百万円の費用が発生することが判明。なのに、誰が負担するかは曖昧なままトラブル発生。原因を特定するには、複数メーカーに所属する技術者の協力が欠かせない。だがメーカーは競合同士なので、協力に難色を示している
  • 長い付き合いで「大丈夫」と信じていた顧客が、口約束を守らない

 

「儀式」でひっくりかえるというには、何度も経験している。儀式こそ、念入り の根回しが重要である。「どこから着手すればいいのか、皆目、見当が付かない」というのは、火を噴いているプロジェクトの火消を命令された時によくある話である。そもそも火中のプロジェクトメンバーは、プロジェクトがどうなっているのかわかっていないので、火消しに入っても、すぐに着手できることはない。何も着手せず、状況把握を急ぐしかない。
 ここで書かれていることは、大なり小なり同じような経験をしていて、身につまされる。ただ、「以前にけんか別れした元同僚が、ユーザー側のコンサルタントを務めている」という経験だけはない。どのように切り抜けるんだろう???

2017年4月12日 (水)

PMに向いていない人:ちょっと違う気がする

 ダメPMな人たち - なぜ急増?PMに転じて失敗するベテランSE:ITproという記事があった。SEとPMとは、向き不向きがあるという話である。これは同意なのだが、PMに向いていないタイプというのが列挙されていた。少し引用する。

・知らない人や大勢の人の前で話をするのが苦手である
・他人に指示して仕事をやらせるよりも、自分でやるほうが得意である
・問題が発生すると自分で解決しようと頑張り、あまり人に相談しない
・技術的なスキル習得に興味が強く、ビジネススキルへの関心は薄い
・自分が好きな仕事であれば、何時間でも没頭し、それが苦にならない

 これはちょっと違う気がする。エンジニアでなくても「知らない人や大勢の人の前で話をするのが苦手である」人は多い。というか、大抵の人はそうだろう。このタイプはPMに向かないと言われたら、誰もPMはいなくなる。
 SEの中で「仕事であれば、人の前で話ができる」タイプであれば、PMになることは可能ではないか。そして、PMとしてやっていく中で、徐々に、慣れていくものだ。もちろん、「仕事であっても、人の前で話はできない」タイプはPMにはなれないだろう。
 仕事であってもできないことがあり、それが、その仕事に必須のことだったら、その仕事にはつかない方がいい。でも、仕事ならできそう、ということであり、その仕事に興味があり、自分のスキルアップにつながると思えば、少しくらい苦手でもチャレンジするのは悪くない。そうやって、自分のスキルを拡大していくのが社会人の勉強なのだと思う。

2017年3月26日 (日)

4M変更の通知:部品メーカーに要求しても守られないのが普通

 日経エレクトロニクスの安全設計の記事の中で、サイレントチェンジの問題が書かれていた。部品メーカーが、勝手に部品の材料を変更して、それが大きな問題になってしまうという話しだ。その対策として、「いかなる材料の変更も事前に連絡・承認を得るなどの内容を契約に盛り込むこと」と書かれていた。
 これは、いわゆる4M変更の通知という話で、たいていのメーカーは部品メーカーとの基本契約に盛り込んでいるはずである。でも、守られたためしがない。特に海外の安い部品では、絶対に守られない。
 私はずっと開発なので、この手の製造にまつわることには直接かかわったことはないが、かなりの頻度でおきている問題のようだ。電源まわりの部品だけは、日本のしっかりしたメーカーを使うとかしないと、いつか大問題を起こすような気がする。

2017年3月15日 (水)

製品を試作する技術があってこそ部品の開発力が向上する

 日経エレクトロニクス3月号の特集「家電がクルマになる」で紹介されているパナソニックの取り組みは面白い。同社は、独自に2人乗りのEVを試作し、テストコースまで作りながら、EVを製品化することはないという。この試作で得た知見を、車載の部品やモジュール開発に活用するのだという。つまり、自分達が売りたい部品やモジュールを開発するために、それを組み込んだ製品を試作・評価できる技術を持つのだ。
 よく考えてみると、マイコンメーカーは同じことをやっている。今や、マイコンには試作基板とサンプルソフトウエアがあるのは、当たり前になっている。これが、EVのような、高度な技術が必要な領域にも広がってくるということなのだろうか?

2017年3月14日 (火)

日経エレクトロニクス3月号の特集は力作:電子機器設計者は必読

 3月号の特集記事は、「安全設計、待ったなし」。副題は「Note7問題だけにあらず」。イントロは、Note7のバッテリの発火問題だが、そこから、現在の電子機器における安全設計の問題へと論を進める。
 あまりに専門が分化されてしまった現場で、一番心配なのが安全設計だ。幅広い知識と経験が必要な分野だからだ。
 一番びっくりしたのが、ディレーティングの問題である。熱の問題は、電子機器におけるかなり大きな設計課題である。熱が部品におよぼす影響は大きい。寿命に関係したり、許容電力に関連したり、電源だと出力電流に関連したりする。そういう設計の際に参照されるのがディレーティングなのだが、その値そのものが今の設計に追随していないらしい。例に出ていたのが、抵抗である。そもそもの値は、抵抗をラグ端子に実装した状態を想定した値だったとは知らなかった。30年前でも、ラグ端子に抵抗が実装された製品など見たことはない。今の高密度な表面実装部品時代には合っていない。
 今は、先進的な取り組みをしている部品メーカーが、独自に、新しいディレーティングの基準と値を提供しつつあるらしい。
 こういうことは、知っているか否かで、設計品質が大きく変わる話である。部品が燃える可能性があるような安全対策については、電子機器設計者は必ず知っておくべき内容である。モーターなどの機械的安全を除けば、電子機器の安全対策で重要なのは、発火と感電の2つだからだ。機器が動かなくなっても、クレームになるだけだ。でも、発火と感電は人の命にかかわる問題である。

2017年3月13日 (月)

開発用Windows機のウイルス感染によりAndroidアプリもウイルス感染

 ウイルス入りAndroidアプリが132個見つかる、原因は開発用Windows機の感染か - Computerworldニュース:Computerworldによれば、Androidアプリの中に、ウイルスが組み込まれたものが132個見つかったが、その原因は、アプリの開発に使われたWindowsマシンがウイルスに感染していたことだという。
 その感染ウイルスがWindowsでしか発症しないウィルスであれば問題ないが、HTMLファイルがらみのウィルスであればAndroidでも問題が出る可能性があるらしい。
 オフィス用のPCであれば、厳密なセキュリティ管理が実施されているが、開発用マシンは、その対象外である会社も多い。いろんな開発ツールとの相性で、常駐のセキュリティ監視ソフトを外しているような開発マシンも結構あったりする。
 開発環境のセキュリティというのは、実は大きな課題である。

2017年2月21日 (火)

参謀本部体制の業務委託方式:丸投げをこう表現するのか・・・

 もんじゅ廃炉の背景に動燃の歴史、組織を腐らせた遠因(5ページ目) - 日経テクノロジーオンラインを読んで世の中にはいろいろな表現があるものだと思った。少し引用する。


 動燃のナショナル・プロジェクトの特徴は、参謀本部体制の業務委託方式3)を採用したことである。動燃自身は直接、技術開発を担わず、個別の技術開発に分けて業務委託契約先の産業界に委託する参謀本部機能に徹する方式だ。この結果動燃は、巨額な国家予算を産業界に分配する「トンネル機関」としてのみ機能した。この体制は動燃の組織体質を劣化させ、結果として足腰の強い人材を育てられないという不備の原因となったと筆者は考える。


 よくある話である。大企業の研究機関でも、こういう話は多い。特にソフトウエアでは、プログラミングを低く見るきらいがあり(汚れ仕事と称していた人もいた)、仕様だけ書いてあとは外部へ丸投げしている。現在形で書いたのは、今も続いているからだ。
 諸悪の根源は、必要以上の予算があることである。金があると、金に開発をさせるようになる。本当は、自分達で開発するのが開発者の役目なのに。

2017年2月14日 (火)

「不測の事態の対応」をどうするか?:やっぱり残業で対応するしかないかも

 前に書いた品質に関する姿勢:工場からの電話は週末にかかってくる・・・にyさんからのコメントがあった。そこに不測の事態の対応という問題が書かれていた。もっともな疑問である。
 私の結論は、やはり残業でこなすしかない。不測の事態に備えるための余裕はないからだ。でも問題は、それが、本当に「不測の事態」だったのか、ということである。本当に誰が見ても不測の事態であれば、みんな頑張るだろう。それあ日本人の気質だからだ。
 でも、不測の事態でないことが多々ある。現場は、何か問題がある、と薄々感じているとか、前兆はあるものだからだ。いかに早く問題を見つけ、通常の開発をストップし、問題対応に切り替えることができるかが、重要である。まあ、言うのは簡単だが・・・。

2017年2月 2日 (木)

品質に関する姿勢:工場からの電話は週末にかかってくる・・・

 市場クレーム時に分かる「お客様第一主義」 - 日経テクノロジーオンラインを読んで、日本のメーカー技術者なら、大抵は経験したことがある、と昔を思い出す(現在進行形の人もいるかもしれないが)ではないか。
 少し引用する。
 市場でのこうしたトラブルは、盆や年末年始の長期休暇の前日に起こることもあるし、連休の初日に発生して呼び出しがかかることもある。
 私の経験では、その通りである。だいたい、週末に工場から電話がかかってくると、この手の話である。そして、そのまま深夜残業、休日出勤になだれこむ。
 いつもは、きっちり休日は休んでいるし、残業はほとんどしないので、こういう緊急事態は仕方ない。そういうものである。
 こうした話と、電通のように、状態化している話とは全く別である。緊急事態の対応は、たまにしかない。開発電場でも緊急対応が常態化しているところがあったりするが、開発業務そのものができていないので、問題が発生するのである。私の感覚では、緊急事態が半期に1回くらいなら仕方ないが、それ以上の頻度で起きるなら、開発体制そのものを見直した方がいい。

より以前の記事一覧

2017年5月
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

公告

  • Google Adsense
無料ブログはココログ