普段ゲーム開発をしているエンジニアがコードクロニクルを使ってみた
はてなブログでお題にあがっていたというのと先週リリースされてるのを見て気になっていたというのもあって使ってみました。
気になった理由としてはプログラミング教育に以前から興味を持っていたからです。小学校で必須化するというのもあり今後全員がプログラミングがわかるようになると思うとワクワクします。このゲームは全くの初心者がプログラムの基礎部分を学ぶのを目的として作られていますが僕自身はどちらかというと中級エンジニアになるのを教育するようなことの方が興味があったりします。
ちなみに僕自身は普段業務でゲーム開発をしているエンジニアで一定以上のプログラミングスキルはあるのでこのゲームの想定しているユーザではないかなと思います。それを踏まえて読んでいただければと。
さて、本題ですがこのコードクロニクルはストーリーは王道でお姫様が王の命のもとお供と旅に出るという形で進んでいき、その合間のクエストをクリアするためにはプログラミングでお題をクリアしなければいけないというものです。
ちなみにガチャとかパーティ編成とかあるのですがここらへんは若干取ってつけたような形で特に面白さはなかったりします(^^;
目的がプログラミング教育でユーザに課金させることではないのでキャラの魅力や強さとかがあまり関係なかったりするんでそこは残念。パーティ編成のUIもやけにわかりにくかったりしてここらへんはゲーム制作の素人感があるなと思いました。ゲームバランスをしっかり考えてプログラミングを学ばせるというのができれば流行るとは思うのですが。
ちなみに30分ほどしかやってないのですがクエスト自体はいたって簡単で指定の数や文字を出力しろというものが今の所多かったです。
この問題自体は運営元のpaizaのpaizaラーニングから問題を連携しているんじゃないかなと。前述したように僕は経験者なんで単調な作業に思えましたが初心者の習熟度はきになるところでした。
強み診断調査であるVIA-IS診断をやってみた
1年ほど前に会社でストレングスファインダーというのをやってお互いの強みを知ることができ組織の運用に役立ったので良いと思ったのですがこのツールは有料(本を一冊買わないといけない)なので無料のツールでやりたいなと思って見つけたのがVIA-IS診断
ストレングスファインダーとは結果の項目が違うので完全に代替となるわけではないですがある程度の強みは知れるのでそこそこ有用だなと感じました。
やり方は
- https://www.viacharacter.org/Survey/Account/Register から日本語を選択してメールアドレス・名前を入力。ここらへん厳密に入力しなくても大丈夫
-
120問の質問に答える
-
結果を確認
僕の場合はユーモアが高い人間でした。センスあるかどうかはともかく笑わせるのは好きな方なのである程度納得。
1 ユーモア
2 好奇心
3 忍耐力
4 誠実さ
5 親切心
6 リーダーシップ
7 スピリチュアリティ
8 知的柔軟性
9 公平さ
10 社会的知性
11 愛情
12 創造性
13 審美眼
14 思慮深さ
15 希望
16 チームワーク
17 熱意
18 自律心
19 勇敢さ
20 感謝
21 向学心
22 寛容さ
23 慎み深さ
24 大局観
好奇心や忍耐力は確かに高い方かなと。我慢の男と読んでください！
僕と関わることがある人は無茶振りしても大体我慢してやってくれると思うのでどうぞよろしくお願いします。
カルディのチリコンカンの缶詰が手軽で最高
たまにチリコンカン食べたくなるんですがチリコンカンって豆とトマトと挽き肉とスパイスとか揃えないと作れないんで面倒だったりします。豆とか普段買わないですし。
そんな時に偶然見つけたのがこれ。ホーメルのチリコンカン。カルディで売ってます。
これを温める
パスタにかける
パンにかけてトーストする
まぁ美味い
【映画レビュー】恋は雨上がりのように
漫画は見たことないので原作と比較することはなく純粋に映画の感想です。
見たキッカケとして内容に興味があったというわけでなく主演の大泉洋が結構好きなのと小松菜奈の魅力に惹かれて。
オープニングの部分で小松菜奈が走るシーンがあるのですがエンタメ性があって印象的です。リアルであんな風に走る女子高生はいないと思いますが演出がカッコよく作られている。
真面目な映画というよりはコミカルな映画で大泉洋、戸次重幸、濱田マリ等の演技は笑える部分も多くて素晴らしいです。
ネタバレになりますが素直に大泉洋と小松菜奈がくっつかなくて良かったなと。
それぞれの道を歩みつつ二人の関係性は終わったわけではない。
爽やかな気持ちにさせてくれる映画だったなと。
ちなみに小松菜奈の友達役の清野菜名はあまり女子高生には見えなかったです(笑)
プライベートで年次の目標設定にWeekdoneを使ってみた
最近プライベートで目標を立てているのだが2018年に関しては達成率が37%と良くなかったので今回からもう少し達成率を高めたくツールを使ってみることにした。このパーセンテージは目標をいくつか立ててその目標を何割達成したか計算してその合算である。
ちなみに2018年に使ったのはLINEのノート。LINEのノートを使った理由としてはグループで共有するため。自分一人で目標を立てても達成できそうになかったので共有してできるだけ有言実行をしようとしたのだが結果は先ほども書いた通り良くはなかった。
今年はその状況を変えるべく何か目標達成を強制、もしくはサポートしてくれるツールはないかと探しているところで見つけたのがWeekdoneです。
これはOKRの管理ツールで制限はあるが無料で使えるので試しに使ってみることにしたという形です。OKRとはインテルのCEOだったアンディ・グローブ氏が開発した手法でGoogleやFacebook、日本ではメルカリあたりが採用していると聞く。僕はGoogleのre:Workで知った。
Googleのrw:Wrokは結構有益な情報が多くオススメでだと思っている。これ以外にも面白い情報があるのでこのブログでも機会があったら勧めていきたい。OKRではストレッチした目標をたてて60〜70%の達成率が理想的らしいので今年は僕も60%以上の達成率を目指したいと思っている。ちなみにOKRは四半期毎に目標を設定するのが一般的なので年次の目標は別にGoogle Docsで管理してその中から分割してこの四半期で行う目標だけをOKRとして管理するようにしている。ちなみに普段会社ではMBOで目標管理をしていたりするのですが1度OKRを実勢してみたいと思っていて良い機会だと思ってプライベートで実践してみようと思った次第です。
Weekdoneにログインしたら以下のように現状の目標の進捗状態等表示してくれる。
目標は左のQuarterly Objectivesで登録できる。目標(Objectives)に対していくつかの成果指標(Key Results)を登録できて成果指標はプログレスバーで簡単に進捗を変更できる。今回は3つ目標をたてている。バスケと英語勉強とアウトプットについてである。他にも年次の目標はいくつかあるのだが今回は3月終わりまでということで1ヶ月しかないので様子見で立てている。
Weekly Planningのタブで今週の計画と振りかえりも行うことができる。
しばらく使って見てどのような効果がでてきたかはまた報告しようと思います。とりあえずはこのQuarterが終わる4月はじめに。
Engineering Manager Advent Calendar 2018を見て学んだこと・使おうと思ったこと前編
アドカレって大量にあるのでバズったり話題にあがったりしたものだけ見ていつもは終わっていたのですがせっかくなので今年は関連するものを全部見て学びになったものはまとめておいて次につなげられるようにしようかなと思いました。
以下のものを全部見ると形で。
エンジニアリングマネージャーという枠だけで50記事なんで相当やな。
一旦vol.1だけ見てまとめてみました。
最初は一気に全部見ようかと思いましたがさすがに50は多すぎた。。
プロダクトオーナー兼EMとしての資質について考えてみた。 – i35-267 – Medium
大体自然にやっている事がおおかったがVSMという手法については初めて聞いた。自分の周りでは問題となっている部分は皆すぐ言って改善していく文化なのでここらへんも自然とやっているのかもしれませんが。
駆け出しエンジニアリングマネージャーの苦しみ - Qiita
会社に会う人を採用する
これは重要だなと思います。僕もまずはマインドが合うかどうかというのを重要視しています。
Managerでありながら尖ったEngineerであるために自己組織化チームに挑む - Qiita
自己組織化するためにやるべきことが記載されていて良かったです。筆者と同じ様な立場ですができてない事も多いなと。モブプログラミング一度やってみたいんですが嫌がる人もいるかもなと思ってできていない。
アジャイルとは無縁の組織の中で、エンジニアリング・マネージャーとして取り組んでいること｜nnjyami｜note
アクノレッジメントコミュニケーションというのは初めて聞いた言葉だった。うまく言葉にはしづらいですが相手に関心を持ってコミュニケーションするという感じですかね。
エンジニアリングマネージャーになってから守っているたった3つのこと - motokieeの日記
規則正しい生活を送る。
マネージャだけじゃなく社会人としてパフォーマンスだすために正しい生活送るのは重要かなとは思います。
可視化してデバッグする
1on1でdocs共有とかは僕もやっていますがいいですね。
僕の場合も最近一つのプロダクトに関わりすぎないようにしていますがここらへんのバランスは本当に難しい。チームの状態を明確に見えるかするというのは本当に重要だなと思う。
この人はマネージャとして成果がだせなかったと書いているが自分がいる状態と別の人がマネージャをやった場合とで客観的に分析できているのでこういう見える化する能力あると思う。
マネジメントスタイルの選択基準、一貫的スタイルを持つことの困難 - valid,invalid
その時のフェーズや能力にあったマネジメントスタイルを選択する。マネジメントの押し付けはよくない。
コミュニケーション取っていると思いがちというのは自分にもあてはまったりするのでそこらへんは意識したい。そうは言ってもその人にあったコミュニケーションは取りたいところですが。
スタートアップ1人目エンジニアが、仲間を増やしEngineering Managerを志した - ユアマイスター株式会社エンジニアブログ
エンジニア一人というところからエンジニアが増える過程でのマネジメントの変化
意識しているのは無駄なことをしないということ。1on1が重要ということ
Engineering Managerをエンジニアのマネージャーとするのはやめませんか？ - Unknown Error
こらからエンジニアマネージャの定義を決める形でまとめられている。具体的にどの部分が楽しいのか記載があればよかった。一般的にはエンジニアのマネージャという方が多いようには感じますが。
コンサルティング同行で学んだ、エンジニアリングマネージャーとして新しい組織にジョインして取るべき姿勢 - ねこのひたい
記事のどの部分がコンサルティングで学んだ事かわからなかったのですが取るべき姿勢は同意です。書いてある事は普段のチーム行動で学べそうではありましたが。
-
プロダクトマネジメント
-
プロジェクトマネジメント
-
ピープルマネジメント
の技術が必要だが重要なのはエンジニアが楽しく開発できる環境を作る。だいたいの人はピープルマネジメントが主になるんじゃないかなとは思います。
人見知りマネージャが100回1on1をしてわかったこと - だいくしー(@daiksy)のはてなブログ
個人的に1on1苦手意識持った事ないんですよね。1ヶ月に1度しかしてないので話題が何かしらあるからかもしれません。
ちなみに一度1on1を頻度増やしてほしいですかとメンバーに聞いた事ありますがその時は月に1度で十分と言われました。1on1は月に1度でそれ以外は普段の業務コミュニケーションでまかなったりしています。ランチ行ったりとか。
今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間
Stable Teamの話が印象深かった。確かに効率はあがると思うのですがメンバーとしては飽きがきちゃうのでそこをマネジメントするのが大変だなと思ったので。弊社ではプロダクトで思考することが多いです。
Engineering Managerの難しさTOP3 – EM.PM – Medium
僕のTOP1は目標設定と評価ですかね。メンバーに対してこの話題で交渉するというのは常に慎重に望んでたりします。ここでいえば感情のマネジメントが近いですかね。
組織コンディションのスコアリングとその運用 ~wevoxを半年使ってみた~ - TOMOLOG
wevoxちょっと面白そうだなと思った。エンゲージメントを高めると事業が成長するというのはゲーム事業においてもそうかしっかりデータを取ってやってみたい。じゃないとお金を払い続けるか判断できないので。
エンジニアリングマネージャーが成人発達理論の視点で育成を考えてみた – Masahiro Taniuchi – Medium
あれ、やばい。自分の意識が低いのかオシャレな写真がところどころ挟まっているせいかあまり理解できなかった。ただ色んな視点で育成考えるって部分は重要だと思うという気づきは得られました。
良いチームとは何か、そして良いチームであり続けるために何が必要か - Qiita
重要な事繰り返しかいてあるのがいいなと。成長を常に意識しなければいけないなと。そのために振り返りは重要だなと。一応一週間に一度よかった事、改善点はあげているのでその点についてはできているなと思ったがチーム全体で同意するような形にしてもいいかもしれない。
1on1等であらかじめそういう文化を作っていくのが重要ということで交渉力みたいなものがマネージャーには必要というのがわかる。毎週技会開催されるの凄いので見習いたい。うちは大体続かないので。ちょっと気になったのがマサカリを投げ合う殺伐としたのエンジニアの一つの理想形なの？と言ったところ。あまりそう思わなかったので。あとmixiがロボット開発しているの初めて知りました。
ナイーブな問題ですが同じく引き止めは基本しない方針です。本人のためを思って退職がよくないと判断した場合は引き止めますが本人のためになるなら引き止めはしないです。あたりまえだとは思いますが。
逆に心理的安全を高める役割「煽り型リーダーシップ」について、聞いてくっしょ？ - Binary Diary
これは大分チームのメンバー構成によるなと思った。もしくはよほどうまくチームを作っていくか。少なくとも自分のチームでやるのは難しそう。リーダのキャラクターにもよりそうですし。ただこうやって新しい形のリーダシップの手法がでてくるのはいいかなと思う。
組織をデザインするという経験がないのでうまく活用はできなさそうだった。
エンジニアリングマネージャーとしてこころがけていること - Qiita
10年以上マネージャやってるということで歴戦感がありますね。
決定、決断しないというのがなかなかできないので意識したいところ。技術ではまだまだ負けないと思っているところ強い。
消極的なキャリア選択を減らすためのEngineering Manager入門｜serima｜note
Engineering Manager になったらソフトウェアエンジニアに戻るの難しいとありますが人によるのかなというイメージ。最前線でやってる人もいるし元々コード書くの好きな人が多いのでプライベートでも書いたりしてるので。
余談ですが実は僕の周りでは最近スペシャリストよりマネージャーを目指す人が増えてたりします。昨今の流行りとかもあるのかしら。
エンジニアリング組織の文化ができるまでの3年間の軌跡 - dskst's diary
なかなか0から組織作るというのはないのでここに書いてある以上に歴史あるだろうなとは思いつつ最初にやったことが全力でコミットというのがわかりやすいなと。信頼重要ですね。
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
これを知った所で活用するのは難しいが読み物としては面白かった。ただ、面白いだけじゃなくて読んだ後に気づきが得られる方がやはりいいな。
NextAction
一気にインプットしすぎてかなり疲れました。まだvol2あるがここまで見て次何やるか。
- モブプログラミングの提案
- チームの状態の可視化(課題があればメンバー全員に見える様にしておく）
- チームとしての成長、個人として成長できているかを振り返る
- ビジョンとか思いを繰り返し(大袈裟なくらい)表現する
- 組織において仕組み化した方がいいところ等があれば務める
