鳴り物入りで導入されるもすぐに大規模な不正アクセスが発生、セブンイレブンという企業自体のITリテラシーを疑われる事態にまで発展してしまった、セブンペイ問題。なぜこんなことになってしまったのでしょうか。世界的エンジニアでアメリカ在住の中島聡さんは今回、自身のメルマガ『週刊 Life is beautiful』で、いびつで時代遅れな開発体制を持つ日本ITゼネコンと、そんな組織にセブンイレブンが開発を委託したところに根本の原因があると指摘しています。 ※ 本記事は有料メルマガ『週刊 Life is beautiful』2019年7月16日号の一部抜粋です。ご興味をお持ちの方はぜひこの機会に初月無料のお試し購読をどうぞ。 プロフィール：中島聡（なかじま・さとし） ブロガー／起業家／ソフトウェア・エンジニア、工学修士（早稲田大学）／MBA（ワシントン大学）。NTT通信研究所／マイクロソフト日本法人／
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
マイクロソフト、Mac版Microsoft OfficeのソースコードをWindows版のソースコードと一本化実現 20年以上の歴史ではじめて、Microsoft OfficeのWindows版のソースコードとMac版のソースコード、iOS版、Android版のソースコードが一本化されたと、マイクロソフトのプリンシパルソフトウェアエンジニアであるErik Schwiebert氏がツイートで報告しました。 Mac Office 2016 version 16 is now live! For the first time in over 20 years, Office is again built out of one codebase for all platforms (Windows, Mac, iOS, Android)!https://t.co/6gNdKTOEHl — Erik
どこの会社でも「1行直すだけでしょ？ そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
似ているところ どちらも「やっちまったー！」な状態で「前の方が良かったー！」な状態です。 違うところ 同じと解釈する人もいますが、若干ニュアンスが違います。 エンバグは単純に「バグを入れちゃったー！」です。 作っているプログラムや変更しているプログラムにバグを入れちゃったらエンバグです。 解釈にもよりますが、個人的には新規作成中のプログラム（まだ未完成のもの）にバグを入れちゃうのもエンバグであると解釈しています。 ですから、エンバグは後戻りとは限りません。 状況が前に進みつつも、残念な方向に向かうことがあります。 一方のデグレは「前の方が良かったー！」です。 既に出来上がっているプログラムに対する「バグを入れちゃったー！」（エンバグ）もデグレの一種ですが、それ以外にも、以前は有った機能がなくなっちゃったとかの「バグではないけど、やっちまったー！」な状態も含みます。 また、デグレは後戻りです
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
どう作ればいいか分からないとき，同僚に相談したりするけど，それでもいい方法がなければ，我々のスキルがしょぼすぎて，しょぼすぎるスキルではそういうものしか作れないのだからあきらめて作ろう，ということになる． それはそれでよくて，どんなに実装がしょぼくても，テストは合ってるはずなので，将来的にいい方法が見つかったときに，テストはそのままに実装だけ美しく書き直すことができる． そんな都合よく行くのか，という話だけど，意外とうまくいっていて，ここいけてないなーと思ってたところは半年もすればどう書けばよかったのか分かってきて，初めからそこにあったかのような美しいモデリングができる． 本番環境でプロトタイピングしてるようなものだけど，半年間プロトタイピングを重ねてついにリリースよりは，なんか動くものを今日リリースできるほうがいいし，最初にしょぼいコードを書いているのは，さぼってるわけではなく，技術力が
どこがいけてないのか？ クラス名とか、機能名とか、概念とか、名前があると考えやすくなる まだ名前なかったら新たな抽象が見つかるかもしれない どんな経緯でそうなっているのか 最初は抽象を捕らえられていたのが拡張を繰り返すうちに失われたのか、書かれた当初は単純な仕様だったのが膨れ上がったのか、動けば良いという感じで書かれたのか 今の設計のいいところは？ 何か意図や事情があってそうなってるのか、動いてるだけなのか 詳しい人や書いた人に気に入ってるところを聞いても良い みんなどう思ってる？ みんなおかしいと思ってるけど手が出せないのか、これでいいと思ってるのか、など雑談して聞いて回る 最高の状態ならどうなってるべき？ 正しいモデリングや、すごい技術があったら、どうなるか 鋭い分析によって豊かなドメインを得られたり、リコメンドシステムなら脳波を読み取って直接推薦してくれたり、変なドアで世界中好きな場
最近、業務と趣味の副産物で、一日に1~2個のnpmモジュールを作っている。基本的にGithubで公開している。 node界でそういうことをしているのは主に substack (James Halliday) 氏だ。 趣味と仕事の横断 自分は基本的に、仕事で使うテクノロジーと趣味で使うテクノロジーを合わせていることが多い。会社ではツールを作っていても家では同じテクノロジースタックでゲーム作ってたりする。 最近だと mizchi-sandbox/ar2 がそれに該当する 会社のコード、自分はあんまり家に帰ってまで触りたいという気持ちがあんまりないんだけど、どうせ家でもコード書いてて、業務中のコードを切り出してOSS化してあると家で触るモチベーションになって便利。 趣味でノウハウが溜めて、業務にフィードバックするというループに載せることで、26歳としてもそこまで高くない社会人としての自覚をコーデ
バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 2012-02-24 13:21:23 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ 2012-02-24 13:46:29 バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかっ
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える 1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？ 将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほ
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く