ソフトウェア開発とは何か？ | DevTab - 成長しつづけるデベロッパーのための情報タブロイド
ベタープログラマ 書籍「ベタープログラマ」の14章を読んで、「ソフトウェア開発とは何なのか」という問いに直面しました。ベタープログラマがさまざまなメタファを用いて明らかにしようとするソフトウェア開発のあり方、一つ一つに私は共感しました。このうちどのくらい出来ているのか？を考えるのに良い機会となりました。 一方、ソフトウェア開発とは何かという問いの向こう側に、そもそも「ソフトウェアとは何か」という問いがあることに気づきました。ソフトウェアとは一体何でしょう？ 煩わしさを減らす、嬉しさを増やす 先日、ベトナムのホーチミンに講演に行く機会がありました。そこで空港からの移動のためにUBerを使ったわけですが、やっぱりこれが便利なわけですね。少し詳しく考えてみると、もしUberが無かったら、私は右も左も分からない空港周辺で、タクシーを探すことになります。向こうのタクシーの売り込みは激しく、異国の地の
ソフトウェア例え話、格言、小噺 - from scratch
2016年になってから色んなソフトウェアエンジニアの人と話してきて、その中で3人から聞いた例え話、格言、小噺が面白かったので、僕の中だけで留めておかずに開放しておく。 息継ぎをするには『まず息を吐く』という例え話 水泳で息継ぎをするなら『まず息を吐きなさい』と教わるらしい。これは息を吐かずにどこかで息を貯めてしまうと、ちゃんと息を吸えないという事を意味してる。息を吐くと苦しくなって顔は絶対に水面に出る。 これと同じことがソフトウェアの学習にも言える。 つまりまずアウトプットする、なんでも良い。作ったものをGitHubに公開するとか、発表するとか、ブログやQiitaに書くとか。ちゃんとアウトプットしたものはフィードバックがあり、そのフィードバックを受ける(PRやissue, 質問, マサカリ etc)、どんどん吐き出していくと吸わないとネタがなくなるので、吸い込むためにまたインプットする。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
JJUG CCC 2015 Fall 2015-11-28T15:00-15:50 の発表資料です。 話せなかった分は切りましたが、言いたいことは言い切っています。
「基本設計を分担してはいけない」わけねーよという話 - novtan別館
こういう話をするときに前提というか設定というかそういうのが雑なままで進めるとさっぱり話のフォーカスが合わない。という話になっている時点で「そりゃ分担したら上手く行かないよな」と思ってしまうわけで、つまりこの話は定量的・定性的な分析ではなくて個人の体験談なんだろうな、と思った次第。 私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。 基本設計を分担してはいけない: 設計者の発言 もういきなりわからないのが「何人もの」で、１人じゃないとダメなのか、何人までならいいのかとかそういうどうすべきかの話がわからず、DB設計がインフラの話なのかモデルの話なのかネーミングの話なのかもわからない。え、それ全
アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。（言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを
その契約で大丈夫？請負契約と準委任契約の違い - 三つ数えろ
ソフトウェア開発などで登場する主な契約には「請負契約」「準委任契約」「派遣契約」などがあります。それぞれの契約には大きな違いがあるため、契約締結の際には十分な契約内容の理解が必要です。 よく目にする契約としては「業務委託契約」があります。しかしこの「業務委託契約」は契約書の名称としてはあっても、民法で定められた契約種別に該当するものではありません。後述しますが、業務委託契約は「準委任契約」に属するケースが多い契約です。混同しがちなこれらについて整理してみました。 請負契約とは 委任契約とは準委任契約とは 派遣契約とは 準委任契約と派遣契約の違いは？ 契約時の注意点 請負契約とは 請負契約とは、成果（納品物）と納期が確定している契約です。発注者（注文者）は納品物の期日通りの完成をもって請負人（この記事ではソフトウエア開発を行うIT業者）に対価を支払います。 民法632条 請負（うけおい）とは
開発ワークフローを、いつどう変えるか | GREE Engineering
こんにちは、岡崎 @watermintです。 このエントリは GREE Advent Calendar 2013の記事です。この記事は5日目の記事です。 今日はGREE Tech Talk #04 スマートフォン時代のソフトウエアテストが弊社セミナールームで行われます。岡崎は「Jenkinsによるテスト自動化の会社への導入」というパネルディスカッションに参加させていただきます。パネルディスカッションの内容がどうなるかは会場の皆様からのご質問などによって変わっていくと思いますが、今日の記事では開発ワークフローについての考えを紹介します。 開発プロセスをなぜ変えるのか 開発プロセスを変えようとするモチベーションはいくつかあると思います。組織規模、ビジネスモデルなどによって多少諸条件は違うとしても大まかには次のような目標を達成することがモチベーションになるでしょう。 開発メンバーが変わっても対応
システム化の目的は、Excelの焼き直しであってはならない - GoTheDistance
これは興味深い問題提起。 エクセルでできることができない何百万のシステム・・ 「Excelで出来ることが出来ないシステムとかいうものに、なんで数百万も突っ込む必要があるのか」という話には、キチンと整理して説明できるようにしておきたいもの。 機能面ではExcelには勝てない Excelが提供している豊富な機能群は、世界でも選りすぐりのソフトウエア開発チームが途方も無い期間と金額をかけて作り上げたものです。Excelで出来る機能と同等の機能を提供することは、納期も予算も上限がある業務システム開発プロジェクトにおいて、非常にハードルの高い機能要件でしょう。業者からすると「ウサイン・ボルトに100m走で勝利しろ、期間は2ヶ月で」って言われても的な・・・ でも、「Excelとかいう最強の業務ソフトと同じこと望むなよ、そんなもん無理」で突っぱねてしまうのも違う。Excelには無い価値ってどこにあるかを
SAP、業務アプリ用のJavaScript製UIライブラリ「OpenUI5」を公開。レスポンシブ対応でモバイルデバイスにも
SAP、業務アプリ用のJavaScript製UIライブラリ「OpenUI5」を公開。レスポンシブ対応でモバイルデバイスにも 業務アプリケーション最大手の独SAPは、業務アプリケーションのためのJavaScript製JavaScrit UIライブラリ「OpenUI5」をオープンソースとして公開しました。 OpenUI5は、同社のモバイルアプリケーションなどに用いられているJavaScript製ライブラリ「SAPUI5」の主な機能をオープンソース化したもの。jQuery、CSSプロセッサのLESS、ODataライブラリのdatajsなどが使われています。 ボタンやアコーディオン、メニュー、テーブル、ダイアログと言った部品だけでなく、レスポンシブ対応のグリッドレイアウトなどのレイアウト用部品も含まれており、モバイルデバイスに対応するレスポンシブデザインのUI構築が可能になっています。 JavaS
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
がんばるあなたがプロジェクトを殺す - haradakiro's blog
あまりに暑いのでちょっと怪談を。 今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。 投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。 しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)
基本仕様書の書き方 - LumberMill's Notes
「仕様書の書き方」の一連のページをまとめて電子書籍化しました。 iBookstore で発売中です。 2015.05.11 この文章や、文章中で定義する用語は、株式会社ランバーミルの開発業務の中で蓄積されたノウハウを基にしています。業界一般や書籍等で定義されているものとは、必ずしもニュアンスが一致していない点に注意して下さい（業務の参考にはなるかもしれませんが、試験対策には使えません）。 基本仕様書とは クライアントからの（システムに対する）要求がほぼ出揃ったと判断できるタイミングで作成する仕様書です。クライアントの要求（要件定義書）を、ディベロッパからの視点で再定義すると共に、大まかなスケジュールや構成等を決定します。さらに、予定する方法でシステムを実現した際に発現が想定される問題点、制限事項等も、現段階で可能な限り明らかにします。 各項目の記載指針 以下では、基本仕様書に含まれる各項目
riac.jp
riac.jp 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
僕がCOBOLから学んだこと - worarの日記
SAStruts＋DBFluteでの開発が終わり、またCOBOLで書かれたシステムの保守が始まる・・・。 あぁ、楽しかったSAStruts、楽しかったDBFlute、楽しかったJava。 ということで、この辺りで一度、COBOLから学んだことについてまとめてみようと思う。 僕が今、主にかかわっているシステムはクライアント側がVB(Windows)、サーバ側がCOBOL(UNIX)で出来ている。そして更にバックボーンには、メインフレームが構えている。メインフレーム側の構成は主にPL/1＋JCLで、もちろんDBは階層型だ。 そんなシステムを２年近く保守してきた中で気付いたことを書いて行こうと思う。 カプセル化やスコープの重要性 今更何を言っているのかと思う方もいると思うけど、マジなんだ。僕が初めて学んだ言語はC言語でそれからC++、Javaと続き、その後LL言語にも手を出し始めた。C++を始め
巨大な(あるいは、汚くて邪悪な)コードの泳ぎ方 - mizchi's blog
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発工程とテスト入門
NameBright - Domain Expired
ふつうの受託開発チームのつくりかた
ウォーターフォール開発／スパイラル開発／アジャイル開発 お金と契約にまつわる本当の話
