機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書き残しています。

[2019/5/21(火)]JAWS-UG横浜 #16 DevOps へ参加してきました

先月に続きJAWS-UGイベントに参加してきました。

今回参加させてもらったJAWS-UGイベントは下記です。

jawsug-yokohama.connpass.com

https://s3-ap-northeast-1.amazonaws.com/img.jawsug-yokohama.connpass.com/jawsug_yokohama3.jpg

前回と同様に講演を聞きながら自分用メモとして書き留めた内容なので、意味不明な点もありますが、ご容赦ください。

プレゼン内容(とメモ)

会場は横浜の馬車道駅側のアトラシアンさんです。今回のテーマは DevOps でした。

入場時にビールを渡されて、乾杯で開会する勉強会は初めてだったので少し驚きましたw

発表者 内容(とメモ)
アトラシアン 皆川さん
DevOpsとITSMはマブダチになれるか??

f:id:orinbou:20190521191900j:plain

ITサービス管理(ITSM)
AtlassianSummit2019の話
2008 Agile Infrastructureがルーツ
ITIL資格保有者は年配者が多し
変更:トランクベースの開発?
ITIL3まではフットワークが重い
ITIL4はルールよりPFを重視する
→よりAgile的な考えになってきた
→原則がAgile宣言に酷似
DevOps3つの道(原則)
DevOpsは自動化そのものではない!
天文学が望遠鏡そのものではないように(※目的と手段のはなし)
JBアドテク 新居田さん
CircleCIとEKSによるCI/CD環境
3つの視点(人:文化、プロセス、ツール)
circleCIは同じこと何度もやらない仕組(context)
Orbs:CircleCIの定義をまとめたパッケージ
GitOps:k8の状態=Gitの状態
kubediff
kubectl apply -f ./ -R
tfnortify:Terraformフォーム結果を良感じで通知するOSS

CircleCIとEKSをはじめよう!(終了メッセージ)

f:id:orinbou:20190521192713j:plain

F-Secure 河野さん
DevSecOps と Cloud Security
~継続的な脆弱性診断とセキュリティ運用・監視のベストプラクティス~
4種類Scan統合(読み方:レーダー)
CentOS(セントス)
IDS(internetDiscoveryScan)
海外事例:50000インスタンス、10000診断/週
→継続的なセキュリティ診断とパッチ適用
API連携による継続的な脆弱性診断(エージェントレス)
f:id:orinbou:20190521193447j:plain
アクロ 石田さん
AWS Amplify Consoleを使うと
本当に幸せになれるか?
↓(※タイトル変更)
開発者がCI/CDを通して幸せになれるか?
開発プロセススクラムです。
静的ページのUpならお手軽(微妙)
→圧倒的なCD感。無理ゲー(※やる気はある)
やれそうな感覚を持たせる(心理的安全)
一本通ってるサンプルがある(超重要)
→ワンパス・サンプルだいじ
SPAサンプル(Amplify Consoleでビルドできる)
f:id:orinbou:20190521200147j:plain
* フロントエンドのシナリオテストはKarate
* バックエンドのテストはPythonのunittest
→不安を取り除く。長期的な文化の醸造
→CI/CDでhappyDevelopment
タグバン 佐々木さん
佐々木さんとこのDevOps

f:id:orinbou:20190521201033j:plain

Springの人、主なデプロイ先はAWSJAWS横浜初登壇
Jira→BitBucketリポジトリ作成→SonarQube→Bamboo(ビルドツール)→Beanstalk
ログを監視し、例外発生時にJiraにタスクを自動生成する
AWS SAMで利用者を管理、CWL?
DLQ(デッドレターキュー)ソース設定をする
クラメソ 大栗さん
AWSのプロDevOpserへの道

f:id:orinbou:20190521201724j:plain

みらい翻訳(Google翻訳より精度が高いらしい)
試験に合格したかったら、(WP全部は長いから無理)
DevOps系サービスのチュートリアルは全部読め!
試験対策は何を問われているのかちゃんと見極める。

f:id:orinbou:20190521202906j:plain

必要十分条件でOK。過剰はNG。

サイダス 小深田さん
AWS認定DevOpsエンジニア・プロに体当たりチャレンジしてきた!

speakerdeck.com

DevOpsエンジニア・プロフェッショナル本日受験
750/1000が合格ライン目安、今年2月に問題が改定された
やったこと:模擬試験40$で20問、Udemy(英語)、AWSレーニングSample
f:id:orinbou:20190521204531j:plain
新サービスの概要も出題されるので注意(メイシー、ラムダエッジ、ドューティーなど)
→本日は残念ながら不合格だったが手応えはあった!
※参考:試験会場は歌舞伎座がお勧め
Nソリュ社 好光さん
PF-SIの現場でクラウドネイティブなDevOpsを進めるためのあれこれ

f:id:orinbou:20190521205141j:plain

エンジニアのパフォーマンスを最大化させてビジネスニーズに迅速に答えるための活動(なんでもアリ)
DevOps化大作戦#1~5
1:トップダウン(偉い人に頼る)立上はスムーズ
2:ボトムアップ(現場で頑張る系)マスク面倒、手間重
3:ツール活用(AWSマネジドツール、OSS活用)
4:テンプレ・ガイドの整理(最近化メンテが必須)
5:事前体験ハンズオン教育プログラム
カルチャ、ツール・プロセス、人材
→DevOpsレディにする
※5/24(金)SecJAWS13回@トレンドマイクロ(ほぼ満席)
Michael H. Oshitaさん(I am devops)
My DevOps toolsets

speakerdeck.com

f:id:orinbou:20190521210158j:plain

Terraform(Infrastructure as Code)
teraform workspace list
default
production
* staging
みたいな感じのコマンド。。。
モジュール化して、共通化部分を作成。環境は変数化する
→DRYな感じでインフラ・コードを書ける
f:id:orinbou:20190521210439j:plain
秘密情報はSSMで管理する。
CircleCI(他のツールは見にくいのでこれを使用)
【例】:CircleCI→Terraform(成功/失敗の通知)
ECSサービスの待ち時間が長いのでStep Fncsを使っている
サイダス 吉田さん
サーバーレス x DevOps

f:id:orinbou:20190521211725j:plain

役割が変化していく中で、DevとOpsをデカップル(連動)してチャレンジしていく

f:id:orinbou:20190521212046j:plain
※常時コアメンバを募集中だそうです。

今回は会場を提供してくれたアトラシアンさんTシャツをいただきました!

JAWS横浜さん、アトラシアンさん、皆様どうもありがとうございました。

また、F-Secureさん差し入れのドリンク(ビール&お茶)ご馳走様でした。

イベント後の懇親会では、新しい出会いもありました。是非また参加させてください。

f:id:orinbou:20190525235837j:plain

【補足】本ブログ内で参照しているスライドは下記URLで公開されているものです。

 https://jawsug-yokohama.connpass.com/event/125095/presentation/

 

[2019/4/20(土)]JAWS-UG さいたま支部 第11回勉強会〜re:Invent 2018 re:Cap & AWSフリープレゼン〜へ参加してきました

以前から参加してみたかったJAWS-UGイベントに参加してきました。思えば、数年前「JAWS-UG 中央線」にエントリしてみたものの、仕事の都合で参加できませんできした。結局JAWS-UGへの参加はそれっきりしないままになっていたのですが、数年越しのリベンジ参加となりました。

今回参加させてもらったJAWS-UGイベントは下記です。

jawsug-saitama.doorkeeper.jp

最初、このイベントを薦めれられた時、正直「え!さいたま。遠っ…」って思ったのですが、今回は初の都内開催とのことでした。場所は大崎駅から歩いてすぐのコムチュアさんの会議室で開催されました。

 

以下コンテンツですが、講演聞きながら自分用メモとして書き留めた内容ほぼそのままなので、イミフな点も多々ありますが、何卒ご容赦ください。

 

プレゼン内容(のメモ)

今回のテーマは
re:Invent 2018 re:Cap & AWSフリーテーマとのことでした。

f:id:orinbou:20190423020439p:plain

発表者 テーマ 内容(ざっくりメモ)
浅野さん AWS AWSアップデート情報と活用例(仮)

# JAWS-UGさいたま支部について

* さいたま支部は、初心者向けとして結成された。
(つまり初心者もWelcome!ってことかな?
# 気になる最近のアップデート
JavaSE標準を満たすと認定されているCorrettoがGAになった。(Java8,11)
AWS Backup(EC2静止点を見ないので注意)※東京まだ!
* WorkLink(セキュアなモバイルアプリ接続アクセス)※東京まだ!
* 格安Glacier Deep Archive Storage Classが全リージョンで使える
* QuickSight ML Insight(MLベースの解析、分析)
* サービスメッシュを実現するAppMesh(コンテナ系)※東京OK!
* RDS Performance Insight(対応DB種類が増えた)
* Neptune, M5a, FSx for Lustre/Windows File Srv東京OK!
* Amplify Console, Cloud9 ※4月に東京でも使えるようになる!
* その他(NLB、ALBパワーUp、DCGWマルチアカ、GluePython) 
# 事例紹介
* スマート宅配ポスト(IoT系マイクロサービス)※よくできてる
* 住信SBIでAuroraポスグレ10採用でランニングコスト83%ダウン
* ググりキーワード「AWS 資料」
古渡さん   KMSについて考えてみよう

コンテナを使って開発してみた話
# ゲーム会社でSNSアプリ開発でコンテナを使おうとした件
* DockerでAuroraに似せた開発環境構築(Read:endppint, Write:endppintを分ける)が大変
* Amazon ECRにベースとなるイメージを置く
* コンテナ利用はキャッシュ制御をうまく使わないと処理時間がかかる
* B/Gデプロイはやめて、時系列の名前でやらないと混乱して辛い(特に週末リリースした後の月曜の朝)
* インフラ構築はterraformを使ったが、今はCloudFormationがオススメ
 日本ユニシス 会澤さん  AWSkubernetesことはじめ
# 自社サービスビジネス立ち上げ支援が生業
* Ops-JAWSにぜひご参加ください(今年まだ未開催。都内運営募集)
* クーベネティス→Kubernetes(クーベルネイテス) 読み方いろいろWP
* Docker composeが便利
* 様々なコンテナオーケストレーション→勝者Kubernetes(デファスタ)
* kubectl(キューブコントロール?)コマンドで操作
* ECS / EKS(コントロールプレーン、データプレーン)
* ECS:AWSデータプレーン(EC2、Fargate)
* EKS:AWSデータプレーン(EC2のみ、Fargateまだ)
* どっちを使えばいいのか?(別途議論したい)
* EKSの特徴(VPC統合、IAM認証:aws-iam-authenticator)
* AWSクラスタGCPやAzureと違って起動中ずっと課金されてしまう(割高感が半端ない)
渥美さん

AWSフリーテーマ 

世界でたぶん最も遅いre:Invent 2018 reCap

~きっと後世まで語られる味わい深い新サービス

日本のデジタル国家戦略はクラウドが支える

~2019 政府CIO補佐官がすごいことになっている

f:id:orinbou:20190423013943j:plain# re:invent 2018 ふりかえり
* re:invent 2012 の衝撃(顧客の「ITの不自由」を、毎年、着実に解決)
* 2018年(キーワード:Developer→Builder)
* 個人着目新サービス1(Ground Station)※人工衛星を管理する地上局のマネージド・サービス←今後、航空宇宙ビジネスは民間が中心になる
* 個人着目新サービス2(Inferentia)機械学習の推論チップ
Amazonが、世界のITを牽引したチップ開発社になった。
* 個人着目新サービス3(QLDB)フルマネージドな元帳DB
ブロックチェーンで使用するような改竄不可DB
* 個人着目新サービス4(DeepRacer)強化学習のためのRCカー
→子供向けのおもちゃではない。深層学習エンジニアの為のマジ教材 。日本に40, 50台(※内20台がクラメソ)
* Amazon GOでのかつてない購買体験(アプリ利用でキャッシュレス)
* 2019年政府CIO補佐官がすごい(クラウド・バイ・デフォルト)
→いよいよクラウドが日本の国策になる!

(6月の国会で法律が変わる)

* IT担当大臣:平井拓也(AWSサミット2017登壇者)
→助人:元MS砂金(いさご)、元MSエバ鈴木章太郎、元SN銀大久保光伸
→国家創造戦略(日本国策)←デジタル3原則←クラウド
* Amazon配送センターのオートメーションは実は三菱電機
f:id:orinbou:20190423015240j:plain
※個人的には、この日イチ盛り上がりだったセッション。スピーカーの情熱が皆にも伝わっていた気がします。

深堀さん 

 AWS EC2/AutoScalingGroupについて
# オートスケーリングを使おう!
* リザーブインスタンス買うのメンドイ(見積もり、稟議も。。)
→技術でコストダウンできる
* 日常の安定運用における負荷を下げたい(耐障害性も上げたい)
→オートスケーリングを活用(フィジカル、メンタルな負担を低減)
* スパイクに備えた暖気申請(Pre-Warming)ができる(知らんかた)
* RDSのリーダーのオートスケーリングのメリットは何だっけ?
* 今時のスポットインスタンス(何か怖い。突然止まるんじゃない?)
→だいぶ改善されているので、本番で活用していきたい(らしい)
* ヘルスチェックが死亡判定(負のループ)
→ビルド&デプロイに失敗しEC2がどんどん減っていく(異常系重要)
* まとめ(新規はオートスケーリング積極活用。手を動かして慣れる)
 

乾杯!〜懇親会〜

re:Invent 2018 お土産プレゼント 

f:id:orinbou:20190423011711j:plain

JAWSでお土産たくさんいただきました!この他に(nginxの)Tシャツなども。ビアバッシュも楽しかったし、至れり尽くせりの会でした。JAWSさいたまさん、コムチュアさん、渥美さん、皆様どうもありがとうございました。

 

都内で開催の折は、是非また参加させてください。

さいたま開催の折は、、、考えときます(汗

 

Linuxサーバのプロンプトのカスタマイズ

複数のLinuxサーバへSSHリモート接続して、複数コンソールを同時に立ち上げていると、今どのサーバに対してコマンド打ってるか間違えそうになるので、サーバ毎にプロンプトを少しだけカスタマイズした。本当はリモート接続ツールから変えたかったけど、沢山のTelnetショートカット(.ttl)が既に存在してて、プロジェクトメンバがそれに慣れてたので、、、

 

やったこと

bash設定ファイルをエディタで開いてファイルの最後に下記(変数:PS1)を追記しただけ。

 > vi ~/.bashrc

-------------------------------

# for MyProject
export PS1="[\u@\[\e[32m\]WEB_AP\[\e[0m\] \w]\$ "

-------------------------------

これで、次回のSSHリモート接続後から、プロンプトにサーバ名(例:WEB_AP)が緑色文字(\[\e[32m\])で表示されます。

f:id:orinbou:20190114120655p:plain

 

ちなみに変更前(デフォルト)の設定は下記のとおり。

> echo "$PS1"

-------------------------------

PS1="[\u@\h \W]\$"

 -------------------------------

 追記した内容を削除すると元に戻ります。

f:id:orinbou:20190114121124p:plain

サーバ毎に、分かりやすい名前を付けてあげれば、リモート接続中に、自分がどのサーバに対して操作しているのか分かるので、事故を防ぐための最低限の事故を防ぐための予防として、とりあえず、、、

 

<参考URL>

* http://www.rem-system.com/apache-security01/#http_TRACE

https://qiita.com/katsukii/items/da37d1fdf974bd0e4c2f

https://qiita.com/hmmrjn/items/60d2a64c9e5bf7c0fe60

何となく2018年をふりかえってみる

今日書かないと2018年の投稿が0件になってしまうので何か書いておこうと思う。

という訳で、本年の最終日ということもあり今年を振り返って思うことをつらつらと書いてみることにする。

 

昨年末から今年の夏くらいまで、とあるプロジェクトの開発リーダーを担当し、特に今年前半はなかなか多忙な日々を過ごした。なんとかリリース&サービスインに漕ぎつけ、結果としては、

  • Spring Boot
  • AWS(SQS、SES、RDS、CodeDeployなど)
  • Ansible

など、新しいものに触れる機会にもなった。途中いろいろな問題に直面したけど、人や機会にも恵まれ何とか乗り切ることができたのは幸運だったと思う。

 

その後、また別のプロジェクトにアサインされ、ベトナムとのオフショア開発を行うことになった。オフショア開発は初めてで分からないことだらけだったが、同じチームに経験者がいたことと、10月にベトナムを訪問させてもらったことで、互いの顔も分かり少しずつコミュニケーションが取りやすくなり、後半押し寄せたフェーズ毎の納品の対応もベトナムチームと日本チームの共同作業でなんとか乗り切ることができた。相互のコミュニケーションがスピードや品質のネックだったが、なんとか乗り越えることができたと思う。まだ改善の余地が山程あるので、今後も継続した施策が必要だと思うのでこれまで以上に精進したい。

 

全体的な総括としては、担当プロジェクトに全力投球し過ぎて、日々の業務のその先を見る、中長期的な目線を持って働くことが全然できていなかったなと少し反省している。きっと来年もきっとそこそこ忙しい日々が続くと思うけど、単に日々を何とか乗り切る…だけでなく、少し先を見据えた働き方をしていきたい。

 

あと、来年は「AWS 認定ソリューションアーキテクト – プロフェッショナル」取りたい。今年はいろいろあって受験すらしなかったので…

 

それでは今年もお世話になりました。それでは良いお年を…

AWS 認定ソリューションアーキテクト – アソシエイト(SAA)を取得しました

先日 12/24(日)に AWS 認定ソリューションアーキテクト – アソシエイト を取得(1回目:12/3不合格、2回目:12/24合格)しました。

認定を取得するまでに個人的に何点かハマったところがあったので、メモしておきます。何かの役に立てば幸いです。

AWS認定とは?

あまり説明する必要もないかもしれませんが、ざっくり言うとAWS(Amazon)が公式に認定するベンダー資格です。大きくは2つのレベル(アソシエイトとプロフェッショナル)に分かれていてプロフェッショナルのレベルは、アソシエイトを取得した人しか受験できません。

  • アソシエイト(基礎レベル)
  • プロフェッショナル (応用レベル)
    • ソリューションアーキテクト(SAP)
    • DevOps エンジニア(DOP)

また、プロフェッショナルとは別に専門知識というカテゴリも用意されていて、こちらもアソシエイトを取得した人しか受験できません。

  • 専門知識(※英語のみで受験可能:2017/12/31時点)

 

 詳細は以下の公式ページに記載されています。

aws.amazon.com

 

APNパートナー認定とは?(AWS認定との違い)

AWS認定と混同してしまいそうなのがコチラです。APN(AWSパートナーネットワーク)の認定です。例えば自社がAPNに参加しているパートナー企業の場合は、下記の認定についての学習と取得を個人的な負担なしで受けることができます。

  • APNパートナー認定
    • ビジネスプロフェッショナル
    • テクニカルプロフェッショナル
    • TCO and Cloud Economics

公式のAWS認定についての情報はよく見かけるのですが、こちらのAWSパートナー認定の情報はまだそれほど多くない気がします。少なくとも私は最初区別がつかずに混乱したのでメモとして書いておきます。

 

APN(AWSパートナーネットワーク)とAPNパートナー認定についての詳細は以下の公式ページに記載されています。

ちなみに APNパートナー認定は、制限なく無償で何度でもチャレンジできるので、有償のAWS認定試験を受験する前の基礎知識を学ぶのに役立ちます(後述)。可能な場合は、APNポータルへログインして活用すると良いかと思います。

 

AWS試験対策

試験対策については、様々なサイトやBlogでいろいろと公開されているようでググればいっぱい出てくるので、ここでは取得までに実践した内容を簡単に記載しておきます。

  • APNパートナー認定を取得定
    • 前述のAPNパートナー認定(3つ)のオンライントレーニングを実施して修了認定を取得しました。オンライン学習は、音声付きのスライドが用意されているので、なかなか快適に学べます。これでAWSについて広く浅く学ぶことができました。
  • 公式サンプル問題集(※10問のみ)
    • AWS認定試験の公式サイトからサンプル問題集をダウンロードできます。但し10問しかないので、どのようなレベルの問題が出題されるのかを確認する程度にしか使えません。
  • 合格対策 AWS認定ソリューションアーキテクト - アソシエイト
    • 数少ない合格対策本です。この本はAWSの基本的な知識を広く学ぶことができるので、全体を通して何回か(※最低でも2回くらいは)読み込んむと良いかと。ただし、本に掲載されている演習問題は、本試験よりもかなり簡単な内容で、かつ数も少ないので問題集としてはあまり使えません。また、本の内容が多少古いので最新のAWSサービスの情報を別途チェックする必要があります。

      books.rakuten.co.jp

  • 模擬試験(※有償:¥2000 yen)
    • AWS認定の模擬試験をオンラインで受けることができます。本試験と同じような画面レイアウト(時間制限なども本番に近い)で体験できるので、特に一度もAWS認定試験を受けたことがない場合は、一度はやっておくと良いと思います。ちなみに、AWSでは、試験問題の流出をかなり厳密に管理しているため、試験後に模擬試験の問題を見返して復習することはできませんのでご注意を!
  • AWS WEB問題集で学習しよう(※有償)
    • オリジナルのAWS認定試験対策問題集を有償で公開しています。公式の問題集がないので、こちらを利用しました。無料で26問が利用できますが、たぶんそれだと足りないので、有償プランの利用が現実的かな。問題の解説もあるので単に解くだけでなく、疑問に思った点を理解するのにも役立ちます。AWSホワイトペーパーへのリンクも掲載してくれていたりするので、最新の情報へも比較的シームレスにアクセスして確認できます。

      aws.koiwaclub.com

  • AWS Black Belt Online Seminar

 

本試験は差をつけるためか結構いやらしい問題(ひっかけとか)も出題されるので、しっかりと準備をしないと散財しまくる可能性もありますのでご注意を!!!

 

本試験は少しですが英語のチャットで会話したり、試験前にリモートで2種類の身分証(うち1つは写真付きの必要アリ)を提示したりと、試験以外にも気を使う点があるので、何度も受験するのはお金以外の面でもいろいろと面倒だと思います。なので、本試験前に書籍をはじめ有償サービスに投資して対策するのはアリかと。あと、AWSが推奨している公認のセミナーの「AWS Technical Essentials」や「Architecting on AWS」は有効なのでしょうが、とてもお高いセミナーです。会社から補助などが出るなら考えてみても良いと思うのですが、個人での負担は厳しいと思います(人にもよるけど)。

 

とりあえず目標だった年内にギリギリ取得できて良かったです。たまたまクリスマスに受験して合格してなんとなくスペシャルな気分にもなれましたし(笑

 f:id:orinbou:20171231054042p:plain

 

それでは今年もお世話になりました。それでは良いお年を…

 

ソフトウェアの材料は何か?

先日とある飲み会で「ソフトウェアの材料」というテーマで話をする機会があった。あまり深く考えたことがなかったけど、もともと大学の研究室が材料力学を専門にしていたこともあり、何だかおもしろいぞって思った。

 

例えば、自動車を製造しようと思えば、それを構成する多数の部品が必要になる。それぞれの部品は様々な材質の材料からできている。そして、それぞれの材料の材質は、その用途に適合した特性を持っている。

 

例えば金属部品のボルトを考えてみる。ボルトが純粋な鉄でつくられていることはなく、合金として、何種類もの金属や物質を混ぜ合わせてつくられている。混ぜ合わせる物質によって合金の特性が決まる。物質は分子でできていて、分子は原子が組み合わさってできている。原子は、陽子と電子と中性子でできていて、陽子と中性子クォークという基本粒子でできてる(らしい)。

 

そんなことを考えつつ「ソフトウェアの材料」について考えてみる。

 

自動車と同じように、ソフトウェアの部品というものを考えてみると、やはり、それを構成する多数の部品が必要になる。

 

例えばボタンという部品を考えてみる。ボタンはソフトウェアを構成する部品であり、それはやはり何種類もの材質でできてる。画像や文字や動作(マウスアクション)などで構成されている。それによって特性が決まる。そして、それらの材質は、動くプログラムだったり静的な素材だったりするけど、結局のところは【0 or 1】のbitの組み合わせでしかない。このbitが、ボルトの場合でいうことろのクォークみたいなもんかな?

 

そう考えると、材料っていう意味では非常に似ている。

 

じゃ、どんな違いがあるのか考えてみる。

 

【0 or 1】のbitは、クォークみたいに、物理的にこの世界に存在するものではなく、コンピュータの中に存在する信号でしかない。そして、コンピュータの基板を流れる時は電気信号、光ケーブル内を通過するときは光、無線通信の場合は電磁波などに姿を変化させて世界中を飛び回ることができる。飛び回ることができるのは、今ではインターネットというものが世界中に張り巡らされているからだけど。

 

物理的な存在ではない。もともとこの世界になかったもの。人が作り出したもの。

 

そんなこと考えてたら、とある人が言った。

 

「ソフトウェアの材料は(人の)想像力ですよね。」

 

確かに。コンピュータもそこから産まれたんですもんね。

今までも、これからもきっとそうなんだろうな…と思いつつ。

最近、目先の仕事にかまけて、あんまり想像(妄想)してないなって

 

久々に、アカデミックで楽しい飲み会でした。

こういう機会を増やさないと、ですね。

 

【2017.11.04 追加】

この日の思い出になったワイン「ロバートソン ピノ・ノワール2015」の写真をUP。

f:id:orinbou:20171104103434j:plain

[2016/9/24(土)]“俺たちの!!” XP祭り2016へ参加してきました

昨年は諸事情により参加できなかったXP祭りでしたが、今年は参加できました。

午後からの参加となったため、午前の牛尾さんの基調講演を聞くことができなくて残念でしたが、早々にスライドをUPしていただけたようなので、後程じっくりと堪能したいと思います。

 

私が最初に参加したのは、まずビブリオバトルですね。ビブリオバトルって何?って思う人もいるかと思いますので、軽く説明しておくと、ひとり5分間で自分のオススメ本をプレゼンしていき、観客(プレゼンの聞き手)の投票により、一番読みたくなった本(チャンプ本)を決めるコンペ形式のプレゼンバトルですね。私も初体験でしたが、なかなかいい感じのユルさで楽しめました。結構多くの挑戦者が入れ替わり立ち替わり参加していたので、最後まで聞けませんでしたが、今度自分もプレゼンター側で参加してみたいなと思いました。本を選ぶとするとやはり「アジャイルプラクティス」かなw

 

次は、

XP祭り2016:普通のチームメンバーがリーダーになってやったこと(三浦 伸明さん)

speakerdeck.com

経験値のあるメンバーが次々と離脱する過酷な状況の中、何の事前説明もなく突然リーダーを任された三浦さんが試行錯誤しながらチームを立て直すお話でした。本人曰く、特別なことはしていない。当たり前のことを当たり前に続けただけということでしたが、そこがキモなんだと思います。プラクティスって、すぐに試せたりするんですけど、チーム全体が効果を実感できるようになるまで続けることって、なかなか難しいことだと思います。平時でもそうなんです。これをメンバーの離脱が相次ぐ非常時に続けていくのは、小手先のテクニックでなくて、積み重ねてきた経験や信念のようなものがないと難しいことなんじゃないかと思います。

 

次は、

XP祭り2016:エンタープライズアジャイルへの挑戦と苦悩(森實 繁樹さん)

アジャイルマニフェストは、単にソフトウェア開発の開発の経典ではなく、ビジネスの経典として読んでも実にしっくりくる内容であるという話はとても興味深かったです。私もソフトウェア開発を生業にしていますが、アジャイルについて学んだことは、単に開発だけでなく、社内インフラの運用や情報セキュリティへの対応といった社内の通常業務を遂行する際、おおいに役立っています。これはアジャイルの根の部分である、このマニフェストが言わんとしていることが、ビジネスにおいて共通に大切すべきことを含んでいるからなのかもしれません。また、現場レベルだけでなく顧客の経営層が理解できる価値を創造することをテーマにして、1年(12ヶ月)を4分割した3ヶ月単位の開発クールに分けて、各クールで開発した価値を評価しながら、次クールの開発項目を調整するという進め方を実践して成果が得られたという内容は、なかなか興味深いものがありますね。上記スライドの中でも触れられていますが、今年のAgileJapan2016鈴木雄介氏が発表していた「アジャイルと言わないエンタープライズアジャイル導入」とも少し似ているなぁ…と思いながら、エンタープライズアジャイルという漠然とした考え方の中の、ひとつのプラクティスになるかも…と感じました。

 

次は、

XP祭り2016:巷にはびこる間違ったUX論へのヘイトをぶつける集い(滝川陽一さん)

f:id:orinbou:20160924145956j:plain

スライドは大人の事情でたぶんUPされないと思うので、撮影した写真をUPしときますね。私自身UX(User Experience)について正しい知識がなかったことを痛感しました。UXは「ユーザー体験」なので思った以上に広い領域であって、よく略語が似ているという理由からかUI(User Interface)などとごっちゃにされてしまいがちです。それがひとり歩きしてしまったことで、様々なヘイト(憎しみ)が生まれてしまったのかな?UXを専門に学んだ人からすると、許しがたいものもあるようで、全員が正しく理解するのは無理としても、もう少し多くの人が正しい認識を持たないと、この先もっとヘイトが溜まってしまうかもしれません。結構まじめに学術的な話も多く、ここで一言でUXやUXデザインについて語ることは難しいのですが、UXは「User Experience」であって「User eXtreme Interface」のことではないので、決して「すごいUI」のことではありません。これだけは覚えておいてください。スライド中でも紹介されていたUIとUXの違いについては、

『UIってUXのスゴイ版なの?』- わだちゃんが聞くよ! by インターリンク株式会社

を見ていただければ10秒くらいで分かるかなと思います。

 

次は、

XP祭り2016:国際会議 Agile 2016の風 – とある参加報告 -(伊藤 宏幸さん、川口 恭伸さん 、竹葉 美沙さん)

印象に残ったのは伊藤さんと竹葉さんの報告にあった「Blameless Culture(非難されない文化)」という言葉ですね。

f:id:orinbou:20160924161956j:plain

知り合いを含め、会場の多くの人も、(ツイッターでも?)「そうだよね~」っていう空気になっていたように思います(※あくまで個人の感想です)。チャレンジを謳いながら、失敗した時、問題でなく人をしこたま非難するという状況では、なかなかチャレンジし続ける文化は醸造され難くなります。もちろん、全く無責任で良いということではありませんが、問題が発生した時、真っ先に人を攻めるのではなく、まず問題と向き合うという文化で働けたら幸せですね。

 

最後は恒例の XP祭り2016:LT祭り ですね。

大いに笑い、そして、学ばせてもらいましたが、数が多すぎてここでは語りきれませんので割愛します。スンマセン…^^; 聞いてたらまた自分もLTやりたくなってきました。

 

そんな事を感じた今年のXP祭りでした。日常の溜まった疲れ(たぶんメンタルなやつ)が取れた気がします。デトックス効果抜群ですね。今年も癒しをどうもありがとうございまた。

 

<追伸>

LTに参加していた永和システムマネジメント木下さんに、たまたま持参していた愛読書アジャイルプラクティスにサインいただきました。

f:id:orinbou:20160925162258p:plain

どうもありがとうございます(^^)