読者です 読者をやめる 読者になる 読者になる

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

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

[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

 

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

 

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

 

今年の個人的な流行語は「Git」と「プルリクエスト」※今更ではあるが…

2015年も今日が最終日。

今年は(も?)自分なりの目標を立てて挑んだ一年。

技術のみならず、チームとかマインドセットとかモヤモヤしたものに挑んだ一年でもありました。

 

モヤモヤの部分を語るには、ここは適切で無いかもしれないので、それはまた別の機会に譲るとして、今年そのモヤモヤの部分に大きく影響を与えたツール「Git」について少し書いてみようと思います。

SVN

今年の始めは、バージョン管理はSVNで行っていいました。

既に社内にGitの環境はあったのですが、社外の現場と連携したソースコードの共有を行う必要があったことからクラウドベースで運用していたSVNを選択しました。並行してチームメンバーで作業を見える化するためにタスクボードは先ずは下記のようなスタンダードなカタチから始まりました。

 

f:id:orinbou:20151231204431p:plain

チケットの粒度が大きくて、作業が完了しないまま次の作業が始まるケースが多発して、価値を産まない仕掛中のタスクが多発する傾向にあったのでWIPを設定しました。

 

f:id:orinbou:20151231204636p:plain

さらに、個人作業がメインで完了の定義があいまいだったタスクを、他の人がチェックするようにしました。

 

f:id:orinbou:20151231204731p:plain

これにより個人任せだった完了定義と品質が少しずつ改善されていきました。

 

Git(bucket)期

社外メンバーとの連携の制約が解かれて、晴れて(?)社内のGitbucketでのバージョン管理が始まりました。最初は、ひたすらmasterブランチへPUSHするSVNのような運用を行っていましたが、プルリクエストを前提とした運用を始めました。これにより、動作的な確認だけでなくコードベースのレビューが自然の流れで可能になりました。当初はSVNの時の運用と違って、いちいちブランチを切るのが面倒くさく感じたのですが、プルリクエストの恩恵に気付いてからは、その手間はあまり気にならなくなりました。加えて、フィーチャーブランチを切る時に悩まないよう、ブランチの命名規則をルール化(案件を示す英字一文字_ISSUE番号)したことで、さらに気にならなくなりました。

 

f:id:orinbou:20151231210043p:plain

が、チームメンバーが増えるに従ってどれを誰がやっているのかが分かりにくくなるという新たな問題も発生しました。

 

f:id:orinbou:20151231210759p:plain

そこで、現在(今年の最後)は、タスクボードは上記のようなカタチになりました。新たにレビュー待ち、レビュー中という状態のレーンも設けることで、以前と比較して【実装】→【レビュー】→【完了】までの流れと状態がかなり分かりやすくなりました。また、この流れはプルリクエストを出してからレビューしてマージするまでの流れと非常に非常に非常に…自然な流れでシンクロしています。

 

プルリクエストの文化を徹底するため、ふりかえりなどで運用のしかたを相談して、masterブランチ、developブランチには直接PUSHできないよう、フックスクリプトを設定して事故を未然に防ぐような運用にしました。

 

あとは、ブランチ戦略としては

nvie.com

 を参考に、先ずは下記のようなシンプルなルールで運用をし始めました。実際は、下記をベースにテスト用のブランチやドキュメント用のブランチをケース・バイ・ケースで切るなどの試行錯誤や工夫はしていますが、現在でも大枠は下記の戦略です。

f:id:orinbou:20151231235453p:plain 

これによって、何が変わったか?

ですが、下記のような目に見えた恩恵がありました。

  • レビューをする文化の定着
  • 責任の分担(ソースコードの共同所有)
  • ソフトウェア品質の向上
  • 開発スピードの大幅UP(※メンバーにもよるけど半端ないくらいUPした)
  • 柔軟なリリース(プルリクブランチのマージを選択することで可能)
  • 人のソースコードを見る習慣から自然と学びがある

ハッキリ言って本当にいいコトずくめで、考えてみてもデメリットは思いつかないくらいです。

 

良い文化というものは、ツールの力を借りはするものの、それはメインのパワーとはならないと思っていたのですが、Gitとプルリクエストは、上記のような恩恵をもたらす文化を醸造するのにものすごい力を発揮してくれました。

 

モチロン結局は運用するのは人なので、このような機能を良くも悪くも使えるとは思いますが、個人的にはこれを使わない手はないと思っています。(※だって只だし)また、メンバーが必要を感じて段階的にカイゼンしていけたことも(今思えば)結構大事なことだったんじゃないかなと思います。押し付けて一方的にやらせていたらまた違った結果になっていたんじゃないかなぁ…

 

使ってる人にとっては今更イマサラですが、巷ではなんかGitが流行っているなぁ…と思ってから随分と時間が経って(気付けば数年?)しまいましたが、その恩恵を感じた一年でした。

 

個人的に今年は燃えプロ(※炎上プロジェクト)もあって、イロイロと大変なこともありましたが、チームメンバーと同じかそれ以上にGitとプルリクエストに助けられた年でもありました。たぶんSVNとかTFSを今までどおりの感覚で使ってたらもっと炎上していたんじゃないかなぁ…(※これらのツールがダメという訳ではないです。ちゃんと使えばいいだけだとは思います)

 

今、いっぱい飲んで年末を堪能しながらいい気持ちでこの記事を書いています。

きっと誤字もたくさんあることでしょうが、ご容赦ください。

 

それでは、今年も残すことろあと2時間…

 

良いお年をお迎えください。

 

初めてのATTでCSMになれた話

この記事は TOCfE Advent Calendar 2015 の14日目の記事になります。

昨日はメイド長こと大和さんの「未来福音」のおハナシでした。

 

まずは自己紹介。Twitterアカウントと同じくorinbouというHNでBlog書いてます。派遣や受託でソフトウェア開発を行うの小さな所謂SI屋で働いています。プログラム書いたりマネージメントしたりしながらそこそこデベロッパな生活を送っています。時々、IT系のコミュニティに参加したりTOCfE Boot Campに姿をあらわします。

 

TOCfE歴は、TOCfE Boot Campで、考えるための3つの道具「ブランチ、クラウド、アンビシャス・ターゲット・ツリー」をひととおり学びました。そういえば、今回TOCfE Boot Campに参加するキッカケもメイド長だったような…w その人からのバトンを引き継ぐことになるとは、何やら不思議な縁を感じますね。

 

今回は、一年前に参加した

で 「アンビシャス・ターゲット・ツリー」を初めて学んだ時のお話をしたいと思います。

 

アンビシャス・ターゲット・ツリー(長いので以降はATTと略しますね)は、「目標を実現したいけど、どーやったらいいんか分からない…」という時に、今ある情報を基に達成計画を立てるツールです。ATTについては「目的と目標について|Eijiのブログ」でもEijiさんが解説してくれているのでそちらもご覧ください。

 

ATTをつくる流れはこんな(↓)感じです。

  1. アンビシャスターゲット(AT)を決める
  2. ATに対する障害やリスクを洗い出す
  3. 障害を乗り越えたといえる中間目標を出す
  4. 中間目標を前提条件順に並べる
  5. 中間目標に実際の行動を加える

 

この日は折角の機会だったので、私が普段から抱えているリアルな目標(AT)を達成するためにワークショップを活用させてもらいました。私のATは「認定スクラムマスター研修(通称CSM研修)に参加して認定資格を得る」というものでした。資格を得る事自体が本質的な目標というわけではなく、IT系コミュニティなどで仕入れた様々な知見やツール、マインドセットなどを自分の現場や社内に展開するにあたり、分かり易い資格というカタチとして持っておくことが、それを加速するひとつの武器になると考えたからです。人事考課の面談や折をみては1年くくらい上長に訴え続けていたのですが、なかなか行かせてもらえず半ば諦めモードな感じでした。

 

そんな状態で先ずは個人作業で自分なりに障害やリスクとなることを洗い出してみてATTを作ってみましたが、手詰まりの連続でした。直列的なツリーとなり、とても目標を達成できそうもない木になってしまいました。ATTというツールを初めて使うということもあったと思いますが、自分なりにやることはやってきた…という変な先入観というか自尊心みたいなものが邪魔をしていたいように思います。

 

ワークショップが進行していき、各自が自分なりに作ったATTを3人一組のグループ内で共有する時間になりました。その時、同じグループのお二方から様々な指摘やツッコミ、問いかけをしていただき、自分なりに手は尽くした…と勝手に思い込んでいたカチカチ頭の自分に気付けました。ありがたいことです。

 

さらに、私があまりにも切実そうだったためか、お二方とも自分のATTを差し置いて、後半のグループワークの殆どの時間を、私のATTを完成させることに費やしてくれました。自分だけで考えることももちろん大事ですが、前提として思い込みがあるような場合は、他者から質問されたり、声に出して読んでみて自分自身の耳から情報を入力してみたりすることは、自分の置かれた状況を客観的に捉えるための手段として、とても有効なのだと改めて感じました。

 

その日、完成したATTがコチラ(↓)になります。

  • 濃黄色:アンビシャス・ターゲット(1年以内にCSMの資格を取る)
  • 薄黄色:中間目標
  • オレンジ色:行動

f:id:orinbou:20151213141722p:plain

玄人の方からすると、まだまだ十分な完成度とはいえないツリーかもしれませんが、自分なりにしっくりきていたので、翌日からこのツリーに沿って下から順番にやっていくことにしました。徹夜でCSMアピールスライド作ったり、社長室へ乗り込んで説明したりとか。ツリーに沿って進めていく中で新たに分かること、状況の変化などに応じて微妙に修正を加えはしましたが、基本的には、この日決めた方向へ殆ど迷うことなく進んでいくことができました。アンビシャス・ターゲットに期限をつけたのが良かったのかもしれませんし、また、一緒に考えてくれた人達の顔(プレッシャー?w)が後押ししてくれたようにも思います。

 

そんな訳で、今年の3月めでたくCSM研修に参加して資格を習得することができました。

その時の様子は

の記事に書きました。単にATTだけの力ではないかもしれませんが、この日この会に参加していなかったら、間違いなくこのようなアプローチはしていないかったと思います。TOCfEのATTというツール、また、TOCfE Boot Campという場、また、そこで出会えた人達には、ただただ感謝の言葉しかありません。本当にありがとうございます。

 

TOCfEに興味がある人、また、学びたい人にとって、TOCfE Boot Campは費用もそれ程かかりませんし、初心者でも気兼ねなく参加できる場になっていますので、少しでもご興味ある方は、一度参加されてみては如何でしょうか?もしかしたら素敵な "アハ体験" ができるかもしれませんよ。

 

最後に告知です。TOCfE Boot Camp直近のイベントは

になります。年内最後のイベントになるのかな?

ご興味ある方は是非ともご参加ください。

 

明日は15日目、Kunikazu Fujita さんです。どんな話が聞けるのか楽しみです。CLRかな?クラウドかな?そんな訳で、まだまだ TOCFEアドベントカレンダー2015のバトンは続くのです。それでは、よろしくおねがいします。