質とスピード / Quality and Speed
質とスピード 初演: 2019/10/31 @ EOF2019
質とスピード 初演: 2019/10/31 @ EOF2019
今年3月に政府のAI戦略が年間25万人を目標にAI人材を育てるとぶち上げたのに続いて、教育再生会議が全ての大学生がAIなどの基礎的な素養を身につけられるように標準カリキュラムを作成することを提言した。ガートナーが2017年1月に産業界で2020年末時点で30万人以上のIT人材（原典を確認したところAI人材ではなかったようですね）が不足するといったらしいのだが、今からカリキュラムをいじったところで2030年くらいにならないとAIネイティブな新入社員は入ってこないし、その頃まで深層学習が流行っているのか、NVidiaが残ってるのか、PythonやTensorFlowが広く使われているのか、GAFAがどうなっているかなんてさっぱり見当がつかない。 残念ながら私たちは2010年代に深層学習の実用化の局面で米国に負けたのであって、いまから教育をいじるといったって泥棒を捕らえて縄を綯うような話である。
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。 ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。 高い技術力よりも「いい感じ」力を求めている エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。 しかし、実際には開発プロジェクトの失敗
日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日本には毎年数回仕事で帰国しているし、日本語でブログや記事を書いてもいて、ある意味で「日本のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日本のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
本シリーズは、WebブラウザをUIとして利用した業務システムやアプリケーション（以下、Webシステム、Webアプリケーション）のテストをテーマとして、Webブラウザを使ったテストを自動化するOSSのツール「Selenium2」を紹介します。業務システム開発の現場で適用してきたノウハウを元に、これまでSelenium2について知らなかった人から以前使った経験がある人まで、より実践的な「使える」内容を盛り込んでいきたいと思います。 本シリーズのスコープと対象読者 本シリーズはWebシステム・Webアプリケーションのテストの中でも「Webブラウザを操作して実施するテスト」をスコープにしています。開発工程としては、1モジュールとして単体テストに位置付けられる場合もあれば、複数のモジュールやシステムと連携して結合テストや総合テストに位置付けられる場合もあるでしょう。これらのテストのことを、本シリーズ
2023年にエンジニアな私がマネジメントに目覚めてから読んでよかった3冊 - Lean Baseball
タイトルそのままのエントリーです. 気がつけば現職含めて「エンジニアのマネジメント」を行う職種を6年ちょいやらせてもらっています. マネジメントをする・しないを含めてキャリアパスどうする? マネジメントをやるとして何を教科書にしたら? 今どきの開発スタンス・マネジメントってどうしたら? みたいな悩みや迷い（&やっぱコードを書くエンジニアの仕事良さそうという脱マネジメントの検討*1）は常にありますが, 今年はそれに応えてくれる良著3冊に出会いました. スタッフエンジニア エンジニアのためのマネジメント入門 人が増えても速くならない 以上の3冊です. この3冊です（結論） スタッフエンジニア マネジメントを超えるリーダーシップ 作者:Will Larson日経BPAmazon エンジニアのためのマネジメント入門 作者:佐藤 大典技術評論社Amazon 人が増えても速くならない ～変化を抱擁せよ
こんにちは！やまもと＠テスト番長です。 前回satoさんの書いたエントリーが好評のようですね。 自分は実は美術系出身です。なので「デザインセンスのある人からみた～」というエントリーでも続けて書いちゃおうかなと一瞬思いましたが、世の中にはWEBデザインのプロの方もいらっしゃることだし、控えておきましょう。 センスってのも考え込むと難しいですしね。 個人的には、WEBデザインの美醜って「使いやすさ」とかなり直結な気がしてます。 さて、今回は僕が普段テストに使っているツールでもご紹介してみようかと思います。 Selenium 一年前くらいに登場した無償の自動実行ツールです。 有償の自動実行ツールは以前からありましたが、 ベンチャーが購入するには高価なものなので 大手以外にはあまり導入されていなかったであろう類のツールです。 テストシナリオにそってブラウザを自動で操作してくれます。
業務系SEの末路的なお話でして
Statistics Favorites 4 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 業務系SEの末路的なお話でして — Presentation Transcript 業務系SEの今後について 消費税増税と年金問題が与える影響 2012// 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Fax: 03-6712-0664 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.NAUTILUS Proprietary &
世に出ている「デザイン原則」と呼ばれるものたちをまとめてみました。 ユーザビリティ関連からモバイルUX、サービスデザインにいたるまで、広い範囲のデザイン原則を網羅したつもりです。ただし、チェックリスト的にまとめたため、内容の詳細は記述していません。 出典や内容を紹介している外部リンクを張っておきましたので、詳細を確認したい方はそちらをご参照いただければと思います。 なお、この記事は有用なデザイン原則を見つけ次第、随時更新していきます。 更新履歴 2018/10/01： 「アクセシビリティの4原則」「Material Designの原則」「Android TV デザイン原則」「インクルーシブデザインの原則」を追加 2016/12/28： 「Microsoft デザイン原則」を「Windows UX デザイン原則」にアップデート 「Apple Watch デザイン原則」を追加 2015/10/
Why doesn’t Japan excel in software as they did in hardware? (なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？) という英語Quoraのやり取り、分析が興味深かったので、まとめ。 仮説1: 日本は完璧を求める 10人のエンジニアのソフトウェア開発会社を経営しているフランス人の友人が、ルイ・ヴィトン日本支社のコンピュータシステムのマネージャーと同意した話：ソフトウェアはハードウェアではなく、産業用でもない。50年間同じトヨタカローラのように構築され、洗練され、完成されたものではありません。ゼロバグでそれを「完璧」にすることは不可能であり、したがって、「ゼロデフォルト」という、総合的な品質、継続的な改善を求める日本人の精神に反するものです。 日本は職人の国であり、漢字を書いたり、折り紙を折ったりする技術を
要はアジャイルは行き当たりばったりってことですか？
回答 (10件中の1件目) 逆に「行き当たりばったらない」進め方ってどんなのだろうなって考えてみると少しわかるかもしれないです。 「あれ？おかしいな？こんなはずじゃなかったんだけどな？まあいいや、予定通り進もう」 こんな感じのプロジェクトでしょうか。ヤバい予感しかしません。 アジャイルを計画を立てないことの免罪符として使う人が非常に多い（個人の感想です）ので、こうした質問はよく聞く気がします。 特にマニフェストに書かれている、 > 計画に従うことよりも変化への対応を アジャイルソフトウェア開発宣言 より ってあたりを曲解して、計画がないから進捗は常にグリーンなのだ！くらい...
夫の仕事のやり方が昭和すぎる
無事に保育園がきまったので、夫にスマホのカレンダー共有アプリの導入を夫に提案した 子供が保育園で熱を出した時にどっちが迎えにいくのか、看病で休むのかを素早く判断したい、が最初のモチベーション ちなみに共有する情報は、平日はどうしても外せない用事や会議体、保育園のイベント、休日は遊びに行くときの情報程度を想定していた 結果は、夫大激怒で完全否定 一方的に怒られて驚いたが、怒る理由にあとからもやもやが出てきた 深夜授乳をしつつ、書き殴ってみる 彼の言い分は以下の通り 仕事のスケジュールは水モノである それをいちいちスマホをパチパチして最新の情報に更新する手間は無駄でしかない 会議の時間帯以外にも準備時間もある。優先順位の高いスケジュールだけでいい、と言うが俺にとっては全てが最高の優先順位かつクオリティもMAXに持って行くべき仕事で全てスケジュールは埋まっている 単にスケジュールを見せたところで
syacyo @syacyo_twit みずほの件がお昼のニュースで取り上げられてたけど『言われたことしかやらないような担当者の意識を改革する』って言ってた。 これは日本独特の考え方。日本以外の作業者は普通は言われたこと以外はやらない。なので欧米はマネジメント層が優秀だし高給。 2022-01-14 12:41:18 syacyo @syacyo_twit 日本は精神論、根性論を盾にマネジメント層が圧力をかけて作業者がなんでもかんでも気を利かせて動くように強要する文化ができあがってしまっている。 本来はマネジメントする側が綿密に各自の作業内容を分担して、それ以外はやるな、とまで指示するのが正しい姿なのよ。 2022-01-14 12:44:06 syacyo @syacyo_twit だからオフショア開発で外国勢に作業依頼したときに成果物が酷くてなぜ◯◯していないんだ、と問い合わせると オ
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
いいね！ 6 ツイート B! はてブ 738 Pocket 138 tracをご存知ですか？tracは主にシステム開発系プロジェクトにおいて、バグ管理・バージョン管理・ドキュメント共有に使われる超便利ツールです。これがないと開発なんて出来ないよ！という開発者も多いはず。 そんなtracですが、個人用や家庭用でもカナリ使えるツールなんです。開発をしなくても、「脳をすっきりさせたり」「自分タスクを整理したり」「アイデアを貯めたり」「旅行計画を家族と共有したり」、日常生活という自分プロジェクトの管理ツールとして活用することができます。 tracとは 前述の通り、tracは主にシステム開発で使うプロジェクト管理ツールで、無償ソフトとして配布されているので、誰でも自由にダウンロードして使うことができます。 主に利用できる機能が4つあって ■ wiki 誰でもいつでも編集できるwiki機能があります。
GPT-4時代のエンジニアの生存戦略 ※ この記事の内容の一部はこちらのイベントでお話したことと重複します。 はじめに 2023年3月1日にOpenAI社よりChatGPTのAPIが公開されました。 さらに14日にはGPT-4が登場し、その翌々日にはMicrosoft 365 CopilotでGPT-4をOffice製品に搭載することが発表されるなど、AI領域で大きな変化が起きています。 変化の速度の速さと変化量の大きさにより、私自身も追いつくのが精一杯な状態です。 個人的には、iPhoneの登場時以上の衝撃を受けています。 人類の歴史上、過去3回AIブームがありました。Generative AIが4回目のブームになります。 そして、特に日本においては顕著なのですが、AIへの過度な期待とそれへの失望の繰り返しがここ数十年にわたって繰り返されてきました。 直近だと数年前のDeep Learn
2013-04-11 UXを学ぶならこれだけは目を通しておけ！ UXとはなんぞや!?って日々思いながら手探りでUXを意識したサービス開発、UXの向上を測っております、どうも @tacumacy です。 ボク自身、UXのことはなんとなーくわかってはいましたが、本格的にそれを仕事としてやろうとなった時から本気で勉強しなきゃやばい！と思い猛烈に危機感を感じたので、めちゃくちゃネットサーフィンをしてUXに関する情報を集めては読みまくりました。そこでボクが読んで参考になった書籍や記事を、どうせならここでまとめて見れるようにしておこうと思います。もし勉強したいな、と思ったときに見ていただけると幸いです。 こんな人に読んでほしい ・これからUXを学びたいと思っている人 ・UXについて、手っ取り早く情報が欲しいと思っている人 書籍紹介 以下、これだけは頭に入れておきたいなぁと感じた内容をまとめてくださって
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
衝撃的な効率性～最高の DevOps チームは「知っている事」で構成されていた～ - メソッド屋のブログ
今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ
この1年ほど、プロジェクトのリードを任せてもらえるようになりました。2017年の夏くらいから「プロジェクト推進役」→「PJO」→「Tech Lead」, 「Project Lead」など、正式ではないものの「肩書」のようなものがついていますが、実際にやっていることは「プロダクトの成功に向かってプロジェクトを行動で引っ張っていくこと」で統一されています。 これは別に偉くなったとかではなくて、そういう責任を持ってPJに関わる役割だと思って臨んでいますし、実際マネージャーからもそのように言われています。 自分なりに試行錯誤をして時には成功し、時には失敗しながらなんとかかんとかやってきていているのですが、「あー、この本に救われた」とか「ちょっと前にこの本読んでおけばよかった...」という本があったので何冊か紹介したいと思います。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリフ
エンジニアの次のステップへの勉強法 - Qiita
言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的に成り立ってしまっているので、それ以上成長をする必要がないのです。 まあ、そういう生き方もありかな？って思うので、それでいいやって思う人は続きは読まなくてもいいかなって思います。 ここから先はエンジニアとして技術を伸ばすことが楽しい、ものを作ることが楽しい、
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
NTTコミュニケーションズのソフトウェアエンジニア向け研修内容・資料を公開します | NTT Communications Developer Portal
こんにちは、SkyWayの開発・運用をしている岩瀬（@iwashi86）です。 今回の記事では、弊社の研修内容の一部を公開します。 研修の狙い 毎年200名超の社員がNTTコミュニケーションズグループに入社しています。 入社いただいた社員の中には、もともと高い技術力を持っている社員も多くいます。 今年度より、ソフトウェアエンジニアリングのスキルの高い社員（今回は35名）を対象として新たな研修1を実施しています。 研修の主な狙いは以下の2つです。 即戦力レベルのスキル習得 実際の現場で有用となる技術・開発スキルの習得して、現場ですぐに活躍できるように ネットワーキングの強化 / コミュニティ形成 同期だけでなく、講師・メンタを含む先輩エンジニアとのネットワークを形成し、互いに影響を与え合い成長できるように なお、2点目について補足すると、今回の研修では社外のエキスパートによるプログラムに加え
補足を以下に記載しています: https://www.wantedly.com/companies/ikyu/post_articles/42802
横田です。 自分の個人ブログに「行っておくべき、有名IT系勉強会のまとめリンク集」と「フォローしておくべきIT系勉強会の公式Twitterまとめ」という記事をエントリしたところ、これらの記事を「さくらのナレッジに転載してはどうか？」というお誘いをいただきました。 確かにこれらの記事については「IT系のナレッジ」と言えば、そうなのですが、ただ転載するだけではつまらないので「IT系勉強会」のリンクと、これらの勉強会の情報を入手するにはどのようにすれば良いのか、考えていきたいと思います。 《参加すべきIT系有名勉強会》 ITに関係する勉強会は毎日のように開催されています。これだけ勉強会の数が多いと、どのようなIT系の勉強会があって、自分が関心がある勉強会がいつ開催されるのか、わからない人も多いと思います。 まずは、一度定期的に開催され、参加人数も多い勉強会に参加するのが良いと思います。 下記に有
こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba
最近、毎日のようにEMのいくおさん（ @dora_e_m ）とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを本当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う（ふだんから
We are constantly updating our collection of different sources. All content absolutely free!
ケルビン＠斜壊人 @legendkelbin ラーメン屋で「醤油ラーメン」と注文した後に「半ライスつけて。餃子つけて。やっぱ塩で。ネギ多め。やっぱ炒飯で。メンマつけて。やっぱ味噌で。もやしつけて。海苔要らない」位の追加注文した客が、最初の醤油ラーメン代だけ払って帰るのを呆然と見るのがシステム開発です。
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
2015年1月10日にジュンク堂池袋店で開催された「このコンピュータ書がすごい！2015新春座談会 －2014年に出たコンピュータ書ならこれを読め！－」に行ってきましたのでレポートをつらつらと書いていきますね。 最初に言っておきますが、怖ろしい文量というか、紹介書籍量なので時間のあるときにでもゆっくり読んでもらうことをお薦めします。 このイベントは、日本Rubyの会代表でありプレゼンの高橋メソッドでお馴染みの高橋征義さんのマシンガントークでコンピュータ関連書籍をひたすら紹介するというもの。19時30分にスタートして、終了したのは21時45分。ジュンク堂の担当者さんが「時間、超ヤバイ！！」という泣きカンペを出すぐらい、濃密なイベントでした。 【追記】技術評論社さんの公式チャネルに動画が上がってました。 2014年すごいコンピュータ書総合ランキング 1位 リーダブルコード 2位 インフラ／ネッ
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
大きく挙げたのは7冊なので、7日の休みで1日1冊ですね！ 連休の間に読んでおいて、友達に差をつけよう！ うっかり、先輩にも差をつけちゃえばいいと思います。 プログラムを組むとはどういうことか 本を挙げる前に、まずプログラムを組むとはどういうことかということを考えておきます。 ざっくりとした説明なので、だいたいこういう感じ、だと考えてください。 その上で、どのような本が必要かを考えて、本を選んでいきます。 以前描いたものですが、プログラムを作るということと各分野の関係はこのようにあらわせます。 まず、プログラムは最終的にユーザーに使ってもらうためのものです。 ただ、ユーザーはプログラムを直接使うことはできません。プログラムはハードウェアで動かす必要があります。そして、ユーザーインタフェースを介してユーザーが使います。 (ハードウェアからプログラムへの矢印は逆のほうがいいですね) このような、
プロジェクトの基本
The spirit of TDD - Oct 22, 2010 at Cybozu Developers Conference
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AI時代へ向けて育成すべきはAI人材か?｜楠 正憲（デジタル庁統括官）
市場は「なんかいい感じにしてくれる」エンジニアを求めているのではないか - 毎日がもふもふ
第3回 なぜ日本のソフトウェアが世界で通用しないのか | gihyo.jp
最近SIerがだいぶヤバくなっている件 - GoTheDistance
さよなら手作業・人海戦術！ HTML5時代のツール「Selenium2」でWebシステムのテストを自動化
ウノウラボ Unoh Labs: WEBアプリのテストに必須なツール７種
UI/UXデザイナーなら一度は目を通しておきたい「デザイン原則」まとめ【随時更新】
海外「なぜ日本はハードウェアの時代と同じようにソフトウェアに秀でることができない？」 - Qiita
"言われたことしかやらないのはダメ"という日本の考え方は独特→海外委託で衝突する原因やマネジメントの機能の話へ
要件定義～システム設計ができる人材になれる記事 - Qiita
Web2.0ナビ: 意外と使われていない「個人用trac」活用のすすめ
GPT-4時代のエンジニアの生存戦略 - Qiita
UXを学ぶならこれだけは目を通しておけ！ - UX-design
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
プロジェクトをリードする前に読みたかった本 - motokieeの日記
テスト駆動開発チートシート - やさしいデスマーチ
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
System of Record と System of Engagement
「行っておくべき有名IT系勉強会」と、その開催日をチェックする方法 | さくらのナレッジ
【初心者向け】Mac OSX10.8(Mountain Lion)で Ruby on Railsを動かすための5ステップ « pplog.org
システム開発をラーメンの注文に見立てたツイートが話題に！「納得」「うちの業界でも…」と悲痛な声が…
日本でアジャイルが流行らない理由 - @ledsun blog
このコンピュータ書がすごい！2015のランキングと参加レポート（長文）（動画追記あり）
システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
4月にプログラム始めた人がゴールデンウィークに積んでおく本 - きしだのHatena
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して