SIerで開発合宿を始めた話。そしてPMジェダイが立ち上がる : 小野和俊のブログ
「技術力強化、PM力強化」 この1年間、私がCTOとして向き合うべき主たる課題はこの2つだった。 ■ 技術力強化 技術力強化については、昨年4月に私が管轄するテクノベーションセンターを立ち上げ、「ものづくりの技術の会社への原点回帰」という方針に基づいて1年間で様々な施策を講じてきた。モダン開発推進チームの立ち上げによってCI/CD、テスト自動化等の概念が徐々に浸透し始めてきたし、一度モダン開発推進が支援したチームからは、その後さらなる改善に向けて継続的に相談が来たりもし始めた。全社的に利用されるようになったSlackでは毎日のようにプログラミング談義も含めた多数の技術的な質問と回答、情報共有が行われるようになった。 さらに、全社的に技術面での成長が実感できるよう、技術力評価指標を策定する取り組みも着々と進んでいる。こうした取り組みにより、技術力強化については次第に取り組んでいたことが形にな
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
タダでソフト開発の生産性と品質を上げる方法（3）：意外に使えるフリーツール「PictMaster」を使いこなす
ソフトウェアの開発では、プログラミングが天国ならデバッグは地獄。デバッグさえなければ、プログラム開発ほど面白い仕事はありません。「試験のない学生生活」のようなものですね。 ソフトウェアは、膨大な入出力の組み合わせで成り立っており、入出力の組み合わせを適当にテストしても、バグは検出できません。何もやらずに出荷するのは、エンジニアの恥というより、「不正電磁物作成罪」を新しく法制化して告訴したくなります（有罪時の量刑は、「3年以上、または、一生涯、他人のプログラムをデバッグする刑に処す」です）。組み合わせテストが面倒なのは、テスト項目が爆発的に増加することと、作成したテスト項目の取捨選択が難しいことが原因でしょう。テスト項目数を少なくする代表的な技法に、「直交表」と「オールペア法」があります。これを使うと、少ないテスト項目で網羅的なテストができます（ただし、テスト項目を間引いているため、当たり前
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
新技術導入を米国並みに！働き方を変えて生産性を高めるための８つの習慣 - メソッド屋のブログ
クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める８つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください！また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。 元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ１０数分以下のサイズになっています。 序章：イントロダクション ８つの習慣をなぜ作成したのか？どういう効果があるのか？と
「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第３の習慣 - メソッド屋のブログ
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。 ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。 不確実性を受入れる マネージメントは詳細まで細かく練られた計画を期待しない。 予算と報告のプロセスは精密な結果の予測を要求しない。 内部プロセスは計画や優先順位の変更に柔軟である 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる 学びに基づいて、変化を精力的に行う。 この習慣は日本人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ 「Site Reliability Engineering」（SRE）とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 これまでの運用チームやインフラチームによる運用や改善とSREが異なるのは、SREでは積極的にコードを書き、ソフトウェアによって目的の達成を目指している点にあるといえます。 Googleが公開しているSREのWebサイトでは、SREを次のように説明しています。 Like traditional operations groups, we keep important, revenue-critical syst
SIer出身者を採用したい非SI経験＋採用責任者の叫び
Webサイドでも人材不足の中で、ポテンシャルの高い SI出身者に活躍してもらえそうな期待を判断する目を持つのは 重要課題Read less
「検討」は無駄である - リスクや間違いを快く受け入れる第２の習慣 - メソッド屋のブログ
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。 最初の習慣は次のブログで紹介してみた。 simplearchitect.hatenablog.com リスクや間違いを快く受け入れる リスクを背負うことは推奨されている 間違いを厳しく批判したり懲罰したりしない 失敗から学ぶ態度 Fail Fast(早く失敗する） 実験が推奨されている 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される 非難や恐怖感の無い環境 この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない！ 間違いや失敗に対す
ソフトウェアエンジニアならもっと気軽にアメリカ移住を考えたほうがいいよ｜Rui Ueyama｜note
なんか数年に一回くらいシリコンバレー移住は割りに合うのかという話が上がってくる気がする。前の地獄のシリコンバレーはトンチンカンで噴飯ものだったけど、今回の海外移住？アメリカは止めた方がいいよはまあまあまともな意見な気がする。でも、なんか違うよなーと思った。 まず第一にやっぱりアメリカの方が待遇がずっとよくて、物価差を考慮に入れてもやっぱり全然違うと思う。やや大げさかもしれないけど、日本のプロ野球と大リーグみたいな違いがあるように思うんだけど。 第二に、お金だけではないよね、ということ。現実としてソフトウェアの世界はアメリカを中心に動いていて、他の国はアメリカで開発されたものを使っている。シリコンバレーなら伝説的なプログラマがわりとそこらへんにいて、普通に話をしたり一緒に仕事をしたりすることができる。カンファレンスであまりにも有名人過ぎて話しかけるのに躊躇するようなレベルの人が職場のすぐそこ
人人月の寓話：プログラマで、生きている：エンジニアライフ
わたしがまだ新人プログラマだった頃、キックオフミーティングで渡された仕事の割り振り表のメンバーの欄に「X」と書かれていたことがありました。 「Xって誰ですか？」と尋ねると「そのうち現れるであろう誰か」という答えが返ってきました。要するにエンジニアを確保するつもりはあるんだけど見つかっていないということです。「ホントに現れるのか？」とわたしは疑っていましたが「X」は現れました。 ていうか、わたしでした。 リーダーから「X」と命名（？）された先輩とわたしは2人でその担当分を片づけることに（もちろん本来の担当分も片づけた）。 「結局見つからないんだったら、最初っからXなんて書かなければいいのに」とグチったら、一緒に担当分を増やされた先輩に「上の人間もぎりぎりまでがんばって探してたんだよ。いないものはいないんだから仕方ない。いる人間でがんばって片づけよう」と諭されました。 その後、さまざまなプロジ
SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ
「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と
消えたプログラマの残したものは - megamouthの葬列
システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい
QiitaやKobitoを作る開発チームの文化 - Qiita Blog
こんにちは，yaottiです． 今日はQiitaやQiita:Team, Kobitoを開発するチームでぼくたちがどういう文化，価値観を大切にしているかをお話したいと思います． HRT, SPOF, LeanIncrements(あまり知られていませんが，Qiitaを作っている会社の社名です)の開発チームが特に大切にしているのは以下の3つです． HRTを大切にしたコミュニケーション属人性を極限まで排除する重要な価値に集中する以降でそれぞれ具体的に見ていきます． HRTを大切にしたコミュニケーションHRTとは HRTとはTeam Geek ―Googleのギークたちはいかにしてチームを作るのかという本にある考え方で(あらゆるチーム開発者に読んでほしい!)，Humility(謙遜), Respect(尊敬), Trust(信頼)の3つを意味しています． 「驕り高ぶらないようにしよう」「相手を尊
玲瓏: Moving Ahead
Yesterday was one year anniversary as the Increments' employee (Increments is my current company). Taking a look back on what I did in the past one year, though I can be proud of my achievements, I also must admit I could have done much better jobs. As the first product manager, I introduced several PM methodologies like PRD (Product Requirements Document) as well as company-wide process including
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
英語鎖国で深刻なのは情報入手のスピードじゃないと思う - メソッド屋のブログ
エンジニアに英語が必要と言われて久しい。技術情報を早く入手するためには、英語を使えないといけないからとあるがこれは本当なのだろうか？自分的な気づきがあったので、その考察をシェアしたい。 エンジニアに英語が必要と言われている。いろんなことが言われているが、情報の入手のスピードが遅くなるという意見がある。個人的にはこの意見はある意味微妙な意見だと思う。 最近だと例えば最新技術に関する海外イベントがあったとしても、翌日、早ければ当日の間に誰かがまとめブログをアップしてくれたりする。もっと時間がかかったとして、２カ月程度後に誰かが書いた日本語の情報でそのことを学んだ ところで、大勢に影響はない。 また、日本語で出ている書籍は確かに翻訳のタイムラグがあるが、海外の人も主だったすべての本を読んでいるわけではないし、日本語になったものを着実に勉強しても、勉強の知識としては、相当なエンジニアになれるはずだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
タスク管理アプリ「Trello」の買収に470億円！ 豪ソフトメーカーの思惑
Twitter
Service development for users - Speaker Deck
