お腹.ヘッタ。

関数型とかセキュリティとか勉強したい。進捗つらぽよ

2018にやりたいこと

「2017年にやりたいこと」 - お腹.ヘッタ。

恒例のアレです。

反省点

  • 勉学面はぶっちゃけダメでした。具体的は英語がなんだかんだ言い訳してやってしまったのがダメだったと思います。厳しい....
  • 生活面も自力目覚ましできませんでした....サボった1限目は数知らず....
  • 趣味、ダーツはしばらくお休みしました。ダメかどうかはさておきこの時間を情報科学に割くことが出来たのは良い話
  • 情報技術・情報科学について。去年はセキュリティをやりたいと書いてますけどぶっちゃけ全然出来ないです。お前何なら出来たんだよって話ですがブラインドSQLiとかは見ながらなら書けてるので許してください()あといまだにDPは全然書けないです...orz
  • 計算論理は全然出来てないですが、代わりに意味論と型システムが出来てて良かった。もうちょい頑張れ私。
  • イベントについては思ったようにいかなかったけどもくもく会とかひらけてある程度サーベイになったので良かったと思います。

総評としては50点。ぶっちゃけ甘めにつけたけど目標にしてたこと達成できたかというと怪し過ぎる。目標外でアジャイルとかgitとか意味論勉強してたし10点色をつけた。大学なら赤点。

来年やりたいこと

  • 英語 どうやったら英語できるようになるのか。それは英語を読むしかないんだよなぁ。。。。英語の時間毎日取るようにするぞ!!!
  • コンパイラを作る。関数型ってロマンだよね。僕はコンピュテーション式が好きです。そこにロマンはあるかしらではなくてあるんだよ
  • 関数型を用いて一個プロダクトを立てる。あくまで趣味から出れてないからね。
  • 意味論を勉強する。出来ればもう少し検証論の知識をつけたい。俺がCoqだ。
  • バイナリを読む。去年できてないheep問できるようになろうなーという感じ
  • CFPを出す。出したいところは定まってるんですけど通ったら嬉しいぐらいの話。
  • 編入する。絶対だからな。

締め

今年も至らない点あると思いますがご指導ご鞭撻を賜りますようよろしくお願い申し上げます。

Git Objectの話

これは Harekaze Advent Calendar 2017 23日目の記事です。

git objectを皆さんはご存知ですか。そもそもとしてgitをご存知であるか問題があるわけですが、まぁ親の顔よりgitのdiffをみた人もいるんと思うので知ってることにして話を進めます。

で、git objectって何よって話をすると皆さんがgit initをしてホゲホゲすると生まれる.git/objectsを指しており、gitのコアの部分のデータストアのことを指します。

さて、このオブジェクトは大きく分けて三つの構成がされています。

  • blob
    • ファイルデータを表現する
  • tree
    • フォルダ構造を表現する
  • commit
    • treeへの参照、コミットしたユーザーやタイムスタンプなどのスナップショットの表現

それをラップしているのが僕らが普段扱うコマンドたち。

そのコマンドも大きく分けると二つで、

  • 磁器コマンド(Porcelain command)
    • 僕らが普段使うようなbranchとかユーザーフレンドリーなコマンドたち
  • 配管コマンド(plumbing command)
    • 普段のgitフロー開発では普通全く使う必要がないgit objectを直接触るようなhash-objectなどのコマンド

後者の方はあまり聞きませんが、今回はこれも用いて行なっていきます。

何が何だかわからんって人もいるかもしれませんが、git使ったことあるならばなんとなく分かるんじゃないかなと思うのでつらつらと書いて行きます。

ではサックっと見ていきましょう

.git/objects

gitのデータは前述の通り、gitオブジェクトという形で.git/objectsの中に格納される。 実際にコピってやってみよう。(以下よ#〜は結果)

git init
echo "hello" > piyo.txt
git add piyo.txt
git commit -m "init commit"

find .git/objects -type f
#.git/objects/73/0c1bf1546ce745073e50572b64d951427b868c
#.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
#.git/objects/2e/1206f177f168e9654bd0f803c3b79100308516

中身を見てみると.git/objectsフォルダの中にファイルが3つできているのがわかると思う。 この不規則に見えるgit objectの名前は40文字のhashがつけられていて、先頭の2文字がサブフォルダ名、残りの38文字をファイル名として1つのオブジェクトにつき一つのファイルに保存される。ちなみにこのobjectの名前はsha1で生成される。

さて、これではそれぞれどんなオブジェクトなのかわからない。そこでgit cat-fileというコマンドを用いる

git cat-file -t 2e12
#tree
git cat-file -t 730c
#commit
git cat-file -t ce01
#blob

よって以上のobjectはtree,commit,blobと言うことがわかった

blob object

-pオプションでオブジェクトの中身を表示ができる。

git cat-file -p ce01
#hello
cat piyo.txt
#hello

blob objectはファイルデータのスナップショットで、ファイル名などのメタ情報は含まれてない。

tree object

git cat-file -p 2e12
#100644 blob ce013625030ba8dba906f756967f9e9ca394464a    piyo.txt
ls 
# piyo.txt

tree objectはfile構造を指していて、file属性やblob objectへの参照、filenameを記録している。 なお、サブフォルダの場合はtree objectへの参照になる。

commit object

git cat-file -p 730c
#tree 2e1206f177f168e9654bd0f803c3b79100308516
#author take <****@gmail.com> 1513838255 +0900
#committer take <****@gmail.com> 1513838255 +0900

#init commit

//流石にメールはぼかしましたw

commit objectには、トップレベルのtreeへの参照、commitしたユーザー情報、タイムスタンプ、commitメッセージが含まれる。

ちなみに最初のcommitなので親commitがないが、2回目以降のコミットでは親commitへの参照も含まれる。 ほんまか?って思うかもしれないので試しに見てみる。

ではまずは新しいファイルで新たにオブジェクトが生成されるか確認する。

echo "world" > fuga.txt
git add fuga.txt
git commit -m "second commit"
ls
#fuga.txt piyo.txt

find .git/objects -type f
#.git/objects/da/22367adec08f45e1f4c368361f7582159c9012
#.git/objects/b4/7b491cb488426c0ea4c0b04bc0ac9609fb6cc0
#.git/objects/73/0c1bf1546ce745073e50572b64d951427b868c
#.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
#.git/objects/83/c7a922210527a3543ce0cfa9f1f63d9dce921b
#.git/objects/2e/1206f177f168e9654bd0f803c3b79100308516

確かに、以下のobjectが増えていることがわかる。

.git/objects/da/22367adec08f45e1f4c368361f7582159c9012
.git/objects/b4/7b491cb488426c0ea4c0b04bc0ac9609fb6cc0
.git/objects/83/c7a922210527a3543ce0cfa9f1f63d9dce921b

ではcommit objectをgit cat-fileをする。

git cat-file -p 83c7
#tree da22367adec08f45e1f4c368361f7582159c9012
#parent 730c1bf1546ce745073e50572b64d951427b868c
#author take <hayatake396@gmail.com> 1513954425 +0900
#committer take <hayatake396@gmail.com> 1513954425 +0900

#second commit

この場合、確かにparentと言う親commitが出来ていることがわかる。

折角なので、他に増えたobjectたちも確認してみよう。

git cat-file -p da22
#100644 blob b47b491cb488426c0ea4c0b04bc0ac9609fb6cc0    fuga.txt
#100644 blob ce013625030ba8dba906f756967f9e9ca394464a    piyo.txt

treeなのでファイル自体がやはり増えている。

git cat-file -p b47b
#world

blobなのでファイルの中身が確かに出てきている。素晴らしい。とりあえずgitobjectが頑張ってることはわかった。

ここで思うだが、git objectを配管コマンドから直接いじって見たい気持ちになったりするわけである。

と言うわけでこれってもしかして全くファイル作らずにgit commitができるのではと言うことが容易に思えるので検証していく

配管コマンドを用いたファイルを一度も作らずに行うcommit

初めはまずはgit initをして確かに初めにはないもないことを確認する。

mkdir fugafuga
cd fugafuga
git init
#Initialized empty Git repository in /Users/Home/Desktop/fugafuga/.git/
find .git/objects
#.git/objects/
#.git/objects/pack
#.git/objects/info

さて、使うコマンドはgit hash-objectと言う物を使う。これはobjectIDを計算してファイルからblobを作成するコマンドである。 オプションがいくつか設定する必要があって、今回使うのは-w,--stdinと言う実際にobjectデータベースに書き込むオプションと標準入力からobjectを読み込むと言うものを指定する。 ちなみに-wをつけないとただ単にIDを吐くだけになる。blobは出来ない。

echo 'create data' | git hash-object -w --stdin
#070f3bd01632c945394b3aac7187a9d91ca4816a
ls
#(何もない)
git cat-file -p 070f
#create data

これで確かにblob objectだけができた。

次にこれを格納するtree objectを作る。

さて、下準備をする必要がある。 まず、使うコマンドはgit update-indexと言うコマンドを使う。これはworking treeのファイル内容をindexに登録するコマンドである。

これにもオプションをつける必要があり、Stageingしてるファイルに対してこれは実行されるので(と言うかファイルがないのでStageingする場所もない)--addオプションをつけて追加すること必要ある。

また、このindexに追加するものはファイルではなくてobjectデータベースにあるので--cacheinfoオプションをつけて指定された情報をindexに直接挿入してやることになります。このオプションは引数を3つ取ることになって--cacheinfo <mode> <object> <path>と記述する必要がある。

ちなみにだがこのmodeとはchmodなどと同じパーミッションの数値の値を指しています。今回の100644chmod 644と同じですので通常の一般的な権限のファイルであることを意味します。逆に実行可能ファイルとかならば100755になります。

git update-index --add --cacheinfo 100644 8b137891791fe96927ad78e64b0aad7bded08bdc test.txt

さて、これ無事indexにぶち込んだのでStageingエリアをtree objectに書き出すことができるようなった。 これをどう書き出すかと言うとgit write-treeコマンドで行う。これはまだtreeがないときに自動でindexからtree objectを作る。

git write-tree
#c47b19c8b7a3b7724138f73e4cd53efa0f1e9595
git cat-file -p c47b
#100644 blob 070f3bd01632c945394b3aac7187a9d91ca4816a    test.txt

これによって作ることができた。

さて、次はcommit objectです。ここまでやれば簡単で、

echo 'first commit' | git commit-tree c47b
#5cb61261e3c4d2d15d09583c107577564cc6335e
git cat-file -p 5cb6
#tree c47b19c8b7a3b7724138f73e4cd53efa0f1e9595
#author take <*****@gmail.com> 1514031034 +0900
#committer take <****@gmail.com> 1514031034 +0900

#first commit

確かにcommitが出来ました。やったぜ!

終わりに

私は今回NICT主催のSecHack365というのに参加しているんですが、計画性のなさが露呈して、開催期間中に記事を書く羽目になりました。ツライ....

次は@Knom10さんです。お楽しみに!

参考

AVTokyo2017に行った話

AVTokyoとは

http://ja.avtokyo.org/ ウェブサイトには 「AVTOKYOは、コンピューターセキュリティに関する発表と、気軽に情報交換をする、コンピューターセキュリティのカンファレンスイベントです。ひとときの楽しい時間をドリンクとHACKで過ごしてみませんか?」 と書いているがまんまその通りのイベントです。

元々は「ブラックハットジャパン」参加者のミニプレゼンを含むパーティーが原型だったそうです.

参加した動機

元々はずーっと行きたいなぁと高校の頃から思ってたイベントの一つでした.

今回あわよくばcodeblue学生スタッフで余裕があったら行きたいなぁとか思ってたわけですが残念なことにどうやら僕は落ちたようでした....残念!まぁ実力不足ってことでしょうね: (

というわけで勢いでAVTokyoのearlyチケットを取ってしまいました.....苦学生には....ここからが本番でした

参加するのになるべく金かけないように行きました

どういうことかというとチケット取ったはいいが、じゃあどうやっていこうかなぁという話が出てきたりお金の出所が頭を回す必要があります.

ちなみにですが10月回のsechack365では今回のスピーカーの神園さんとお話ししてる際には「いやー行きたいんですけどお金がないんです(涙目)」みたいなことを話してた記憶があります そのせいで当日お会いした時は「よくこれたね!!!」ってビックリマークが3つぐらいついてましたw

まぁ結論から言えば、安定の夜行バスを使うわけなのですがコツがあります.

やはり、いわゆる早割を使うわけなのですが、 自分の使ったのはさくら交通のバスでした. 、 これは実は眺めてるとわかるのですがサイトによって記述値段が異なることや、時間によって当然謎の安い値段帯のものが降りてくることがあります. また行く日にちをずらすなどで今回は運よくそれを拾い往復7000円ほどで行きました.

ちなみにもコツがあって、どうやって自分の体力を確保するかがあります(もしかしたら最重要) これも2つ方法があって、

  • なるべく背後を取ってリクライニングシートを使えるようにする
  • 空いてるバスを狙うということがあります.

自分は無事条件を満たすバスに乗りました.

さてかなりリサーチした結果なのであまり語ると長くなるのでここら辺でやめておきます.なお友達の家に泊まらせてもらったのでホテルなんてものはありません:(

参加当日

勢いで決めたせいで当初ぼっち参加だったわけなんですが、同じSecHack参加者の三須さんと一緒に行くことになり会場前で待ち合わせしてました. 三須さんありがとうほんと大好き(大泣)

実際参加してみると雰囲気としては結構地味に圧倒されますが....しかし入ってみると外人の方もいらしたり和気藹々と楽しそうな印象を受けました.

というかなのですが明らかにどう見ても知ってる人多くて実際セキュリティにどっぷり使ってる人はオフ会にしかならないのではwと思いました。

面白かった公演について

あんまりCall for Xの出し物にハマってたせいで聞けなかったんですが(神園さんの聞きたかった....)個人的には2つ。

  • pancake氏のradare2
  • 木村 廉氏のMore efficient remote debugging with Thin Hypervisor

がとても良かったです. 特に前者のradare2の作者は界隈では有名な方で、なかなか英語なので辛いってなりながら耳をかっぽじってました.割と既知の知識ばかりでしたが後から聞こえた話によるとandroidでも動かせたりとかなかなか強い人だなぁと思ってました. ちなみなんですが参加後リポジトリを眺めていたらhttps://github.com/radare/r2jp なんと日本コミュニティができていてびっくりしました・・・しかも公式だし. 後者のるくすさんこと木村氏のはbitvisorを用いていてかなり先進的なことをしているように感じました.これまた面白いのがGSoCにおいて木村さんはradare2についてコミットしていたので界隈が近いなぁと強く思いました.

参加したイベント

  • SMD Soldering Practice
  • Open xINT CTF

この2つに一緒に来た三須さんと参加しました.

前者のSMD Soldering Practiceはツラい半田付け体験でした.

具体的には表面実装用の細かい抵抗やコンデンサ、ICなどを取り付けていきます.自分は残念なことに手を焼肉してしまってツラいさんでした. 自分はラッキーなことに半田付け初心者ではなかったので無事完成させました: )

後者のOpen xINT CTF http://xintctf.wpblog.jp/ はOSINTと言われる要はスパイぽいCTFです(ざっくり) 結果として3問解いて12位でした. f:id:taketarou2:20171116121603p:plain 一問目はwhoisするだけだったのですが....(なぜかここで自分たちのコマンドから通らずこける) ちょっと時間をかけてしまいましたw その後出て来た管理者のメアドからSNSを漁り、見つけていくってことを行いました.ですが3つ目終わった地点で時間切れ.悲しい.さんまでGOってなんだよ... ちょっと雰囲気をつかめばワンチャンありそうだったので来年もやりたいと強く思いました.

雑多な話

  • 英語できなすぎてジェスチャーで乗り越える
  • うっかりするとジンジャエール頼んだのにジントニックが出てくる
  • カールおじさんこと、NICTのカナハマさんにお会いしたのでカールを得た f:id:taketarou2:20171116120859j:plain
  • AVTokyo参加記書くのでTシャツくださいとカナハマさんに言ったらもらった
  • CFP来年は出そうなって煽られる
  • Sechackの関係者余裕で10人ぐらいいた
  • ツイッターでAVTokyoにいく旨を話したら何人かフォロワーさんをお会いすることができた
  • hiro1357(@eserver_dip_jp)と会うために待ち合わせしてたら同じ場所に別のひろさん(@kazu1130_h)に話しかけてしまい初対面で挨拶替わりにtwitterフォローするという謎事件
  • CodebBlueの人たちがまんまマイグレーションしただけという事実が行けなかった俺に刺さった
  • @__ukun さんがCTF強くてプロだったけどメッチャうるさかった
  • NICTの石川さんが明日は合コンだ!って目が輝いてた
  • アフター行きたいのでやはりCFP出すだけ出すしかない

まとめ

これ書くの12月でもいいかなぁと思ったら f:id:taketarou2:20171116120911p:plain という指定暴力団sechack事務局お世話になった人たちに煽られたので急いで書きました.

ともあれいろんな方々がいろんなところからやって来て幅広いバックエンドをお持ちなので話してて飽きないです!

ぜひセキュリティに興味ある人はみんな楽しめると思うので行きましょう!

ThinkPad USB keyboardをMacOS Sierraで使う

ThinkPad USB keyboardをMacOS Sierraで使いたい!

macThinkPad USB keyboardを使いたいが、MacOS Sierraで使うと残念なことにKeyRemap4MacBookでバインドが使えないんですね….探すのにだるかったので載せときます。あとこのキーボード非常に優秀なのでみんな使ってください。 というわけで備忘録です。

キーバインドをする。

これは基本的にググれば出てくるので割愛。ポイントとしては今のところSierra以降はKarabiner-Elementsでのみキーボードのバインド周りを変更できる。ただし以前のようにマウスに仕事させれない。 GitHub - tekezo/Karabiner-Elements: The next generation Karabiner for macOS Sierra

マウスのミドルボタンを押しながらスクロールしたい。

ディフォルトではミドルボタンスクロールができないんですけど、USBOverdriveでマウス周りを変更できます。 http://www.usboverdrive.com/USBOverdrive/News.html

トラックポインターの速度を上げる

mousezoom Ben Net - MouseZoom OS X Official Site

これらでできるはず。

僕が運用中に困ったこと

このキーボード実は換装可能で、jis->uk->jisってことができたりするんです。 自分はこのキーボード、ボロボロの中古で買って、修理して使ってます。

そこで引っかかったことを書いておきます。決して上の使い勝手の話ではないです。

キーボードがukになってしまう。

どういうことかというとjisで使ってるのにukとして振舞ってしまう。ってことがありました。 いろいろ調べていくとまぁいろいろありますが、僕の場合前に今のキーボードをukで使っていて、そのあと換装してjisにしました。つまりキーボードの設定がukのままになってるって考えるのが妥当ですよね。 なのでライブラリの中にあるcom.apple keyboardを削除してrebootしました。

そうすると使えました。はい。特殊ケースですね。。。

終わりに

ThinkPad USB keyboardクソ最高なんだけど環境に合わせるのがめんどいっていう人がいそうなのでまとめました。 ThinkPad USB keyboardは汚れたり壊れたりしたら自分で中身だけ買って換装が可能です。フレームが割れない限り永遠に使えるので某馬の鎧で表現してるキーボードよりもよっぽど永遠にプログラマを支えうる道具だと思います。 また、PC切り替え機とかと併用すると最高に作業がはかどります。自分はこれでノーパソきりかえて使ってます。

ざっと30分クオリティですけど誰かの役に立てば幸いです。備忘録でした。

リーン開発の現場を読んだノート

リーン開発の現場

という本のノートを描いて見た。この本は実例を交えながら紹介している本である。

当ノートは自分なりに本の中身を元にまとめて見ている。 個人的に後から考えてもいいのではみたいな章は省いたり、簡約したり纏めたりしてる。他にも自分で知っていることを含めて見たりもしているので必ずしもこれが正解とかは言えない可能性もあるのを忘れずに。

さて、そもそもアジャイルとかリーンとは何じゃ、ということをざっくり説明します。

アジャイルの概要

ソフトウェアコミュニティの17人のオピニオンリーダーたちが2001年にユタ州のスキーリゾートに集まってソフトウェア開発を成功させる方法について議論しお互いの考えを擦り合わせていくうちにアジャイルソフトウェア開発という言葉が誕生しました。そしてソフトウェア開発を成功させる方法に関する共通のビジョンを見つけて文章化したもので、いわゆるアジャイルマニフェストと呼ばれる文章になったもの。 内容を以下に示す。

私達は、ソフトウェア開発の実践、あるいは実践を手助けする活動を通じて、より良い開発方法を見つけ出そうとしている。この活動を通して、私たちは以下の価値に至った。

  • プロセスやツールよりも個人と対話を。

  • 包括的なドキュメントよりも個人と対話を。

  • 契約交渉よりも顧客との協調を。

  • 計画に従うことよりも変化への対応を。

価値とする。すなわち、左記の事柄に価値があることを認めながらも私たちは右記のことに価値を置く。

  • 顧客満足を最優先し、価値のあるソフトウェアを速く継続的に提供する
  • 要求の変更はたとえ開発の後期であっても歓迎する。変化を味方に身に付けることでお客の競争力を引き上げる。
  • 動くソフトウェアを2〜3週から2〜3ヶ月という短い時間の間隔でリリースします。
  • ビジネス側の人と開発者はプロジェクトを通じて日々一緒に働かなくてはいけません。
  • 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事終わるまで彼らを信頼します。
  • 情報を伝える最も効率的な方法はフェイストゥフェイスで話すことです。
  • 動くソフトウェアこそが最も進捗の重要な尺度である。
  • アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなくてはなりません。
  • 技術的卓越性と優れた設計に対する普段の注意が機敏さを高めます。 シンプルさが本質です。(言い換えると無駄なく作れる量を最大限にすること。)
  • 最良のアーキテクチャ・要求・設計は、事故組織的なチームより生み出されます。
  • チームがもっと効率を高めるかどうかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイルという言葉自体は2001年に誕生したが、ほとんどのアジャイルの方法論は1980年代にはすでに作られていた。アジャイルはこれらを包括的に指す言葉で、様々な共通点があればアジャイルとも言えなくもない。 つまり全てアジャイルとも言える。 逆に言えばではあるが、これらの共通点原則を持つものをアジャイルという多面的な表現を許容することでもあると考えれる。

スクラムの概要

ソフトウェア開発のフレームワークのことである。1990年ごろにできた。 スクラムは経験則に基づいたプロセス制御や複雑適用系理論を元にしている。 以下にコアコンセプトを説明する。

  • 順番付けされたプロダクトバックログ

  • 実現すべき事柄を小さくリリース可能な作業一覧に分割することを指している。

  • プロダクトオーナー(OP)はプロダクトビジョンを定義して、ビジネス価値やリスク、依存関係などのエレメントに基づきプロダクトバックログを作る。

  • 要は全体の仕事の山を分割する。

  • 職能横断型チーム
    • 自己組織化したチームに小さく分割していく。
    • それぞれのチームにはPOとスクラムマスター(SM)が存在している。POはビジネス全体のプライオリティをチームに提供して、スクラムマスターはチームの改善や障害を取り除く作業に力を注ぐ。
  • スプリント
    • 開発期間を短く固定されたイテレーションのことを指す。例えばリリース期間とかのこと。
    • 目標まで走り抜けるのでスプリンターから来てる。
      • しかし。短距離ランナーではなくペース配分をするマラソンランナーの方が現実は正解なのであるのは忘れずに。
  • 継続的にリリース計画を調整する。
    • プロダクトオーナーはリリース計画を最適化し、各スプリント後のフィードバックを顧客と強調しながら優先順位について更新する。
  • 継続的にプロセスを調整する。
    • それぞれのフィードバック後の振り返りによって最適化していく。

大人数で長い期間大きなものを作るのではなく、少人数で短期間で小さいものを作るのがスクラムであるということである。

XPの概要

1990年中盤に生まれたエクストリームプログラミングとは

  • シンプル

  • コミュニケーション

  • フィードバック

  • 勇気

  • 敬意

というジャンプばりの五つの価値を基盤にしたものである。 スクラムと並行して進化して来たためにほとんど同じ要素を持っている。例えばXPにおけるオンサイト顧客はスクラムのプロダクトオーナーとほぼ同一。

じゃあスクラムと何が違うかというと外向的か内向的かである。

スクラムはしばしばXPを取り囲んでると言われる。何故ならば組織構造の課題や外部とのコミュニケーションに着目しているからである。

ではXPはどうかというと、エンジニアリングプラクティスが主幹的だったりする。

  • 継続的インテグレーション
  • 自動ビルド、自動的な統合。そしてチームが開発したコードを自動テストする仕組み。これによって作業の品質が関わる早期のフィードバックをチームはより早く得ることができる

  • ペアプログラミング

  • ペアでプログラミングする。学習や設計品質を最大限引き上げることができる。また欠陥の発生を最小限にできる。
  • ペアのレベル差が大きいと片方のレベルが格段に上がる。

  • テスト駆動開発

  • テストコードを書いてテストを通すためのコードを書く。
  • またリファクタリングをしてコードを洗練させていく。

  • コードの共同所有

  • チームメンバは全員ソースを修正することが許されている。また奨励されている。これにより理解が進み協同的な感覚が生まれる。

  • インクリメンタルな設計の改善

  • 初めはシンプルで実現可能な設計から始める。
  • その後改善してブラッシュアップしていくアプローチ

カンバンの概要

カンバンはアジャイルソフトウェア開発におけるリーン的なアプローチだ。これは日本語から来てて工場にあるカンバンと同じところから来ている。つまるところ物理的な伝達システムのこと。

しかし、勘違いしてはいけないのが2004年にデイビットアンダーソンがソフトウェア開発におけるカンバンとしたのだ。間違っても天井に貼り付けるあのカンバンとは微妙に違う。

カンバンのルールを以下に示す

  • ワークフローを可視化する。
  • 作業を小さく分けてそれぞれをカードに書いて壁に貼り付ける。
  • それぞれのカードがワークフローのどのstatusであるのか可視化するためにそれのラベルのついたものに貼り付ける。

  • WIPを制限する。

  • サイクルタイムを測定し管理する。

  • これを元にプロセスを最適化していく。
  • 例えば人員の転換やさらに仕事の分割など。

リーンの概要

リーンとは「TPS」というトヨタ生産方式を元にしたものである。(というかぶっちゃけ同じで西洋でTPSと呼ばれるだけの話。)このTPSという方式は様々なものに適用可能とされている。その中にはソフトウェア開発も含まれる。

よくある勘違いとしてアジャイルとリーンは共通の価値があるために親戚や同一視されるが起源は異なっている。 リーンは製造業から、アジャイルはソフトウェア開発から誕生した。お互いの原則は相性が良く、適用できる範囲も広い。 最近多いのは製品コンセプトの開発〜デリバリまでというエンドツーエンドの開発の流れ全体でアジャイルとリーンをどう組み合わせて適用していくのかということが探求されている。

このリーン(TPS)の原則を、リーンソフトウェア開発として提唱したのがメアリー・ポッペンディークとトム・ポッペンディークである。

全体を最適化する

システムの一部分の最適化に時間をかけても必ずしもシステム全体の最適化にはならない。

  • ストリーム全体を最適化する。
  • つまりコンセプトからデプロイまでの包括的な部分を指している

  • 完全な製品を提供する。

  • 顧客の一番の目的は問題解決なのでそれを解決できるソフトを作ろう。

無駄をなくす

無駄とは、顧客に価値を付加することのないあらゆるものである。ソフトウェア開発では3つの大きな無駄がある。

  • 間違ったものを作るという無駄。

  • 学び損ねるという無駄。

  • 頻繁な引き継ぎや現場からかけ離れれた意識決定などいわゆる方針のブレのことを指してる。

  • 過度な作業切り替えによる無駄。

品質を作り込む

プロダクトのテスト段階で毎回過度の欠陥が見つかるのであればプロセスに問題があると言える。

  • 最終テストで欠陥を見つけないような仕組みづくり。

  • テスト駆動開発による誤りを防ぐプロセス。信頼を担保し続ける必要がある。

  • 依存関係を断ち切る。

  • 機能追加や変更を可能な構造をすべきで疎結合なものであるシステムアーキテクチャである必要があるべき。

たゆまぬ学び

計画は立てることに意味があり、学びを得ることにその本質がある。この学びというのは実験を重ねることなどを指している。

  • 成果の予測可能性はフィードバックにより高まる。

  • 選択肢を幅広くもつ。

  • 変化への耐性を持たせる。

  • 意思決定を最終責任地点まで遅らせる。

  • 取り返しのつかない所に来る前に(決定とも表現) 可能な限り学習をしてできるだけ実験を重ねる。

速く提供する

ステークホルダー全員についての深い理解と、彼らにとっての価値を何かということを考えるところをから始めるべき。 それによって継続的にビジネス価値を生み出していく流れを作る。

  • 素早いデリバリと更新しつ。低コストでの実現。

  • 待ち行列理論は鯖だけではなく開発にも応用できる。

  • ゆえにプロセスには作業の塊を小さくして少しずつ流す。代わりにサイクルタイムを短くしていく。

  • ワークフロー管理はスケジュール管理よりも簡単にできる。

  • 任意の日にリリースする最善の方法はイテレーションやカンバンシステムを使ってしっかりとイテレート可能なワークフローを確立することにある。

全員を巻き込む

優秀なメンバーは起床資源である。チームメンバーは公平かつ公正に適切に対価を得る人々であり、自律、熟達、目的に応じて意欲を感じるのだ。

  • 自立
  • 効率よく働くチームのメンバーというのは半ば自律しているチームである。チームにはメンバーの精神面を支えるリーダーが存在し、リーダーは完了させるべき作業や意義のある作業について始めから終わりまで責任を持つ。

  • 熟達。

  • 人に敬意を払うことでチームの誰もが素晴らしい人なるための挑戦やフィードバック環境が生まれる。

  • 目的。

  • 仕事と価値を繋ぐものが目的である。仕事の意義を感じることで初めて人々は目的の達成に没頭する。

改善を続ける

結果が重要なのではなく、人と結果を出せるシステムを育てるのが重要なのである。

  • 失敗とは学ぶ機会である。
  • 小さな失敗でえ注意深く調査し、修正すれば最高に信頼できるパフォーマンスを生み出せる。

  • 標準は挑戦や改善のために存在する。

  • 現在の標準になっている物への挑戦や変更を奨励していく。その上で現状最も知られていて誰もがわかる理解を標準化していく。

  • 科学的な方法を使う。

  • 仮説の検証法、早くたくさんの実験を行うやり方、簡潔なドキュメントの作り方。これまでとは違った良いやり方をやる。

つまるところある種の信頼が担保されたものを実行することである。 何言ってるんだって感じなのでつまるところ、

  1. 顧客の目で「価値」を定義。

2.その価値の流れを可視化する。

3.それを「エンドツーエンド」で「細く、速く」流れるようにする。

4.その流れの改善活動を現場で実際に仕事をしてる人が行う。

ということである。以下から実際に当該書籍を元に紐解いていこう。

一章 プロジェクトについて

スウェーデンの国家警察で作ってるPUSTという新しい捜査報告システムを元に紹介する。これを実現するにはある要件を満たす必要があった。

  • 膨大な量のレガシーなシステムと統合

  • 相手に質問しながらリアルタイムでシステムを使うため警察官にとって簡単に使えるシステムである必要がある

  • 堅牢なセキュリティ

  • たくさんの複雑な法律や規則を遵守しなくてはいけない

  • スケジュールが厳しい

タイムライン

スタートは2009年9月から。一年後にはリリース。その後は隔月でリリース。 スケジュールの中で重要なマイルストーン

  • 1.0の最初のバージョン

  • 1.4の警察全体で使えるようなったバージョン

早めにリリースしていくスタイルである。 理由としてはバグや思い込みなど仕様をすり合わせつつ行うことのできる点にある。よって頻繁なリリースをするというのは一度のリリースに抱えるリスクを減らすと言えるだろう。 また、リーンの特徴として開発のプロセスがどんどん変わって、進化し続けることが挙げれる。

スケジュール分割について

大きなプロジェクトでリスクを最小化する鍵は大きな像を分割する方法を見つけ出すことである。こうすることで、小さい機能を徐々に増やしていくことができてシステムを何度もリリースするインクリメンタルリリースを行える。リスク分散の観点からもユーザーにそれぞれ価値を送りフィードバックをされていくというより良くしたいという流れからも良い作業と言える。 今回の場合は地理的な場所犯罪者別という点から最小化にかかった。

  • リリース1.0から1.2
  • 一つの地域のみに対応。
  • 飲酒運転など武器の所持。よくある多い犯罪種のみ対応。
  • 徐々に犯罪種のサポートを増やした

  • リリース1.3:

  • 2つ目の地域に対する拡張リリース
  • これをメインリリースとした

  • リリース1.5

  • 犯罪種別を追加押収品の管理システムなど他のシステムと統合したバージョンをリリース このような形に分割した。

顧客について

これは警察組織のプロジェクトで顧客やユーザも身内であった。がこれは当該プロジェクトではある一人が主役である「顧客」として振る舞った。 エピックにあってるかどうか、詳細なフィードバックをもらうなどを行った。 (エピックは一般的には壮大な作品という意味だが、この文脈では大まかな要求大きなストーリーという意味である。)

二章 チーム編成

ソフトウェア開発プロジェクトにおける難題の一つとしては適切な人数でチーム編成して、不空のチームが強調して動くためにはどうすれば良いのかというのが挙げれる。 メンバーの人数が増えるに従ってコミュニケーション問題やコラボレーションの難しさにぶち当たる。組織が成長する際によく発生する痛みの症状と同じ。 初めの小さい頃は疑問があれば人数が少なく近くにいることが多いのでどのように運営するかなど方針に対する容易に行えた。 これに対して、実際人数が増えたが上手くいけたのはメンバーが一つの場所で働いていたことにあるだろう。また柔軟にチーム編成を進化させた。今では5チームで行っている。

  • 要求分析

  • システムテスト

  • 機能開発が3チーム

  • チームではなく、プロジェクトマネージャや構成管理、パフォーマンステスト、コーチなどがいる。

さて。 三つの開発チームは基本的によくあるスクラムチームで構成されている。職能横断型で、自己組織化していて、昨日全体と開発とテストする能力がある。 要求分析のチームは仮想的なチームでアナリストが所属していて、基本的に他のチームに所属しながらなので仮想的。 これによってプロジェクトメンバー全員が分散して配置されている。 また、この理由としてアナリストと各プロジェクトの人たちがコミュニケーションを取りやすいようになっている。

基本的に要求分析チームは3つの役割をこなすことになる。

  • 何人かのアナリストは機能開発チームの一つに所属し、開発者からの質問に答えて要求を明確にするために、開発からチームの開発をサポートする。

  • 何人かのアナリストはどの機能開発チームにも参加せずシステムの全体像の分析に重点を置いて取り組んでいいる。彼らはシステムの概要となる昨日エリアを定義するために、将来像を見定める。

  • 残りのメンバーは上記の2つのうちどちらかに柔軟に横断して必要な作業を行う。

テストチームも同じように、

  • 何人かのテスターは機能開発チームに属して機能レベつのソフトウェアテストデバッグを手助けする。

  • 何人かのテスターはシステムの全体像に対するテスターで、リリース候補版の概要レベルのシステムテスト結合テストの実施に力を入れている。

  • 残りのメンバーは2つのうちどちらかに柔軟に横断して必要な作業をする。

初めはチームは担当する作業で分けて編成していた。要求分析チーム、テストチーム、機能開発チームをはっきり区別し、テスターやアナリストがいなかった。

しかし、これによってコミュニケーションの問題でスケールが上手くいかなかった。さらには担当するチームで分けてしまうとチーム間のコミュニケーションを文章で行ってしまうことが多くなった。そして問題責任の押し付け合いが始まってしまった。また、それぞれのチームは自分の仕事だけの完了だけをしようと考えがちであった。

例えば、アナリストであれば機能が本番環境にリリースするまでに行われる開発やテストに付き合わなくなったりする。これは要件定義を書き終え、自分の手から離れた時に機能に関する自分の仕事が完了したと考えてしまうからである。 コラボレーションの質は、スクラムのような職業横断型のチームに進化したことで劇的に改善した。

しかし、何でもかんでも一つのチームで行うのではなく、何人かのアナリストやテスターを機能開発チームから引き離してシステム全体を見るようにした。

三章 ミーティングについて。

当該書籍では朝10:15前までに3段階のミーティングを行う。

第一段階:機能開発のスタンドアップミーティング

自分たちが使っているtaskboardに立って今日やることや取り組むべき問題や課題について意見交換をしていく。 場合によっては昨日やったことや昨日やること、困っていることと言った3つのことを話すと言うことをしている。

第二段階:スペシャリティ同期(synchroの方)ミーティング

チームごとの話や各場所で行ったことを初めに決めたグループを超えて話し合う。

第3段階:プロジェクト同期ミーティング

これは組織をバラバラに考えて少数精鋭で行ったりする。これは全体的に長期的なスパンで俯瞰したり、フォーカスを広く持つことをひつようとする。

これらのミーティングの特徴として、ボトムアップからのアプローチであることが挙げられる。 細かいディティールから大きな対局へ見ていく。 その際には人を変え、場所を変え、問題を変えて課題を認識して解決していく。

これによって大きな問題を分割していくことができる。

また、これに関してはある固定した期間を持たせて無制限で行わない。また必要に応じてこれをなんどもイテレートする。 ex,9時ごろミーティングを15分、お昼に15分、帰り前に15分。 場合によっては柔軟に増やしていく。

四章 プロジェクトボード

プロジェクトボードとは、プロジェクトにおいてコミュニケーションの大元になるものとすべきものである。具体的にはプロジェクト全体の状況などを見せる。これは、カンバンシステムであったり、ストーリーマッピングであったり、様々な形が考えられる。

当該書籍におけるプロジェクトのカンバンを例に取ろう。 アイディア->機能->次の作るべき10機能->開発->システムテスト->ユーザー受け入れテスト->本番 となっている。 これらはすべてフローとなっている。

何点か細かいディティール例をあげたいと思う。

  • 機能
  • 大局として考える。
  • ユーザーストーリーと呼ばれるフォーマットで書かれている
  • XとしてYをしたい、何故ならばZだから
  • と言うフォーマット
  • ex:捜査官として住所を検索するときに地域によって絞り込みをしたい。何故ならば住所を早く見つけることができるからだ。

  • 次の10機能

  • これは先ほどのエピックといえる機能を細かく分割する。
  • 具体的に詳しい機能や必要な要求を展開する。
  • ここの中身こそミーティングでブラッシュアップを必要だったりする

  • 開発とシステムテスト

  • 継続的インテグレーションを行っていき、機能レベルのテストが出来ならばシステムテストを行っていく。
  • このときgit上には別バージョンのブランチを作って扱おう。
  • ここで素晴らしい点はここも大きい単位でテストを行うのではなく、小さい細かい単位でテストを行うこと、当該書籍の言葉を使うと継続的システムテストを行っている。

ウォーターフォールとの大きな違いとしては、初めから要求を完全に分析しているかしていないかの違いである。 カンバンシステムでは全てのフェーズを並行して進める。これよってフィードバックによるアイディアを組み込みやすく、フローとして価値を作り続けているのである。

ここでもひとつ忘れるべきではない点について、緊急の課題や、ボトルネックについての処理である。 パターン的にはマーカーをつけていろんな人からフォローをもらわなくてはいけないとわかる。

しかし、これをどのように機能させればいいのか。少人数なら気にすることはないが、大人数ならばどのようにすればいいのか。 それについて次章に入ろう。

五章 カンバンボードをスケールする

一般的にプロジェクトが進むスピード大部分は、メンバーがどれくらい状況を理解しているかによって決まる。 もしも、メンバ全員が何をしていてどこにいるのか、何が起きてるのかを理解していれば同じ方向に進むことは容易であると言えるだろう。 そう。そのためのカンバンボードである。

しかしながら、人数が増えてやることも増えたら付箋だらけだったりカードだらけでとても扱いにくいものになるだろう。 そこでカンバンを分割してあげることをする。例えば開発についてであれば複数チームがいる際に、自分のところに今やるべきメインの課題などは機能開発チームが持っていることをメインのカンバンで示してあげて、議論が深くなるであろうディテールの部分は各開発チームのボードに書き込むなどをすると言ったことができる。

ここでのポイントは階層に分けることである。しかし流れスタックは溢れてしまうものなのでWIPの制御をして行うことなどをしよう。またちゃんと同期しないとあとあと大変なことになるので注意。

六章 プロジェクトゴールの管理

プロジェクトの全体のゴールを理解していると、プロジェクトメンバーはゴールに向かって集中するようになる。 それはそうという話ではあるんですが、実際に行っていくと意見の食い違い等があることがわかる。 なのでゴールへの理解のすり合わせを行う。具体的にはミーティングのプロジェクト同期ミーティングで行ったりするべき。 彼らは初めの方はなかなか難しいという評価をするかもしれない。しかしそれに対してどのようにモチベーションをあげていくのか。また、仕様書は共通認識ではないということを理解して、ストーリーマッピングをするということを行わなくてはいけない。

これらのことは定期的に行うべきである。これによって現状とゴールのチェックを行うというのは、進捗とチームの士気と意識についてを知ることである。

技術課題を捌くとバグを捌く

以下は章に合わせず必要なことを纏めて書き留めていく。

技術課題さばき

技術課題が出てくるのは仕方ない。なのでどれくらいそれにコストがかかっているかを機能の情報と別に用意して作る。要は機能カードと技術課題カードにそれぞれどれくらい労力を必要としてるか見えるようにしよう。

やるべきものにうまく乗っていくために。

例えばリファクタリング。あまりにも技術的負債が大きいと、とてもやりたくないものである。しかし、これを嫌だからと言って看過してしまうとその後技術的負債は増大していく。

この場合は、実際にこの脅威を可視化するといい。 この場合であれば実際にそのクラスファイルを印刷をかけて、どれくらいが理想のコードサイズであるかを示すべきである。 それによって僕らが行わなくてはいけない技術的負債の線引きガン見えてくるだろう。

また、リリースの前のパイロット版にはそれに対するリハーサルをコストとして見ていこう。どこまで用心することに越したことはない。

バグさばき

カンバンを使わないで捌くとテスターがバグを見つけて、開発のサイクルの終わりにバグを見つけては要求分析にプライオリティをつけて、変更管理ミーティングをしてそれに対するコストにシンクロさせていく。

が、しかしこんなのは厳しいのでしっかりとカンバンを使いたおそう。

  • 継続的システムテスト
  • 要は大きいテストをやるのではなく、一つのスプリントごとなど小さいうちに部分のテストを行っていこうというスタイル。
  • これの良い点はバグを探すなど無駄な本質から離れたことで時間を多く取らなくても済む点である。そう考えると結果として最後にまとめてテストする場合と比べると時間に関するコストが明らかに軽減される。

  • さっさとバグをぶっ殺せ。

  • テスターがバグを見つけたらさっさと殺す。いっそその場で殺しにかかるのがベターだろう。
  • 後からバグとかで揉めるより効果的
  • 会って話すというコミュニケーションをするということはバグトラッキングのシステムに状況を記述するよりも対面でのコミュニケーションの方がドキュメントコミュニケーションより多くを知ることができからである。
    • しかし、これについてはただ会って、口頭で話すというだけではなくユーザーストーリーのフォーマットなどある種のフォーマットで簡潔に述べたものを用意してそれに対するディティールとしてテスターが受け持つのが良いと言えるだろう。
    • また、引き受けたことがあるバグに近いタイプのをなんども引き取ってしまうことがあるので、バグに関する統計を取るのおも良いと考えれるだろう。
    • 開発者とテスターがお互いの仕事に関して学び合うのでチームとしての改善点など多くが見えてくると考えれる。
    • 簡単な細かい古いバグが含まれたタスクカードの管理に無駄な時間を使わなくても良い。(難しいのは適宜対応
    • では大きい難しいのはどうするのか。そういうものを優先して積極的にバグとしてバグトラッキングシステムに登録する。細かいものは統計は取るが、追加などはしない。
    • この際、どこまでもサイズが増大する可能性がある。よってバグの登録数にはラインを引く。30個とか適当なサイズを。また、バグのレベルとしてはブロッカー(絶対リリースに支障が出るバグ)かどうかなどを問い合わせて重要度を決めて登録するか決める。

バグを可視化する

何をやるべきでどんだけ今後やるべき仕事があるのか。あまりに多いならプロセス改善が必要だし、余裕があるならば今後のイテレーションに関する学習を行うことができる。

また、くりかえし起きてしまうバグに対してどのようにアプローチしていくか。繰り返し発生するバグのステージから引きずり下ろすために分割統治的なアプローチをかけていくべき。 例えば根本原因を見つけるために因果関係図を描くなどをすべき。 これを用いて本来やるべきモジュールなど、何が問題であるのかなど本質を捉えるのに役立たせる。

例えばこれによって、

  • 不要なモジュールのリファクタリング

  • ドキュメント作成に対してコストを取る。

  • (テスターや作り手同士で)お互いの技能を幅広く活用するためにどこぐらいのレベルでコラボレーションしていくかを示していく。

バグの根本原因が必ずしも技術的課題だけではないということをまずはしっかりと念頭においてほしい。ここで述べてるのは自分の技術に依存しない整理して本質を得るために書いていることを再度認識しよう。

みんなもないだろうか。数学の計算をする際に急ぎすぎて字が汚くてケアレスミスをしてしまって間違ってしまったこと。これにプロジェクト開発は似ている。多くの人がそれによって手戻りで失敗してしまう。

プロダクト(方針や開発を進めること)の中で生まれたバグというのはプロセスのバグから生まれる症状である。じゃあプロセスってどうすればもっとより良くしていけるのかを考えていこう。

継続的プロセス改善とバージョン管理

プロセスをデザインするというのはとても難しい。何故ならばプロセスというのはスケーラビティを求められるプロジェクトに包まれるものである。つまり、プロセスもスケールして変化を求められる。

そこでプロセス改善エンジンを導入していく。要は機械学習と同じで評価関数を決めてそれに対して定常偏差を合わせていくといったイメージである。下に一般化して示す。

  • 明確さ
  • プロジェクトがどのような状況なのか誰にでも伝わるように目立つところに誰もがわかる明確なゴールを示す。
  • 一週間目標などを用意して目標を層にするの有効である

  • コミュニケーション

  • チーム内で定期的にプロセス改善ミーティングを開く

  • 統計データ

  • プロセスを改善できたかどうか。できるだけシンプルな方法で動向を追跡する。
  • 例えば、ベロシティ(開発した機能の数)、サイクルタイム(機能一つあたりのかかった週)の二軸で見るなど

この三つである。これを行なっていくことで自己組織化を目指していく。

さて、これを行うに当たってチームの振り返りなどは必須である。 良くある振り返りの方法として、他者を呼んで、外部的視点を見てもらうことをしてもらうこと。他にも色々方法はある。

さて、それを通じて良くある改善内容としては

  • もっとコードをコミットしよう

  • ミーティング方法を変えていく

  • コーディング規約を更新

  • チーム内に新しい役割を増やす。バージョン管理の主幹の人を作ったり、様々なインフラ的な問題が起きた場合主幹となって動くゴールキーパーを作ったり。

これらの振り返りのキーとして、エスカレーションポイントを用意することである。エスカレーションポイントとはチームを超えて影響を与えたる、一緒に解決したりする。たとえ他のことをしているとしても、お互いにプロセスの改善を行うことで視点が養われてシナジー効果が期待できる。

プロセス改善ワークショップ

振り返りの手引きをざっくり示したい。 これを開く意義は、仕事のベクトルを明確に、そして改善することである 当該書籍ではスクラムオブスクラムで示されているが、ここで話される取り組みというのは他にも適用可能だと考える。 以下に示す。

  • 場を設定する
  • テーマを決めてそれに集中する

  • データ収集

  • 以前に実施したワークショップから行なったことを話し合う

  • アイディアを出す

  • データをもとにそれらにどんな意味があるのかを議論する
  • そして辛いポイントを出して、それを今後どうするのかを具体的に示していく

  • 何をすべきか決定していく

  • 振り返りを終了する

    • 次のワークショップまでに誰が何をすべきかを決めてクロージングする

ワークショップではみんながさっさと話せるように心がけるべきである。今思っていることをサッサといってみようと投げるぐらいの勢いで手早くしていくのがいいだろう。 しかしながら目標を見失っていくのではダメで、期待すべき事柄をしっかりと示していくことが大切。

これは運用次第であるが、リーン主義で居続けるなら漠然としたことを許さない可能性もあるが、クリエイティブな、カンバンといったことであるならばブレインストーミングや直感で決めるというのも大切である。ただしいつかは抽象から具体に変えなくてはいけないのを念頭におくべき。

早すぎても難しい

当該書籍では興味深いことを述べている。 以前は変化が少ないことが問題であった。今回は変化が多すぎることが問題だった。 ほどほどというのが必要だと感じる話だ。

こういう時はプロセス改善提案書を書いて一手間加えるワンクッションを入れてもらうことにしている。 理由は提案者に対して簡単に出しすぎないようにする枷であり、何故こうしたいのかということの再認識をすることができるからである。

  • あなたが改善したい問題は何?

  • この変更で誰が影響を受ける?

  • この変更を実施する上でどのように進めるべきなのか?

  • どれくらいのコストがかかってくるものなのか?

  • これを実現するのにどのように分割できるのか想定させることができる(注意すべきはここまではやらせるべき範囲が違う。ここでは問題を分割するのではない。)

迷ったらシンプルな解決策を選ぼう。

因果関係図

根本原因分析を行うのに有用な方法である。 なんでこれが必要かというと、適当に解決するとまた浮き彫りになlって厳しいことになるからである。 具体例を挙げると * 寝室に煙が充満してる * 窓を開けて、また寝る(ダメな例) * 煙の発生源を見つける。おっと危うく火事になるとこだったぜ(良い例)

といった話である。

A3シンキング

リーンシンキングの中核にある教えの一つとして、継続的なプロセス改善を表す「カイゼン」という言葉がある。 トヨタ曰くこの正しい問題解決手法を厳格に運用にしたからであると表現している。これをA3の用紙に描くのでA3シンキングという。

A3シンキングのサンプルやテンプレートはネットにあるので要参照 テンプレートリンク

因果関係図の使い方

基本的な流れはこう。

  • 問題を選んで書き出す。

  • 明らかな損害やそれの弊害を上向き(トップダウン)に突き止めていく

  • つまりこの書き出した問題が理由として扱えるように描く
  • 問題:リリースした奴がバグって死んでる
  • 突き止め:リリースした奴がバグって死んでるー>客がキレる

  • 根本原因を下向き(ボトムアップ)に見つけていく。

  • テスト不足
  • 描く時間が不足してたなどが上の例には当てはめれる

  • 図に現れた循環(基本的に悪循環)を特定して目立つように描く

  • 図を洗練するために上記をイテレートする。

  • 根本をどう解決するか(ミーティングに持ち込んだりする)

これを行なっていく。 もし今回の場合はテスト自動化のトレーニングとかが足りないとかそういうとこに帰着するであろう。

因果関係図の書き方

ぼっちなら線画ツール好きなの使って頑張ってくれ。

複数人8人以下ならホワイトボードや付箋と模造紙で書いて作ろう。

30人以下とかの大規模なら人数を分けて具体的な問題の一つに着目して纏めたりしておく。最後に持ち寄って纏めたりする

定期的にこれをちゃんと認識できるシステム組み込みが必要だったりするのでそこはアナログツールに頼ったりしていくべき。

よくある失敗

  • 幅優先ではなく、深さ優先探索で見ていこう。

  • 問題領域が広すぎる場合がある。分割可能な問題になのではないのかということを見極めよう。

  • 簡略化しすぎない。専門用語ではなくできるだけ一般化した言葉で話すべきである。

  • 具体例に頼ったり、専門用語に頼るのは説明ではない。一般化してる表現で説明してこそ本当の説明なのだ。

  • いらないのが出てくるけどそこは問題ではなく、根本に辿れるかが問題。あくまでブレインストーミングのような形でも問題はない。

  • 個人攻撃をしないように気をつける。しばしば誰かが足を引っ張ってることがるだろう。しかしそれはチームで解決すべき問題だ。出来ないならばそれを解決するプロセスが工数なだけなのだ。そもそとして問題解決ができるのはそのシステムに要因があると仮定できた時のみなのだ。

なぜ因果関係図を使うのか

  • 共通理解を構築するためある。
  • 他の手法としてはストーリーマッピングが挙げれる

  • 問題がどのようにビジネスに影響を与えるか明確にする。

  • 根本原因を見つける

  • 悪循環のループを見つけ、潰す

なぜやるかを意識して問題解決に当たろう。

終章 まとめ

なんでこんなのを纏めたかというと、学生が情報技術を学ぶというの通じて楽しいというのを続けたいならば、それを業務にうまくたたみこむ必要が有るんだぜということが最近よくわかってきたからというのが大きい。

結局最近思うのは実用技術>>>大局的な開発手法ということがやればやるほど僕らは痛感するだろうと思う。現に本質的ではないgitがわからなくて右往左往してみたりまだまだ辛いものはある。精進したいものである。

間違えがあったらそっと教えてください。

参考文献

学生アルバイトが決まった話とそしてコミュニティ

こんばんは。学生アルバイトで学費を稼がないと大学が通えない疑惑が出ている竹です。(初めから重い)



kazukichi.hatenadiary.com
かずきちくんがなんかこの前言及していてたということと、この前そうえば内定したよということは話してもいいと言われたので、高校生学生アルバイプログラマ(?)として僕も思うところがあって喋って見たいと思います。

僕は一発で決まってしまったのでこれから学生アルバイトとして飛び込みたい人向けではありませんが、今後何したいんだろうという話をしたいと思います。

結局どこに決まったの

インフェニットループっていう北海道で有名な会社に決まりました💫
(いやまだ定期考査明けに出社なので内定ってだけなんですけど)←
それで今年度仙台支社ができて私はそこで働くことになりました。ぜひ何もできない若輩者なので各位ご指導の程宜しくお願い申し上げます><
www.infiniteloop.co.jp


どうやらブログや大会出場を評価してくださったようで無事内定が決まりました。ぜひ自分の技術に思うところがあるなら主張してみると案外通るかもしてません。ぜひ仙台支社に仲間が増えたら私も嬉しいです!

社風としてはかなり自由な風通しのいいようで、私はとてもワクワクしています(ダーツボードがあったり生ハムの原木があったりもうなんかフリーダムすぎる笑)🌟
先輩方からいろんな知識や技術を奪えたらいいなぁと思います!!!頑張ります!

さてそれで何が思うことがあったの?

この会社を選んだ一つの決め手は情報技術のコミニュティを大切にしていることでした。
例えば勉強会やLT大会を開くにあって場所を貸してくださったり積極的に勉強会にコミットしたりなど、`仙台ではまだまだですが`北海道ではとても羨ましいぐらいに熱く!!!行なっています。
ですが仙台ではまだまだです。



そこで私は一つ野望があります。




私のいるこの仙台駅を中心に学生コミュニティを組み上げたいという野望です。
これに対しては強い気持ちがあります。主観ですが仙台の学生コミュニティはとても内向的なところが多く感じています。ざっくりとした話表面に出てくるのは東北電子専門学校のあたりのコミュニティと東北大のボンプロさんとかのコミュニティ。ぶっちゃけこの辺ぐらいしか観測できていません。とても素晴らしく学生の身分でこんなにやれるなんて素敵だと思います。ですが同じ身内ばかりで内向的なところがどこかあるのではないのか、それによって狭いところで悩みを話せず同じ共通認識がなくだから仙台はと言われる悪循環を作ってるのではないのかと強く感じます。



ですので私が考えているのはみんな所属の違うコミュニティを作るべきだと考えます。
強いていうなら風通しのいい、大学生でも、高専生でも、高校生でも、中学生でも、初心者でも、ガチプロでも自分のやってることを発信して相互的に学べるシナジーのあるコミュニティを持つべきだと強く主張します。個人単位では技術を持った人が多くいます!


そのためにも立ち上げたいと感じているだけではダメで私よりもいろんな意味でバカな奴が仲間に必要です。ぜひ私と仲良くしてくださったらとても嬉しいです!


また今後これを達成するために定期的に声を大にしてプログラムを書いてるんだぜっていうブログを書こうと思います。ぜひよろしくお願いします(着地点を地味に見失ってしまった)

「2017年にやりたいこと」

今週のお題「2017年にやりたいこと」


takeio.hatenablog.com

 恒例の抱負を書こうと思ったらはてなのお題があったのでこれを利用して少し書きたいと思います。

抱負

  • 勉学面

 数学と英語と物理を人並みにできるようになりたいです。
 数学物理は頑張ればどうにかなる機運があるんですが(自称)
 英語ばかりはどうにもダメです。これは中学からそうなので今年こそは本腰を入れて挫折しないように頑張ります!
 あと進学な()


  • 生活面

 自分で目覚ましで起きよう。たまに起きれない!!辛い!!
 あとご飯のレパートリー増やしたいなー。あと男女ともに友達を増やしたい!僕は友達が少ないだからね。。。(性格に難があるのではという気持ちだなぁ)


  • 趣味

 ダーツでのレーティングをAフラを目指したい。
 あと音ゲーを人並みに目指したいなーと思います。デレステ初見で死んじゃうの辛い。
 それと暇があれば剣道の昇段審査を受けて三段取りたいです✨


 セキュリティについて去年ちょいちょいついばむことしかできてないので本腰を入れて学びたいな。特にPwnとWeb。具体的には入学までにヒープ問題の知識があったり、ブラインドSQLiをどうにかして何も見ないで書けるようになりたい。それとインフラ周りの知識を詰め込みたいな。


 それとコーディング力がないので競技を始めようと思う。基本的なダイクストラやBFSなどはできるけど時間かかるし、DPとかはできないし、ダメダメですね。。。一年をかけてあり本を終わらせたいなと思う。それとatcoderのビギナーズと普通のやつにも毎回参加して解き直すのを癖付けたい。


 そして一番のメインは計算幾何学について知見を深めたいです。特に計算論理についてなど。全然Coqとか使っててもよくわからんパズルやってる気分だし、きちんと、しっかり、身の丈にあった学びをしてステップアップしたい。




・・・・結構あるな。。。どうやって配分したらいいんだろう・・・誰か教えて・・・

  • イベントについて

 LT大会を開きたい!結局高校の時部活が忙しすぎてできなかったので是非頑張る。
 ハッカソンに参加する!時間内にそれなりのコードを叩けるようにするぜ!
 今年こそセキュキャン受かるぞ!雑魚並みの力を見せてやるぜ!()
 また、情報系のアルバイトをしたいと思います。ぜひレベルの高い人たちから学びを得たいです!

締め

今年も至らない点あると思いますがご指導ご鞭撻を賜りますようよろしくお願い申し上げます。