業務ハッカーはなぜ必要？ 沢渡あまね氏とソニックガーデンが語り合う (1/4)
ITを使って業務の課題を鮮やかに解決する「業務ハッカー」。まだまだなじみのない概念だが、働き方改革と生産性の向上を両立させる切り札として注目を集めている。いま、なぜ業務ハッカーが必要なのか？ 「職場の問題地図」など数々の書籍や講演で実効力のある業務改善を提案し続けている沢渡あまね氏が、業務ハッカーの総本山でもあるソニックガーデンに切り込んだ。（モデレーター アスキー編集部 大谷イビサ 以下、敬称略） 日本ではカイゼンマインドを持った人が評価されてこなかった 大谷：まずは「業務ハッカー」に行き着いた経緯、ソニックガーデンの方々と話してみようと思った経緯を教えてください。 沢渡：はい。働き方改革や生産性の向上という文脈で、業務改善しなければならない会社は増えています。とはいえ、業務自体を設計できなかったり、今までのやり方や成功体験から脱却できない抵抗勢力から反対を受けているという現場も多いと聞
私が清水吉男さんに教わった色々｜たかぼー
※※※ ブログ引っ越しました ※※※ 発注先の能力は、発注元の能力を超えられない 私がコンサルタント清水吉男さんに教わった色々な言葉 #1 medium.com
【後編】CTO不在で、開発組織改善に着手！ 一休のエンジニアが語る苦悩の1年
＜前編のあらすじと後編のお話＞ 春風が吹く中、本企画のホストである伊藤直也氏（以下「naoya」）が、寿司屋に招いたのは、naoya氏が開発組織改善プロジェクトの手伝いをしている『株式会社一休』のエンジニア、笹島祐介氏（以下「笹島」）と田中健介氏（以下「田中」）の2人。 『一休』とnaoya氏にもともと接点はなかったが、あるイベントで田中氏がnaoya氏に声をかけたことがきっかけで、『一休』の開発組織改善がスタート。順風満帆な出だしとはいかず、現場エンジニアの賛同を得られるまで苦悩の日々を過ごしながらも、GitHubの導入やデプロイの自動化などで、目に見えて組織改善がなされていき、現場の雰囲気も格段と良くなったのであった――。 ⇒【前編】の記事はこちら 【後編】となる今回は、技術的課題を解決すると同時に浮かび上がる「組織・人」の問題に、『一休』はどう立ち向かっていったのか、そして、CTO不
若いエンジニアへ
エンジニアなら誰でも突貫工事に喜びを見出した経験がある。深夜2時の夜食を共にした同僚のことは、その職業人生を通じて忘れることはない。しかし、そこにいかなるドラマがあろうとも、突貫工事は例外である。これを常態としてはならない。 メーカーの組込みプログラマとしてエンジニアのキャリアをスタートした私は、「よい製品はよいプロセスから生まれる」ことを頭に叩きこまれた。素晴らしい製品を生み出す工場は静かである。常に誰かが大声で叫んでいるような工場には明らかにプロセス上の問題が認められ、素晴らしい製品を生むことは決してない。 本物のエンジニアは突貫工事を好まない。突貫工事とはプロセス上の誤りであり、つまり誰かが大声で叫ばなければならないということだからである。エンジニアの仕事は計画され、コントロールされたものでなければならない。 長時間労働によって成果を生み出そうとすることも、やはり例外としなければなら
クリエイティブなエンジニアスタイル５カ条：目次 | 豆蔵ソフト工学ラボ
クリエイティブなエンジニアスタイルとはどうあるべきなのか、ここでそのイメージについてみなさんと共有するために、ここにクリエイティブなエンジニアスタイル５カ条を定義する。しかし、開発プロセス同様に、定義した日からこの定義は改善されるので、１か月後には進化しているかもしれない（笑）。 第5条：常にスタイリッシュでカッコよく生きるべし 要求開発とは、ビジネスを「見える化」し、IT化すべき箇所をできるだけ早く定め、そこに必要とされる要求を決めていく活動ことである。要求開発はビジネス開発と言っても過言ではない。クリエイティブなエンジニアスタイルとして、なぜ要求開発まで踏み込むべきなのか説明しよう。 2009/07/07 この記事を読む 第4条：要求開発まで踏み込むべし 要求開発とは、ビジネスを「見える化」し、IT化すべき箇所をできるだけ早く定め、そこに必要とされる要求を決めていく活動ことである。要求
改革リーダーの執念 - rabbit2goのブログ
日経ビジネス（2010年3月29日号）にリコーの遠藤紘一氏の記事が載っていた。社内の改革に奮闘した苦労話が出ており興味深い。会社の景気が悪くなったり、組織が変わったりすると「今こそ改革を実行すべきだ」と叫ぶ人がいるが、そんな発作的なスローガンに遠藤氏は警笛を鳴らしている。 こうした主張を耳にするたびに私は思う。「冗談じゃない」と。よく考えてみてほしい。日頃から努力を重ね、コツコツと改善活動に取り組んだ経験のない人や企業に、果たして改革のような大手術を遂行することが可能だろうか。 日経BP SHOP｜日経ビジネス2010年3月29日号 日頃から小さな改善を積み重ねていくからこそ、結果的に大きな改善をもたらすことが出来るのだ。今まで何もやってこなかったのに、いきなり一発逆転の改善を望むのは無謀だし、そもそもそのような状態に陥るまで改善できなかったという現状をまずは認識すべき、という主張はもっと
負の連鎖を断ち切れない開発者 - rabbit2goのブログ
ソフトウェアの開発現場では、正しいことばかりではなくて、正しくないことも何故か平気で行われている。行われているどころか、問題を指摘する人がいないと、あたかもそれが正しいかの如く脈々と受け継がれていたりする。その一例。 正しくないAPIの使い方を続けている そのような使い方をしている開発者に理由を聞くと、「もともとそのような使い方をしている箇所が有ったので真似をした」とのこと。その更に元の開発者をSubversionの履歴で調べていくと、実はもう既に退職した人だったりする。 開発プロセスが形骸化している 仕様書レビューやコードレビューがまともに行われない。リーダに理由を聞くと「忙しいから」「この案件は急ぐから」とのこと。でも、いつも同じ返事が返ってくるし、それを見聞きしているメンバもそんなリーダを見習ってしまうので、悪しき慣習は決して途切れない。 同じ問題を繰り返し発生させている 興味深いも
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社プロセスデザインエージェント