「マイクロサービス」のメリットをざっくり言うと「変化に対応しやすい」こと──ただしファウラー氏は“使い過ぎ”を警告 | さくらのナレッジ
「マイクロサービス（Microservices）」という用語が、Web企業を中心に注目を集めています。マイクロサービスという言葉には、「おや？」と思わせる吸引力があると思います。ここでは、このマイクロサービスとは何か、いままでの考え方とは何が違うのかを見ていくことにしましょう。 マイクロサービスについて簡単に説明すると、システムを複数のサービスの集合体として構成し、サービス相互をRESTful Web APIのようなシンプルで軽量な手段で連携する手法です。その最大のメリットは、小規模なサービス群を疎結合する作りにすることにより、「一枚岩」（モノリシック）のシステムの複雑さから自由になることです。つまり、マイクロサービスの考え方を導入することで、変化に強いシステムを作ることができるのです。 マイクロサービスを深く知りたい方は、まず James Lewis氏、Martin Fowler氏による
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
開発者がアプリのアイデアをヒラメクための22箇条まとめ
「アプリやサービスを開発する技術はあるが、アイデアが出ない」という開発者たちのために、＠ITで掲載したアイデアの発想につながる記事から抽出して22箇条としてまとめた。 ヒラメキを、すぐ形にできる開発者だからこそ これまで、＠ITでは多くのアプリコンテストを行ってきた。そこで、いつも課題となるのは、「アプリやサービスを開発する技術はあるが、アイデアが出ない」という開発者たちの悩みだ。しかし、本当にそうなのだろうか。 開発者の方がより良いアイデアを思い付くことがあるのでは、ないだろうか。なぜなら、何気ないヒラメキを、すぐに形にできることは重要なことだからだ。 例えば、ライフレシピ共有サイト｢nanapi｣のロケットスタート 代表取締役 古川健介氏へのインタビュー記事「伝えることを考え抜く『nanapi』のUIデザイン」（2011年6月29日、聞き手ホシナ カズキ氏）を引用しよう。 デザインに限
システム監査の歴史
<BODY><P>このページを表示するには、フレームをサポートしているブラウザが必要です。</P></BODY>
codic - デベロッパーのためのネーミング辞書
codicは、プログラマーのためのネーミング辞書です。新しいcodicでは、翻訳エンジンを搭載しネーミングをジェネレートできるようになりました。
あなたの知らない超高速開発
あなたが携わるシステム開発プロジェクトで、開発速度が10倍速くなったらどう思うだろうか。「利用者にすぐに使ってもらえたり早く帰れたりするので、嬉しい」と思うか、「人月で見積もっているので売り上げが減ったりこれまでのマネジメントの方法が変ったりするので、嬉しくない」と思うか。 いずれにしろ、その後にこう思うことだろう。「そもそも10倍なんてできるわけないじゃないか」。だが、実際にできているユーザー企業が登場している。 記者は今年の1月と2月、日本と韓国で25社以上のユーザー企業を訪ねた。日経コンピュータの3月15日号に掲載した特集「『超高速開発』が日本を救う ～サムスンは既に始めている～」の取材のためだ。その中で、スクラッチ開発と比べて「10倍以上に開発効率が高まった」という声を、いくつも聞くことができた。三井住友海上火災保険や朝日生命保険、東京都足立区役所などである。 これは簡易的なシステ
構成管理 実践入門 第1章 構成管理入門 はじめに
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その１ メインライン コードライン編その２ コードラインポリシー コードライン編その３ プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その１ リリース管理 リリース編その２ 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか？ Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
「エクスプレス開発バイブル」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
エクスプレス開発バイブル（7）： エクスプレス開発は、クラウド時代に本領を発揮する いかにして開発を効率化し、納期を短縮化するか？ 家造りの考え方を参考に短納期開発の方法をあらゆる確度から紹介してきたエクスプレス開発バイブル。最終回となる今回は、従来以上にスピードが求められる本格的なクラウド時代の到来に備え、いま一度、エクスプレス開発手法の実践のポイントを振り返っておこう。（2010/9/16） エクスプレス開発バイブル（6）： 2チーム制で、開発効率とユーザー満足度を高めよう！ 開発する機能の重要度に応じて、開発作業に優先順位を付ける「開発案件3分割の術」はエクスプレス開発のキモといえる手法。では、それを実践するうえではどのような開発体制が効果的・効率的なのだろうか？（2010/3/25） エクスプレス開発バイブル（5）： 納期・コストを削減する“開発案件3分割”の術 開発案件に含まれる
“読み方”を知って、レビューをもっと効果的に
ソフトウェアレビューは、ただ漫然と行うだけでは期待する成果を得られない。ソフトウェアの品質向上に寄与する効果的な“指摘”をもっと効率的に行うためには、“それなりの読み方”がある なぜリーディング技法を使うか？ 第1回『“確実な記録”こそが、品質・コストに貢献する』では、「何のためにレビューを行うのか、そのために何を重視するのか」といった“観点”を持つこと、すなわち「目的を明確化すること」がレビューを成功させるポイントだと解説しました。 今回解説するリーディング技法とは、そうした「目的」を達成するために、レビューアが「ドキュメント類をどう読み進めていくか」を具体化したものです。一方、プロジェクトマネージャや品質管理担当者など、レビューを管理するメンバーにとっては、技法の種類が「レビューでどんな問題を発見できるのか」大まかに推測する手掛かりとなります。すなわち、「目的」に応じてどのリーディング
勤怠管理および経費精算システムの利用満足度調査 2009年11月18日｜ニュースリリース | NTTデータ経営研究所
株式会社NTTデータ経営研究所（本社：東京都渋谷区 代表取締役社長：谷口 和道）は、NTTレゾナント株式会社の提供するインターネット・アンケートサービス「gooリサーチ」の協力を得て、上場会社の会社員を対象に、企業が利用しているシステムの満足度と刷新の必要性を探るため、多くの会社員が使用している「勤怠管理」と「経費精算」のシステムに焦点をあて、利用満足度や不満の解消方法についての調査を行いました。 (調査期間：2009年9月17日～2009年9月25日) 【主な調査結果】 1.「満足している」は、勤怠管理システムが21.4%、経費管理システムが22.9％ 勤怠管理システムと経費管理システムの満足度はほぼ同じような結果が得られたが、「満足している」との回答は2割弱程度にとどまった。反面、不満足度はおのおの１割程度であり、ほとんどの人は不満を感じているものの「普通である」「しようがない」という
詰めの質問術
手戻りを招く「仕様の認識のズレ」や「仕様の抜け」。これらは質問のコツをつかんでいれば回避できる。システムの出来も見違えるはずだ。 目次
ケンブリッジ・ファシリテーション研究所－－－目次
「プロジェクトの目標がぼやけている」「議論の結果が行動につながらない」「メンバー間の意見の不一致が放置されたまま」「会議で延々と議論する割には結論が出ない」――。こんな症状に悩んでいませんか。こうした症状の治療方法にファシリテーションがあります。当研究所では、プロジェクトを円滑に進めるために、ファシリテーション・テクニックを研究し、実践のお手伝いをしています。現場で培った数々のテクニック/ノウハウの中から、即効性があるツールを紹介していきます。 ■第1回 問題を抱え込む前にイエローフラッグを ■第2回 イエローフラッグには感謝しよう ■第3回 セッション・ゴールとアジェンダ－理論編－ ■第4回 セッション・ゴールとアジェンダ－実践編－ ■第5回 課題管理とTo Do管理－概要編－ ■第6回 課題管理とTo Do管理－実践編－ ■第7回 チェックポイント－概要編－ ■第8回 チェックポイント
「現状のソフトウェア開発は間違っていないか？」（プロセス編）
失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
既存システムを分析するための考え方と対処法
上流工程-設計---目次
アジャイルは絶対、そのまま導入するな！〜本当に得をしたい情報シス部門にこっそり教える導入成功の極意一覧
グラス片手にアジャイル開発 第1回 ― 実践的アジャイル開発とは
SEが知っておきたいソフトウェア構成管理きほんのき
システム変更を安全かつスピーディに進めるための極意とは？～CRUD表で今すぐできるコスト削減