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

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

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

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

 

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

 

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

 

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

 

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

 

例えばボタンという部品を考えてみる。ボタンはソフトウェアを構成する部品であり、それはやはり何種類もの材質でできてる。画像や文字や動作(マウスアクション)などで構成されている。それによって特性が決まる。そして、それらの材質は、動くプログラムだったり静的な素材だったりするけど、結局のところは【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

 

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

 

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

 

今年の個人的な流行語は「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時間…

 

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