ペーパープロトタイピング入門 – 第1回 どうして紙でプロトを作るのか | fladdict
ペーパープロトタイピング講座シリーズ。第1回は導入編。 第1回はの導入編。ペーパー・プロトタイピングとは何なのか、何故必要なのか。そして導入することで、どんな利点があるのかを説明する。 ペーパー・プロトタイピングって何？ ペーパー・プロトタイピングとは、紙で実際にアプリやサイトを「実装する」ことである。 通常の開発においてコンテンツが使いやすいかどうかは、開発が終盤になるまでわからない。このため「作ってはみたが使いにくい」や「いまさら後戻りできない」という問題が発生する。UIや手触りが重要なモバイル系のアプリにおいて、これは致命的な問題になる。ペーパープロトタイピングはこの問題を低コストで解決する。 紙とペンで動作モックを作成することで、本実装を行う前に、素早く手戻なく検証を行うことができる。これにより、仕様書策定や実装前にPDCAのサイクルを実現できる。作業負荷の高い本実装を行う前に軽く
JavaからHTML5ヘ--業務システムの開発におけるウェブ技術の変化と適応事例（前編） - builder by ZDNet Japan
セキュリティモデルは変わった！ クラウド活用、リモートワークはあたりまえ いま求められるゼロトラスト実現のために ID管理の基礎知識 新しい働き方におけるITガバナンスの 向上にむけて 仮想デスクトップサービスの最新事情 複数の選択肢のあるMSのVDIサービス どう違うのかをわかりやすく解説 クラウド導入が進まない本当の課題 ITベンダーだからこそ知っている クラウドに二の足を踏む企業のボトルネック 見えてますか？通信のボトルネック 快適なデジタルワークの阻害要因を解消 Zscaler Digital Experience（ZDX）導入の価値 単純なインフラ製品の販売ではない DX、コンテナプラットフォームの実証など 自社の取り組みで得られた知見を顧客に提案 モダンなOSだからこそ可能 MS製品の歴史を振り返りながら ビルトインセキュリティの利点を理解 ともにDXを推進する コンテナ化され
JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例
JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例 佐川 夫美雄（Ashiras, inc.） フロント開発の現場では、Java中心の開発から、HTML、CSS、JavaScript中心の開発にかわりつつあります。今回は具体的な事例をもとに、実装アーキテクチャや開発インフラに、どのような変化が起きているかレポートします。 はじめに HTML5が2014年に正式勧告されることを受け、フロント業務アプリケーションに影響を与えています。より多くのことがHTMLやCSSでできるようになり、現場レベルでは開発スタイルそのものの見直しも行われています。実際、私が担当しているプロジェクトではJava中心の開発からHTML、CSS、JavaScript中心の開発へと開発環境を変えています。具体的に何をどのように変更しているのかを、私が担当しているプロジェクトの内容に沿ってご説明
フレームワークの責務とセキュリティ - MugeSoの日記
お久しぶりです。 夜中にモツ煮込み作りながら書いてます。 さて、今回はフレームワークの責務とセキュリティについて思うところがあって久しぶりにエントリを書くことにしました。 背景 まず、背景としてBEAR.Sundayの一部であるBEAR.PackageにサンプルとしてBasic認証の実装を追加するPullRequest#90でのやり取りがあります。このPRはzukimochiさんが作ったものに僕が修正を加えて出した物です。この中では、Basic認証用のパスワードをハッシュとして扱うように実装されています。 多くの人が斜め読みしているのは背景説明が長すぎるからだと思ったので削除しました。詳しく知りたい方はPRをご覧ください。 本題 いよいよ本題です。 PRの最後にkoriymさんが発言している次の言葉はフレームワーク開発に於いてとても重要です。 より関心のある問題に集中するために、特に専門と
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
プロジェクトマネジメントなう＼(^O^)／ | ぽんぽんぺいんなう＼(^O^)／
２０代後半から１５年ほどSIプロジェクトのリーダー／マネージャーをやってきた経験から。 『 監督とは、 他人が打ったホームランで金を稼ぐことだ。 』 ケーシー・ステンゲル（MLB監督） ●ポリシー １）全てのメンバーが目的・段取りのわからない仕事をしない／させない。 ２）プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識すること。 ３）プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。 ４）プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。 ５）リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは、中長期的には失敗する。 ６）みんなで得意なことを持ち寄って知恵を出し合ってやってみてダメだったらそれは僕らにはムリな仕事だったということ。 ７）人は一人一人別人であり仕事に対するスタ
安全なバッチ処理の作り方 - KAYAC Engineers' Blog
このまえ登り坂の途中でロードバイクのタイヤが破裂しました。ながたです。 今回はバッチ処理について書いてみようと思います。 バッチ処理？ Webサービスの処理開始条件は、大まかに次の2つに分けることができます。 ユーザーのアクションに起因するもの ユーザーのアクションに起因しないもの このうち後者の処理をバッチ処理が担当することになります。 バッチ処理の担当分はさらに、 特定の条件（時間やサービスの状態）で実行するもの 手動で実行するもの の2つに分けられます。 今回はこの「手動で実行するもの」について書きたいと思います。 バッチを手動実行するのはどんなとき？ バッチ処理を手動で実行するのは、十中八九イレギュラーな状況が発生したときです。 ルーチンワークや実行の条件が決まっているものは何らかの方法で自動化できるはずです。 そしてイレギュラーな状況のほとんどは不具合が発生したとき。 つまり 重
jpshadowapps, Web界隈の皆様、バッチの事も少し好きになってください
私が勤めております会社はコンシューマ系ネットサービス会社でして、所属するエンジニアも大半がユーザーダイレクトなシステムに携わる面々なわけでして、 僕みたいな今も昔もバックエンダーな奴はCoffeeScript？何それキリマンジャロ？とか思いつつ、 シャレオツ( )エンジニアが産んでいく乳根入魂の作品を羨望の白目で眺めていたりするわけです。 それはいいとして。 メインサービスはユーザーダイレクトなフロントエンドとはいいつつ、そういう部署に属する面々も集計・分析などでバッチ処理を書く機会があるわけなんですけど、 彼等の書くバッチ（含:上記火消し）には共通項がある事に気付きまして、そしてそれが火消しを厄介にする大きな要因にもなっているわけでありまして、 ザッと挙げてみますと、 ジョブフローやらファイル設計書etcの仕様書は一切なし やたらと1機能1ジョブ（≠プログラム）を徹底 やたらとオンメモリ
【読書】システム設計の謎を解く 強いSEになるための、機能設計/入出力設計の極意
モニターということで、ソフトバンククリエイティブ様より御本を贈って頂きました。ありがとうございます。 まだ隅々までは目を通しきれてはいないのですが、いま読んでいて思ったことなど書いておきたいと思います。 ■はじめに この本の最後の章には次のような記述があります。 ・本書は共通・文書化などを取り上げているため、「ウォーターフォール」型開発に関する書籍だととらえられてしまうのではないかという危惧を抱いています。 ・本書ではあえて設計や文書化の方法に多くの説明を行っています。これは、「設計要素を知っていて文書や記述を削る」のは適切な行為だと思いますが、「設計要素があることを知らずに文書や記述を削る」のは品質やプロジェクトの遂行に対してマイナスの要素をもたらすと考えているからです。 ・アジャイル開発では「設計はしない」「設計書は書かない」ととらえているとしたら、それは誤解です。アジャイル開発におい
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
「納品のない受託開発」とは 〜 これからの時代にあったソフトウェア受託開発のビジネスモデル | Social Change!
昔は技術的に出来なかった為に運用でカバーしてきた慣習が残り続けているけれども、実は今の技術で考え直すともっと無駄なく簡単に出来ることって、多くの業界で起きているように思います。 もちろん、ソフトウェアの受託開発の世界でも起きています。ソフトウェア開発を生業とする私たちの会社で考えたのは、昔ながらの商習慣によって様々な問題を引き起こしているのは「納品」ではないか、ということでした。 この記事ではソフトウェアにおける「納品」のもたらす問題と、私たちの会社で解決している方法「納品のない受託開発」について書きました。（自社のウェブサイト用に書いた原稿をブログにしただけなので、それっぽい表現になってます。） 「納品」が引き起こしている問題 私たちソニックガーデンの受託開発では、一括委託を行っていません。ソフトウェア開発における「一括請負での受託開発」のビジネスモデルは、多くの問題を生み出してきたから
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
保守性・拡張性に優れたシステムを作る インデックス － ＠IT情報マネジメント
システム開発はなぜ楽にならないか？ 保守性・拡張性に優れたシステムを作る（12） 最終回となる今回は、システム開発がなぜ楽にならないのか、楽になる方法はあるのかについて、私見を披露する
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
システム開発の仕様書テンプレートや参考サイトのまとめ｜IT情報局
システム開発の際に必要になる要求仕様書や基本設計、詳細設計に使う各種の書類のテンプレートを紹介しているサイトをまとめました。 また、参考になる資料を配布しているサイトや開発関連資料の書き方などの説明をしているサイトもあります。 システムを開発時の書式や方法は各プロジェクトによって使うフォーマットは異なりますが、初めて開発する場合や自社での開発資料を作成する際のテンプレートとして参考にしてください。 2017/2/22 追記 リンク先の資料を配布しているサイトがかなり古くなってしまったのでリンクの見直しと、新たにシステム開発の資料を提供しているサイトを探して追加しました。 仕様書のダウンロードができるサイト Pocket 9 要求仕様書から見積、基本設計、詳細設計、コーディング規約、テスト仕様書、その他スケジュールや議事録まで システム開発に必要な書類のテンプレートがそろっています。 htt
Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（１） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） こんなような話は、何回も書いているけど、 最近、ソフトウェア工学ネタで、見てくれる人が多くなった。 なので、もしかすると、見てない人がいるかもしれないので、 また、取り上げてみる。 ■全体の流れと、今日の説明範囲 そもそもＵＭＬだと、「詳細設計書」は、書かなくないか？ http://blog.goo.ne.jp/xmldtp/e/147b230c186e8b5a3d5092cb0c50ecf9 に書いた。 (以下太字が書いたところ。なお、今回は、番号を振っている） いい、いくよ！付いてきてね！！ （１）ユースケースに対して、そのアクティビティを書いて、 要求を明示するよねえ →ユースケース図、アクティビティ図 （２）そのアクティビティに対し、入出力を明示し （ここが入出力設計、Ｕ
結合テストと総合テスト
ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社
結合テスト仕様書兼報告書のテンプレート
シナリオとケースの作り方 筆者が初めて結合テストの仕様書を作成する際、何から作成してよいかさっぱりわからなかった記憶があります。そうこうしているうちに時間ばかりが過ぎ、焦りが募っていきました。今思えば、それは「シナリオ」と「ケース」をどう作ったらよいかピンときていなかったからでしょう。そこで、結合テストに出てくる「シナリオ」と「ケース」について整理してみたいと思います。 シナリオとは「受注業務」「発注業務」「請求業務」「支払業務」といった業務の単位と考えるとわかりやすいでしょう。その単位をシナリオとし、これが結合テスト仕様書の単位にもなります。またこれには通常、上流工程で作成した業務フロー図が対応します。したがってシナリオ＝業務の単位＝結合テスト仕様書の単位＝業務フロー図の単位となるのが基本です。 また、ケースとはシナリオ内での場合分けと考えるとよいでしょう。例えば、支払業務を1シナリオと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発の実際
ログイン - 技術情報Wiki