技術広報ブログ

技術広報のためブログです。

30代ではじめてブリーチをした話

はじまり

リモートワークを推進している企業が多くなっていますが、リモートワークならではの悩みも多くなってきたと思います。個人的な悩みの一つに「社員の顔がわからない」というのがあります。これは入社したての方なら誰でも思い当たると思いますが、リモートワークだとそもそも挨拶できる機会もないのでなかなか解決が難しい問題です。しかし、これは新入社員だけでなく、既存社員も新入社員がだれだかわからない、という問題につながると思います。

 

そのようなことを金曜日に上司に相談したら、帰ってきた言葉がこちらです。

「金髪にしたら?」

え?

「髪染めるのは誰にでもできるし、セルフブランディングは大事だよ」

とのことでした。

今まで髪を染める理由を理解できていなかったのですが、この言葉を受けて、人生ではじめて髪を染めてみようかと思います。

 

店選び

さっそく土日に利用できるお店を探します。知り合いに聞いたら「少なくとも1万円は出してちゃんとした美容室行った方がいいよ」とのこと。[カラー うまい 美容室 メンズ]で検索をし、近い順にクチコミを見ながら決めていきました。それでも膨大なお店の数がありますので、男性もよく利用している所を探していきます。

メニューはブリーチとカラーが必要なので、ツーカラーで1万6千円という価格です。

 

施術中

施術中は特にこれといった話はしていないのですが、人生で始めて髪を染めると言うことで、経緯は結構聞かれました。「会社愛半端ないですねw」というノリでしたが、丁寧にカラーリングしてもらいました。

ブリーチをしてもらった結果がこんな感じ。



こんなに綺麗に金髪になるんだ、とわりと感動していましたが、完全にヤンキーですね。

 

美容師からも「ブリーチすると一人東京リベンジャーズになるのは避けられないのですが、もう一色塗っても東京リベンジャーズが追ってきますね」そこから2色目を塗るにつれて、テンションが上がってきたのか、「これって実はタイムリープしてます?」「握手するとトリガーになったりしますか?」と東京リベンジャーズネタでいじられつつも完成した色がこんな感じ。



「もう少し赤くなったら一人SEKAI NO OWARIですね」という仕上がりになりました。

最終的にはセックスピストルズジョニー・ロットンみたいな髪になり、社会人として色々なものを置き去りにしてしまいましたが、職場ではどんな反応されるのだろう? もう完全にセルフブランディングという言葉は置き去りになってしまっていますが、顔を覚えられたらいいな、と思います。

Rust勉強メモ1

7月16日に開催されたRustのもくもく会に参加したので、勉強したことをメモしておきます。 基本的にはソシムさんから刊行された『手を動かして考えればよくわかる 高効率言語 Rust 書きかた・作りかた』を動かしながら読み進めています。

インストール

curl -- proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

パス

export PATH="$PATH:$HOME/.cargo/bin"

バージョンの確認

rustc --version

バージョンのアップデート

rustup update

VSCodeをインストール。拡張機能でRustが非推奨になっており、代わりにrust-analyzerをインストール。

Hello Worldのコード

fn main(){
    println!("Hello World")
}

コンパイル

rustc hello.rs

実行

./hello

Rustは必ずmain関数を記述する必要がある。このmain関数をエントリーポイントという。 Rustには末尾に「!」をつけることがある。これはマクロであることを示している。

文字列に埋め込むには、{}の中に変数を置き換えて表示する Rustでは変数への代入を「値を変数に束縛する」というらしい。

fn main(){
    let price = 300;
    println!("ガムの値段は{}円", price)
}

四則演算の問題。答えを見ずになんとなくで書いたコード

fn main(){
    let bike = 80.0;
    let train = 300.0;
    let moon = 384400.0;

    println!("バイクの場合は{}日です", moon / bike / 24.0);
}

適当に書いた割には合っていたようですが、「train変数が使われていないよ」という警告が出る(おもしろ)。

warning: unused variable: `train`
 --> q1.rs:3:9
  |
3 |     let train = 300.0;
  |         ^^^^^ help: if this is intentional, prefix it with an underscore: `_train`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

実行結果

バイクの場合は200.20833333333334日です

Rustは型に厳しい言語なので、整数と実数は明確に区別される。

■for文の書き方

for 変数 in 開始地 .. 終値 +1 {
    処理
}

■if文の書き方

if 条件1 {
    処理1
} else if 条件2 {
    処理2
} else {
    処理3
}

■print!とprintln!の違い

print! = 改行がない

println! = 改行がある

■変数

letで宣言した値はイミュータブルな変数になる

let 変数名 = 値;

ミュータブルな変数にするにはmutをつける

let mut 変数名 = 値;

Rustでは不変な変数が基本となっている。 余計にmutをつけると、以下のように警告が帰ってくる

fn main(){
let pc = 98000.0;
println!("A社は{}円です", pc * 0.8 +1200.0);
println!("B社は{}円です", pc * 0.9);
}
warning: variable does not need to be mutable

Rust勉強メモ1

7月16日に開催されたRustのもくもく会に参加したので、勉強したことをメモしておきます。 基本的にはソシムさんから刊行された『手を動かして考えればよくわかる 高効率言語 Rust 書きかた・作りかた』を動かしながら読み進めています。

インストール

curl -- proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

パス

export PATH="$PATH:$HOME/.cargo/bin"

バージョンの確認

rustc --version

バージョンのアップデート

rustup update

VSCodeをインストール。拡張機能でRustが非推奨になっており、代わりにrust-analyzerをインストール。

Hello Worldのコード

fn main(){
    println!("Hello World")
}

コンパイル

rustc hello.rs

実行

./hello

Rustは必ずmain関数を記述する必要がある。このmain関数をエントリーポイントという。 Rustには末尾に「!」をつけることがある。これはマクロであることを示している。

文字列に埋め込むには、{}の中に変数を置き換えて表示する Rustでは変数への代入を「値を変数に束縛する」というらしい。

fn main(){
    let price = 300;
    println!("ガムの値段は{}円", price)
}

四則演算の問題。答えを見ずになんとなくで書いたコード

fn main(){
    let bike = 80.0;
    let train = 300.0;
    let moon = 384400.0;

    println!("バイクの場合は{}日です", moon / bike / 24.0);
}

適当に書いた割には合っていたようですが、「train変数が使われていないよ」という警告が出る(おもしろ)。

warning: unused variable: `train`
 --> q1.rs:3:9
  |
3 |     let train = 300.0;
  |         ^^^^^ help: if this is intentional, prefix it with an underscore: `_train`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: 1 warning emitted

実行結果

バイクの場合は200.20833333333334日です

Rustは型に厳しい言語なので、整数と実数は明確に区別される。

■for文の書き方

for 変数 in 開始地 .. 終値 +1 {
    処理
}

■if文の書き方

if 条件1 {
    処理1
} else if 条件2 {
    処理2
} else {
    処理3
}

■print!とprintln!の違い

print! = 改行がない

println! = 改行がある

■変数

letで宣言した値はイミュータブルな変数になる

let 変数名 = 値;

ミュータブルな変数にするにはmutをつける

let mut 変数名 = 値;

Rustでは不変な変数が基本となっている。 余計にmutをつけると、以下のように警告が帰ってくる

fn main(){
let pc = 98000.0;
println!("A社は{}円です", pc * 0.8 +1200.0);
println!("B社は{}円です", pc * 0.9);
}
warning: variable does not need to be mutable

NFT Summit Tokyoに行ってきた感想

2022713-14日に蒲田でNFT Summit Tokyoというカンファレンスが開催されたのですが、せっかくの休み期間なので参加してきました。

 

NFT Summit Tokyo 第2弾

https://www.nft.pivot-tokyo.com/

印象に残ったセッションを簡単にメモしてきましたので、こちらに公開します。

全体の感想としましては、やはりWeb3に対してどのように対応していけば良いのか答えがまだはっきりとわからない手探りの状態なのだな、と思いました。登壇者の皆様が強調していたのは、いまが乗り遅れないためのチャンスで、いま動けるかどうかで23年後に大きく変わるとのことでした。

今回のカンファレンスを受けた感想として重要なこととして、まず自分がしっかり勉強をする(Rust勉強しないとな)ことと、Web3を構成するもの(暗号通貨、NFTDAO)を構造化し、自分たちができることを見つけ、まずはそこから初めていくことだと思いました(まずはNFTのマーケットを作るのが良いそうです)。

 

以下、メモです。

[M-2] NFTブロックチェーンの未来アジアWeb3企業のグローバル戦略とは

データは企業のサーバーに保存される所有することはなかったが、これからは見る、書く、所有する、といった強力なパラダイムに望む望まないにかかわらず、全てのWebWeb3に移動する。

今後は518ヶ月で5%10%の人がブロックチェーンのゲームに移動してくる。ただし、期待されるほど高品質なものは出てこない。

 

西洋とアジアではプロックチェーンポリティックス(仕組み)の理解が違い。アジアにおいて民主主義はまだ若く、資産の所有権や投票といった合意主義の歴史は西洋のほうが長い。Web3自由形のオープンシンキングを理解するためには哲学、社会学、政治、金融などを理解する必要がある。単純に技術の話だけではなく、そして明確なものではない。人間の扱っているものすべてに関わる。

 

中国は自由に参入できていないインターネット初期にも起こった。最終的にはオープンなインターネットを諦めなければならなかった。

 

——

[M-3] シリコンバレーから見たWeb3の「今」

日本は働き方が変わっていない。

今は暗号通貨の価格がすごい下がっているけど、前の冬ほどは下がらない。ここ23年は加熱しすぎており、詐欺みたいなプロジェクトにもお金が集まっていたので自然淘汰されている段階。2024年にむけてコツコツと技術革新をしていくのが重要。

 

リップル12年目でかなり老舗。リップルの目標としては以下の通り。

  • 価値があるインターネットを実現する
  • 日本円やドルといった通過に限らず価値のあるものを財産にする
  • 今まで価値として見られなかったものを見つめ直す
  • 国際送金にブロックチェーンを活用していく
  • ブリッジ通過として活用していく
  • 全ての価値あるものをトークン化していく

リップルは国際送金に強いが、価値の交換ができるプラットフォームを目指している。

アメリカも薔薇色ではない。アメリカでは暗号通貨の存在が法的にははっきりしていない。日本では2017年に資金決算法で整っているのでそれほど遅れてはいない。

 

これから盛り上がる領域

2020DeFi

2021NFT

2022DAO

 

DAOにはトークンを持ってないと入れない、投資系のDAOとかソーシャル系のDAOとか実際に入ってみて、トークンをもらうのがおすすめ。「日本で広めるから!」とか言う。

 

試行錯誤の段階だけど、トークンを持っている量によって意思決定をするのは金融主義になってしまう。なので譲与できないトークンを配布する。中央集権とDAOはケーズバイケースで使っていかれると思う。FacebookTwitterでも良いサービスを作るにはどうしてもデータを集めて機械学習の分野に行かないといけなかった。

DAOは今までなかったチョイスを選べる。破壊的なイノベーションが来た時の選択肢として、今までできなかったことを取り入れて、独自に進化していく。

 

日本のコンテンツはすごい。日本大好きって人は多い。NFTは最初から世界に販売していく、ファンコミュニティの運営は日本が強い。新しい日本にもDAOが生まれるといい。

 

——

[M-15]ゲーム x メタバース

メタバースにおけるブロックチェーンゲームの可能性

 

メタバースは定義が様々だけど、これから10年間にかけて大きくなっていくと思われる。コミュニティをどう作っていくのかが重要。

Daoコミュニティをどう作っていくか?

 

MyCriptヒーロー ずっと世界ナンバーワンのブロックチェーンゲーム。Opensea9割がマイクリの取引で2万イーサを売り上げた。企業に頼らないネットワークを作る。

ガバナンス好きな人が好きな世界を作っていくのがメタバース(同人誌)、ユーザーがゲームを作っていくのがDAOWeb3というのはファンベースで作られていく。完全独立法人からDaoへの移行が難しい。

 

DAOを回していく。専門性が低い人たちが集まるとうまく行かないけど、それは多数決や民主制の問題。必要なこととしてコミュニティの質を高めていく。ゲームの場合はどうしても中央集権で立ち上げるしかない。一部分だけコミュニティに譲渡していくのが定石。DAOは手段なので、全部をDAOにする必要はない。一部のキャラクターの名前をDAOで決めるとか(メタバースは多用性)。企業が何かを変更すると炎上することが多いが、ユーザの投票で決めれるのは責任の共有ができる点がある。51%あったら、それは正。

 

レディ・プレイヤー1という映画はコミュニティベース。

 

NFTは暗号資産ではない。株と違ってインサイダー取引の規制ができていないので、自分たちで規制していくしかない。

 

トークンの発行が日本だと難しい。シンガポール法人で作っている。

 

日本は今ガイドラインを作っている。主に賭博罪とマネロン。3Dは日本が優先して作っていって欲しい。メタバースNFTもグローバルが作っている。仮想通貨はダウントレードだけど、今は仕込みの時期。若い人たちシンガポールに来ている。すごい重要な産業になるので日本国内で作っていく。冬の時代だからこそチャンス。ここから12年がチャンス。

 

——

[M-4] Web3の本質と未来「イーサリアムの原則」

イーサリアム財団の中に日本人は6人しかいない。

ビジョンがないのは生き残られない。イーサリアムは分散型、公共性、誰にでも平等なアクセスなどに拘っている。主要者がいなくなった後でも生き続けるようにするにはどうすれば良いのかを考えている。

イーサリアムが生き残れたのはビジョンがあってプロダクトではないから

  • 長期思考
  • 引き算の美学
  • 価値観を守る(継続する)

 

キーワードはDegen to Regen

Daoのコミュニティを作っていくのは日本はすでにやってきていた。ツールは人間がどう使っていくかが重要で、日本人はガバナンスが自分たちでできる。資本主義も共産主義も政府が誘導してというのはうまく行かなかった。

 

——

医療とWeb3

シリコンバレーから最新報告

薬の開発時にDAOを使用する。メディカル危機の管理や薬局の開発に使用している。BiotechDAO。例えば不老不死の研究をしてください!などに票が集まる。

どこの国からどこの人でも入っていける。リサーチファンディングによく使われている。メリットとして薬局のコスト削減につながる(薬一個の開発に10億ドルから20億ドルかかる、開発だけに年間900億ドルかかっている)

 

——

クリエイター vs 政治家 日本のweb3 推進政策と課題

Web3を国家戦略にした

24の課題と提言をした(NFTホワイトペーパー(案):https://www.taira-m.jp/2022/03/nft.htmlWeb3は範囲が広く全体を変えないといけない。かなり大きな仕事。担当する省庁がない。ガバナンストークン課税問題とか、暗号資産に対する税金MAX55%とか。

 

日本は動きが遅いというのはその通りだけど、英米はまずはやってみる、問題があれば議論をするといったアジャイル的な運用が国単位でできている。今はどうやって成果を得るか絶望的な状態にはなっている。Web3は日本だとガラパコスではなく無人島になる。日本ってどれくらいの価値があるの?って話。

いま起業家に相談されたら、まずシンガポールでやったほうがいいよ、と言う。政府の理解に時間がかかる。

 

アーリーマジョリティの数が少なすぎる。クリプトは積み上げ式で知識を深めていく。

誰に聞いても正解がない。日本が有利なのは知財。アニメ、ゲームといったサブカル。中国に対抗するWeb3は西洋諸国の国家戦略としては正しい。

——

 

[S-1] クリエイターから見るNFTの戦略

楽しいからやっている。金儲けの話からではなく、何が楽しいか、から話さないと乗れない。

 

NFTは子どもが手を出せないのが一番きつい。ビックリマンシールみたいなコレクションができない。そうでないと文化的な広がりが持てない。

広げるにはストーリーが重要、報酬が分配される。

 

[M-7] Web3が可能にする世界のジャパン・クリエイティブ

初回から世界を目標としている。規模感から世界展開をするのが普通。ひたすらインディーズで行っていく。NFTはアートといった一つの視点からみると不可解になる。

 

パーティーに行くと多用性がなく白人の男性が多いけど、ギャルバースは女性も多く国も様々。コミュニティとしてバランスを取っていく。プロジェクトで回していくには、アーティストリスペクトが重要。アーティストを表に出してあげることとか。

 

大変なこととしては、NFTの価値観を共有していく。大変なことは予測しておく、サーバーがダウンしたら、こういうコメントを出すようにするとか。

——

[S-2] How to dive into web3

大企業がWeb3に入っていくために

Web2ではデータを所有しても、企業のサーバーに入っているので、企業が潰れたらなくなる。Web3はインターネットでいうとドットコムバブルが終わる時期。暗号資産にいきなり入るのは難しい。まずはNFTから始めるのが始めやすい。→だれにNFTを配るのかが問題。NFTを配るのに対象者が今はほぼいない。持続可能性の仕事をできるのかが考えなければならない。

 

だれでも参加できる企画をどうデザインしていけばよいか?

炎上しないためにはWeb3としての思想を

 

技術的検討項目

チェーンをどうするか?

イーサ。ポリゴン。ソラナ。ASTARLINE

処理スピード

保守性

安全性

 

支払い通過をどうするか?

ウォレットをどうするか?

マーケットプレイスをどうするか?

財務会計的視点

ガバナンス問題(ウォレットの管理とか)

 

BeReal1日に2回しか投稿できないSNS。希少化された帰属意思に再帰してきた。

 

ちゅらうみ水族館のジンベイザメの所有権を売るとか

——

2日目

Web3の未来

Web3は人々の生活をどのように変えるのか

ファンクラブをどうやって長く価値を持たせるか。

Web3の一番面白いところは透明性とか、決算手数料とかではなく、ロングターンで考えて直接参加者とアーティストがつながることができる。

マーケットをどう作っていくのかが日本のポイント。

本当は自分の人生は自分が経営者にならないとならない。

自分が表現するために勉強していく必要があり、それが3年後に差がでそう。まずは4割からスタートしていく。

Web3は前に行くしかないので、安心して突っ込んでください。

 

———

Web3で勝負をかける若き起業家が描く未来

Astar Networkはレイヤー1の日本発パブリックチェーン。チェーンとチェーンを繋ぐマルチブロックチェーン

Webがでてから日本は負け続けている、次の成長企業ってなに? Web3.0のプラットフォームを取りに行く。

Web3の事業は税制が一番厳しいけど、税制を変えるのは企業家の仕事ではない。

技術レイヤーで戦える技術者が出てくる必要がある。

Web3.0は現状ではインフラに問題がある。チェーンとチェーンをつなぐプロトコルがまだ整っていない。

 

日本人ってそもそもあまり0から1を作った経験が少ない。イノベイティブは欧米に任せてもよくて、日本人の強みは改善にある。

日本はマーケットが構造的に小さくなっていくので、外貨を稼いでいく人が増えていくといい。

 

開発言語はSolidityが主流だけど、イーサリアムを動かすものとしてできたので、スマートコントラストでの汎用性が高いとはいえない、またセキュリティがよろしくない。

Rustネイティブだと型が厳格なので、コンパイラエラーがわかりやすい。セキュリティも安定している。パフォーマンスもよい。Web3をやるならRustWebアセンブリーがよい。Polkadot100%Rust

——

独自のNFTプラットフォームを構築するには:技術からマーケティングまで

 

宣伝はWeb2がまだまだ強いので、Web2の人たちは拡散することに強みがある。

まだ1%イノベーションしかない。

DAZNは新規にNFT事業に入った。

真ん中のサブスクを軸に、スポーツを中心にいろいろな可能性に挑戦する

企画自体は2年ほど。→権利をどう獲得するかが問題にあった。

 

開発はMIXIさん、グルーバルでNFTマーケットプレイスDapper)を作っていた。

コンテンツとして動画をもとに選手をNFT化。選手、クラブ、Jリーグとの権利獲得が難航

 

まずは一人でも多くの人に買ってもらうので安価で販売している。

今度セカンダリマーケットプレイス(ユーザー同士で自由に取引ができる)を作る予定。平等にするために抽選販売をしている。

NFTを持っていたら、選手に会えるとかの特典を行うかも。

———

Web3プロダクトの刺さるUXの作り方

クチコミ大事!

UIとしてはハントの報酬がある。

安心安全を伝えるためにSNSの更新がある。

PMFPCMを意識する。Web2Web3はどうでも良くて、ユーザーが誰で、何を提供するか?が大事

 

———

アニメを中心としたコンテンツプロデュース会社が、なぜNFT事業にチャレンジするのか?

AnimapはジャパンコンテンツのNFT事業進出を支援している。

まずはイーサから始めて、秋にポリゴンを実装する。

イーサかクレジットカードで購入可能、エアドロップができる。

デジタルコンテンツ開発から、販売までを一気通貫でできる。

コンテンツ価値の最大化、コンテンツの価値を最大化させていく。

どうやってファンを繋ぎ止めていくのか?

成功したと言えるプロジェクトはまだない。

 

ファンサイドの課題感

- ウォレットをつくらないといけない(体験設計)

- 作品愛がある

- すでにあるもので満たされている

 

IPホルダーサイドの課題感

- 製作委員会の壁

- 作品ファンとNFTファンとの向き合い方

- リスクにつながる

 

どうやったらファンとのコミュニケーションを成功させられるか?

- IPの持続価値を理解する

- ファンの推しを知る

 

———

才能ある世界のWeb3プレーヤーを日本に惹きつけるためには

英語で情報を入手するとよい、もちろん考え方を変えるのも重要

まったく違う挑戦にチャレンジになる

 

10億人の人たちにアピールする必要があるが、日本の場合だとアニメ・漫画があるからIPとしてはとても強い。日本にはnftのマーケットリーダーになれるか可能性がある。日本が投資するにはそこだと思う。

クリプトを作る会社、教育、ローカリゼーション、エコシステムなど課題があるがまだ日本市場は重要だと思われる。

 

エンジニアを雇うにはどうすればいいのか

快適さや成功を手助けする必要がある。高い給料を払う、若い日本人が英語を話せるかが重要

日本のWeb3にお会社は10年もたっていない。Web3は世界で最も動きが早く、これからもっと早くなると思う。

アジャイル開発とスクラムの基礎勉

今日は昨日に続いてアジャイルについて学ぼうと翔泳社さんから2001年に刊行された『アジャイル開発とスクラム 第2版 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント』を読みました。昨日読んだ『SPRINT 最速仕事術』でsprintに触れたのですが、よくよく今回の本を読んで見えると、スクラムのスプリントとスプリントって別物だったんですね。今回は改めて、そういったアジャイルスクラムの基礎を知ろうと思います。

【概要】

読んだ理由:アジャイルスクラムの基礎を知りたい

学んだこと:アジャイルスクラムの基礎と進め方(プラクティス)を学んだ

実践すること:まずはインセプションデッキ(チーム結成時のドキュメント)作成から始める

 

読んだ理由

今までのキャリアのなかで、チームで動いたことがほとんどないので、うまくチームに馴染めるようスクラムはなんとなく学んでおきたいと思っていました。今回この書籍を読んだのは大正解で、やはりソフトウェア企業は面白そう、という気持ちになれました。時間があったらオーム社さんの『アジャイルサムライ−達人開発者への道−』も読もうかとは思いますが、現状ではこの本を読み込めば良さそうです。

 

学んだこと

まず勉強になったのが「IT(開発)のゴールはビジネスとしての効果をあげること」ということです。IT活用の本質として「業務の効率化」というのはよく言われていることではあるのですが、「完成させること」がゴールではないことは頭の片隅に入れておくのに良いと思いました。

その上で「アジャイルとは?」というお話ですが、もとはベトナム戦争従軍時に極限状態での臨機応変なマネジメントの重要さに気づき、その後ハイテク企業を渡り歩く中で作られた価値観だそうです。アジャイルは価値観なので、いくつか実践するための手法があるのですが、その中でも人気なのがスクラムです。

 

スクラムは全体が協同するためのコミュニケーションルールが以下の3つあります。

  • 責任
  • イベント
  • 作成物

 

責任

責任はメンバーの役割を定めたもので役割は3つあります。

  • プロダクトオーナー(プロダクトに責任をもつ)
  • 開発者(コーダー、テスター、デザイナーといった区別はしない)
  • スクラムマスター(チーム支持する責任を持つ。障害物を取り除く)

この3つがスクラムチームになります。一般的にはオーナーと開発者は揉めがちですが、同じチームに組み込むことによって「問題VS私たち」という構造にします。

 

イベント

イベントはプロジェクトを回す期間内で起す行動です。以下のような流れがあります。

  • スプリント(1ヶ月以内の行動スパン)
  • スプリントプランニング(1回のスプリントで行う計画を練るミーティング。スプリントのゴールをメンバー全員で合意する)
  • デイリースクラム(15分の朝会。目的に合わせた再計画をしていく)
  • スプリントレビュー(成果物をデモストレーションしてフィードバックを得る)
  • スプリントレトロスペクティブ(スプリントの振り返り)

 

成果物

スプリントを回していくことで成果物が出てくるのですが、スクラムでは以下の3つが定義されています。

  • プロダクトバックログ(プロジェクトに組み込む機能の一覧)
  • スプリントバックログ(スプリントで回す機能)
  • インクリメント(スプリントを回してできた成果物)

 

スクラムでは上記のルールがあるだけです。対話を重視しており、チーム内の暗黙知を共有し、テストとコードという動くものを作っていくことによって、品質を保っていきます。人とチームを育てる「場づくり」としても注目されている手法です。

 

スクラムを回していく方法はプラクティスと呼び、プラクティスには以下のようなものがあります。

 

インセプションデッキのみ初耳だったのですが、これはチーム結成時に作成するドキュメントです。プロジェクトに対してWhyとHowを表示しておくことによって、プロジェクトの灯台にします。

 

Why
  • チームの目的
  • プロダクトの説明
  • メンバーの役割と強み、期待していること
  • パッケージとデザイン
  • やらないことリスト
  • ステークホルダー

 

How
  • 利用する技術
  • リスクの特定
  • スケジュール
  • 最重要項目の洗い出し
  • 初回の動き

 

スクラムを構成するものは以上です。スクラムアジャイル開発の中でも人気の手法で、採用理由としては市場投入までの時間短縮があげられています。

 

実践すること

スクラムはチームで成果を作っていく活動でもあるので、どのようなプロジェクトにも組み込みやすいと思います。とはいえ、プラクティスはまだ実践する機会がないので、まずはインセプションデッキを作りながら、小さなチームで実行していきたいと思います。アジャイルスクラムは勉強会でも人気のテーマなので、積極的に参加をしていきたいと思います。

最短でプロジェクトを回す方法

突然ですが、Sprintという言葉をご存知でしょうか? 直訳すると「短距離走」という意味になります。IT業界で使用される意味としては、アイデアを最短でテスト段階まで進めるプロセスを指しています。もともとGoogleが生み出した手法で、Gmailアドセンスを開発する際に使われたそうです。それ以降スタートアップ界隈で有名になり、アジャイル関連の勉強会でもよく話題になります。今回はこのSprintを実践するための書籍を読んでみることにしました。

 

【概要】

読んだ理由:言葉の意味しか知らなかったから。あわよくば次の職場で活かしたい

学んだこと:最速でプロジェクトを回すための一週間の動きを理解できる

実践すること:新規のプロジェクトの際に思い出すようにする

 

読んだ理由

冒頭で記述した通りなのですが、Sprintという言葉だけ知っていて、なんかしらの開発手法なんだろうな、とは思っていたのですが、「Sprintでガンガン回していく」といったことを最近耳にし、どういった手法なのかを知りたくて手に取りました。あわよくば、次の職場でもいかせればと思っています。

 

学んだこと

Sprintは一週間(月〜金)で問題の洗い出しから生身の人間でテストする段階まで持っていく、プロトタイプを短時間で開発するプロセスです。より重要で重大な問題を集中的に解決しよう、という主旨のようです。確かに時間をかければ良いものができるわけでもなく、ダラダラと会議が続きがちなので、時間を区切って短時間でプロジェクトを進めていくというのは合理的な気がします。

Sprintでどのように進行していくかは下記の通りです。

  • 月曜日:問題を洗い出し、どの部分に照準を合わせるか決める(プロジェクトの長期目標を定める、マップを考える、リスクを考える、自問する)
  • 火曜日:解決法を紙にスケッチする(3分ほどのデモもする)
  • 水曜日:最高の解決法を選ぶ。アイデアを検証可能にさせる(一斉に評価して、一斉に決める。15コマでストーリーを作る)
  • 木曜日:プロトタイプを作る(このプロトタイプはテスト後に捨てる)
  • 金曜日:生身の人間でテストする(テスト人数は5人ほど、それで問題の85%がわかる。テストは全員で確認する)

さすがになかなか忙しそうですね。Sprintにもルールがあり、デジタルデバイスを使わないのと、スピード優先なので決定者を必ず参加させるとのことです。決定者が参加できない場合は代理の決定者にすべて委ねることを約束させる、ということも書かれており、なるほどなと思いました。

また、一週間丸ごと使用するので、課題は大きければ大きいほど良いそうです(何からはじめればいいのかわからない、進行しないとリスクが高い、時間がたりない等)。

 

実践すること

付録に一週間のスケジュールが書かれていたり、用意するもののチェックリストがあったり、Sprintを実践させるための方法が徹底的に書かれている、非常に凝った書籍でした。わりとどんなワークショップにも流用できそうな内容で、もう少し早く読みたかったな、という印象です。

ただ、本格的に実践しようとなると機会が少ないですね。何か新しいプロジェクトを開始する際に威力を発揮すると思いますので、何かしらの機会があればこの書籍を思い出して実践したいと思います。そもそも日本でSprintを実践したことがある企業ってどのくらいあるのでしょうかね? インタビューや勉強会を開いてみたいと思いました。

 

最後にライト兄弟の初飛行を見守ったジョン・T・ダニエルズという方の言葉が心に刺さりましたので引用します。

私は夢見ている−−−誰もが自分のアイデアを信じ、ライト兄弟のように全身全霊をかけてそれを追求したら、多くのことを成し遂げられるだろう

引用:(ジェイク・ナップ (), ジョン・ゼラツキー (), ブレイデン・コウィッツ (), 櫻井 祐子  (翻訳) SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法, ダイヤモンド社, 20174262刷)

 

ちなみにジョン・T・ダニエルズが撮影した写真がこちらです。

か、解像度がすごい笑

 

Go言語のすごさとその将来性についてのメモ

結構前の話になってしまいましたが、7月1日に開催された「Qiita Night〜これだけは伝えたい!Goのすごさとその将来性〜」に参加していました。Goには興味があったので、本当に短文ですがメモ残して起きます。Goの前提知識がそれほどなかったので、今回勉強会を開いてくださり、とても助かりました。ありがとうございます。

 

【概要】

参加した理由:Rustを勉強しようかと思ったけど、Goについても関心があったから

学んだこと:GoはGoogleが開発しており、コードの一貫性にこだわった言語

実践すること:とりあえずRustを触っていく(すみません)

 

登壇内容は下記の通り。

  • LT①「弊社でのGoの取り組み〜どう広げたか、その後の人員戦略〜」
  • LT②「スケールするGo」
  • LT③「Googleソフトウェアエンジニアリングに沿った開発をするためのGoの利便性」
  • トークセッション

 

LT①「弊社でのGoの取り組み〜どう広げたか、その後の人員戦略〜」のメモ

Go言語は2018年のデータ連携バッチにつかい始めた。

その時からの課題

・みんな初心者

  • OSSコードを読んだり勉強会に参加して知見を貯める

・正しい書き方がわからない

  • Ossのコードを読んだりしてブラッシュアップ

・リリースして終わりじゃない

  • 自動化を加速して解決していった

・リリース時にバイナリ再起動が必要

  • コンテナベースの仕組みを利用で解決していった

 

人員戦略

その時に出た3つの案

  • 社内の他のチームから持ってくる → 現実的ではない
  • 新規で人を増やす → 時間がかかる
  • パートナーさんに頼る

勉強会やチュートリアルを作って、みんなで高めるようにするのが大事

 

Goの良いところ

  • 標準で用意されているツール群
  • シンプルな言語である
  • 並行処理の書きやすさ
  • ワンバイナリ(他の環境構築に持っていけば大抵動く)
  • Goユーザの愛情深さ

 

LT②「スケールするGo」のメモ

Goができた背景は次の記事に書いてある

Go at Google: Language Design in the Service of Software Engineering

https://talks.golang.org/2012/splash.article

 

Go v1の間は言語の後方互換性が保たれる(Go v2はしばらくは出ない)

コードフォーマットができている

コミュニティの意見の取り組みがある

Goの言語だけでなく文化も学ぶ

 

LT③「Googleソフトウェアエンジニアリングに沿った開発をするためのGoの利便性」

エムスリー株式会社はGoを多く採用している

Go言語の良いところはコードの一貫性を大切にしている

  • gofmtやgoimportsで標準ツールの自動化 → 公式が用意しているのが良い
  • スケーリングを可能 → 長期保守をしやすくする
  • GoもGoで書かれている → 手を動かして書き方を学べる
  • Goは驚くような書き方ができない → 初心者と経験者でそれほど差がでない

 

トークセッション

Q Goのここが困っている

情報が少なくて調べるのが大変

 

Q Goでの調べ方

公式ドキュメントやHelpコマンド、ソースコードをみて調べる。

公式のブログ

 

Q おすすめのフレームワーク

net/http、他はnet/httpのラッパー

 

Q Goの魅力

触りやすい

モジュールが公開しやすい、コミュニティもモジュールをよく公開してくれている

 

Q どの場面でよく使われているか?

WebApi、インフラ系のOSS

 

Q なんの言語に似ているか?

圧倒的にCに似ている

 

Q Goで何から行えばいいか?

小さいことから始める。コマンドラインツールとか社内向けの画像変換ツールとかを作る。

 

Q Goの苦手なところ

UIを作ることや数値計算系。APIサーバに徹することが多い