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

2018年2月21日 (水)

紺屋の白袴:情報処理学会の会員管理システム

 情報処理 2018年03月号に、情報処理学会の新会員管理システムの開発についての記事があった。今のシステムの状況も少し触れられているのだが、会員のマイページ機能が、セキュリティの問題でサービスを停止していたり、入会申し込みからの転記ミス(人が介在してるのだろう)があったり、という状況のようだ。
 実態は、そんなものなのだろう、とも思う。最新の機能をうたうITシステムを、そのITシステムベンダーは使っていない、という状況は、よくある話である。

2018年2月 1日 (木)

PoCが終わると誰もいなくなってしまう:社内プロジェクトも同様

 IoTにつきものなのが、PoCだ。これに関して面白い記事があった。
 記者の眼 - デジタル化に疲れた、「お代は見てのお帰り」では辛い:ITproPoCが終わると、誰もいなくなるというのだ。これは、社内プロジェクトでも同様である。
 私は、大企業の研究開発部門にいる。こういう位置づけの部署は、やっているプロジェクトの全てが製品化されることはない。技術開発だけで終わることも多い。しかし、なんとなく、なのだが、PoCとかいう言葉が流行してから、やたらと製品化までこぎつかないプロジェクトが多くなっている気がする。昔は、こんな便利な言葉がなかった。なので、プロジェクトを立ち上げる以上、一応、ビジネス的な検討をした上で、事業部門ではリスクが高いので、研究開発部門で、というスジは通していた。ところが、PoCという言葉で、何となくでプロジェクトを立ち上げることが増えた気がする。だから、PoCで何を検証したいのか、ということも議論せずに何となくプロジェクトが始まり、もともとの目標があいまいだったので、得られる成果などあるはずもなく、なんとなくプロジェクトが終わる。こんなプロジェクトにいたくはないので、終わったとたんに、みんな逃げ出すのである。

2017年9月20日 (水)

3現主義は開発でも重要

 「現場」「現物」「現実」の3現主義の重要性は、主として製造現場で語られる言葉である。メーカー勤務の技術者なら、開発でも聞いたことがあるはずである。
 「3現主義」を甘く見ていないか? - 日経テクノロジーオンラインは、深く共感する話だ。私は、製造現場はあまり知らない(開発者として製造の立ち上げに協力したことがあるくらいなので)。でも、開発においても、同じことがいえる。開発という業務は、開発の現場とは異なるところで役に立つモノやサービスを創造する行為である。そのためには、実際に、そのモノやサービスが使われる現場を知らなけらばならない。開発者は、どうしても開発者が集まった閉じられた空間で、長時間働くことが多い。3現主義を本当に実践するのは難しい。なので、開発者の全員とは言わない。場合によっては、1人だけでもいいから、必ず現場の勉強をさせる必要がある。

2017年9月19日 (火)

AI専用チップはFPGAが有利?:IntelがAltera社を買ったのはこのためか

 ディープラーニングは、学習はCPUパワーが必要だが、その学習結果を使った推論はそれほどでもない、というのが定説である。実際、推論を組み込み機器に入れる取り組みも多い。ところが、実際には、莫大なユーザーがいるクラウドサービスでは、推論もCPUパワーが必要らしい。サーバー・プロセッサ バトルロイヤル2017 - GoogleのAI専用チップに挑むMS、奥の手は「謎の精度」:ITproから少し引用する。

 Googleは2013年に「スマートフォンのユーザーが1日当たり3分間、音声認識を利用する」というシナリオに基づいて、推論に必要となるITインフラストラクチャーの規模を見積もっている。その結果、CPUだけで全ての音声認識の推論を実行しようとすると、当時のGoogleが保有する全データセンターの2~3倍に相当する処理能力が必要になることが分かった。

 なるほどね、量が質に転換するという典型例である。Googleは、これを解決するために、専用チップを開発した。マイクロソフトは、同じ専用チップでも、FPGAで実装するという手段を提供した。少し引用する。

 FPGAを使うソフトDPUのメリットとして、柔軟性が高いことを挙げる。「機械学習の進化はとても早いが、FPGAであれば論理回路を後から変更することで、新しい手法に対応できる」(Chung氏)という主張だ。Microsoftが独自に浮動小数点の精度を定義し、それを実ハードウエアで検証できたのも、FPGAならではのメリットだ。論理回路をハードウエアとして実装すると、新しい手法を考案してもチップが完成する1~2年後までハードウエアでは検証できない

 これは納得である。技術が確立したら、専用チップをASICとして開発する方がいい。同じゲート規模でも、FPGAよりも安いし、消費電力上も有利だろうからだ。一方で、ディープラーニングは、発展途上の技術だという側面がある。その場合、すぐに回路を変更できるFPGAの方が有利だ。インテルは、Xilinxと並ぶ大手FPGA会社のAltera社を買った。これは、マイクロソフトのような動きを見越してのことなのだろう。AI時代には、新たなインテルとマイクロソフトの連携がはじまるのだろうか。

2017年7月14日 (金)

50歳台のSEを集めた新会社

 50歳台の社員の活用という話題は、他人ごとではない。自分が、その世代だからだ.。
 どうする?50代SE - “55歳ショック”の緩和を狙う富士通、50代SEを集めて新会社:ITproによると、富士通の役職定年制度では、給与が25%ダウンの75%になるという。さすがに、これは、やる気がなくなるだろう。ということで、SEの子会社を作り、50歳台のSEをそこへ異動させて活躍させるということをやっているらしい。そうすることで、給料のダウン率を少しでも下げられるのだという。
 SEという仕事は、体力のいる仕事だ。だから、50歳台のSEは、戦力外というのが、会社の論理なのだろう。でも、今の世の中、50歳台になると戦力外になるという職業とはなんなのだろう?
 昔、仕事で付き合った富士通のSEが、月100時間以上の時間外労働や、夜の11時から始まる開発会議などを、自慢げに話していたのを覚えている。50歳どころか、40歳になったら、勤まらない会社だなあ、と思ったものだ。まずは、体力勝負のデスマーチの開発を、定時退社できる開発の仕組みにすることが重要な気がする。

2017年6月29日 (木)

公共機関の神様は絶対に自分が“アホ”であるかを自覚することはないだろうなあ・・・

 木村岳史の極言暴論! - (4/4)発注者として最低最悪、公共機関のシステムをどうするのか:ITproという記事を読んで、表題のようなことを思った。特に、国のお偉い方々はそうである。国という抽象的なことを考えることが重要で、現場のことなどは、業者にやらせればいいと思っているに違いない。でも、庶民にとって重要なのは、現場である。現場の人間から見れば、現場のことをわからない雲の上の人は、“アホ”である。でも、雲の上の人は、現場しかわからない人間を“馬鹿”だと思っているんだろうなあ、きっと。

2017年6月22日 (木)

ソフトウエア開発をアウトソーシングしないGE社の本気度

 ソフトウエアのコーディングはアウトソーシングすべき、という会社は多い。
 超巨大スタートアップGE - ソフト開発のアウトソーシングを全面否定するGE:ITproによると、ソフトウエアの会社になると公言しているGE社では、そうではないらしい。だいたい、開発工程の中に、アウトソーシングすべきものなどない。開発そのものが付加価値の高い工程であり、アウトソーシングすべき付加価値の低い工程など存在しないと思うからだ。

2017年6月21日 (水)

廃棄まで責任を持つ:メーカーの技術者の心がけを実行に移すのが品質部門の役割

 IoTセキュリティに関する記事常識破りのIoTセキュリティ - (5/5)ユーザーはセキュリティを気にしない! それでも安全なIoTデバイスを:ITproで、廃棄まで責任を持つ、ということが明記されていた。本当にその通りである。機器というのは、最後には廃棄されるものである。そのライフエンドまで製品責任を持つのがメーカーというものである。何が売れるのかという話が製品開発の中心になりがちであるが、メーカーの最大の役割は品質保証であるということを、設計者は心に命じる必要がある。しかし、開発の忙しさにかまけて忘れがちである。それを思い出させるのが、本質保証部門の審査だ。まともなメーカーなら、製品化の前には必ず品質保証部門の審査が必要だろうし、まともなメーカーならその審査で開発部門が忘れがちでありながら製品にとって必要なことを審査する。

2017年5月 4日 (木)

マジメと本気の違い

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

2017年4月19日 (水)

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

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

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

 

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

より以前の記事一覧

2018年2月
        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      

公告

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