KISSの原則 - Wikipedia
KISS の原則 (英: KISS principle) とは、「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）という内容の、1960年代の米国海軍において言われた、経験的な原理・原則[1]の略語。その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。 由来[編集] この言葉は、ロッキードスカンクワークスの技術者のケリー・ジョンソン（1910-1990）によって造られた。 この言葉は、一般には Keep it simple, stupid.（シンプルにしておけ！この間抜け） と解釈されるが、ジョンソン自身は「simple」
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
ちょっと前にTogetterで作成したまとめに対して大きな反響をいただきました。 SIerは自動化する対象が違っているのでは？ - Togetter これは、私が Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) 作者: Jez Humble,David Farley出版社/メーカー: Addison-Wesley Professional発売日: 2010/07/27メディア: ハードカバー購入: 3人 クリック: 141回この商品を含むブログ (23件) を見るを読み始めて、ふとつぶやいた をきっかけに始まったTL上での議論をまとめたものです。この本は、7月に行わ
大規模SIは少数精鋭で乗り切れるのか？ - 急がば回れ、選ぶなら近道
まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草食集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術
「あなたのチームに最適なテスト」を考える（1/2） - ＠IT
連載：.NET中心会議議事録 第5回 「あなたのチームに最適なテスト」を考える デジタルアドバンテージ 一色 政彦 2011/07/12 今回のテーマは「.NET開発におけるテスト」。開発プロジェクトをスムーズに完了させるには、効率的なテスト手法で、高い品質を確実に確保する必要がある。そこでVisual Studio 2010のテスト機能を中心に、.NET開発におけるテストについて説明・議論した。セミナーの構成は、下記のとおり。 基調講演『Visual Studio 2010によるテスト手法』： 1時間。詳細後述。 パネル・ディスカッション『あなたのチームに最適な.NET開発のテスト手法』： 2時間。詳細後述。 Ｑ＆Ａセッション／懇親会： 45分。本セミナーに寄せられた質問をモデレータが発表し、パネリストが回答。 本稿では、基調講演およびパネル・ディスカッションのUstream中継の動画と
ユーザー主体開発が、最初からうまくいくわけがない
ユーザー主体開発が、最初からうまくいくわけがない：情報マネージャとSEのための「今週の1冊」（50） 業務課題は千差万別。真に有効なシステムを簡単・手軽になど作れるわけがない。ユーザー自身がそれなりの覚悟と情熱をもって「どう使うか」を考えることが必要だ。 激変する市場環境に追従するために、ビジネスの展開スピードは年々増している。一方で、必要なとき、迅速に利用できるクラウドサービスが浸透しつつあるほか、アプライアンスやパッケージ製品なども充実し、企業にとってはITを利用しやすい環境がますます整いつつある。 だが同時に、そうした環境は企業に主体性を求めるものでもある。いくらサービス・製品を利用しやすいとはいえ、それらを「どう使うか」というイメージがなければ、手軽に使えるだけにコストを無駄に垂れ流すことにもなりかねないためだ。ましてや、自社の業務はSaaSやパッケージだけで対応できるわけではない
バッチ処理時間が要件の7倍、SQL最適化から発想変えて対処
1. 届け先を管理する新設のDBサーバーで、バッチ処理時間が想定の6～7倍と判明 2. 一括ロードツールを使い、メモリー上での処理を活用して1時間以内に収めた 3. SOAサービスの粒度は、カスタマイズの手間を減らすため単純な機能単位にした 「1時間が要件のバッチ処理に当初、6～7時間もかかった。工夫を重ねて、ようやく時間内に収められた」（ヤマトシステム開発 グループソリューションカンパニー 次期NEKOプロジェクト マネージャー 田中諭氏）。 ヤマト運輸が5年ぶりの刷新を進めている基幹システム「第7次NEKOシステム」。住宅に送る「宅配」から、住宅に住む個人の都合に合わせて送る「個配」を目指したものだ。2010年9月には、送り状に記載された届け先の個人名や住所などを登録した「届け先DBサーバー」を新たに稼働させた。これまで送り状に書かれた届け先は、郵便番号など一部の情報しかシステムに登録
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい
無差別に技術をついばむ鳥アジャイル開発が日本で普及しない理由
アジャイル開発が提唱されてずいぶん経ちます。しかし、日本ではあまり普及していません。その理由は様々ですが、私は日本の情報産業の体質と、日本人特有の商習慣が一番大きな要因だと考えております。これからその理由を書きます。 話しを円滑に進めるために、先ずはアジャイル開発で良くある誤解について触れます。アジャイル開発を知らない人は、プロトタイプモデルと同じと考える傾向があります。しかし、アジャイル開発はプロトタイプモデルではありません。「設計書などの書類を作成せずに実装を行う開発手法」といったイメージを持つ人が多いのですが、アジャイル開発はプロトタイプモデルと本質的に異なります。 アジャイル開発の本質は、物事に柔軟かつ迅速に対処する事です。それは、プログラミングだけに限った話ではありません。テストファーストのイメージが強い人が多々見受けられますが、アジャイル開発は、実装段階を工夫するだけの開発手法
大和ネクスト銀行が開業、国内で初めて勘定系にLinuxを採用
大和証券グループのインターネット専業銀行である大和ネクスト銀行が2011年5月13日に開業した。同行は国内で初めて勘定系システムにオープンソースソフト（OSS）のLinuxを採用した銀行だ。5月17日現在、システムは順調に稼働している。 中核の勘定系システムにライセンスコストのかからないLinuxと安価なx86サーバーを採用し、提供業務を絞ることでシステムへの投資額を80億円以下（本誌推定）に抑えた。銀行の勘定系システムは一般的に、メインフレームで構築する場合で200億円程度、オープンシステムだと100億円程度かかる。 アプリケーションについては、新銀行の提供業務を「預金」と「為替」に絞り込んで開発費の増加を防いだ。「融資」はせず、投資信託などの金融商品も扱わない。 勘定系パッケージには、富士通の新ソフトを採用した。同ソフトは、ソニー銀行などで稼働実績がある「W-BANK」を基に開発した。
属人性を突き抜けろ−ソフトウェア業界のパラダイムシフト - レベルエンター山本大のブログ
もはや、エンジニア業界とは別の業種が生まれたのだろう。 先週の土日、あるコンテンツプロバイダ企業向けにAndroidの研修講師をやっていた。 そこでコンテンツプロバイダ（もしくはサービスプロバイダ）という仕事をしている人たちにふれて もはやSIエンジニアのような業界とは、ちがう業種だなと感じた。 研修担当のマネージャーさんの言葉が印象的だった。 「この業種はもはや、いままでのエンジニアの業種とは全く違うんです。 いわば属人性を突き抜ける感じですね。」と その言葉にひざをうつ思いがした。 SIの業界は、個人のスキルにたよる部分をなくすこと基本としている。プログラムを「いかに誰でもできる仕事にするか？」に、最大限の労力をついやしてきた。 そのための設計書でありそのためのウォーターフォールモデルである。 きわだって優秀でない人たちでも回せるように仕事を組み立てることが、 ウォーターフォールモデル
SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance
日本のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか？ - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと？」という１点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか？ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術者
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SIerは自動化する対象が違っているのでは？
SI企業はどうやってもうけているのか？
コードは負債、少ない方がいい