わたしのバイモーダル戦略 : 小野和俊のブログ
このところ知人からよく、「小野さんはプログラマーから経営者になった」と言われる。これはまさにその通りで、かつてソースコードを美しくリファクタリングすることに情熱を燃やした私は、いまは組織をより良いものにしていくことに情熱を燃やしている。つまりリファクタリング対象がソースコードから会社に変わったのだ。 そんな私が今やや苦戦しつつもやりがいを感じて取り組んでいるのが、「2つの異なる文化の共存協調」だ。具体的には、大企業的な文化とベンチャー的な文化を共存させ、かつ協調させようにしようとしている。ウォーターフォール的な文化とアジャイル的な文化の共存協調、と言い換えることもできるだろう。 アプレッソでかなり自由にやってきた私にとって、当初、セゾン情報の動き方は不慣れであり、また動きが遅く感じることもあった。だが少しすると、こうした動き方や文化にも相応の合理性があり、アプレッソで取り入れることが望まし
一括請負という契約形態のままアジャイル化するのは危ない - すこしふしぎ
何年か前に、顧客（と元請けの営業）だけがアジャイルに盛り上がった結果盛大に火を噴いて関係者が闇に消えた開発に関わったことがある。立場上そのままは書けないし、適宜フェイクも混ぜていくが、バッドノウハウの一例として紹介するとともに、ウォーターフォールからの脱却という意味でのアジャイルについて書いておきたい。 前提 契約はSI型一括請負、全外注。且つ、アジャイル。 闇アジャイル化の経緯 営業がアジャイルを売り込みたかったという背景があり、「だいたいこれぐらい」で契約が成立（仕様がないのに見積もりだけはあった） その時点で、元請け企業の偉い人たちがこの案件を切り捨てた（応援要請も突っぱねるよう根回しがあった）（まあしかし偉い人はさすがである、経営的な観点では正しい） 全外注は予想されうる責任回避のための手段として決定された（選択権もなかった） 顧客は仕様を決めなくてもなんとかなるのがアジャイルだと
アジャイル開発を円滑に行うための契約モデルを考える--アジャイル開発を実案件に生かすための基礎知識（3）
柏木雅之、山下博之 （IPA SEC エンタプライズ系プロジェクト） 2011-06-08 12:00 これまで2回にわたり、アジャイル開発の概要や特長について、主にウォーターフォール型開発と比較しながら解説してきました（「第1回：アジャイル開発って何がいいの？」「第2回：アジャイル開発はなぜ難しい？」）。「変化への対応を重要視する」「顧客が開発に密接に関与する」など、ウォーターフォール型開発では見られなかった、さまざまな新しい特徴を有していることをご理解いただけたでしょうか。 ウォーターフォール型開発と開発スタイルが大幅に異なるのですから、顧客と開発側で締結する契約のあり方もこれまでとは違ってきます。最終回となる今回は、アジャイル開発をスムーズに導入し、プロジェクトを成功裏に終わらせるための契約モデルのあり方について考えていきたいと思います。 開発者の方は、「契約なんて自分には関係ない」
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
アジャイルで人はどう育てるんだろうか - novtanの日常
最近ちょっとアジャイル（風）PJTに首を突っ込んでいるんだけど、やっていて思うのはエンジニアとしてある程度のラインを超えていないとお話にならないよねってあたり。で、このある程度のラインを超えていない人たちがそこをクリアするためには育たなくてはならないんだけど、お話にならないアジャイル開発の現場で育てることは可能なのだろうか。みんなそこをどうクリアしているんだろうか、というあたりがすごく気になる。 僕自身はそういう点について経験がなさすぎて、無償で貼り付けるんだよとかそういうのも込みで値段設定しているんだよとか育った人間しか使わないんだよとか甘えんな勝手に育てなのか何が正解なのか全然わからないんだけど、アジャイルのプロからすれば自明の問題に過ぎないと思うので知ってたら教えてほしいんだよな。 ウォーターフォールって一度始まっちゃえばよっぽどのことがない限りエンジニアが一定割合ポンコツでもある程
契約もしていないし働いてもいませんが、お金は払ってください。売り上げ期待していたんですから
契約もしていないし働いてもいませんが、お金は払ってください。売り上げ期待していたんですから：「訴えてやる！」の前に読む IT訴訟 徹底解説（28）（4/4 ページ） 関連記事 納期が遅れているので契約解除します。既払い金も返してください 東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は頓挫した開発プロジェクトの既払い金をめぐる裁判例を解説する 2年超も仕様が確定しないのは、ベンダーの責任か？ システム設計書を提出しても、プロトタイプを作成しても、どうしても仕様を確定させてくれないユーザー。この契約、解除しても大丈夫？ IT訴訟弁護士「塔子」参上！ ITシステム開発で最も大切な「要件定義」。だが1度合意したはずの要件に、開発中に追加や変更を繰り返し行われてプロジェクトが混乱する例が後を絶たない。こんなときはどうすればよいのか
ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 弊社に５年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日本の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します（転載について本人同意済み。弊
NTP Security Project、「NTPsec」ベータ版をリリース
ネットワークタイムプロトコル（NTP）がなければ、インターネットは機能しない。しかしNTPは同時に、一部の分散型サービス妨害攻撃（DDoS）の原因にもなっていた。これに対する対策が、NTP Security Projectが今回初めてリリースしたNTPsecだ。 NTPは世界のインターネットを支える、目立たないが必要不可欠なパーツの1つだ。これによって、世界中のサーバとPCの時計が同期されている。 しかし残念ながら、インターネットのほかの基礎的なパーツと同じく、NTPの開発も、長年の間ほとんど無視されてきた。最近まで、NTPの開発とメンテナンスには、ほとんど予算が投じられておらず、NTPは完全にパートタイムの開発者1人に依存していた状態だった。 幸い、Core Infrastructure Initiative（CII）がこの問題に踏み込み、NTPとその後継プロトコルであるNTPSecの両
ITは必要悪か？を読んで | F's Garage
第一部は、ビシバシ、インスピレーションを刺激された。第二部は少し専門的すぎてわからなかった。 ITは必要悪か？その1 – 急がば回れ、選ぶなら近道 内容について何かを言えるとか言いたいとかないのだけど、読んでいてツマミグイ的に書かせてもらうと、 「ITは、IT + ITで繋がってナンボ」 だなって思った。 手前味噌であるが、クレカ決済システムに繋がるためのWebサービスとしてのPAY.JPとかなら、そもそもITシステムと連携するITシステムとして作らなきゃ参加ができないし、提供しているものはAPIなので、その先もITシステムだ。 IT x ITという構造で自動化可能なビジネスが育っていくのであればITシステムを作るのにはものすごく意味がある。 入り口でお金を払ってる存在が人で、買ったモノを届ける人が人間だったとしても。 自動化vs人力 価格.comの掲載リストの常連店は、価格.comの価格
ITは必要悪か？その1 - 急がば回れ、選ぶなら近道
もともとは2016年の年の初めに書こうかと思っていたことですが、時間も経ってしまっていたところ、アリエルの井上さんとの対談 IT屋はバズワードを使ってはいけない……のか？ (1/5)：EnterpriseZine（エンタープライズジン） も あって、ちょうどいいので記録的に思うところを書いておきます。 ・前提 ここではITと言う漠然とした言い方になっていますが、日本で最もマーケットの大きい、いわゆる業務システムを対象にしています。いわゆるSIの対象になるところです。と言っても一概に言えないので、売上2000億円程度の大規模企業の、下の方から、中小企業までの話にしています。売上が兆円単位の規模の社会インフラ系のシステムは、その2 ITは必要悪か？その2 - 急がば回れ、選ぶなら近道 で考えます。業務システムなのでコンシューマーものは考えてません。 ・ITは必要悪という認識 基本的にユーザ企
SIerのITインフラ技術について、若手社員に伝えたいこと
社内の若者がAWSやAzureをやりたくて仕方が無いみたいなのだが、 30も過ぎた中堅の年齢で率直に思ったことは、「どこまでを考えているのだろうか」ということだ。 そんなことを直接言うのは生き急ぎ野郎の火に油なので、伝えたかったことを含めて増田に書き殴るとする。 以下その若者というか、5〜6年前の自分のような奴に伝えたいこと。 新技術であるべき理由の説明が必要だパブリッククラウドを使う際にはざっと思い付く限りでこれだけ説明することがあると思うんだ。その過程で旧技術や現状の業務を詳しく知る必要がある。 セキュリティ対策は具体的にどうするんですか？オンプレから大きく実装が変わるNWは具体的にどうするんですか？弊社でオンプレが前提要件な案件の比率を鑑みて、採用したらどのように利益に還元されるんですか？既存業務でスケールアウトが前提の精度の設計が許される案件の比率は？課金の試算の精度は保てますか？
NHK紅白に"弾幕"流した男 小林幸子"ラスボス"舞台裏 (1/4)
小林幸子さんが、インターネットとともに紅白に戻ってきた。 昨年の第66回NHK紅白歌合戦、ニコニコで“ラスボス”と慕われる小林幸子さんの紅白特別企画出演。黒うさPのボカロ曲「千本桜」を歌いはじめてしばらくすると、巨大なステージ衣装にニコニコのコメントが流れはじめた。 ツイッターのタイムラインにも、「弾幕」「コメント」といった字面が躍った。歌が終わりに近づいたとき、テレビ画面全体がコメントで覆われると「おおおおおおおお」「すげえ」「まじかよ」とツイッターは一層の盛りあがりを見せた。 じつに4年ぶりの紅白出場だ。ネットにも活躍の場を広げ、若者たちとともに歩んできた小林幸子さんにとって、その結実ともいえる舞台となった。 失敗の許されない生放送、ラスボスを支えたのはドワンゴの技術部隊だ。 ニコニコ生放送のコメントをリアルタイムで紅白歌合戦に流す。一世一代のプロジェクトに挑んだマルチデバイス開発部
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
日本のIT業界に対するニュージーランド人エンジニアの反応｜NZ MoyaSystem
何度もブログで書いている通り、筆者がニュージーランドでの就職を目指している理由の一つは、以前勤めていたIT企業の文化にほとほと愛想が尽きたからです。 筆者は5年半、某メーカー系SIerでSEをしていました。まぁ大変な環境の中がんばってがんばって、ポッキリ折れちゃったんですね。 その時代の話をニュージーランドのIT業界の人にもお話することが時々ありまして、その反応がなかなか興味深いんです。今日はそんなエピソードを2つほど紹介したいと思います。 社内にシニアプログラマがいない？ 筆者が以前務めていたSIerでは、一般の例にもれず、プログラミングは協力会社さんに発注するのが一般的でした。社員がプログラミングをするのは入社後1〜2年だけで、その後は業務分析やマネジメント業務に従事することになります。ということで社内にはプログラマとしてのキャリアパスが無いに等しかったんですね。 という話を、某企業の
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ
技術推進室の浅井です。 技術的負い目とは、世に言う技術的負債のことです。 社内で技術的負債の定義、ことばの表現を考える中で、「『負債』は優れた比喩表現であるものの、第三者への返済義務がない点で会計上の負債とは異なり、言葉としての問題も多く、不必要な議論を生み出しやすい」などの指摘があり、代わりの表現として社内の一部で使われている言い回しです。 最近社内のたいへん古いシステム（16年の歴史があります）の技術推進を行う機会があり、たくさんの技術的負い目と向き合いました。 そのような古いシステムの技術的負い目と向き合ったとき、エンジニアはストレスを感じ、ネガティブな感情を抱いてしまいがちです。負い目に苦しめられることで過去のコードや技術的判断に対して不満を言いたくなる気持ちはとてもよくわかりますし、実際に私もたくさん苦しんでたくさん不満を言いました。 ですが技術的負債の文脈でよく言われるとおり、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルにおけるドキュメント：いつどれくらい書くべきか
長文日記
システム開発をラーメンの注文に見立てたツイートが話題に！「納得」「うちの業界でも…」と悲痛な声が…
「コードを書かなくなったら一人前」、そんな業界構造を変えたい
