ただの記録

積み重ねと繰り返し

UX KANSAI UXデザインセミナー vol.1 ブートキャンプ

5/14(土)のこと。

UX KANSAI 主催の

UXデザインセミナー*1@某所*2

に参加した。

  

体験したことを記録するために、ブログに残す。

特に自分が響いたところについてまとめていく。

 

今回はvol.1「ブートキャンプ」ということで、

これから学ぶにあたる姿勢について指導がメインだった。

 

判断・態度(多様な学びと失敗の繰り返し)

即効性のある手法などない。

コスト(時間)をかけて学びと失敗を繰り返すしかない。

 

判断力が足りないという悩みを浅野先生にぶつけてみた。

するとこんな質問をされた。

「同じ店にいくかどうか?失敗するかどうか?」

私は同じ店にはいかない&ほぼ失敗しないタイプだが、

人に聞いたり、事前に調べることが多い。

 

ずばり

「自分で体験していない、失敗が足りない」

と言われた。なるほど。

例えば 

・自分で新しい店を嗅ぎ分ける:体験

・並んでる場所にいく:観察

・人に聞く:インタビュー

インタビューが一番よくないらしい。

  

自分で体験することでしか、判断力はあげられないので、

失敗を恐れずにたくさん失敗して

また失敗から学ぶことにトライしたい。

 

時間(コスト)をかける

セミナーを受けるだけでは出来るようにはならない。

言われたことをどれだけ実行できるか。(大抵、できない。)

学んだことを実務でやってみたり、

次のセミナーまでに勉強しなければ意味がない。

 

自分が次回までにまず取り組もうと思っているのは、

の3点。

頑張れたら

  • エスノグラフィの予習

もする。

vol.2 の記事で振り返る予定。

 

考える=作業する

手を動かしていないとき、考えていない。

うなってばかり考えている風な人、考えていない。

考えるときは必ず書くこと。

 

もうひとつの大きなメリットは

自分の意見をまず紙(ポストイット)に書いて

それを壁に貼った瞬間に「その人」の意見ではなくなり、

ひとつの意見としてみんなで扱うことができる。

 

プロトタイピングをしながらチームビルディング

チームビルディングをするには共同作業が一番良い。

一緒に作業をすることで、色々なことがわかる。

 

人のものや他のチームのものを見にいく

意外とできない。

アトリエ型授業*3というらしい。

ダメなとき・行き詰まっているときこそ、

周りがどうやっているか・どうやったらうまくいくか

を持ち帰る。

 

調べる=比較する

何かを調べることは比較すること。

 

省察と外化を怠らぬこと

省察には反射も大事。

反射は、やったことに対する周りの反応から自らを客観視する。

外化は、頭の中身を外に出すこと。ブログとか。

 

フレーミング

フレーミングとは

状況や考え方によって捉え方を変えること。

「常識を疑う」といったことに近いかもしれない。

例えば、「切符を失う」という問題に対して、

フレーミングの解決策は「切符を失わないようにする」

フレーミングの解決策は「切符を不要にする」

といった感じ。

(ちょっと雑かも。良い例を忘れてしまった。。)

 

フレーミングが難しい場合は、

一度フレーミングしてから、

フレーミングするとわかりやすいかもしれないと思った。

一番興味が湧いたので、もっと知りたい。

フレーミングが得意になりたい。

 

次回以降のセミナーで必ずやること(反省点)

  • セミナーには時間早めに行く(人として当たり前のことをする)
  • ペットボトルにネームカードを貼る(アピールする)
  • 期限・締切を厳守する(タイムマネジメントする)
  • グループワークは壁に向かって立ってやる(効率3倍)
  • 問題を定義(言語化)する
  • 問題がみつからなかったら問題を「作る」
  • 本質的な問題を含んだストーリーを作る
  • フレーミングする

 

最後に・・・

チームメンバの方のブログにすごくいいことが書いてあったので紹介したい。

masaki-ravens.com

 

 

これまで。

*1:前期5回、後期5回の全10回のセミナーで、前期はワークショップを交えながら手法を学び、後期は前期で学んだプロセス・手法を活用してサービスをひとつ作ります。講師は(株)経験デザイン研究所の浅野智氏です。

*2:毎回場所が変わるのですが、今回は非公開の会場ということで伏せています。色々なところに行けるので楽しみです。

*3:浅野先生のブログで説明を発見した。→ アトリエ型の授業 | 経験デザイン研究所

Golang のパッケージ構造がわからん



Golang のパッケージ構造がわからんちん。

go run main.go すると

カレントパッケージにある

main パッケージ の main 関数が実行される。

ふむ、それはわかった。

カレントパッケージに別ファイルを作って

そこにある関数をよびだそうと思ったら

あれーって頭が混乱した。

そもそもの目的は

せっかく写経したソースを

整理して GitHub に公開していこうと思ったから。

そーゆーわけで

そこからちょっと調べてみることに。

うまく情報が探せてないけど、

こちらのブログ様を参考にさせていただいた。

そして、実際トライしながら、自分なりに考察してみた。

例えば・・・

gosample パッケージにある main.go に

package main

func main()

と書くのが違和感なのか、私は。。。

以下、正しくない記述だけど、

package gosample

func main()

の方がしっくりきてしまう。。。慣れか。。。

Golang の言語仕様に慣れないと。

というより、理解せよ、だよなぁ。

main は "カレントパッケージのメイン" ぐらいの意味で捉えてたらスムーズなのかな。

むしろ、わざわざ自分のパッケージ名を名乗るのは

他パッケージから参照されることを明示しているのか。

逆にいうと、main パッケージの実行はそのパッケージだけに限定される。

そう考えると、確かにシンプルでわかりやすい(かも?)。

しかも、それって逆にいうと

もし main パッケージの中に記述したメソッド

他パッケージで使用したいってなった場合は

main パッケージ以外に切り出す必要があるってことかぁ。

というか、そもそも

main パッケージ ≠ パッケージ

ってことな気がしてきた。。。

(「main バッケージ」ってわざわざ呼ぶくらいだもんなぁ。)

あと、自分がファイル名にとらわれたりするあたり、

だいぶ頭が java 化されてる気がする。。。ぐすん。。。

まだ全体邸によくわからんけど、

じょじょに Golang のこの辺りも理解できるよう勉強しよう。。。

応急処置として、ひとまず sub パッケージに切り出すことにした〜。

へぼい。

Qiita の Contribution が 50 超えた

 

Qiita を始めてから約 3 ヶ月。

総投稿数は 15 になりました。

地味な地道な活動の結果、

Contribution が 50 を超えることができました。

 

前回は 10 Contribution の際に振り返り記事を書いたので、

ひっそりと、次は 50 Contribution で・・・

と、思っていた矢先の出来事でした。

では、眠いのでサクッと振り返りましょうか。

 

投稿数に関しては、

前回の振り返りで約 1 ヶ月で 9 投稿、

そこから今日まで約 2 ヶ月で 6 投稿と

数で言うとあまり伸びなかったかな、と思う。

ただ、あまり数にはこだわっていないので、

あまり気にしなくて良いと感じている。

 

そして、今回注目したいのはこっち。

(1)濃い投稿内容が書けたこと

(2)下書きが溜まってきていること

(3)投稿内容の更新ができたこと

(4)プライベートでチャレンジしたことの投稿ができたこと

が、とても良かった。成長だと思う。

 

特に、(4)については、

前回の振り返りで、

今は仕事の内容が多いから

プライベートで学習している投稿を増やしたい、

と書いていたので、実現できていることを自信をもって

これからも続けよう。

 

あと、(3)の「投稿内容の更新」は

結構、大事なことだなと個人的には思っている。

投稿内容の更新は、正直、責任でも義務でもないし、

地味で、面倒で、大変な作業だと思ってる。

だって、新しい記事を投稿する方が

すごいやったった感あるし、Contribution もカウントされやすい。

要するに、成果が見えやすい。

 

でも、自分がアウトプットする大きな目的は、

「貢献=誰かの役に立つこと」なので、

新しいことを調べたにも関わらず、

記事の情報が古いままというのは

やっぱりよろしくないことのように思う。

まぁ、情報の内容にもよるんだけど。

 

投稿した記事だって、進化して良いし、

そういう価値のある記事の蓄積ができれば、

より本質的な貢献を実現できるように思う。

 

それが、目指してる「じわる貢献」だよなぁ。

 

まぁ、そんなたいそうな話じゃないにしても、

自分自身が技術的なことを調べるときに、

情報の「鮮度」というのは、すごく重要視していること。

情報は更新されることで、鮮度が保たれるように思う。

 

だから、自分はそこ結構気になるというのもあるし、

未来の自分が、

「そういえば自分で書いたな〜」と思って

過去の自分の記事を参考にしようとしたときに

「全然つかえねぇ!!!」って思うようなのは

やだな〜って思ったりする。

それより、

繰り返し見るたびに、この記事残した自分に

「よくまとまってるわ!自分やるな!」

って、スゲー感謝したいしされたいじゃん、やっぱ。

(小さい人間ですみません。)

 

だから、より良い方法や情報が見つかったときは、

できるだけ記事を更新するよう、

これからも心がけたい。

うん、「心がける」という表現がちょうどいい感じ。

 

ちなみに、結構前に投稿した記事を

ストックされるのって、なんか妙に嬉しいね。

これ嬉しいの、ただの変態やね。自分らしいと思う。

 

自分は割と時間をかけて

記事を完成させたいタイプだから、

どうしても量より質に気持ちがいってしまうというがある。

どっちがいいってのはないんだけど。

ただ、自分自身は

もう少しバランスが取れるようになれたらいいなと思ってる。

まぁこれは、長い長い目標かな〜すぐには無理。 

 

そんな感じかな〜。

振り返ると色々思うことありました。

大事だね、振り返り。

 

最後に。

感謝の気持ちで、これからも。

いつも、ありがとうございます。ふかぶか。

 

次は 100 かな。

かなり道のり遠そう(笑)

 

続けよう。

 

塩漬け

  

何かとつまづく私へのエール。

 

 

「行き詰まったら、一度、塩漬けにしましょう。」

 

 

これまでの経験から、

だいたい 2 日くらい塩漬けにすると、

いい感じね。

 

いやぁ、ぬか漬けでも味噌漬けでもしょうゆ漬けでもいいんだけど。

そこは比喩ってやつですよ。

 

なにごとも、ちょっと寝かせると

自分の頭が整理されたり、視点を変えたりできる。

 

要するに、

同じ物事も「違った」ように感じられたり、

解決の糸口が見えたりするってこと。

 

一回つまづくと本当に嫌になっちゃうんだけど、

そんなときは思い切って

「しばし、やめてみる」

ってのは、ありなんじゃあないでしょうか。

 

そういやぁどうでもいい例だけど、

昔、ドンキーコングで 100 ドンキーぐらい死んでも

クリアできなかったダンジョンがあって、

悔しかったんだけど、仕方なく寝て、

次の日の朝、一発でクリアできたっていうことあったな・・・。

 

「ヤケ」になるってのも、よくないね。

 

 

あぁなんか、サケの味噌漬けたべたくなってきた・・・。

 

おなかすいた。

ぐぅ。

 

GitHub で作成したリポジトリを git clone して git branch したらエラー

GitHub デビューしようと意気揚々と始めたけど、早速つまづいた。

GitHubリポジトリ作成して、 https の URL で git clone できたところまではいいんだけど、 git branch コマンドで確認しようとしたら以下のエラーが発生。

$ git branch
fatal: Not a git repository (or any of the parent directories): .git

エラーの内容を調べながら、git init したらどうにかなるかな?と思ってやってみたら、 .gitディレクトリは作成されたけど、 git branch コマンドを実行しても、エラーも何も出なくなった。あれー。

git init コマンドについて調べてみると、 リモートリポジトリを git clone した場合は git init を実行する必要ないように思えたけど、 どういうことなんだろうか・・・。

会社で git を使ってきた自分の勘で考えたあたりどころだと、

  • GitHub の WEB 画面でリモートリポジトリを作成してから clone しているところになにか問題がある

可能性は低そうだけど、会社のと違うとこといえばここかな。 会社で使っている git では、ローカルリポジトリを作成してから リモートリポジトリに push して始めるので、そのパターンで一度やってみる。

  • git を使い始める最初になにか git の設定をしないといけないのを忘れている

なにかしたか記憶にないから、調べてみる。

とりあえず、明日詳しい先輩に聞いてみるかな〜。

むむむ。

Qiita の Contribution が 10 超えた

 

初めて Qiita に投稿したのが 2014/12/12 で、

最新の投稿が 2015/01/08 となり、

約1ヶ月、9投稿目の記事で

私の Contribution が 10 を超えることができました。

 

数を目標にしてたわけではないのですが、

10 はいつ頃超えられるのかな?という楽しみがあったので、

正直、結構嬉しかったです。てへへ。

 

なにか成果が目に見えるのは素直に嬉しいですね。

いつも激励したり、サポートしてくださる皆様、

たくさんの情報を残してくれた先人の皆様、

ストックいただいた皆様にも感謝です。

もちろん、Qiita というサービスにも。

 

せっかくなので少し振り返りをしてみよう。

やっぱり、仕事関係の投稿が多いので

これからはもっとプライベートでチャレンジしたことで

投稿が増やせるようになるといいなと思う。

でも、焦らず、できることを続けよう。

 

他人と比べてしまえば、

「10」という数字はなんでもないかもしれない。

ひとつの記事でも、何百、何千とストックされる記事を

書くユーザーさんはたくさんいる。

 

でも、過去の自分と比べてみたらどうだろうか。

何もアウトプットしなかった自分は、

「少しアウトプットした自分」に変わったんじゃないかと思う。

「0」と「1」の違いは、

エンジニアなら誰でも知っている大きな違いだ。

 

たま〜に増えるストックの喜びを味わいながら

これからも「じわる」貢献を続けたい。

 

続けよう。

 

IntelliJ IDE で Go 1.4 の環境設定に失敗

 
 
くっそ。  
 
フィフスエレメントが始まるまでに、
IntelliJ IDE で Go 1.4 の環境設定しようとしたら、失敗した。  
 
とにかく、IntelliJ に Go SDK を設定できなくて詰んでいる。  
 
Go(1.2 ぐらいの古いやつ) をインストーラで設定したときは
IntelliJ での設定も問題なくいったんだけどね。

自分のやり方が悪いんかと、下記の記事も参考にした。

MacにIntelliJ IDEAでGolangの開発環境を構築する - Qiita  
 
今回は Homebrew でインストールして
$GOROOT に /usr/local/opt/go/libexec を設定したから IntelliJ の Go SDK の設定にも、$GOROOT の PATH を 選んだら下記のエラーが発生。

IllegalArgumentException: Argument for @NotNull parameter 'virtualFile' of com/intellij/openapi/projectRoots/impl/ProjectRootContainerImpl.addRoot must not be null

なんやねん〜と思って、最後のあがきでエラーメッセージでググってみたら、
こんなんでてきた。

setting go sdk fails sometimes · Issue #927 · go-lang-plugin-org/go-lang-idea-plugin · GitHub

もしからしたら、IntelliJ の Go Plugin の問題かもしれん。。

って、ふらふら情報探してたら、
まさかの下記の記事のコメントにナイスな情報発見!!!
素晴らしす。  
 

Go の開発環境は IntelliJ IDEA + golang plugin がマトモだった - Qiita  
 
やっぱあかんねや〜。 原因はわかったんで、明日やって Qiita にまとめるかな。  
 
それにしても、ブログ記事書き始めた時は絶望の淵だったのに・・・  
 
 
諦めてからが、勝負じゃのぅ。


追記(2015/01/09)

Qiita の記事にまとめました。解決方法等は、こちらをご覧ください。