Submit Search
Upload
"地方エンジニア" という考え方はすでに終わっている
•
144 likes
•
63,726 views
Hiroshi Ogino
Follow
2014/2/1 DevLOVE四国の発表資料。
Read less
Read more
Report
Share
Report
Share
1 of 94
Download now
Download to read offline
Recommended
「正しいアジャイル」でなくてもいい
「正しいアジャイル」でなくてもいい
Hiroshi Ogino
Microservices Meetup vol.8 Lightning Talks Battle! で話した内容です https://microservices-meetup.connpass.com/event/99190/
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
ota42y
SQLアンチパターン 読書会用メンター資料
SQLアンチパターン メンター用資料
SQLアンチパターン メンター用資料
Hironori Miura
Redmine+Git+GitLab+Jenkinsを総合的に利用した少人数チームでのプロジェクト管理とそのフローについて English version: http://www.slideshare.net/cakeyoshida/best-practices-of-project-management-for-small-teams
少人数チームにおけるプロジェクト管理のベストプラクティス
少人数チームにおけるプロジェクト管理のベストプラクティス
Cake YOSHIDA
ドメイン駆動設計でなぜつくるのか? 「核心にある複雑さ」とは何か? その複雑さにどう立ち向かうか?
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に落としこむか 今回のスライドでは、概念の方の説明をしたいと思います。
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
Japan Oracle User Group (JPOUG) Oracle Database入学式 2017 – 保護者の方はご遠慮ください http://www.jpoug.org/?p=1979 で使用した資料の抜粋です。
Introduction of Oracle Database Architecture(抜粋版) - JPOUG Oracle Database入学式 ...
Introduction of Oracle Database Architecture(抜粋版) - JPOUG Oracle Database入学式 ...
Ryota Watabe
クラウドネイティブアプリケーションの設計パターン「Beyond the Twelve-Factor App」の紹介
Beyond the Twelve-Factor App
Beyond the Twelve-Factor App
Kazuya Takahashi
Recommended
「正しいアジャイル」でなくてもいい
「正しいアジャイル」でなくてもいい
Hiroshi Ogino
Microservices Meetup vol.8 Lightning Talks Battle! で話した内容です https://microservices-meetup.connpass.com/event/99190/
マイクロサービスにおける 結果整合性との戦い
マイクロサービスにおける 結果整合性との戦い
ota42y
SQLアンチパターン 読書会用メンター資料
SQLアンチパターン メンター用資料
SQLアンチパターン メンター用資料
Hironori Miura
Redmine+Git+GitLab+Jenkinsを総合的に利用した少人数チームでのプロジェクト管理とそのフローについて English version: http://www.slideshare.net/cakeyoshida/best-practices-of-project-management-for-small-teams
少人数チームにおけるプロジェクト管理のベストプラクティス
少人数チームにおけるプロジェクト管理のベストプラクティス
Cake YOSHIDA
ドメイン駆動設計でなぜつくるのか? 「核心にある複雑さ」とは何か? その複雑さにどう立ち向かうか?
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
ブログでもいろいろ解説しています。 http://little-hands.hatenablog.com/entry/top ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。 --- 公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています) bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable. 境界付けられたコンテキスト 特定のモデルを定義・適用する境界を明示的に示したもの。 代表的な境界の例は、サブシステムやチームなど。 まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。 ・概念としての境界付けられたコンテキスト ・境界付けられたコンテキストをどう実装に落としこむか 今回のスライドでは、概念の方の説明をしたいと思います。
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
境界付けられたコンテキスト 概念編 (ドメイン駆動設計用語解説シリーズ)
Koichiro Matsuoka
Japan Oracle User Group (JPOUG) Oracle Database入学式 2017 – 保護者の方はご遠慮ください http://www.jpoug.org/?p=1979 で使用した資料の抜粋です。
Introduction of Oracle Database Architecture(抜粋版) - JPOUG Oracle Database入学式 ...
Introduction of Oracle Database Architecture(抜粋版) - JPOUG Oracle Database入学式 ...
Ryota Watabe
クラウドネイティブアプリケーションの設計パターン「Beyond the Twelve-Factor App」の紹介
Beyond the Twelve-Factor App
Beyond the Twelve-Factor App
Kazuya Takahashi
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
Junitを使ったjavaのテスト入門
Junitを使ったjavaのテスト入門
Satoshi Kubo
アーキ部#15の資料です。
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
Springのポイントを押さえて開発を面白くしましょう。
Springを何となく使ってる人が抑えるべきポイント
Springを何となく使ってる人が抑えるべきポイント
土岐 孝平
Pythonで二段階認証
Pythonで二段階認証
aoshiman
2017/05/26のDB比較セミナーで使用した資料です。 NoSQLであるRedisについて説明しています。
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
2018年12月14日に行われたJaSST Review'18(ソフトウェアレビューシンポジウム 2018)での講演「アーキテクチャのレビューについて」の資料です
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
ver1.0 公開 ver1.1 ディスクイメージを直接操作する方法を追加 (2015/02/20)
Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造
Etsuji Nakai
低レイヤー入門
低レイヤー入門
demuyan
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
従来のWebアプリケーションとSPAの違いに着目し、Spring Boot × Vue.jsでSPAを作る際のポイントやハマりどころを紹介します。
Spring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作る
Go Miyasaka
分析処理基盤において、データの民主化・マルチテナント化を進めるためにはいくつかのハードルがあります。そのハードルの一つに、データリスクを低減するための認証・認可の実現が挙げられます。 本講演では、ドワンゴが分析処理基盤の認証・認可機構を一新した内容とポイント、またそれらの認証・認可機構をベースとし、分析処理を数倍から数十倍に高速化した事例を紹介致します。
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤
Masahiro Kiura
越境アジャイル in 札幌。RDRA,ドメイン駆動設計,価値探索
RDRA DDD Agile
RDRA DDD Agile
増田 亨
チームとして未経験な領域が多い中でどのようにしてプロジェクトの不確実性を下げていったかということをお話しした内容です
ユーザーデータ基盤を1からScalaでつくった話し
ユーザーデータ基盤を1からScalaでつくった話し
Hideaki Tarumi
ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
増田 亨
2017-06-30 #ssmjp AWS LambdaとDynamoDBがこんなにツライはずがない
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
Masahiro NAKAYAMA
レッツゴーデベロッパー変真で行ったぐるぐるDDD/Scrumのワークショップ資料です。
ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう
ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう
Kiro Harada
PostgreSQL Conference Japan 2017(2017年11月3日) チュートリアルトラック4コマ目の発表資料です。
PostgreSQLレプリケーション(pgcon17j_t4)
PostgreSQLレプリケーション(pgcon17j_t4)
Kosuke Kida
RLSを用いたマルチテナント実装 for Django by Takayuki Shimizukawa 複数のテナント(チーム・組織)向けにサービスを提供するシステムで、テナント相互の情報を分離して扱う、複数のマルチテナントアーキテクチャが考案されています。「各プログラマが努力して実装する」戦略でも実現はできますが、プログラミングミスや設定間違いによるデータ混濁が高確率で発生します。このトークでは、マルチテナントアーキテクチャにおけるデータ分割アプローチのひとつ「共有アプローチ」をDjangoとPostgresのRow Level Security (RLS) の組合せで安全に実現する方法を紹介します。またこの方法のメリット、デメリットを紹介します。 https://djangocongress.jp/
RLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for Django
Takayuki Shimizukawa
関心の分離とは
Ooc 2020
Ooc 2020
Zenji Kanzaki
松江Ruby会議06での倉貫の行ったゲスト講演での資料です。
「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから
Yoshihito Kuranuki
エンジニアがとるべき8つの行動
エンジニアがとるべき8つの行動
Hiroshi Ogino
More Related Content
What's hot
イベント・ソーシングを知る
イベント・ソーシングを知る
Shuhei Fujita
Junitを使ったjavaのテスト入門
Junitを使ったjavaのテスト入門
Satoshi Kubo
アーキ部#15の資料です。
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
Springのポイントを押さえて開発を面白くしましょう。
Springを何となく使ってる人が抑えるべきポイント
Springを何となく使ってる人が抑えるべきポイント
土岐 孝平
Pythonで二段階認証
Pythonで二段階認証
aoshiman
2017/05/26のDB比較セミナーで使用した資料です。 NoSQLであるRedisについて説明しています。
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
2018年12月14日に行われたJaSST Review'18(ソフトウェアレビューシンポジウム 2018)での講演「アーキテクチャのレビューについて」の資料です
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
ver1.0 公開 ver1.1 ディスクイメージを直接操作する方法を追加 (2015/02/20)
Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造
Etsuji Nakai
低レイヤー入門
低レイヤー入門
demuyan
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
従来のWebアプリケーションとSPAの違いに着目し、Spring Boot × Vue.jsでSPAを作る際のポイントやハマりどころを紹介します。
Spring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作る
Go Miyasaka
分析処理基盤において、データの民主化・マルチテナント化を進めるためにはいくつかのハードルがあります。そのハードルの一つに、データリスクを低減するための認証・認可の実現が挙げられます。 本講演では、ドワンゴが分析処理基盤の認証・認可機構を一新した内容とポイント、またそれらの認証・認可機構をベースとし、分析処理を数倍から数十倍に高速化した事例を紹介致します。
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤
Masahiro Kiura
越境アジャイル in 札幌。RDRA,ドメイン駆動設計,価値探索
RDRA DDD Agile
RDRA DDD Agile
増田 亨
チームとして未経験な領域が多い中でどのようにしてプロジェクトの不確実性を下げていったかということをお話しした内容です
ユーザーデータ基盤を1からScalaでつくった話し
ユーザーデータ基盤を1からScalaでつくった話し
Hideaki Tarumi
ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
増田 亨
2017-06-30 #ssmjp AWS LambdaとDynamoDBがこんなにツライはずがない
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
Masahiro NAKAYAMA
レッツゴーデベロッパー変真で行ったぐるぐるDDD/Scrumのワークショップ資料です。
ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう
ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう
Kiro Harada
PostgreSQL Conference Japan 2017(2017年11月3日) チュートリアルトラック4コマ目の発表資料です。
PostgreSQLレプリケーション(pgcon17j_t4)
PostgreSQLレプリケーション(pgcon17j_t4)
Kosuke Kida
RLSを用いたマルチテナント実装 for Django by Takayuki Shimizukawa 複数のテナント(チーム・組織)向けにサービスを提供するシステムで、テナント相互の情報を分離して扱う、複数のマルチテナントアーキテクチャが考案されています。「各プログラマが努力して実装する」戦略でも実現はできますが、プログラミングミスや設定間違いによるデータ混濁が高確率で発生します。このトークでは、マルチテナントアーキテクチャにおけるデータ分割アプローチのひとつ「共有アプローチ」をDjangoとPostgresのRow Level Security (RLS) の組合せで安全に実現する方法を紹介します。またこの方法のメリット、デメリットを紹介します。 https://djangocongress.jp/
RLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for Django
Takayuki Shimizukawa
関心の分離とは
Ooc 2020
Ooc 2020
Zenji Kanzaki
What's hot
(20)
イベント・ソーシングを知る
イベント・ソーシングを知る
Junitを使ったjavaのテスト入門
Junitを使ったjavaのテスト入門
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Springを何となく使ってる人が抑えるべきポイント
Springを何となく使ってる人が抑えるべきポイント
Pythonで二段階認証
Pythonで二段階認証
Redisの特徴と活用方法について
Redisの特徴と活用方法について
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Dockerイメージ管理の内部構造
Dockerイメージ管理の内部構造
低レイヤー入門
低レイヤー入門
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Spring Boot × Vue.jsでSPAを作る
Spring Boot × Vue.jsでSPAを作る
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤
RDRA DDD Agile
RDRA DDD Agile
ユーザーデータ基盤を1からScalaでつくった話し
ユーザーデータ基盤を1からScalaでつくった話し
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
AWS LambdaとDynamoDBがこんなにツライはずがない #ssmjp
ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう
ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう
PostgreSQLレプリケーション(pgcon17j_t4)
PostgreSQLレプリケーション(pgcon17j_t4)
RLSを用いたマルチテナント実装 for Django
RLSを用いたマルチテナント実装 for Django
Ooc 2020
Ooc 2020
Viewers also liked
松江Ruby会議06での倉貫の行ったゲスト講演での資料です。
「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから
Yoshihito Kuranuki
エンジニアがとるべき8つの行動
エンジニアがとるべき8つの行動
Hiroshi Ogino
日本の中小企業のお嘆きである「業務がわかるSEがいない」を解決するロールを考えてみました。
顧問エンジニアというロールを作りたい
顧問エンジニアというロールを作りたい
Michitaka Yumoto
LINE Fukuokaや、妖怪ウォッチでおなじみのレベルファイブなど、福岡で旗揚げや部署の移設をしたネット企業やベンチャー団体、エンジニア界隈のコミュニティ。IT企業が集まる福岡の魅力を解説します。
エンジニアが幸せに暮らせる県!?Itベンチャーがこぞって開発拠点を作りたがる福岡県の魅力
エンジニアが幸せに暮らせる県!?Itベンチャーがこぞって開発拠点を作りたがる福岡県の魅力
iengineer1008
Zend OPcacheの速さの秘密を探る
Zend OPcacheの速さの秘密を探る
Yoshio Hanawa
小学校以降〜大学受験まで、学年に関係なく、受験を控えている or 受験をするかもしれない子どもの親に向けて、親にこそ知っておいて欲しい効率的な勉強方法を有給ニート中の有り余るヒマを注ぎ込んでまとめてみたスライド。
親に知ってほしい受験勉強
親に知ってほしい受験勉強
Tomoaki Nishikawa
エリックのDDD本を読んで30分で挫折した僕が考える、こーゆーことをやるのがドメイン駆動設計なるものなんじゃないの、という資料です。
これって、ドメイン駆動設計?
これって、ドメイン駆動設計?
Michitaka Yumoto
Viewers also liked
(7)
「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから
エンジニアがとるべき8つの行動
エンジニアがとるべき8つの行動
顧問エンジニアというロールを作りたい
顧問エンジニアというロールを作りたい
エンジニアが幸せに暮らせる県!?Itベンチャーがこぞって開発拠点を作りたがる福岡県の魅力
エンジニアが幸せに暮らせる県!?Itベンチャーがこぞって開発拠点を作りたがる福岡県の魅力
Zend OPcacheの速さの秘密を探る
Zend OPcacheの速さの秘密を探る
親に知ってほしい受験勉強
親に知ってほしい受験勉強
これって、ドメイン駆動設計?
これって、ドメイン駆動設計?
Similar to "地方エンジニア" という考え方はすでに終わっている
インフラエンジニアとして普段心がけていること
インフラエンジニアとして普段心がけていること
インフラエンジニアとして普段心がけていること
Shohei Koyama
エンジニアライフの勉強会にて、久々の登壇。
エンジニアライフ 市場価値 20140322
エンジニアライフ 市場価値 20140322
Mamoru Sato
仲間になろう!~ We are the World ~
仲間になろう!~ We are the World ~
Hiroshi Ogino
2016年4月30日(土曜日)に開催されたkintone Café 沖縄女子会 Vol.1で発表した資料です!
20160430 kintone Café 沖縄女子会 Vol.1 kintoneデモ環境紹介
20160430 kintone Café 沖縄女子会 Vol.1 kintoneデモ環境紹介
Midori Ikegami
社内勉強会で使用したセミナーのスライドです。 UI設計そのものというより、その前の土台となる考え方について講義しました。基礎の基礎のものです。
UI設計の土台になる考え方-インテリジェントネット社内勉強会
UI設計の土台になる考え方-インテリジェントネット社内勉強会
INI株式会社
インフラエンジニアというものを、次の側面で理解する - レイヤー - スキル - フェーズ
qpstudy 2014.04 インフラエンジニアとは、なんだ
qpstudy 2014.04 インフラエンジニアとは、なんだ
Takashi Abe
ビープラウドさんの勉強会 BP-StudyのLT資料です。 BPStudy#140〜IT企画/エンジニアリング組織・マネジメントを語る会 https://bpstudy.connpass.com/event/122728/
行動できるエンジニアは何が違うのか
行動できるエンジニアは何が違うのか
修治 松浦
2016年2月19日(金) Developers Summit 2016 2日目 に行ったgusukuハンズオン資料です。 http://event.shoeisha.jp/devsumi/20160218/session/1064/
20160219 Developers Summit 2016 gusukuハンズオン
20160219 Developers Summit 2016 gusukuハンズオン
Midori Ikegami
注目スタートアップ4社が語る!~ オレたちが目指す"最強のエンジニアドリブン" ~(http://connpass.com/event/9971/)で話したスライドです
マネーフォワード流エンジニアドリブン
マネーフォワード流エンジニアドリブン
Keisuke Izumiya
SmartNewsさん主催の『SmartNews Tech Night Vol.2』でお話した内容ですm(_ _)m
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
Libre Office の発表で使用したスライド
2015/8/8 関西 オープンソースカンファレンス 勉強会 スライド
2015/8/8 関西 オープンソースカンファレンス 勉強会 スライド
anubis_369
若手ゲームUIデザイナー向けにDeNAにて開催した『魅力を感じる、伝わるポートフォリオ作成講座』のセミナー資料です。 ※こちらの公開シェア版に関しては、参考作品の画像を、伏せさせて頂いております。 セミナー内容については、下記の記事にてまとめています。 http://creator.dena.jp/archives/40367346.html
魅力を感じる、伝わるポートフォリオ作成講座 (シェア版)
魅力を感じる、伝わるポートフォリオ作成講座 (シェア版)
Junichi Izumi
SNS系アプリ開発のUI/UXまでやったけど、事業としてのスタートをやめた話をLightning Talkで発表しました。
スタートアップできなかった話
スタートアップできなかった話
MontBlanc. Tsukuda
DevOpsが引き金となるインフラエンジニアの進撃
DevOpsが引き金となるインフラエンジニアの進撃
Teruo Adachi
電話とガンダムのお話
IoTの原点
IoTの原点
Shinichi Takahashi
CTOやフリーランスのキャリアについて、函館の蔦屋書店で公演してきた資料 プライバシー設定更新されなかったので上げ直した
CTOやフリーランスのキャリアについて
CTOやフリーランスのキャリアについて
Yusuke Kon
CTOやフリーランスのキャリアについて話してきたよ
CTOやフリーランスのキャリアについて
CTOやフリーランスのキャリアについて
Yusuke Kon
第6回 node setagaya勉強会 提案できる技術者になろう!
第6回 node setagaya勉強会
第6回 node setagaya勉強会
yujifukatani
サイボウズ東京オフィスで開催された「エンジニア副業Night #1」での発表資料です。
せっかくエンジニアやってるのになんで副業やらないんですか? - エンジニア副業Night #1
せっかくエンジニアやってるのになんで副業やらないんですか? - エンジニア副業Night #1
Yuki Okada
IAとかUIとかUX…ここ数年これらの言葉をよく聞くようになりましが、はたして自分はちゃんと理解できてるのか?と疑問になりまして、まずはIAをちゃんと理解してみよう!と思ったらいきなり深みにハマりました…
いまさらですが IAってなんだろう
いまさらですが IAってなんだろう
芳彦 佐伯
Similar to "地方エンジニア" という考え方はすでに終わっている
(20)
インフラエンジニアとして普段心がけていること
インフラエンジニアとして普段心がけていること
エンジニアライフ 市場価値 20140322
エンジニアライフ 市場価値 20140322
仲間になろう!~ We are the World ~
仲間になろう!~ We are the World ~
20160430 kintone Café 沖縄女子会 Vol.1 kintoneデモ環境紹介
20160430 kintone Café 沖縄女子会 Vol.1 kintoneデモ環境紹介
UI設計の土台になる考え方-インテリジェントネット社内勉強会
UI設計の土台になる考え方-インテリジェントネット社内勉強会
qpstudy 2014.04 インフラエンジニアとは、なんだ
qpstudy 2014.04 インフラエンジニアとは、なんだ
行動できるエンジニアは何が違うのか
行動できるエンジニアは何が違うのか
20160219 Developers Summit 2016 gusukuハンズオン
20160219 Developers Summit 2016 gusukuハンズオン
マネーフォワード流エンジニアドリブン
マネーフォワード流エンジニアドリブン
インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
2015/8/8 関西 オープンソースカンファレンス 勉強会 スライド
2015/8/8 関西 オープンソースカンファレンス 勉強会 スライド
魅力を感じる、伝わるポートフォリオ作成講座 (シェア版)
魅力を感じる、伝わるポートフォリオ作成講座 (シェア版)
スタートアップできなかった話
スタートアップできなかった話
DevOpsが引き金となるインフラエンジニアの進撃
DevOpsが引き金となるインフラエンジニアの進撃
IoTの原点
IoTの原点
CTOやフリーランスのキャリアについて
CTOやフリーランスのキャリアについて
CTOやフリーランスのキャリアについて
CTOやフリーランスのキャリアについて
第6回 node setagaya勉強会
第6回 node setagaya勉強会
せっかくエンジニアやってるのになんで副業やらないんですか? - エンジニア副業Night #1
せっかくエンジニアやってるのになんで副業やらないんですか? - エンジニア副業Night #1
いまさらですが IAってなんだろう
いまさらですが IAってなんだろう
More from Hiroshi Ogino
Slides at @trbmeetup https://trbmeetup.doorkeeper.jp/events/73198
Designing Practical RESTful APIs
Designing Practical RESTful APIs
Hiroshi Ogino
Remotework journey EHIME リモートワークを語る座談会 https://remoteworks-journey.doorkeeper.jp/events/38187
ハートレイルズ流リモートワークのご紹介
ハートレイルズ流リモートワークのご紹介
Hiroshi Ogino
2014/06/14 プロ生 松山でLT
レッツゴーゆるふわ.Rb
レッツゴーゆるふわ.Rb
Hiroshi Ogino
JAWS-UG 愛媛キックオフでの発表資料です。
今すぐAWSが使いたくなる話
今すぐAWSが使いたくなる話
Hiroshi Ogino
信頼される仕事
信頼される仕事
Hiroshi Ogino
ビジネスモデルキャンバス素振り会
ビジネスモデルキャンバス素振り会
Hiroshi Ogino
Agile japan 2013 四国サテライト(LT)
Agile japan 2013 四国サテライト(LT)
Hiroshi Ogino
More from Hiroshi Ogino
(7)
Designing Practical RESTful APIs
Designing Practical RESTful APIs
ハートレイルズ流リモートワークのご紹介
ハートレイルズ流リモートワークのご紹介
レッツゴーゆるふわ.Rb
レッツゴーゆるふわ.Rb
今すぐAWSが使いたくなる話
今すぐAWSが使いたくなる話
信頼される仕事
信頼される仕事
ビジネスモデルキャンバス素振り会
ビジネスモデルキャンバス素振り会
Agile japan 2013 四国サテライト(LT)
Agile japan 2013 四国サテライト(LT)
"地方エンジニア" という考え方はすでに終わっている
1.
“地方エンジニア” という 考え方はすでに終わっている 2014年2月1日 株式会社ハートレイルズ 荻野 浩史(@ogin_s57)
2.
自己紹介 ゆるふわ.rb 創設者 Agile459 スタッフ Blog:ITエンジニアとして生きる
3.
アジェンダ 終わりゆく “地方エンジニア” という考え方 “仕事力”
を考える・・・その前に 在宅勤務から学ぶ信頼を得る “仕事力” まとめ
4.
アジェンダ 終わりゆく “地方エンジニア” という考え方 “仕事力”
を考える・・・その前に 在宅勤務から学ぶ信頼を得る “仕事力” まとめ
5.
“地方エンジニア” と聞いて どのような印象を持ちますか?
6.
わたしは何だか違和感を覚えます
7.
なぜ “エンジニア” ではなく “地方エンジニア”
なのか?
8.
“地方” という言葉は “首都圏” との対比で使われている???
9.
※こんなイメージ 首都圏 地方
10.
しばしば語られる 多額のIT予算を持つ企業や官庁が 集中する “首都圏”とそれに従属 する “地方”
の構図
11.
http://diamond.jp/articles/-/46790
12.
首都圏にIT産業が集中すれば 地方からエンジニアはいなく なるのでしょうか?
13.
労働集約的な考え方だとYES
14.
仕事のある場所に 仕事をこなす人がいる
15.
知識集約的な考え方だとNO
16.
仕事に必要な知識・技術を それを持っている人から集める
17.
有用な知識を集約出来るのであれ ば離れた場所であっても問題ない
18.
地方に住む我々は知識集約的な 方向へ歩を進めるべき
19.
それをお膳立てするための 環境も整ってきている
20.
Google Drive Hangouts! お膳立てする環境
21.
様々なクラウドの登場によって 地方⇄首都圏といった物理的な 距離は制約ではなくなりつつある
22.
物理的な距離が制約でなくなると どうなるのか・・・?
23.
物理的な距離を越えてでも 優秀なエンジニアと仕事がしたい という企業が出てきます
24.
つまり日本中のエンジニアが 同じ土俵で能力を競い合う 大海賊時代がやってきます
25.
「オレの財宝か?欲しけ りゃくれてやる。探せ! この世のすべてをそこへ 置いてきた!!」
26.
「オレの財宝か?欲しけ この世のすべてを りゃくれてやる。探せ! この世のすべてをそこへ 手に入れられるかも?www 置いてきた!!」
27.
冗談はさておき・・・
28.
その時代の到来と共に あなたは “地方エンジニア” ではなくなります
29.
ロケーションが離れていても あなたを求めて仕事がやってくる
30.
あなた自身が仕事を 勝ち取ってくるような時代
31.
ワクワクしませんか?
32.
・・・とはいえ不安もあります
33.
そのような時代で生き抜いていく ためには何が必要でしょうか?
34.
わたしはこう思います
35.
技術力はあって当たり前 必要なのは信頼を得る仕事力
36.
仕事力とは・・・?
37.
わたしの在宅勤務事例を通して 信頼を得る仕事力について 一緒に考えてみましょう
38.
アジェンダ 終わりゆく “地方エンジニア” という考え方 “仕事力”
を考える・・・その前に 在宅勤務から学ぶ信頼を得る “仕事力” まとめ
39.
まずはざっくり在宅勤務の 雰囲気をお伝えします
40.
職場
41.
職場(2m×2m)
42.
離れたロケーション
43.
900km
44.
2パターンの仕事のしかた (メリット・デメリットと共に)
45.
顧客 ※1 顧客代理が開発スタッフに仕事を割り当てる ※2 開発スタッフは顧客代理とのみやりとりする 隔週の打ち合わせ 顧客代理 起票 issue単位で作業 開発スタッフ その1.
顧客代理パターン
46.
メリット ・顧客代理がイイ意味で情報を精査出来る ・開発スタッフがやりとりするのは基本的に 顧客代理だけなので気兼ねしない
47.
デメリット ・トラックナンバー1になりがち ・顧客代理がボトルネックになってしまう ・開発スタッフの自主性を生みづらい
48.
隔週の打ち合わせ 管理スタッフ 顧客 ※1 開発スタッフが顧客と直接やりとりする ※2 必要に応じて管理スタッフと相談しながら 進める 開発スタッフ その2.
開発スタッフ主導パターン
49.
メリット ・トラックナンバーを増やせる ・クラウド上に情報を集約出来る ・開発スタッフの自主性を生みやすい
50.
デメリット ・開発スタッフからは顧客の表情が読み取れ ないので思わず失礼なことをしてしまうかも ・開発スタッフの自主性がないと回らない (自らクラウド上の情報を追いかけてプロジェ クト全体の内容を整理したりボトルネックを推 測したりする等のスキルが必要)
51.
アジェンダ 終わりゆく “地方エンジニア” という考え方 “仕事力”
を考える・・・その前に 在宅勤務から学ぶ信頼を得る “仕事力” まとめ
52.
在宅勤務で出来ること
53.
密接な対話
54.
飲みニケーション
55.
ソフトウェア開発
56.
在宅勤務で出来ること 密接な対話 飲みニケーション ソフトウェア開発 ➡対話や飲みではなく開発(仕事)を 通して信頼関係を築く
57.
在宅勤務で出来ること 問. 密接な対話 どうすれば開発(仕事)を通 飲みニケーション して信頼関係を築けるか? ソフトウェア開発 ➡対話や飲みではなく開発(仕事)を 通して信頼関係を築く
58.
在宅勤務で出来ること 答. 密接な対話 飲みニケーション 信頼される仕事をする ソフトウェア開発 ➡対話や飲みではなく開発(仕事)を 通して信頼関係を築く
59.
信頼される仕事をするために 大きく3つ重要なことがあります
60.
(その1) 成果にコミットする
61.
成果とは?
62.
このシステムのおかげで 請求書管理がとっても楽 になった 製造 成果 利用者A エンジニア ちょっとUIが分かりづら 利用者B くて使いづらいんだよ な∼
63.
このシステムのおかげで 請求書管理がとっても楽 になった 製造 成果 利用者A エンジニア ちょっとUIが分かりづら 利用者B くて使いづらいんだよ な∼
64.
利用者にとっては重要なのは 「ソフトウェアで自分の問題を解 決出来るか?」であり、それが どんなテクノロジーで実現されて いるかは全く重要ではない
65.
どうやってソフトウェアを製造す るか?ではなく、ソフトウェアを 通してどのような価値を利用者に 提供するか?にコミットする
66.
(その2) トレードオフを考える
67.
価値を提供するスピードと技術 的負債のトレードオフを考える
68.
エンジニアとしては技術的負債を 抱えないために拡張性の高い 無駄のないコードとしたい
69.
でも利用者は待ってくれない ソフトウェアを早く届けることは それだけで価値がある
70.
早く届けることも技術的負債を 残さないこともどちらも大事 ちょうど良い着地点を見つける
71.
(その3) 毎日成果を出す
72.
在宅勤務で1番避けるべき状態は 「何をやっているか分からない」 という状態
73.
作業している姿が見えないので 「今日は1日xxxの調査をしてました」 は通用しづらい
74.
だってホントにやってたか どうか分からないでしょ?w
75.
だから信頼される仕事をする ためには毎日少しずつでいいから 成果を出すことが大事なのです
76.
そのために・・・ 1つの仕事を「2時間∼1日」 単位に分割する
77.
利用者に価値が届けられる最小の 粒度かそれよりもう少し大きな 粒度で分割する ・帳票登録できること ・帳票出力できること ・etc...
78.
分割することで小さな価値を 毎日届けることが出来る
79.
アジェンダ 終わりゆく “地方エンジニア” という考え方 “仕事力”
を考える・・・その前に 在宅勤務から学ぶ信頼を得る「仕事力」 まとめ
80.
仕事力とは・・・?
81.
仕事を通して小さな信頼を積み 重ねていく我慢強さを持つこと
82.
成果にコミットし、小さな 成果を出し続けていくこと
83.
・・・だとわたしは思います
84.
あなたの答えは出そうですか?
85.
本日は “地方エンジニア” というものが終わりゆく時代が やってくるという話をしました
86.
ただし! 誰にでも等しくその時代が 到来することはないでしょう
87.
あなたが望めばその時代は きっと到来するでしょう
88.
あなたが望まなければその時代は きっと到来しないでしょう
89.
あなたはその時代の到来を 望みますか? 望みませんか?
90.
もしあなたが新しい時代の 到来を望んだ時、今日の話を ほんの少し活かしてもらえれば 嬉しく思います
91.
共に大海賊時代を懸命に 生き抜いていきましょう
92.
「お前がどこの誰だろうとおれはお前を越えていく」
93.
やっぱり訂正。 1番大事なのは仕事力じゃなくて どんなことがあっても生き抜こう とする信念と志だと思います
94.
ご清聴ありがとう ございました
Download now