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

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

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

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

Agile Japan 2016 公認レポーターとして記事を書きました

f:id:orinbou:20160531093650j:plain

だいぶ時間が経ってしまいましたが、今年始めて AgileJapan2016 (5/31開催)に参加してきました。初参加ながら縁あって公認レポーターをお願いされ記事を書くことになりました。

現在までに4本の記事を執筆しましたが、ありがたいことに全て掲載していただきました。

素人の拙い文章なので、読み手に内容がしっかりと伝わるか不安なところではありますが、興味のある人に読んでいただき、当日の雰囲気が少しでも伝わると嬉しいです。

 

■マイレポート#1

www.manaslink.com

■マイレポート#2 

www.manaslink.com

■マイレポート#3

www.manaslink.com

■マイレポート#4 

www.manaslink.com

 

今回、記事を書いてみて、気ままに好きに書き綴るブログと違い、文章の組み立てを考えながら、ある程度指定された文字数で文章をまとめ上げるということを経験しましたが、思いのほか大変な作業でした。マナスリンクの編集の方には編集・校正で大変助けれられました。ありがとうございます。普段、新聞や雑誌などの記事を何気なくサラッと読んでいましたが、文章を生業にしている方々のスゴさを改めて感じました。

 

今回、公認レポーターの声をかけてくれた友人、私の書いた記事の編集・校正をしてくれたマナスリンク編集部の方々、査読に協力してくれた職場の後輩、記事を読んでくれた皆さまに感謝です。

 

余裕があればもう一本くらい記事を書くかもしれませんが、ひとまず私の中での〆としたいと思います。

HTTP TRACE / TRACK Methodsの無効化を確認する方法

先日Apache脆弱性チェックで指摘された設定を無効化した際に、設定変更が本当に適用されているのか確認する方法が分からなかったので調べました。 なんか、まぁ、今更なヤツですがここにもメモしておこうと思います。

TRACE TRACKメソッドの無効化

まず設定変更ですが vi などのテキストエディタApacheの設定ファイル(例:/etc/httpd/conf/httpd.conf )を編集して下記の設定(TraceEnable)を無効(off)にします。有効(on)の場合は無効(off)に、設定が存在しない場合は、設定ファイルに下記を追記します。

 

TraceEnable off

 

次にApacheを再起動して設定変更を反映します。

 

> service httpd restart 

 

これで設定が反映されました。

ここまでは手順書に書いてあったんだけどね…^^;

無効化の確認方法

さて、ここからが今回の本題。

以下の手順でTRACE TRACKメソッドが無効化したことを確認します。

まず必要に応じてtelnetをインストールします。(※未インストールの場合のみ)

 

> yum -y install telnet

 

以下のコマンドで設定変更したApacheへ接続して無効化を確認します。

> telnet localhost 80

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

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

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

ここで入力待ち状態になるので以下のように入力します。

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

OPTIONS / HTTP/1.1(Enterキー)

host: localhost(Enterキー)

(Enterキー)

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

※各行を入力したら(Enterキー)を押して改行することに注意してください!

私はこの無知により15分くらいハマりました。

続いて下記のように表示されます。

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

HTTP/1.1 200 OK

Date: Mon, 22 Aug 2016 18:48:12 GMT

Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS ← ココに TRACE がない!

Content-Length: 0

Connection: close

Content-Type: text/plain; charset=UTF-8

Connection closed by foreign host.

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

上記の許可メソッド一覧(Allow:の部分)に TRACE メソッドが表示されません。

これで設定変更が適用されたことが確認できました。

 

<参考URL>

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

http://www.tohoho-web.com/lng/199909/99090233.htm

http://d.hatena.ne.jp/end0tknr/20131127/1385518307

 

[2016/7/20(水)]『駅すぱあと』のヴァル研究所さんへ大人の社会見学へ行って来ました

夏風邪でダウンしていたので少し時間が経ってしまいましたが『駅すぱあと』のヴァル研究所さんの現場を社会見学させてもらいました。ちなみに大人の社会見学…というタイトルには深い(やらしい)意味はありませんw

f:id:orinbou:20160814020851j:plain

入口ではペッパーくんがお出迎えしてくれました。

アナログボードと付箋で情報共有

まず驚いたのは、とにかく社内にボードが沢山あるということでした。自立式のホワイトボードはもとより、壁の空きスペースにホワイトボードシートを貼り付けて巨大なホワイトボードにしたり、巨大な(1畳くらい?)ダンボールやベニヤ板を置いてホワイトボードにしたりと、使えるものは何でも使っているという感じでした。

手書きした付箋をボードに貼りつけてチームで情報共有を行う「タスクかんばん」は私の現場の開発チームでも使っていますが、現状はあくまでも開発チーム内の情報を共有し見える化、見せる化するにとどまっています。

ヴァル研さんの社内ではざっくり下記のような粒度でアナログボードを使い分けているという印象を受けました。

  • ボード(大):複数チームの半年分のざっくり計画と進捗を共有(リリーストレイン時刻表
  • ボード(中):チームのタスクと進捗を管理(チーム毎にユニーク。複数使い分けるチームも)
  • ボード(小):個人のタスクと進捗を管理(人によってあったりなかったり)

これはウチの現場にも大変参考になります。各チーム間の細かいことまで全部ひとつのボードで管理しようとするとすぐに破綻するし、Redmineのような電子化されたチケットにしてしまうと開発者以外があまり見なかったりして埋もれてしまうことが多々ありましたが、こんなふうに粒度ごとにボードをつくれば共有できるようになるかも…という気付きをいただきました。

開発チームだけでなく、総務や営業もカンバン

次に驚いたのは、開発チームだけでなく、総務や営業といった部署まで前述のアナログボードを使用した情報共有を行っていることでした。それぞれのチームが使っているボードも部署やチームごとに実に多様でした。例えば総務では、年間を通して時期によって定期的な作業があったりするので、定期作業と不定期作業を分けてタスク管理したり、改良したニコニコカレンダーでエモーショナルな領域も含めた問題になるべく早く気付けるよう配慮していました。また、営業では売上や達成率など数値化されたものが多くボードや柱に貼られていました。 社内のカンバンの様子はこちら(↓)で詳しく紹介されています。 

speakerdeck.com

全部門にカンバンが導入された10の理由と活用事例 「駅すぱあと」はカンバンと秘伝のソースでできて... // Speaker Deck

 「カンバン」や「タスクかんばん」というと「TODOーDOINGーDONE」のオーソドックスなものを思い浮かべますが、それだけでは足りなかったり、業務やメンバーに向いていなかったりすることもあると思います。無理に同じやり方をするのではなく、ふりかえりながら自分達が働きやすいやり方を自分達自身で探していくことが大切なんだ…ということに、改めて気付かされた気がしました。

最後に

この日、一緒に見学したメンバーは社内の同じ受託開発チームのメンバーだけでなく、自社サービス開発チーム、普段は客先に常駐して作業している組込系の開発チームからも興味を持って参加してくれたのがとても良かったです。参加してくれたメンバーに感謝です。

また、それ以上に、社会見学をこころよく受け入れてくださったヴァル研究所さんに感謝です。Webサービス監視にベイダー卿XFD(eXtreme Feedback Device)を使用するなど、遊びゴコロ(↓)も大変参考になりました。本当にどうもありがとうございました。

f:id:orinbou:20160814043407j:plain

こちら(↓)に当日の様子をアップしていただきました。

本日も社内見学に来ていただきました。 2時間近く、熱心に色々興味を持っていただきましたー! | Facebook

 

<追伸>

当日参加した自社サービス開発チームのメンバーがヴァル研さんの現場をヒントに、さっそく独自のカンバン的な何かをおっ始めました。やはり何か感じるものがあったようです(^^) これが越境Powerってやつですね。

f:id:orinbou:20160814041240j:plain

社会見学当日に残念ながら業務の都合で来られなかったメンバーやエンジニア以外の人(総務や営業や広報など)を募って、もう一度見学を企画したいな…と思いつつ、自分の現場も社会見学で人が呼べるような会社にしたいな…と感じたのでした。

SEのための契約知識【超】入門

諸事情により少しだけ勉強する機会があったので

知ってそうで意外と知らないIT系システム開発の契約に

関しての基礎的な知識(の一部)をスライドにまとめてみました。

 

★SEのための契約知識【超】入門(#1)

SEのための契約知識【超】入門 // Speaker Deck

 

★SEのための契約知識【超】入門(#2)

SEのための契約知識【超】入門(#2) // Speaker Deck

 

【超】がついているだけあってホントに基本のキだけですが…

 

社内勉強会用の資料ですが何かのお役にたてば幸いです。