二級知的財産管理技能士になりました。
8月22日になってたのですけど、なんやかんやあってスキャンしてブログに書くのをすっかり忘れていました。
どんな試験内容か知りたい人はこちらから過去問を見ると良いと思います：国家試験 知的財産管理技能検定 過去問題
なお一級の試験はうっかり申し込み損ねました。
ちなみに今年の前半には弁理士試験も受けてみて、科目別得点では商標だけが足りてない感じでした。商標はあんまり興味を持ってなかったからさもありなんという感じ。あと商標が足りても総合点が5点足りないので、全体的に底上げが必要ですね。弁理士になるにはこの試験に受かった上で、論文試験に受かって、それから口頭試問に受かって、実務修習をして、弁理士会に登録して(35000円)、月会費(15000円)を払い続けないといけません。そこまでやるのかどうかはまだ悩んでる感じです。受かってから考えようかと。(受かったら「もったいない」とか言って登録しそう)
https://gyazo.com/e6d96968296b2272aa01ad5dd71e1e78
Google翻訳を試してみた
精度が上がったと話題のGoogle翻訳で僕が書いた日本語を訳してみて、その英文を見て意味が分かるかどうか、英文に違和感があるかないかを検証する。
What is Moyamoya?
まあわかる。
The purpose of this book is to solve the "Moyamoya on programming".
引用符の閉じ位置とかtheとかに違和感があるけど、まあわかる。
Everyone is learning programming, "What is object-oriented? I do not know like I understood ..." You may have felt moaiyoya such as.
これは書き直しが必要そう。元の日本語が「わかったようなわからないような…」という文字列を含む複雑な構造だから訳せないんだな。
In this book I would like to help solve such mooyamoya and refresh it.
and以降は削った方がいいかもな。
Moyamoya is not understood, I do not understand well, I can not understand well.
Moyamoya is a mental state such as "I do not understand well" or "I can not understand well."かな。
So what is understanding?
うん通じそう。こういうケースって冠詞いらないんですかね？
Makoto Nagao wrote in "What is" Understanding "" Understanding the sentence is to reconstruct the written content in the reader ".
引用符が乱れてるけど、まあ理解できる。
Moyamoya is a state in which the knowledge input to the brain by sentences etc. does not connect with other knowledge that he owned, fluffy floating.
割と訳しにくい原文だと思うんだけど、理解できる訳になっている。日本人etc.使いすぎって英会話の先生によく言われるけどこの文章でも「by sentences etc. 」はいらない気がする。
Even in this state, you may be able to spit the knowledge as it is like a parrot as it is.
「as it is like a parrot as it is」が微妙。先のas it isは「与えられた知識を与えられた形のまま吐き出すことしかできない」なのでas it was givenかなと思うし、like a parrot as it isのas it isが必要なのかどうかよくわからん。あえて訳出するにしても「まるであなたがオウムであるかのように」だからitじゃなくてyouだろう。
あと日本人的な曖昧表現が気になる。英語で書くなら「Even in this state, you can spit ...」と言い切った方がすっきりしそう。
However, we can not connect it with another knowledge.
文脈上、このweはyouの間違い。
もうちょっと技術的な話を試してみよう。
First, it is a concept of "implementing general functions in superclasses and implementing specialized functions in subclasses"? This is a design policy that superclass is generalization of subclass and subclass is specialization of superclass. This design policy matches the idea of "class = classification".
いや、なぜ疑問形……。そこを直せばだいたい意味は取れそう。
The second one is the idea of "extracting the intersection of multiple classes as its superclass?" This is a design policy of "extracting common parts" that is similar to mathematical factorization rather than generalization / specialization. This design policy matches the idea of "sharing common parts of processing" already familiar with how to make functions.
こちらも疑問形。原文を確認したら"「複数のクラスの共通部分をそのスーパークラスとして抽出すればいいのではないか？」という考え方です"とか書いてたからそのせいだな。あとさっきはconceptでこっちはideaだな。
-
-
-
- -
-
-
実験をしての所感
It is not satisfactory quality as it is, but probably it can be passed as it is. Since you can see what you want to say in most places without referring to the original text, the labor of the work of correcting the translations made in Google Translate will be much less. Perhaps in this state you could also outsource "to correct sentences to be naturally" to people in English-speaking countries who do not understand Japanese.
そのままで満足できるクオリティではないけど、たぶんそのままでも通じる。原文を参照しなくても大部分の箇所で何を言いたいのかがわかるので、Google翻訳で作った下訳を修正していく作業の手間がだいぶ減る。たぶんこの状態なら日本語の分からない英語圏の人に「文章を自然になるように直して」って外注することもできそう。
minimum *** product(MVP)のVはvaluableではなくviableです
リーンスタートアップにはこう書かれています：「本書におけるMVPは、構築―計測―学習のフィードバックループを使って学びのプロセスをはじめられる製品を指す。詳しくは (下記リンク先) 参照のこと」
リンク先はこちら: Lessons Learned: Minimum Viable Product: a guide
viableという単語はfeasibleの同義語で「実現できる」という意味です。see: Oxford Advanced Learner's Dictionary
製品に価値がある(valuable)かどうかを決定するのは顧客であって、作り手のあなたではありません。なので、作り手は「顧客がこの製品をvaluableと思うかどうか」を検証するために、最小限の実現可能(viable)な製品を作って、顧客の反応から学ぶのです。
300円持って170円のパンを買った場合のお釣りは平均0.03円
問題は「100円玉を3枚持って」とは書いていない。日本で流通している硬貨で300円を持つ方法は3506通りある。うち「100円玉3枚」「100円玉2枚50円玉2枚」「100円玉1枚50円玉4枚」「50円玉6枚」の4通り以外では、10円以下の硬貨を十分持っているのでお釣りは0円になる。この4通りではお釣りが30円となるので、お釣りの平均値は 120 / 3506 = 0.034227... である。
首都大学東京の「情報通信特別講義」で話してきました
昨年に引き続き首都大学東京の「情報通信特別講義」で1時間半の講義をしてきました。スライドはこちら http://www.slideshare.net/nishio/2016-67480959
@overlastさんから「自分が学生の時に解決したかった問題を例にした方が学生さんにとって分かりやすいのでは」という指摘があったので少し考えてみて、やはり質疑で話題に上がった「料理」が一番伝わりやすいのかなと思いました。
思い起こしてみると「よし自炊をするぞ」と「基本の和食」的な本を買ってきて、最初に作ろうとしたのは「肉じゃが」でした。
肉とイモとニンジンを買ってきて、レシピを見ながら作り始めて、途中まで進んでから「酒を入れる」と書いてあるのに気付いて「料理酒なんて持ってないぞ」となりました。
そこで何かそれっぽいものを入れようとして、たまたまあった芋焼酎を投入。
できあがった肉じゃがはなんだか臭くてざらざらしておいしくなかったです。
和食における「酒」は、飲み物の話をするときの「酒」とは違って、「焼酎」を含む概念ではないということです。どちらかというと「みりん」「砂糖」の仲間らしいです。
残念ながらこの時の僕は料理を作るということに自信を無くしてその後何もしなくなってしまうのですけど、もし2回目のチャレンジをしたとするとPDCAサイクルは
- Do (レシピをあんまり読まずに)肉じゃがを作って、料理酒がないので芋焼酎を入れた
- Check 食べたらまずかった
- Adjust/Plan 料理酒がないのがダメだったなー、料理酒を買ってきて再チャレンジしよう、と考える
- Do 2回目のチャレンジをする
という流れになったかと思います。もちろんAdjustはこれだけに限りません。
- Adjust/Plan レシピは事前にちゃんと読んで必要なものがそろってることを確認してからやるべきだったな、次はそうしよう
とか
- Adjust/Plan 和食は難しいからパスタに挑戦しよう
とかもありえたわけです。現実の僕が選択したのは
- Adjust/Plan 自炊は難しいからコンビニおにぎりでいいか
だったわけです。
料理に関しては、結婚して妻にPlan、Check、Adjustをやってもらえるようになってからようやく学びが進むようになりました。
例えばこの事例に関しては「調味料の不足に作り始めてから気付いた場合、適当なものを入れるのではなく『入れない』を選ぶべき」と指摘されました。
Xが必要なのにXが存在しない、という時に代わりにYを入れると、その結果が「Xがないことによる問題」なのか「Yを入れたことによる問題」なのか識別できない。なにも入れなければ「Xがないことによる問題」だけで、多くの場合「一味足りないなぁ」「Xがないとこうなるのか」と学びが進むとのこと。
なるほどなー。
-
-
- -
-
受講された学生さんからのフィードバックを頂いたのでいくつかコメントします。
「何を学ぶか」はどうしたら思いつくか？
「『何を学ぶか』を思いつく」は実行方法があいまいなタスクですね。なのでまずは小さくて実行可能なタスクにしてみましょう。
1: 紙とペンを用意する 2: 「自分は何が学びたいのだろう？」と書く 3: スマホなどで5分のタイマーをセットする 4: タイマーが鳴るまでペンをもってじっとその紙を見つめる(他のことをやったりしないで)
これは準備を含めても10分でできるタスクなので、まずこれをやってみてはどうでしょう？
これをやった結果は2パターンあります。1つは「意外と思いついた」というパターン。今までにそのテーマについて5分間集中して考えたことがなかっただけ、というわけです。
もう一つのパターンは「5分間まったく何も思いつかなかった」というパターン。これは「学び」というものに心のハードルがあるか、考える材料が足りてないか。
例えば「学びとは、大学生協で教科書を買って読むようなものだ」と無意識に考えていて、かつ「教科書を読むのは嫌だ」と考えていたりすると、心の中でその2つが葛藤してアイデアが出なくなります。そういう状態なら、一旦「学び」から離れて「自分は何ができるようになるとうれしいだろう」「自分はどうなりたいだろう」「自分は何がどうなるといいのだろう」という質問を5分間考えてみるとよいかもしれません。
考える材料が足りていない場合は、色々なことを体験する、色々な講演を聞いてみる、学校の図書館で適当に色々な本を開いて見る、などが有効です。一つ一つは深くなくてよいので浅く色々なものを体験すると良いでしょう。色々なものを見るうちに「これはあんまり好きじゃない」「こっちの方が好き」と徐々に明らかになります。学生さんからのフィードバックの中には「インターンシップなどを通じて見つけていきたい」というものもありました。これもよい案ですね。
PDCAサイクル
PDCAサイクルを高校で学んだ人もいるそうですね。具体的な体験(料理の例)を聞いてよくわかった、という意見があったのでこの記事の冒頭で僕の大失敗の話を書いてみました。
あと、体育会系の部活などで今までやっていたことがPDCAサイクルだと気付いたという意見も複数ありました。そういう「無自覚にやっていた行動パターン」に「PDCAサイクル」という名前がつくことで、今後そのパターンを自覚的に実行することがやりやすくなります。これは「人間増強の四要素」の「言語」の例の一つです。
LINE
LINEに言及しているフィードバックが多くて、今の学生さんにはグループチャットの例としてLINEの話をするとわかりやすいのだな、と思いました。今後参考にします。私が大学1年生の時、グループチャットとしてはICQやYahooメッセンジャー、MSNメッセンジャーなどが使われていました。レポートの締め切り前などには夜な夜なグループチャットで「課題1の答えってこれでいいの？」とか議論したものです。
「LINEは企業で使われていないのか」という質問がありました。私自身は使っていないけども、LINEを使って仕事をしている人も世の中にはいます。LINEに限定しないで広く「グループチャット」と考えると、Facebookメッセンジャー、Slack、Skype、などがよく使われています。私自身も4つの組織をまたぐ5人のチームでプロジェクトをしていた時にはFacebookメッセンジャーを使ったことがあります。それを使う選択をしたのは私ではないですけど。
世の中には色々な形の組織やチームがあり、色々な仕事をしています。なのでLINEにも向いているケースと向いていないケースがあります。例えば私の会社には500人くらいの社員がいます。もしこの500人が一つのチャットルームに入ってそれぞれ話をしたら、話があっという間に流れ去って大変なことになりますね。なのでこの種の組織で使うツールには部署ごとにグループを分割する機能が必須です。
一方で部署をまたぐコミュニケーションも必要なので、単に分けるだけではダメです。例えば私は先日会社の入館カードキーを紛失したのですが、こういう時に500人の中から誰にメッセージを送ればいいでしょうか？私は500人の名前と仕事の対応付けが頭に入っていません。
また「カードキーをなくした社員の応対をする」という仕事は、実は1人の人に割り当てられているのではなく、複数人のチームで担当しています。そのチームの中の人は、有休でお休みだったり、育児休暇を取ったりする可能性があります。もし仮に誰が担当でその人が今日は会社に来ていることを知っていても、直接メッセージを送るのは適当ではありません。その人が休暇に入った時にチームの他の人がタスクを引き継げないからです。この状況をどうすれば解決できるでしょうか？私の会社の例をあげると「グループウェアの中で『カードキー 紛失』で検索すると紛失物報告窓口が見つかり、そこに報告すると担当チームの人が応対してくれる、担当チームは全員その応対や報告を読める」というような仕組みになっています。
他にも、たとえば会社組織の仕事の中には「年に1回行う」というタイプのものがあります。そういうものは「去年はどうやったっけ」というのを知りたくなるわけです。チャット上でのやり取りでこのタイプの仕事を進めるなら、過去ログから日時範囲を指定して検索する機能などが欲しいです。チャットより、1年後見て分かりやすいように情報を整理してストックできるツールの方が適していると思います。
このように色々な組織/チームと仕事がある中で、チームメンバーが「我々のタスクはLINEでできるね」となればLINEを使うことももちろんあるでしょう。所詮ツールにすぎないので、そのツールで目的が達成できるかどうかで、そのツールが使われるかどうかが決まります。
他人から否定的な言葉を受けることが怖い
否定的な言葉を言われても、自分の腕が切り取られたり、寿命が減ったりするわけではなくて、ただ「ある人がこの件に関して否定的に思っている」にすぎない、「この人の心の中で起こっていること」にすぎない。そう思うと少し楽になるかもしれないですね。
とはいえ、毎日不条理に人格否定され続けたりすると心にダメージが溜まってしまうので、そういう環境からは(逃げ出す心の余裕があるうちに)逃げた方が良いと思います。
今の社会は情報量が多く、欲しい情報がすぐ得られない。その解決方法として分類が考えられるが、一筋縄ではいかない。資料にあったワークショップでは分類に12時間も掛かったとあったが、正確性を求めると時間がかかるのだなと思った。
うーん、ここは僕が端折りすぎたせいでうまく伝わらなかったみたいですね。あのワークショップでは「正確に分類する」ということは目指していません。
他の学生さんからのフィードバックで、ゼミで長時間発表する機会があったのだけどもまとまりのない発表になってしまった、という話がありました。長時間の発表が求められるようなテーマは、だいたい簡単に割り切れないテーマかと思います。例えば「死刑制度は廃止すべきか」とかですかね。
そういうテーマに対して、色々な人の意見を収集して「分類」して発表すると「Aという意見がありました、Bという意見がありました、Cという意見もありました」みたいな発表になりがちです。そのゼミが「自分の意見を発表すること」を求めるものだったら「で、あなたの意見は？」と聞かれるでしょうね。
「正確に分類しよう」と考えて時間を掛けても、発表が「Aという意見がありました、A-1とA-2のパターンがありました、Bという意見もありました、B'とB''がありました。Cという意見の中にA-2とB''を合体したものがあり…」などという「まとまりのない」発表になって、やっぱり「で、何が言いたいの？」と言われてしまいます。
逆に、例えば「うちの会社の新製品に対して顧客がどんな意見を持っているか調べよう」という目的なら、収集して分類して「Aという意見がありました、Bという意見がありました、Cという意見もありました」という発表でOKなわけです。求められているのが「みんなの意見」なのか「自分の意見」なのかでやり方は違うのです。「自分の意見を発表しよう」 が目的のタスクなら、いくら分類してもダメなんです。
「分類」は、多数派意見に注目し、少数派意見は無視したり、まとめて「その他」につっこんだり、と細部を捨てることで情報を要約する作業です。一方で、「新しく生まれたもの」は少数派です。目新しい意見や着眼点、アイデア、これらが「目新しい」なら、それは「多数派ではない」ということです。「新しい自分の意見を作る」ということは、その少数派の中から自分がよいと思うものをピックアップし、混ぜ合わせ掛け合わせ磨き上げて行く作業です。細部を捨てる「分類」とは相容れないのです。
このブログ記事自体が実例です。この「正確に分類する」という切り口は、44枚のアンケートのうちの1枚の少数派です。ちなみに多数派は「考え方が変わった」や「この考え方を役立てていきたい」でした。そういう多数派にフォーカスするのではなく、少数派にスポットライトを当てて、そこに別の人からの「ゼミの発表がまとまりのないものになってしまった」という切り口を混ぜ合わせ掛け合わせ、それをきっかけに自分の中から「考え」が引き出されてきてこういう文章になったわけです。
「正確に分類する」は答えが自分の外にあるイメージかと思います。「自分の意見を発表する」では答えは自分の中にあります。外から集めた情報は、自分の中の答えをひっかけて引っ張り出すためのフックだったり、引っ張り出してきたものを論理的に補強するための添木だったり、どちらにせよ答え自体ではなく、答えを作るための道具なんです。
絶対正しい現実を見ることは不可能
その通りです。それを前提として、どうすれば少しでもマシになるか。その一つの方法が自分の視点だけではなく他人の視点も使うこと、というわけです。
人と人のズレを直すのは楽だが、人と人以外のズレを直すのは楽でない
うーん、2人の間に気兼ねなくやりとりできる「信頼関係」がある場合は確かに楽ですけど、そうでない場合は逆じゃないかなと思いました。
例えばプログラムを書いて実行したら表示されるはずのメッセージが表示されなかったとしましょう。プログラムを修正して何度も実行したり、問題を突き止めるための別のプログラムを書いたりするかと思います。PDCAサイクルですね。
一方、気になる異性にLINEでメッセージを送ったら既読スルーされたとしましょう。メッセージを修正して何度も投げたら……かえって機嫌を損ねるのではないか……。気兼ねしてPDCAサイクルが回せない、なんてこともあるのではないでしょうか。
もし「変なプログラムを書いて実行したらパソコンが爆発するかもしれない」と思っている人がいたら、プログラムを修正して実行しなおすことを恐れてしまうでしょう。「この対象にはDo/Checkしても大丈夫だ」という状態かどうかがキモなのではないかなと思います。
自分が取り組んでいる分野に関してはPDCAサイクルを回すことで新しい学ぶべきものに出会えるだろう。しかし取り組んでない分野の学ぶべきものに出会えないのでは？
出会いは運です。幅広く色々なものに触れれば、新しいものに出会う確率は上がりますが、掘り下げる速度が落ちます。狭い分野に集中すると、深く掘り下げる速度は上がりますが、新しいものに出会う確率が下がります。どちらか片方ではなく、両方が必要です。
ところで、特定の分野だけをやっているつもりでも、意外と隣の分野の話が紛れ込んで来たり、たまに全然違うものが飛び込んで来たりするものです。「情報通信特別講義」でこんな話題が出てくると事前に予想していましたか？
この話題がチョイスされたもの、運です。去年小町先生から講義の打診があった時に、たまたま同じ時間の長さの講演をした直後だったので「このテーマでどうでしょう？」と聞いてみて、いいねとなったのでこの話題になったのです。
個人的な感覚ですが、出会いの確率は結構高いと思います。ただ、そういう予期しないものとの出会いがあった時に、多くの人は通り過ぎてしまいます。「情報通信特別講義でなんか毛色の違う話があった」「単位のために感想アンケート書いた」「よし、これは終わり」「次は線形代数のレポートを片付けなきゃ」みたいに。
時間は有限なので、新しく入ってきたよくわからないものより、よくわかってる前からあるものの方を優先してしまいがちなのです。出会えないことより、通り過ぎてしまうことを心配した方が良いかもしれません。
35歳になりました
7月23日に35歳になりました。なんやかんやでブログに書くのが先延ばしになっているうちに気がついたら1ヶ月も経ってしまいました。
30歳から毎年誕生日に更新していたのに、どうして今年はこんなに遅くなってしまったのか。書きかけ原稿には「35歳と言えば『エンジニア35歳定年説』を連想するわけですが」なんてことが書いてあったりして、「35歳」という節目に気負いすぎなのでしょう。過去の誕生日記事を読みなおしてみると、昔はもっと軽い感じでした。というわけできちんと書くのをやめて、書こうと思っていたことをざっくりまとめてみます。
エンジニア35歳定年説の話題は、「色々なプログラミング言語を学ぶこと」に話の舵をとって、そのまま完結しないで中断していました。色々なプログラミング言語を学ぶことで視野が広がるというのであれば、プログラミング以外のことを学ぶことも視野を広げるわけで、というあたりが次の段落へのつなぎになるのかな。
その次の段落のメモとして「未踏社団の理事」「1ヶ月に1回ペースでの活動報告」とか書いてあるので、昨年の9月から始めた未踏社団の理事としての活動と「何をやっている団体かわからない」という問題の解決のために定期的な活動報告を行うようにしたことなどを書こうとしたのかと思います。これは次の段落への伏線でしょう。
その次のメモは「ブログの更新頻度が落ちている」でした。これはこのメモを書いた時点では「ブログには、技術的なメモを書いていたけど、ここ数年技術に割く時間の割合が減ったから」なんてことを書こうと思っていたのだけど、これって間違いですね。技術にはコンピュータ関連ではないものだってあるし、そもそも技術的なメモ以外のことも昔はたくさん書いていたので。更新頻度が落ちている原因は「気負い」でしょう。完成度の高いものをリリースしようと考えた結果、リリース自体がされなくなる、という完璧主義の罠です。
もっと気負いを捨てて生きた方がよいのでしょうか。40歳不惑まであと5年、まだまだ惑いまくりの人生ですが、今後ともよろしくお願いいたします。
ESP8266のファームアップデートがSYNCで止まる問題→解決
ESP8266(ESP-WROOM-02)のファームアップデートがSYNCで止まる
→指定したファームの横のチェックボックスをチェックしなければならないことを見落としていた。
