できの悪いソースコードをAIで発見、富士通が不採算案件の抑制へ
富士通が人工知能（AI）などを活用し、システム開発プロセスの改革に本腰を入れ始めた。システム構築・運用支援のツール群を「KIWare（ケーアイウェア）」として体系化し、2017年11月に50件の開発プロジェクトに本格適用を開始した。時間を浪費しがちな開発業務をAIで効率化し、システムエンジニア（SE）が、開発業務の様々な作業や成果物の品質の向上に充てる時間を捻出する狙いである。 富士通がAIの活用に本腰を入れる背景には、開発プロジェクトの作業や成果物の品質の低さが課題になっていることがある。「品質を現場の人任せではなく、技術で底上げする。それによって品質が原因の不採算の案件を減らしたい」（富士通の粟津正輝サービステクノロジー本部 本部長代理 兼 先端技術統括部長 兼 SE変革推進室長代理）。 システム開発において、不採算案件につながる要因は様々だ。設計書の不備による手戻りが発生したり、ソー
ラピッドイテレーションを実現するRE ENGINEの設計
【Unite Tokyo 2019】大量のアセットも怖くない！～HTTP/2による高速な通信の実装例～
技術フェローが「すごーい」「そうなんだー」「たのしー」しか言わなくなった件 - 弥生開発者ブログ
こんにちは！ Misoca開発チームのめろたん(@renyamizuno_)です！ 最近、いわゆる「トゥルーワイヤレスイヤホン」というのを買いました。 ボタンを２回押すとアシスタント機能(OK Googleとか)が立ち上がるのですが、 僕の場合は 「null」と発声 pic.twitter.com/YUWf3Ck1fY— わかり亭めろたん。 (@renyamizuno_) 2017年1月25日 「null」が立ち上がりました*1。 はい。 たーのしー！ 最近、「けものフレンズ」なるアニメが流行っていますね！ その影響をもろにうけていてMisocaちほーでも「たのしー！」とか「すごーい！」とかがすごーい流れてます。 その波はとどまること無く、オフィスに来ていた技術フェロー*2の@kakutaniさんにまで流れていたようで、 技術顧問が「すごーい」「そうなんだー」「たのしー」としか言わなくなっ
『茹でたニンジン』 : ソフトウェア開発の失敗と技術について | POSTD
子供の頃、私はニンジンが嫌いでした。においや食感がイヤだったのです。しかし実家を出て、自炊をするようになってからニンジンが好きになってきました。ニンジンそのものが変わったわけでもないですし、私の味覚が変わったわけでもありません。違いは調理法です。私の母や彼女と同年代の多くの英国人は、料理が得意ではなく、特に野菜の料理はイマイチでした。母はニンジンを20分以上茹でていたのです。適切な方法でニンジンを調理すれば、全く違った味になるということを私は学びました。 ここは調理のことを話すサイトではなく、ソフトウェア開発のことを話すサイトです。しかし、技術やツールはおいしくないニンジンと同じだなと思うことがよくあります。それは、「その技術が適切に用いられなかったことが本当の問題であるにも関わらず、技術自体が良くないものとして非難される」という点においてです。 いつか例を挙げてみましょう。私の複数の友人
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016
強いチームを作るには時間がかかる～強いチームのつくり方（前編）。Developers Summit 2016 業務で行われるソフトウェア開発プロジェクトのほとんどすべては、何らかのチームによって行われています。そしてそのプロジェクトが成功するか失敗するかを左右する大きな要因が、技術力よりも人間系にあることはよく指摘されることです。 では、その人間系に注目して強いチームを作るにはどうすればよいのか、そのヒントを多数紹介したセッション「強いチームのつくり方」が、2月19日に行われたイベントDeveloper Summit 2016（通称デブサミ）で行われました。この記事では、そのセッションの内容を前編、中編、後編の3本の記事で紹介します。 いまお読みの記事は前編です。 プロジェクトの多くは技術ではなく人間系で失敗している 吉羽 龍太郎氏（Ryuzee.com）。 吉羽と申します。いままで野村総
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
ハタさんのブログ : Javascriptによる大規模開発の覚え書き。高速化編
前回書いた「Javascriptによる大規模開発の覚え書き」が凄いことになってました。 今回は、省略した「5.高速化せよ」について書きます。 僕にとってjavascriptは非常に高速な言語です。それは何が高速か 開発速度が高速である 開発速度、及びそこに至るまでの修得速度はとても高速です。動的言語を上手く操る開発者はもちろん、開発に不慣れな(言葉が悪いけど)新人達でさえ「動く」モノをサクっと作ってしまえる。 また、プラットフォーム(? というかブラウザ)が広く普及しているので、ググればスグに問題解決もできる。 それにローカルで簡単に作れる。javascript、それは動作環境を含めて高速です。 高速にUI操作ができる(UI操作が非常に簡単である) swingとかでUI操作をするには多くのオブジェクト操作をしなければならないけど、javascript(もといDHTML)は非常に簡単に
Agile2007 Wednesday：An Agile Way：オルタナティブ・ブログ
Mary Poppendieckのリーダーシップについてのセッションは、立ち見（というか地べた座り）で満席。とくに、ＴＰＳとアジャイルの中から、「人」についての共通の考えを導き出しています。 「標準化」とはなにか。Mary は「現場の経営」（大野耐一の唯二の著書の１つで、最近英訳された）から、以下を引用し、いま、ソフウェア業界、多くの大企業で行われている間違った標準化について、指摘しました。 標準は、カイゼンの最初のベースラインというだけで、変えることが前提なんだ、そして、それはかならず現場で書く。 現在のソフトウェア業界で、いかに多くの「標準」というものが、現場から離れて書かれており、かつ、変えるのが困難か。作るのに１・２ヶ月もかかったら、それはもうダメだ。他人が机の上でつくった標準ではなく、「自分たちが作った標準」でなければ、カイゼンのモチベーションはうまれない。こういう、「あたりまえ
Firebug - Web Development Evolved
Thank you, Firebug. You made the web amazing for all! The story of Firefox and Firebug are synonymous with the rise of the web. We fought the good fight and changed how developers inspect HTML and debug JS in the browser. Firebug ushered the Web 2.0 era. Today, the work pioneered by the Firebug community through the last 12 years lives on in Firefox Developer Tools. Switch to the latest version of
窓の杜 - 【NEWS】米MS、HTML構造やレイアウトを検証できるWeb制作者向けIEプラグインを正式公開
米Microsoft Corporationは9日（現地時間）、Webページの構造を検証できるIE用プラグイン「Internet Explorer Developer Toolbar」の正式版を無償公開した。Windows XP/Server 2003/Vista上のIE6/7に対応し、現在同社のダウンロードセンターからダウンロードできる。 「Internet Explorer Developer Toolbar」は、IEのエクスプローラバーとして動作するWeb制作者向けのプラグイン。ローカルまたはインターネット上のWebページのHTML/CSS構文を解析でき、レイアウトや色合いの調整、W3Cの文法チェックサービスを利用した構文エラーチェックなど、アクセシビリティに配慮したWebページ作成に便利な機能が多数搭載されている。 エクスプローラバーはWebブラウザー画面の下側へ表示され、上部に各
Geekなぺーじ：技術の盗み方
新入生や新社会人として組織に入ったり、他の組織から畑違いの場所に異動すると、ゼロからのスタートになるときがあります。 そのときに、先輩からいかにして技術を「盗む」かが重要な要素になると思われます。 ここでは、自分の養分として吸収するために、先輩から技術を引き出す一手法を紹介したいと思います。 先輩から見て教え易い後輩や、ついつい必要以上に色々教えてしまう後輩などがいます。 今回は、そのような人の特徴を考えたり、過去の私が失敗したと思われる点を思い出しながら書いてみました。 ここで紹介する方法は、あくまで方法の一つであり偏っています。 性格によって向き不向きがあると思います。 また、あまりに露骨にやり過ぎると嫌われてしまう場合もあるのでご注意下さい。 あまり参考にはならないかも知れませんが、まあ、許してください。 やる気を見せる 非常にやる気があって、色々やっている人を見るとついつい応援した
Winプログラマ御用達の高機能エディタ「Notepad++ 4.0」がリリース (MYCOMジャーナル)
Notepad++プロジェクトは28日、Windows用テキストエディタの最新版「Notepad++ 4.0」をリリースした。Win32 APIを備えたWindowsの全バージョンに対応、バイナリパッケージはZIP書庫とインストーラ形式の2種類が提供される。ライセンスはGPL 2に準拠、再配布の制限なく自由に利用できる。 今回のリリースでは、構文のハイライト表示に対応するコンピュータ言語として、HaskellとInnpSetupに対応。文書を切り替える機能が強化され、MRU(最近使ったファイル)も対象に含めることが可能になった。プラグインとの連携も強化され、ダイアログボックスをNotepad++ウインドウの四隅に密着させる機能や、プラグインのコマンドを対象にショートカットを接続する機能が実装された。テキストエディタのエンジン部分として採用されているScintillaも、バージョン1.71に
Geekなぺーじ：「お客様は神様だ」をやり過ぎてはいけない
4. 結局は「最悪な」顧客サービスに陥ってしまう について 顧客よりも従業員を重視すると、結果として質の高い顧客サービスになるということらしいです。 従業員が満足していると、顧客に気を配るようになる。 従業員がエネルギッシュになる 従業員が気さくになる 従業員のモチベーションがあがる 逆に、顧客ばかりを重視してしまうと従業員に対しては以下のようなメッセージを発していることになるそうです。 従業員は重要ではないと言っていることになる 従業員に対する正しい待遇は重要では無いと言っていることになる 従業員が顧客からの敬意をうける必要は無いと言っている事になる 従業員は顧客からの要求に耐えなくてはならないと言っていることになる こうなると、従業員はサービスの質を気にしなくなってしまうそうです。 そして良いサービスは実現できないということらしいです。
recompile.net: サン流だけど一流のバグ管理心得
Java EE 5のStar Spec LeadであるBill ShannonがGlassfishのメーリングリストにバグの考え方の話を投稿してたんで、勢いで翻訳しちゃう。 大規模開発のときのバグ管理の心構えとしても興味深いですね ちがう、ちがう、ちがう。 バグポートフォリオをどうやって使うのかを、また説明しなきゃいけないようだね。もう毎回ずっと、ああもう、8年くらい？ リリースのたびに説明してこなかったっけ？ バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。バグのプライオリティってのは、我々の決定なんだ。単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。 バグの優先度は、意思決定プロセスの結果なんだよ。つまり、どれがバグで、どれがバグじゃない
便利すぎて困る程のFireBug1.0系を使ってみよう:phpspot開発日誌
Firebug - Web Development Evolved 便利すぎて困る程のFireBug1.0系を使ってみよう、ということで、広く使われているであろう0.4系と変わった点をプレビュー。 Googleなどの検索エンジンで、addons.mozilla.org にUPされている0.4系が上に表示されているため、まだ1.0系を使っていない人も多いのではないでしょうか？(という私もそうでした) FireBug1.0系のインストール方法の紹介〜その追加された強力すぎる機能について見ていきましょう。 FireBug1.0系インストール http://www.getfirebug.com/ にてFireBug1.0系のインストール。 FireFox - DOMインスペクタのインストール FireFoxインストール時にDOMインスペクタが入っていない場合は、FireBug1.0系の機能を最大限
開発者によるVisual Basicの利用が急減，JavaやC/C++が主流に：ITpro
米Evans Dataは米国時間11月28日，プログラミング言語の利用状況に関する調査結果を発表した。北米の開発者430人以上を対象に調査を実施したこところ，昨年の春と比べVisual Basic系を使用する開発者が35％減少したという。 Visual Basic 6.0以前のユーザーが減少しているほか，Visual Basic .NETを使用する開発者も26％減少した。 現在，最も利用率が高いのはJava（45％）で，以下C/C++（40％）とC#（32％）が続く。 Evans Data社長のJohn Andrews氏は，「プログラミング言語の世界では，1990年代初頭より米Microsoftが圧倒的に優勢だった。しかし，スクリプト言語やJavaの台頭により，Visual Basicの将来は頭打ちになった」と述べる。 その他の主な調査結果は次の通り。 ・2007年にWeb関連の開発に従事
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MSDN ホームページ
菊池 Blog - 菊池 Blog