ソフトウェア工学は失敗している - きしだのHatena
特に学術的にソフトウェア工学に触れたことはないのですが、むしろそうではなく現場にいる身としては、ソフトウェア工学は失敗しているように見えます。 「成功していない」ように見えるのではなく「失敗している」ように見えるのです。 もちろん、いまソフトウェア開発で使う技法やツールなど、ソフトウェア工学の産物はたくさんあり、現在のソフトウェア開発がソフトウェア工学から生まれたもので支えられていることには間違いありません。 でも、そうやって築き上げてきたものが、1999年以降ガラガラと崩れて、そしてうまく再構築できていないように見えます。 1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。 ここからソフトウェア工学がガラガラ崩れた気がしています。 では、ここまでソフトウェア工学がど
新技術導入の遅さの一端はラーニングモデルの違いかもしれない - メソッド屋のブログ
以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書くテクニック - $shibayu36->blog;
blog.shibayu36.org 上の記事が思ったより読まれていたので、自分がこの基準を満たせるようにやっているテクニックも箇条書きで書いておく。 PullRequestを作ったら必ず自分でコードレビューをする コードを書いているとき、その一部一部はこれで完璧と思ってるけど、実は全体を見直すと分かりにくかったりする 1日寝てから見直す 1日経つとちょっと忘れて新鮮な気持ちで見れる 1週間後にもう一回見てみる 1週間くらい経つともうだいぶ忘れて、穴が見えてくる 穴があったら別PullRequestで直す もう一度同じところを担当することがあればチャンス。自分でもこれどういうことだっけってググり始めたら基準を満たせていない 自分が全く関わっていない部分のところを触りだしたらかなりチャンス。本当にまっさらな頭で基準を満たすか見れる。他人がやったことだからとか思わずにちゃんとその時に直す やっ
分散プログラミングモデルおよびデザインパターンの考察 その5 - Software Transactional Memo
これまでプログラミングモデルのプの字もなかったので申し訳程度にプログラミングモデルの話をする。 分散して特定のアプリを動かしたいだけなら、例えばbitcoinをマイニングするASICクラスタに対して特定のプログラミングモデルは必要とされない。そのように、行いたいタスク抜きにプログラミングモデルを語る事はできない。 HPC（ハイパフォーマンスコンピューティング）系のワークロードは古くからMPIがデファクトとなっている。 MPIでのプログラミング MPIというのは「Message Passing Interface」の略でSmalltalkなどの文脈で語るいわゆるメッセージパッシングとは哲学というかレイヤーが違う。こいつは 配列を引数に取る関数の形で1:1, 1:N, N:Nの通信の典型的なパターン(1:Nなら例えば `MPI_Broadcast` とか)をインタフェースとして定義しており、ユ
デモやプレゼンをするときに使っているツール - ikeike443のブログ
僕はいまソリューションエンジニアというロールで、お客さん先で GitHub や DevOps(バズワード)的なツールのデモをやったり、セミナーやカンファレンスでトークすることが多いのですが、デモやプレゼンをするのに自分が使っているツールをまとめておくと誰かがもっといいものを教えてくれるかもしれないと思い、ここに書いておくことにしました。 別のアカウントを作る まず最初にやってるのがこれで、Mac上に、普段使いとは別のデモ用アカウントというのを作っています。デモやプレゼン中にFacebookのメッセージが飛んできたり、Slack上のふざけた投稿とかが出てきて場を凍らせないようにするためですw 共有したいファイル（VMのイメージとか、プレゼン資料とか）は /Users/Shared/ 以下に置いています。ものによっては Dropbox を使って共有しているものもあるけど。Dropbox を使う
アメリカの大学で受けたソフトウェア工学の授業が実践的ですごかった話 - stefafafan の fa は3つです
私はアメリカの大学で「インタラクティブメディアとゲーム開発」を専攻しましたが、その時受けたSoftware Engineeringという授業が色んな意味で素晴らしかったのでその授業がどう素晴らしかったのかを紹介していきます。 リアリティーがすごい まずこの授業、生徒数が80人ほどいます。ここから教授がみんなを約15人ずつの5つの会社に分けていきます。そうです、我々生徒は実は会社員なのです。 そして初日に出された課題は「自分たちの会社のミッションステートメントを考えてくること」です。 それだけでなく、プロジェクトマネージャー・プロセスエンジニア・リリースエンジニア・ドキュメンテーションマネージャー・クオリティーマネージャーの役割を会社のどの社員が取るのかを決めてこないといけないというのです。私たちは言われるがままにミッションステートメントを用意し、次の授業に備えました。 プロセスがすごい S
それは実験 ― 形骸化した「アジャイル」を再考する新手法”GROWS”について | POSTD
(この記事は 「アジャイルの破綻―原因、そして新たな提案」の続編にあたる記事です。) 前回のブログで、私はアジャイルの変動について、「調査と順応の概念は一体どこへいってしまったのか」、「近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しよう、という考えはどうなってしまったのだろう」、と問いかけました。 VersionONEによるアジャイル開発の2014年アンケートによると、アンケートに答えた56％のチームがスクラム、10%ほどがスクラムとXPの併用、8%がアジャイル手法の混合（XP, かんばん, リーンなど）を使っていることがわかりました。私からすると、アンケートに答えた18%はだいたい正しいことをしているように見えます。他は、もしかしたら、いつもしている単なる朝礼をアジャイルと呼んでいるかもしれません。 それは少し言い過ぎたかもしれませんが、同アンケートの別の
ここ一年の振り返り - Usual Software Engineer
先月、僕が開発のマネージャーを努めていたサービスがクローズになりました。 こんなに無力さを感じたことがあったでしょうか。 ただ、得られたことや感じたことは大きいので 最後の振り返りとして書き留めようと思います。 立ち上げ 思い切った新規開発でリリースまで辿り着けずにプロトタイプの段階で打ち止めになったプロジェクトから 一転して既存のリソースを流用して内製の開発チームをつくることになり 初めて採用の面接官側をやりました。 採用面接と一口に言っても、考慮しなければいけないことは多方面に渡っていて 結局はバランスをとって何を重視するか判断して決めることになりますが 非常に重要であり難しい問題です。良さそうと感じた人がうまくハマらなかったり、 おとなしそうだなと思っていた人がバリバリ仕事できたり。 ただ、少なくとも現場の人間と面接するのは必須だなと。 社風に合うかも大事なんだろうけれど、所属する予
旧・Macの手書き説明書 - FC2 BLOG パスワード認証
ブログ パスワード認証 閲覧するには管理人が設定した パスワードの入力が必要です。 管理人からのメッセージ https://mac-tegaki.comへ移転中 閲覧パスワード Copyright © since 1999 FC2 inc. All Rights Reserved.
「継続的デリバリー」から考えるソフトウェア開発の入り口、出口問題 - Test Automation
「継続的デリバリー」(*1)の章の構成はとても興味深い。第一章では「The problem of deriverling software」というタイトルで、ソフトウェア開発の目的を顧客に価値をデリバリーする事とし、その上でリリースにまつわるアンチパターン３つの紹介から始まる。 * Deploying software manually * Deploying to a Production-like Environment Only after Development Is Complete * Manual Configuration Management of Production Environments これは「継続的デリバリー」というタイトルから考えるに妥当に感じるかもしれないが、一度考えてみて欲しい。 何故リリースにまつわるアンチパターンの紹介から始まるのか？ それはソフトウ
「ドメイン・エキスパート」になろう - 設計者の発言
２０年も昔の話だが、「英語できます」という本を読んで考え込まされたことがある。どんな仕事で稼ぐにせよ、何らかの専門性が要る。英語力というものは、そんな「専門性の効用」を引き上げるためのツール以上のものではない。むしろ中途半端に英語力があったばかりに専門性を深める努力を怠って、英語力を社会で生かせていない。そんな事例がいくつも紹介されていた。 この話、ソフト開発の技能に関してもいえるのではないだろうか。技術が進歩すればするほど開発の技能はコモディティ化し、これを習得しているだけでは大した意味はなくなる。ソフト開発の技能を社会で生かすためには、互いの効用をレバレッジするような何らかの「専門性」が要る。 これは、開発者自身がまず何らかの「ドメイン・エキスパート」であるべしという話に他ならない。ドメイン・エキスパートとは、DDD（ドメイン駆動設計）で言うところの、開発されるソフトウエアの適用分野（
iPhoneの理想的なGmailアプリとしてのOutlook
iPhone が登場したばかりの時と違って、いまではさまざまなメールアプリがひしめいています。Mailbox、Inboxしかり、そしてGoogle自身が提供しているGmailアプリに、その進化版のInbox。 そしてここに、Microsoftからいささか遅すぎるのではないかというタイミングで登場したのがiOS / Android版のOutlookです。 Outlookというと、ずいぶんと前には使いにくいことの代名詞になっていた時代もあって、名前を聞くだけで拒否反応を示す人もいるかもしれませんが、このスマートフォン用のアプリは一味違います。 Exchange, Outlook.com, iCloud, Yahoo! そしてGmailの全てに対応していて、しかもこれまでのメールアプリの良い部分とOutlookらしいソリューションの両方を提供しています。特にカレンダーへの入力が多い人にとっては、
ソフトウェアエンジニアのコンピテンシとか倫理とか - 勘と経験と読経
自戒を込めて。割とこだわっているソフトウェアエンジニアのコンピテンシと倫理について。「IPA/SEC Journal に寄稿: ソフトウェア品質プロフェッショナルに求められる専門性と倫理性: 知識、スキル、コンピテンシ、倫理綱領 | Reliable Software Engineering, Washizaki Laboratory」という記事が興味深かったのでその感想など。 IPA/SEC Journal に寄稿: ソフトウェア品質プロフェッショナルに求められる専門性と倫理性: 知識、スキル、コンピテンシ、倫理綱領 | Reliable Software Engineering, Washizaki Laboratory photo by Dunechaser コンピテンシなどについての様々な枠組み 上記で公開されている寄稿は「スキル、知識、コンピテンシ、倫理要領」に関するものなのだけ
Serverspec本を読んで、先鋭化されつつあるWeb系インフラエンジニアを知る - Glide Note
Serverspec Serverspecを執筆されたmizzyさんからご恵贈頂きました。ありがとうございます。 本書の詳細な紹介はあんちぽさんのブログと、mizzyさんが出演したRebuildがオススメです。 Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - delirious thoughts Rebuild: 75: Book Driven Development (gosukenator) 事前に断っておくと私がここで記載している「インフラエンジニア」はITインフラエンジニアの話です。 以前サーバ/インフラ徹底攻略を本ブログで紹介したあとに、 書内のある特集を執筆担当された方と話していて、 Web系インフラエンジニアがどんどん先鋭化されつつあって、この本の内容を理解出来る人ってどれくらいいるんだろうね という事を仰っていたのが非常に印
状況に埋め込まれた学習 - 未来のいつか/hyoshiokの日記
われわれは学習というのを学校制度の中のかぎられた活動という風にとらえがちである。もちろんそんなことはない。わたしたちは日々の生活のなかで、あるいは仕事の中でなにがしかを常に学んでいる。学び続けている。 単に形式化され言語化された知識を獲得することが学習なのではない。 徒弟制度のような非熟練者が熟練者のもとで作業に参加することによって技術を習得していく方法について焦点を本書はあてている。 ソフトウェア開発コミュニティへの参加ということが、オープンソースの発展によって、より開かれた形になり、一つの企業に属さなくても自由にできるようになった。ごく限られた範囲でしか見聞き出来なかったソフトウェア開発のベストプラクティスがオープンソースコミュニティによってインターネットを介して自由に流通している。 その事例を間近で見聞きするにつれ状況に埋め込まれた学習の有効性を確認することができる。 本書の訳者あと
開発スピードが遅い？速い？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
ソフトウェア開発グループあるいはソフトウェア開発組織の開発スピードが遅いとか速いとはか、何を基準に判断するのでしょうか。 人が単純な作業を行わずに、自動化できる部分を徹底的に自動化した場合、残っている部分が本当の意味では、その組織での開発スピードです。 たとえば、システム全体のビルド作業を手作業で週に一回行っており、開発メンバーは、単体テストも書かずに、高残業をしながら一週間に多くの機能を実装したと報告する開発を考えてみます。もちろん、他のモジュールとのビルドもしていないし、ビルドするのは翌週の月曜日ということになります。これは、80/90年代によく行われた開発スタイルです。 一方で、Jenkinsを使用しながら継続的インテグレーションを行い、自動実行される単体テスト・システムテストを作成しながら、システム全体の機能のデグレードや副作用が起きていないかを常に検証しながら、開発メンバーがあま
アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent - うさぎ組
はじめに これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。 id:a-suenamiがテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。（言いすぎだ 概要 言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを
ソフトウェア開発におけるリスクと居心地の悪さについて - 表道具
アウトライン ソフトウェア開発には，時間の見積も，できるかどうかすらもわからない，リスクのあるタスクがある リスクのあるタスクには，逃げたり既存の工数などに載せないで，特別扱いしてちゃんと負担を減らしながらリラックスして取り組む環境を作るべき はじめに 何で自分がソフトウェア開発という分野に居心地の悪さを感じるのか考えていた．納期の短さが原因だけではないことは明らかである．やればできるし，ただそれだけだからである．それよりも，常につきまとう漠然とした不安が物事を見えにくくしている． 特にインタラクティブ・システムや拡張現実感技術，コンピュータビジョン，機械学習などの分野は，まだ単にライブラリを持ってきただけ機械的にシステムを構成できる分野ではない．そうでなくても，ある程度大規模で複合的なシステムなら，バグ1つの解消にえらく時間がかかったりする． このように，ある機能を実装したり，バグを取っ
書類仕事を追いかけて - steps to phantasien
大きなコードベースの真ん中あたりをさわっていると、仕事の大半はリファクタリングに費やされる。機能を足そうと書くコードも 8 割リファクタリングで新緑は 2 割。失敗して捨てるものも多いから、かける時間は 9 対 1 くらいかもしれない。 それどころかリファクタリング自体がプロジェクトにもなりうる。「今四半期はこの腐ったコードどもをなんとかするのが目標」というように。私もいま大きなリファクタリング、あるいはリアーキテクティング、の手伝いをしている。仕事時間のほぼすべてがリファクタリングに費やされる。今の勤務先で通用する唯一の特技がリファクタリングな私にとってこれはたぶん適職だ。 リファクタリングにコーディングの大半を捧げる人は他にもいる。 プログラマ相手の管理職をエンジニアリング・マネージャと呼ぶ。ほぼ全員プログラマ出身。現場に近いマネージャは多くがコードも書く。ただ血気盛んな人を除くと新機
テスト戦略のたった3つのチェックリスト - うさぎ組
本稿はSoftware Testing ManiaX vol.9に寄稿したものになります。ご興味ある方はJaSST、WACATE、コミックマーケットに参加して買ってみてください。 さーくるWACATE ちなみにkyon_mmの心情的にはだいぶ押さえて書いています。本音を言えば「なんですかそのテスト計画？昼寝しながらでももっといいの書けますよ」「訓練をしないで戦地に向かうことに恐怖を覚えないなら、いますぐこのマサカリを首にかけてやる」って気持ちを必死におさえて書きました。偉いです。自分をほめたいです。 そういう雰囲気で書いているのであまり整理されていない内容ですが、皆様の何かのご参考になればと思います。突っ込み歓迎ですが、こういった文章ですのでface2faceだとコンテキスト共有しやすいと思われます！ はじめに ソフトウェアを開発していくなかで、品質を考えるということは非常に重要なことです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
