ポーカーに学ぶ、ソフトウェア開発のレッスン
あなたは、平均的なポーカーのプレイヤーを打ち負かすようなコンピュータプログラムを設計する事は出来ます。基本的なルールに従えば、あなたの勝利は保証されます。しかし今日に至るまで、最高のポーカープレイヤーを打ち負かせるようなプログラムは存在しません。これは、高いレベルのポーカーは芸術に等しいからです。もちろん、ソフトウェア開発についても同じ事が言えます。平均的な開発者になるためには、ベストプラクティスのカタログさえあれば十分です。そのクックブックに従えば、平均的なアプリケーションを作れる事がほぼ保証されます。正直なところ、その平均的なアプリケーションと言うのは、ほとんどの場合一般的なものよりも優れています。多くのプロジェクトは失敗に終わっており、多くのマネージャーは、平均的なアプリケーションに対して喜んでお金を支払うのではないかと私は信じています。 .もちろん、より高い基準を設けるマネージャー
開発プロセスの基本を学ぶ：ITpro
一口に開発プロセスと言っても，様々な種類がある。具体的に，それぞれの開発プロセスにはどのような違いがあるのか。また，どのような基準に基づいて開発プロセスを選択すればいいのか。ここでは，様々な開発プロセスについて解説する。 「反復型やスパイラル型といった言葉は聞いたことがあるが，それらの内容までは知らない」。読者の中には，こうしたエンジニアも少なくないのではないか。そこでここでは，様々な開発プロセスの歴史や特徴，選択の基準を説明しよう。 まずは「開発プロセス」の定義を明確にしておきたい。 英語の辞書を引くと，プロセスには「処理」と「工程」という2つの意味がある。一般に「処理」は単数形（Process），「工程」は複数形（Processes）で表す。 情報システムにおける「処理」とは，仕様やデータ，プログラムなどの「入力」に対してなんらかの作業を実施して，結果を「出力」することを言う。一方の「
マニュアル駆動開発を考えてみた - kosaruのはてな？
マニュアル駆動開発 １．目的 １−１．ユーザが理解可能な仕様書を作る。（not設計書） まず、仕様書とは何であるのか。設計書とは何であるのかを定義したいと思います。 仕様とは、製品が満たすべき、満たされるべき、満たすことが保証されている性能・機能。 あるいはお客様が望んでいる性能・機能。それを記述した物が仕様書。 設計とは、製品をどのような材料を、どのように加工したり組み合わせて製造するかを計画すること。それを記述した物が設計書。 システム開発における仕様書と設計書とは何でしょうか。システム開発における仕様書とは、このシステムで、なにを実現するのかが解る物。システム開発における設計書とは、このシステムを、どのように構築するかを理解できる物。そういう風に言えないだろうか。なので、ユーザに見える、理解できるようにすべきものとしては、仕様書になると思います。 しかしながら、現実として、仕様書を見
システム開発は20年縮退している，“むしり取る”型の人材育成が必要
システム統合のトラブルや，動かないシステムの事例が後を絶たない。システム開発のどこにどんな問題があるかを明確にし，改善することが急務になっている。事故や失敗から教訓を学び取る「失敗学」の提唱者である畑村洋太郎氏に，日本的なシステム開発の問題点や改善の方針などを聞いた。 失敗学のプロジェクトでは最近，システム開発の失敗に関しても研究されているようですね。 このところ，主に経営トップ層の方々から，システム開発の失敗をテーマに話を聞かせてくださいと言われる機会が増えています。それだけ不安感や危機感があるのだと思います。 システム開発では「流用設計」「付加設計」で失敗するケースが多いようです。例えば，みずほ銀行のシステム統合でのトラブルは，主に付加設計（既存のシステムに，付加的に要求された設計を加える）が原因でした。 そのほか，よく言われていることですが，関係者間でシステムについての概念を共有でき
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
プログラミングファースト開発のアキレス腱 : 404 Blog Not Found
2008年07月21日15:00 カテゴリArt プログラミングファースト開発のアキレス腱 ktkt. プログラミングファースト開発の必要性 - ひがやすを blog これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 実は私自身、この言葉が生まれる前から実践してきたのだけど、一つけったいな問題点があるので、それを指摘しておく。 それが何かというと、 客がそれを安易だと勘違いして、安価だと思いやすい こと。 プログラミングファーストの場合、最早だと打ち合わせのその場で動くものを見せたりする場合がある。客が分かっている人だと、その事にボーナスを出
『理論は暇人のためのものではないということ。』
職業柄、会社についていろいろ意見を頂くことがあります。ネット上で書いてある意見なども見たりします。中には感情的な意見もありますが、その感情に至るまでには何らかの理由があります。ですから、肯定的な意見も、批判的な意見も、製品開発やサービス開発においては非常に参考になります。でも、ひとつだけ、僕が絶対に許せないことがあります。僕は、自分の会社のメンバーが侮辱されることは、それがどんな理由であれ、許せません。 たまには感情的になったっていいじゃない。大人げなくたっていいじゃない。 IT企業が、理論を軽視していいものか。理論が好きな人間を暇人と侮辱していいものか。そもそも、ITの世界で、理論好きか理論が嫌いかという議論が意味があるのか。ITにおける理論は、僕はコンピュータサイエンスだと考えています。コンピュータサイエンスが好きとか嫌いとかの問題の前に、ITに携わる人がそもそもコンピュータサイエンス
“作り手責任”が問われる
メインフレーム技術者が足りない メインフレーム技術者が足りない――。2007年問題がついに顕在化し始めた。ベンダー各社は定年退職者の再雇用で対処する心づもりだったが、必要数を確保できていない。若手や派遣社員での穴埋めは難しく、このままでは顧客企業のシステム開発に支障がでかねない。 ベテラン再雇用のもくろみ外れる 個人のルール違反を撲滅 富士通はベテラン技術者を集めた品質検証専門の新会社を設立した。技術者一人ひとりのテスト手順に不備がないか、第三者の視点で確かめる。従来の品質管理手法では目が届かなかった、個人のルール違反に起因する不具合の撲滅が狙いだ。 富士通の品質検証会社が実装工程のバグ削減に挑戦 クレーム数で品質を測定 日本情報システム・ユーザー協会（JUAS）は非機能要件の記述と評価の手法を策定した。システムの性能や信頼性、保守運用のしやすさなどを195の指標で測る。品質測定にクレーム
ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ
実際に動的なウェブサイトを作ってしまう前に、紙上でデザインや部品の配置、画面遷移などを確認するペーパープロトタイピングという設計技法があります。書籍もありますね。 ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする そのペーパープロトタイピングの事例を集めたページというのがありました。たとえば次のこれは、2000年5月31日にスケッチされたtwitterのプロトタイプです。当時はstat.usという仮名で、これによるとtwitterはLiveJounal(ブログサービス)とAIM(インスタントメッセンジャー)から最初の着想を得てから実装まで5年以上の間があったことになりますね。 FlickrのPlacesページやVimeoなどのペーパープロトタイプの写真も紹介されています。 こちらは韓国のポータルサイトDaumのAjaxウェブメール開発時に行なわれた、ペーパープロト
株式会社マジカジャパンの羽生章洋が書いてるブログ:ルーティンワークはインフラである - livedoor Blog（ブログ）
ルーティンワークを嫌う人は多いです。クリエイティブでありたいと語る人にその傾向が強いように感じられます。 では、ある単純な作業があるとして、それは比較的頻繁にやらないといけないとします。ルーティンワークが嫌いだからといってこれを毎回創造的に考えながらやるのと、ルーティンワークに落とし込んでしまってさっさと終わらせてしまうのとでは、どちらが自分の本来的価値を創出できる可能性が高いでしょうか。恐らくルーティン化されている後者ではないかと考えます。 ルーティンワークがしっかりしているというのは、実はインフラがしっかりとしているということであり、それは実は大きな資産であると言えるのです。 それが如実にわかるのは、大企業出身の人が起業したらどうでもいいようなはずの瑣末な事務に追いまくられて、本来の持ち味を発揮できないというようなケースです。これを解決しようとすると、人を雇うのが一般的でしょう。つまり
第2章 ベンチャー開発編 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第3章 テスト志向開発編 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第1章 受託開発編 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
Appendix エンジニアよオープンになろう | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
グーグル エンジニアのまじめな日常 ― ＠IT
グーグルがどのようにソフトウェア開発を行っているかは、これまであまり詳細が明らかにされてこなかった。だがグーグルは6月10日、開発者向けイベント「Google Developer Day 2008 Japan」を開催し、グーグルのソフトウェアエンジニアがグーグルでの仕事術を語る「Google ソフトウェアエンジニアの日常」という講演会を実施した。スピーカーは、NECでITエンジニアとして勤務した経験がある藤島勇造氏。2006年からグーグルのソフトウェアエンジニアとして働いている。藤島氏は、グーグルでのソフトウェア開発方法について、グーグルのカルチャーと自身の見解を織り交ぜて語った。 グーグル ソフトウェアエンジニアの1日の流れ 藤島氏の1日は、朝10時ごろ出社し、メールをチェックすることから始まる。この時間にメールを見る理由は、米国にいる同僚に連絡が付きやすい時間帯だからだ。 午前中の主な
株式会社マジカジャパンの羽生章洋が書いてるブログ:閉塞感を越えて - livedoor Blog（ブログ）
日本のIT業界には閉塞感が漂っているように見えます。行き詰まりを感じているように思えるのです。ただ、最近になって業界界隈から距離を取るようになって、どうしてそうなってしまっているのかということが、おぼろげながら見えてきました。 ギョイゾー！というサービスをリリースしてから、非常に多くの方々とお会いするようになりました。大抵は情報システム部門さんがない企業さんだったりするので、これまで私どもがお付き合いしてきたような、いわゆる業界を理解してくださっている方々とは違います。そういう方々とのお話をするにつれて、業界全体の問題が浮かび上がってきたように感じるのです。 一言で言えば、説明不足ということになるのでしょう。きちんとしたソフトウェアを作りさえすればよいという空気が間違いなく存在しています。そもそもその基本となる部分で昨今では空洞化などといわれたりするのですが、それを脇に置くとしても自分たち
Ivar Jacobson、Process ではない、Practice が大切だ。：An Agile Way：オルタナティブ・ブログ
RSDC のレポート。 Rational の雄、Ivar Jacobson のセミナーです。彼はもちろん、UseCaseの発明者であり、UMLの定義に参加した１人として有名です。彼は今、Process を捨て、Practiceベースのソフトウェア開発の定義に取り組んでいるようです。 Enough Process, Let's Do Practices! 彼は、過去、３回プロセスの定義に関わっていますが（Objectory, RUP）、もうやらない、と宣言。それは、人々がプロセスが嫌いだから。今、ソフトウェア開発で重要なのはモチベーションであり、「やりたくない」ことを現場に持ち込むのは罪だから。プロセスではなく、プラクティス（実践項目）をチョイスして、プロセスを組み立てる方向です。UMLの意味論で言うと、プロセスを「クラス」、プラクティスを「クラスの要素」という関係でなく、プロセスを「パッケ
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システム開発現場の活気を取戻そう（中）ウォーターフォールからの脱却 ビジネス-次世代ＩＴ産業論考（浜口友一）:IT-PLUS
