タグ

システム開発に関するekshinyahのブックマーク (12)

  • テスト計画の立て方 - Qiita

    テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

    テスト計画の立て方 - Qiita
    ekshinyah
    ekshinyah 2016/12/02
    “自然言語でまちまちに書かれた画面設計書やバッチ設計書がインプットになる機能テストなどは、人による粒度の差異が出やすいので、テストの観点とケースのあげ方のガイドを作るとよいです”
  • 気が狂った設計 - hitode909の日記

    大きめのこととか,自信のないところを触るときは,コード書く前に,こういう作戦考えてみたけどどうですかって聞いてみたり,こういうことやりたいんだけど一緒に考えませんかって,いっしょに話して設計考えたりするとよいと思う. 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので,未然に変な設計のままコード書いてしまうのを防げる. 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「(こんな実装は)有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う.我が社にはそんな強い言葉でレビュー書く人はいない. 我が社には,普段から強い言葉を発する人もいなくて,みんな物腰柔らかな変な言葉を話している. 言葉使いや文体は,ずっと過ごしてると同僚から移ったりするので,普段からそういう言葉を話していると,全体の雰囲気も悪くなりそ

    気が狂った設計 - hitode909の日記
  • kintone活用の「納品のない受託開発」事例から考える「ファストSI」そして「オルタナティヴSI」の本当の価値 | Social Change!

    先月は「Cloud Days」というイベントにサイボウズさんから機会を頂いて、札幌・名古屋・博多と回って講演をしてきました。というのも「納品のない受託開発」でサイボウズさんの「kintone」を活用しているからです。 また各地で併せて「kintone Café」という勉強会で「納品のない受託開発」とコラボしたイベントも開催して頂きました。各地の皆様ありがとうございました。この記事では「納品のない受託開発」でのkintone活用について書きました。 なぜ「kintone」を採用したのか? 「納品のない受託開発」はこのブログでも何度か紹介していますが、月額定額で顧問スタイルでお客様のパートナーとして相談から実装、運用までを終わりなくサービス提供する、新しい形の受託開発のビジネスモデルです。 来であればエンジニアを採用して内製したいけれども人材を集めるのが難しいようなケースに、顧問税理士や顧問

    kintone活用の「納品のない受託開発」事例から考える「ファストSI」そして「オルタナティヴSI」の本当の価値 | Social Change!
  • 今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog

    なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ

    今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
  • デスマをやってみた - satomicchyのつぶやき

    デスマーチとは 【 death march 】 〔 死の行進 〕 - 意味/解説/説明/定義 : IT用語辞典 デスマをやってみた。過去形だけど、リリース日が延期になって、スッキリ終わったわけではない。これからどう進めるかはこれから相談。知人によれば、それもまたデスマらしいと言う。 S/W業界のデスマは初めてだけど、前職の業界でも似たようなことはあった。そのときは、企業体質なのかラッキーだったのか、女性ていうのが考慮されてそれなりには帰らせてくれた。でも今回は、フリーランスになって初めてのデスマで、守ってくれるものなんてない。自分で自分のマネジメントをしなくちゃいけない。 自分マネジメントのためのステップとして、自分観察したことを書いておく。 コードに没頭すると日語が理解できなくなる現象 デスマ真っ最中は、起きてる間はほとんどPCに向かってコードを書いている状態で、作業をするときは「仕様

    デスマをやってみた - satomicchyのつぶやき
    ekshinyah
    ekshinyah 2014/12/03
    "1日に何通もメールがきて、どんな追加要望か、変更要望か、何を言われるか分からないと、メールがコワくなった"
  • 「納品をなくせば」の倉貫CEOたちが語る新しいSIへの道 (1/2)

    11月28日に開催されたCybozu Conference 2014では、「納品をなくせば」の倉貫義人氏など新しいSIにチャレンジする4社によるパネルディスカッションが行なわれた。人月単価や情シスの課題、肥大化するSIerなど、問題の質を突き詰める熱い議論が交わされた。 現場もお客さんも幸せにしない「人月単価」という魔物 「私たちが新しいSIに進む理由~クラウド時代に生き残れるSIビジネスとは~」と題されたパネルディスカッションに登壇したのは、納品のない受託開発を進めるソニックガーデンの倉貫義人氏、39万円でのシステム開発を手がけるジョイゾーの四宮靖隆氏、機械学習kintoneを組み合わせたシステムを手がけるTISの久保隆宏氏、ソフトバンクグループのSI子会社であるM-SOLUTIONSの植草学氏の4名だ。 4名は会社は違えど、既存のSIについて一家言持っており、短納期や定額制など新し

    「納品をなくせば」の倉貫CEOたちが語る新しいSIへの道 (1/2)
    ekshinyah
    ekshinyah 2014/12/01
    "小さい企業でも問題をきちんと解決できる企業が伸びてくるはず"
  • KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ

    はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると

    KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ
    ekshinyah
    ekshinyah 2014/10/31
    “1回目の振り返りはProblemが大量にありKeepは見つからないという傾向になりがちなので、ちょっとしたことでもKeepに挙げたり、Problemで人を責めないようにする”
  • 永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

    この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 | 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り

    永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
  • 「納品」をなくさなくてもうまくいく - arclamp

    倉貫さんから直接献をしていただいきましたので感想がてらに。 書はいわゆる“アジャイル”を清く正しく実践している実績と、その仕組みを丁寧に解説したです。しかも、開発体制は「事業会社の内製化」ではなく「外部のソフトウェア開発企業を継続的に利用する」というスタイルであることに大きな意味があります。 (ソフトウェア開発企業という名称ですが、もはや「ソフトウェアだけを開発している」わけではないので、来は「ITサービスを開発している」企業というような名称が最適なのですが、ここでは一般的な名称として使います) これまでアジャイル開発方法論は「事業会社における保守運用フェーズの内製開発」に最適であるとされてきました。実際、多くのウェブ企業が社内にエンジニアを抱え、継続的な保守運用の中でイテレーティブに開発を行うスタイルを実践しています。 しかし、実際には世の中の大半の企業が“優秀なエンジニア”を雇

    「納品」をなくさなくてもうまくいく - arclamp
    ekshinyah
    ekshinyah 2014/07/21
    “納品をしないとか一括請負契約をしないといったことはどうでもよくて、顧客と信頼関係を築き、優秀なエンジニアが真のパートナーになることが重要”
  • 【書評】「納品」をなくせばうまくいく 〜ソフトウェア業界の“常識"を変えるビジネスモデル〜 - GoTheDistance

    著者の倉貫さんより献御礼。 「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル 作者: 倉貫義人出版社/メーカー: 日実業出版社発売日: 2014/06/12メディア: 単行(ソフトカバー)この商品を含むブログ (1件) を見る 納品のない受託開発とは 簡単に言うと「一括請負契約をしないで、お客さんの欲しいシステムを受託開発すること」になります。何故一括請負契約をしないのかということが理解できないと、このモデルで契約する意味を感じられないでしょう。書の主題の1つに「完成(納品)を前提とした一括請負契約がシステム開発をダメにしている」という問題意識がありますので、そこを重点的に補足したいと思います。 一括請負契約の問題点 作ることが目的になる 一括請負契約では完成責任を果たすことが求められます。その為に要件定義を行い完成となる条件を決めます。そして要件を満

    【書評】「納品」をなくせばうまくいく 〜ソフトウェア業界の“常識"を変えるビジネスモデル〜 - GoTheDistance
    ekshinyah
    ekshinyah 2014/06/23
    "月額定額制の顧問プログラマを活用してソフトウエアとビジネスが共に成長することを目的とした受託開発モデルが「納品のない受託開発」であるいう理解"
  • 『殺される前に逃げるんだ!上流工程で察知すべき事(´・ω・)ス』

    先週6週間以上かけて組んだC#のソフトも、 納品してみたらトンでもない状況で、 大急ぎで仕様変更して3日徹夜->2日徹夜->2日徹夜という、 ストⅡならフルコンボな恐ろしい日々を過ごした。 どうにか土曜日には納品になったが、 肉体も精神も12ラウンドで目の開かない血だらけボクサー状態になった。 いや、WWEのHELL IN A CELLの金網デスマッチ並みだった(´・ω・)ス 徹夜っても朝方4,5時に少し仮眠とるとかそんな生易しい徹夜じゃなくて、 当の徹夜、さすがに50時間を超えたら、 緑のカバみたいなおっさんが出てきて 「 お前、ケジメつけろよ?」とか訳の分からない黄金期の日活ホラーな 幻覚もチラチラみたり。 いや、マジで。 まぁ、それはいいとして、 年に1~2回?いや、ここ最近、 打ち合わせというか、上流工程で、そのまま自分制作も行くケースがあり、 もしこれがチーム組んでいたらヤバか

    『殺される前に逃げるんだ!上流工程で察知すべき事(´・ω・)ス』
  • 特許庁の情報システムについて - myatsumoto blog

    例の特許庁の情報システム刷新の頓挫について興味があるので調べている http://itpro.nikkeibp.co.jp/article/NEWS/20120120/379019/?ST=cio とりあえず、まとめブログで探したのだが http://alfalfalfa.com/archives/5124175.html mP78iXTkの言ってることが尤もらしいので参考にして 報告書と照らし合わせてみたら全然違った。 特許庁の報告書に不備が60M項目あると書いてあったろ? オレの説明したのはその中の1個の話w とりあえず2chは1,000レスしか出来ないが説明欲しいか? 60Mステップは開発規模の話であって不備の話ではない。 報告書には 開 発 規 模 に つ い て は 、平 成 2 2 年 1 2 月 、約 6 0 M ス テ ッ プ に 達 す る と の 見 積 も り が T

    特許庁の情報システムについて - myatsumoto blog
  • 1