老害エンジニアにならないために自分自身を「モダナイズ」するための極意
日々、新たな技術が生まれ、市場環境も変化し続けるIT業界では、エンジニア自身が自分を「モダナイズ」していくことが、生き残りのためのカギとなる。日本マイクロソフトのエバンジェリストが語る「モダナイズ」の極意とは何か。そして、そのために利用できるリソースには、どのようなものがあるのだろうか。 近ごろ、エンタープライズITに関する話題の中で「モダナイズ」あるいは「モダナイゼーション」という言葉を聞くことが増えていないだろうか。字義通りに訳せば「現代化（する）」といった意味だが、特にシステム開発の分野では「数世代前の技術を用いて作られた古いシステムや方法論を、最新の技術要素を使って、より現代的なものへと作り変える」といった意味で使われることが多いようだ。 そして、この「モダナイズ」は、古いシステムに対してだけ使われているわけではない。日々、新たな技術が生まれ、市場環境も変化し続けるIT業界において
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
なぜシステム会社の見積りが「ボッタクリ」に見えるのかを、きちんと説明する。
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』（現在は非公開） ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ（仕様）だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
無料のシステム開発テンプレート集（Excel版）: ある SE のつぶやき
はじめに システム開発を効率よく進めるための１つの方法として、システム開発のテンプレートを使用することがあります。 ですが、システム開発のテンプレートは企業内で閉じてしまっていてなかなかインターネットで公開されることはありません。 ですので、システム開発で使用するであろうテンプレート集を Excel で作成して公開します。もちろん無料で商用利用可能です。改変も OK です。 プロジェクト管理用 スケジュール管理などのプロジェクト管理用のテンプレートはなかなかないのですが、プロジェクト管理の補助となるようなテンプレートを用意しました。 プロジェクト管理ツールは、別記事の「フリーで使えるプロジェクト管理ツールまとめ」をご参照ください。
大規模システム開発案件のデスマーチは、どうしてこんなにつらいのか - あいむあらいぶ
かるび（@karub_imalive)です。 この春までSI業界にいたので、たびたび大型システム開発案件の大規模炎上を見てきました。そして、ここ最近はみずほ銀行のシステム統合案件が厳しいようです。 2012年頃からスタートし、一昨年くらいからヤバイんじゃないの？と言われていた案件がどうも最終局面な感じになってきているようですね。 規模的に見ても、大きすぎて後戻りできないっぽいので、カネと時間がいくらかかっても最後までやりきるしかなさそう。しかし、みずほ社内オトシマエとしてたくさんの悲しい人事異動が発令されることでしょう・・・。（まぁ、今回はソースがまとめサイトやマイナー雑誌の抄訳なので、詳細については続報を見守りたいところですが・・・) さて、プロジェクトの炎上にも色々ありますよね。大きい案件なら数千人規模から、小案件なら2～3人規模のプロジェクトまで、規模を選ばず、炎上するときは炎上する
みずほ銀行次期システム関連のまとめ（2016/11/24 追記あり） - Akio's Log
(追記1：2016/7/11 7/7以降のブログ記事などを追加) (追記2：2016/11/24 延期発表の記事を追加) こんばんは。SE兼PM見習いです。 例のみずほ銀行の次期システム開発が話題になってますね。 blog.livedoor.jp blog.livedoor.jp 毎年この時期に、みずほ案件がグダグダだよね、という情報が出てくるのはもう恒例行事となってますが、開発工程終盤を迎えていよいよヤバイ状況が隠しきれなくなっているようです。 趣味が悪いと言われますが、デスマウォッチャーでして、特にこのみずほ銀行案件をウキウキとウォッチングしているのですが、ここでブックマークしている過去の情報を時系列に振り返ってまとめてみたいなと思います。 2002年〜合併時のシステム障害〜 次期システム案件の話に入る前に、みずほ銀行合併時の大規模システム障害に触れておく必要があります。 https:
土日で作るWebサービス入門 - toyoshiの日記
先週日曜日に総額480円、プログラムコード200行、作業時間8時間で「給与明細.net」(http://www.給与明細.net)というWebサービスを作ってリリースをしました。これは給与支払明細書のPDFをWebで簡単に作れるWebサービスです。 シンプルな内容なので開発を開始してから8時間以内の作業でリリースできました。このエントリではサクッとサービスを開発してリリースするまでの僕なりの方法を紹介します。 特長 無料 会員登録不要 Excelから一括作成できる（CSVではない） オープンソース（MITライセンス） 目次 解決したい課題を見つける ドメインを取得する サイトマップとURLを決定する よいツールを集める まずデプロイ（公開）する そこそこのデザインにする 最低の機能をつけたらリリースする 広めるための準備をする おまけ：コードをかく 解決したい課題を見つける これがないとそ
DeploygateでケーブルレスなAndroidアプリ開発 - 年中アイス
会社で使ってて便利なので簡単に紹介。 私は開発者ではなくPMの立場（開発してないが確認をする）として使ってます。 Deploygate 株式会社ミクシィの提供するAndroid向けプライベートアプリ配布サービスです。 公式はこちらDeployGate - An incredibly easy way to deploy apps in development! スマートフォン向けアプリのプライベート配信プラットフォーム ストア公開前のアプリを瞬時に端末へ配布。 アップデート、ログ収集、すべてをワイヤレスでリアルタイムに。 使い方を簡単に Webサービスと、Androidアプリがあります。要アカウント作成。 Webサービス上で、Androidアプリをアップロードする。 GooglePlayで配布されている、DeploygateのAndroidアプリを開発/テスト端末にインストールする。 開発
実機がプアならリモートデスクトップを試せばいいじゃない？ お名前.com デスクトップクラウド for Windowsアプリで開発してみた - はてなニュース
（ここまでのあらすじ）はてなでは、Windows 8のリリースに合わせてWindowsストアアプリ「はてなブックマーク」をいち早くリリースしました。この開発を主導したエンジニアは、社内でこんな声を耳にします――「ブックマークのアプリは便利やけど、検索もできるともっとええなあ」。そう、新機能追加の要望です。継続的な開発を進めなければなりません。しかし手元のPCはリプレイス予定。これに代わるものはないかしら？ そこにGMOインターネットから、クラウド型開発環境「お名前.com デスクトップクラウド for Windowsアプリ」を試用しませんか？ とのありがたい申し出が！ はてなブックマークのWindowsストアアプリ開発セカンドシーズンでは、クラウド開発による検索機能の追加に挑戦します！ （※この記事はGMOインターネット株式会社によるPR記事です） 「お名前.com デスクトップクラウド
AWS-CloudDesignPattern CDP2.0候補
AWSクラウドデザインパターンとは？ AWSクラウドデザインパターン (AWS Cloud Design Pattern, 略してCDPと呼ぶ)とは、AWSクラウドを使ったシステムアーキテクチャ設計を行う際に発生する、典型的な問題とそれに対する解決策・設計方法を、分かりやすく分類して、ノウハウとして利用できるように整理したものである。 これまで多くのクラウドアーキテクト達が発見してきた、もしくは編み出しきた設計・運用のノウハウのうち、クラウド上で利用が可能なものをクラウドデザインのパターンという形式で一覧化し、暗黙知から形式知に変換したものであるといえる。 パターンの中には、クラウドでなくても実現できるもの、今まででも実現されていたものも含まれているが、クラウド上でも今まで通りのアーキテクチャが実現でき、かつクラウドを利用する事で、より安価にそしてより容易に実現できるものは、CDPとして収
DSAS開発者の部屋:Android アプリケーションが起動するまでの流れ
プログラム開発のために Android 上でアプリが起動するまでの過程を調べてみました。備忘をかねて、ソースコードをひと通り追跡した記録をここに控えます。 まとめ ※クリックすると大きな図が開きます Zygote（ザイゴート）プロセスは、Android システムブート時に起動し DalvikVM 本体と Android プログラムの実行に必要なダイナミックリンクライブラリと Java のクラスライブラリをロードした状態で待機する常駐プロセスである Zygote プロセスの目的は、同プロセスを fork することによりプログラム実行用のプロセス環境を素早く効率的にシステムへ提供することにある UNIX ドメインソケット /dev/socket/zygote が Zygote プロセスへのインターフェイスであり、同ソケットにプロセス生成要求を送出すると Zygote はプロセス fork を実
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
Javaが行き詰まってるだって？ - s-ishigamiの日記
java釣られましたhttp://www.publickey1.jp/blog/10/java_2.htmlおっしゃることは分かります。新人にJavaを教えるのは教えることが多すぎて、かといってCほどCPUの仕組みまで意識することができず、Ruby等の軽量言語よりも開発スピードが遅い、その上、Eclipseを覚えて、HibernateやSpringがまた複雑で……でも、これだけでは、4年前くらいにRoRが台頭してJavaがdisられまくった時期と同じ論調です。Javaがあたかも死んだかのように言われた時期がありましたが、今もJavaは元気ですよ！ということで、別の一面が問題ですね。このアナリストが指摘するように、コーディングなしでビジネス要件を答える手段が重要になってくるのは分かります。最近「Salesforceを使って、一ヶ月で作りました」みたいな話も聞きます。それはそれでいいんじゃない
Javaはアプリケーション開発言語として行き詰まっている、とアナリスト
「Javaによるビジネスアプリケーションの開発は複雑すぎる。開発チームはJavaからの逃避を検討すべきだ」という内容のレポート「Java Is A Dead-End For Enterprise App Development」（Javaはエンタープライズアプリケーション開発に行き詰まっている）を調査会社フォレスターのアナリストMike Gualtieri氏がブログで公開しています。 Gualtieri氏は、Javaはビジネスアプリケーションの開発言語として確固たる地位を築いており、COBOLが消え去らないのと同じように急に消え去ったりはしないけれど、Java以外の選択肢を検討した方がよいとしています。 ビジネス要件が変わり、プレゼンテーションレイヤで失敗した Javaが行き詰まっているというGualtieri氏のおもな理由をピックアップしてみましょう。 ビジネスの要件が変わってきた 変化
受託開発が抱える本質的な非効率性に関する考察 - GeekFactory
受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。
アーキテクチャの情報を伝えるための10のヒント
はじめに 何年か前、私は同僚と一緒に、アーキテクチャの計画をある重役に説明するために使うPowerPointプレゼンテーションを作成しました。何枚ものスライドを含んだ、かなり印象的な仕上がりの（...とそのときは思っていた）プレゼンテーションだったのですが、ご想像のとおり、いざ会議になると、スライド3枚を見てもらうのが精一杯で、こちらのメッセージやその妥当性を効果的に伝えることなどできませんでした。 幸い、我々にはもう一度チャンスが与えられました。そこで、今度は同じ間違いを繰り返すまいと心に決めました。80ページに及ぶ資料で情報を伝えようとするのではなく、この重役に関係のある情報を抜き出し、全体的な計画プロセスと、この重役が担当する自動化製品群に関する例とを組み合わせて、1ページの資料にまとめました。このリーガルサイズ1枚のシンプルな資料を使って、もっと有意義な会話ができるようにする、とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
単体テスト計画書（3） ― ホワイトボックステスト（2）、網羅率
開発工程とテスト ― 単体／統合／受入／システム／回帰テスト