自作アプリ作りに難航中
ASP.MVCでの自作アプリ作りに向き合いつつ、何度か挫折を繰り返しています。
何故挫折しているのか。
考えてみると自分はすぐに動かすことができるものが好きで、動くまでに時間がかかると興味を無くす傾向があるのかも、と思いました。
作りたくない理由 >作りたい理由
作りたくない理由が作りたい理由より勝っているから手が動かせないのかなーと思いつつ分析。
作りたい理由
- 勉強したい
- ちょっとした作業を便利にしたい
作りたくない理由
- 動かせるようになるまでに時間がかかる
- わからないことがすぐに人に聞けない
今まで業務でプログラミングを行っていたときは、常に周りに質問ができる環境にいたり、動かすための基盤をだれかが用意してくれていたり、面倒くさいことを回避してきたので楽しく感じていたようです。
これまでに作ったもの
既存のプロジェクトの修正以外だと基本的には誰かが最低限動く状態にしてくれたものを触ることばかりだったなと思いました。
それ以外だと下記のような状態だと何かを作ることができたようです。
Delphiでマインスイーパー(趣味)
- ヘルプを見るとやれることが載ってた
- それでもわからなかったら隣の席の人が何でも教えてくれた
- ペタペタボタンを貼ってすぐに動かせた
Windowsアプリのクライアント側(業務)
- ペタペタボタンを貼ってすぐに動かせた
- わからなかったらいつでも質問に応じてくれる上司が傍にいた
エクセルマクロでテスト項目の集計(業務/趣味)
- すぐに実行して動作の確認ができる
- わざわざ難しいことをしなかった
- ちょっとでも機能拡張するとメンバーや同僚が喜んでくれた
GASでSlackBOT(趣味)
- エクセルマクロとほとんど同じ
まとめ
文字に書き出すと、自分の好き/嫌いの傾向がわかりやすかったです。
今後、作りたくない理由をどう取り除いていくかが課題ですね。
スクラム道関西 x 楽天 Meet up
先日下記のイベントに参加してきました。
ワークショップ:マシュマロタワー - スクラム道関西さん
1回目:53cm、2回目:55cm
作ることに必死になってしまいましたが、楽しかったです。
理論より実践。 経験しないと分からないことが多いので、まずは作ってみて失敗することから始めよう。 失敗による学びによって良いものが作れる、ということを学ぶようです。
しかし、マシュマロタワーを作るために配布されたパスタには限りがあり パスタが折れる(=失敗する)ことを恐れてなかなか挑戦できなかったな、と反省です。 個人作業ならともかくチームで失敗を恐れずに挑戦するということはまた一段と難しいですね。
セッション1:スクラムとパッション - Crequer Jimmyさん
メモ
- 同じスクラムをやっていてもチームによって成長速度が違う
- チームメンバーは皆それぞれ別のパッションを持っている、そのパッションを利用してサービス改善のためにアクションをとる
- 「チーム内の数人が頑張った」から「チーム全員で頑張った」へ
- モブプロの大きなメリットの一つはレビュー工数の削減
タイトルからパッションを同じ方向に向けさせるための話かと思っていたのですが、情熱は人それぞれだからそれを利用して良いものを作るという、新たな視点に気づかせてもらえるセッションでした。
セッション2:サーバントリーダーシップが起こす組織の"覚醒" - ジャッキー(宮本 剛志)さん
- 明確な期待値と的確なサポート
- 自分のマイクロマネジメントのせいでメンバーの主体性がなくなったのかもしれない
- プロセスのチェックリストをあえて作らない(その代わり指摘をする) =>ジャッキーさんにつっこまれるリストを部下に作られた => トラブルは自分たちで防ぐものだという意識が部下に芽生える
- 発言を促すためには相手のレベル感に合わせた質問を投げてあげるところから
- トップダウンするべき場所:(トップ)ビジョン・ミッション・コアバリューを決める(部下)←のためにどうするべきかの手段を決める
サーバントリーダーシップによる組織の成長を体験談として語っていただいて非常に分かりやすい事例でした。
OST(オープンスペーステクノロジー)
OSTは初めてだったのですが、とても面白かったです。 色んな場所で話し合ったことのメモだけを記録しておきます。
心理的安全性について熱く語りたい!
- 人は自己決定しか愛せない
- リスクに見合った安全性はどこなのか(=>安全性の過剰はコスパ悪い?)
- 自分から離れた悩みほど人は身動きが取れなくなる
- ちょっとずつ進む、ちょっとずつ無茶をすること
POに何を求めてる?
- POの役割が不明確だとみんなが動きづらい(=>デリゲーションポーカーをするといいかも?)
- POに求めるもの=ステークホルダの窓口
- POに求めないもの=はエンジニアチームのことを考える
スクラムの芽生え方 どうやって取り入れよう?
- スクラムは準委任で行うには難しい。請負なら実施できる可能性あり
- スクラムはゴールが決まっていない(ゴールがズレる)ときに有効
- スクラムをやりたいのか、良いをつくりたいのか
- 早くフィードバックを伝えたいからアジャイル(スクラム)をしたい
まとめ
勉強会に参加する前は、スクラムというものが何かわからないから、知りたくて参加しようという意気込みでした。
色んな方とお話しして、スクラムは知識ではなく経験だということがよくわかりました。
自分がまたプロジェクト管理をすることになったときに、実践できるようにもっとスクラム系の勉強会に継続的に参加してみようかな?と思いました。
HTML/CSS学習メモ
Udemyで勉強したHTML/CSSの内容をメモしています。
displayプロパティ
- block:要素が画面幅いっぱいに広がる。複数書くと縦に並ぶ。(p, divなど)
- inline:要素が必要な幅だけ取る。複数書くと横に並ぶ。(a, spanなど)
疑似クラス
~~の時という条件を加えることが出来る
.description img:hover{ opacity: .5; }
imgにhover(マウスカーソルがのったとき)に中身を半透明にする。
アニメーション
transition-XXXで動作を指定する。
.description img{ transition-property: opacity; transition-duration: 1s; transition-timing-function: ease; transition-delay: 0; }
メディアクエリ
表示端末の種類や画面サイズを条件にCSSを適用する
@media only screen and (max-width:600px){ (↑の条件を満たす場合に、この中に書いたCSSが適用される) }
便利なサービス
心理学的な用語の勉強
チームビルディングやコーチングについて人から聞いてわからなかった単語を色々と調べたので 今週新しく知った単語を雑にまとめています。
学習した単語
ディスカッション/ダイアログ
- ディスカッション:議論。効率的な合意。誰かが勝つ(誰かが負ける)。
- ダイアログ:対話。相互理解。新しいアイデアを生む。
メモ:ダイアログのファシリテータースキルはどうやって伸ばすのか。
ティーチング/コーチング
メモ:課題の内容や相手の能力に応じて、適切な使い分けが必要。
傾聴
- 受動的傾聴:耳を傾ける
- 反映的傾聴:話の要約を伝える
- 積極的傾聴:相手の立場、気持ちに深く共感
メモ:絶対ダメ⇒アドバイス・説得・話を遮る・言葉をかぶせる・話を誘導(自分のためだけに聴く)
内発的動機と外発的動機
- 内発的動機:自身の興味から生まれ、達成することで満足感を得る。もっと欲しくなる
- 外発的動機:お金や評価のため。GOALがあり継続が難しい。
メモ:外発的動機⇒内発的動機へのシフトがうまいこと出来たらおいしい。
ヤーキーズ・ドットソン の法則
- コンフォートゾーン:居心地のよい状態。
- ラーニングゾーン:適度なストレス。定期的に学びコンフォートゾーンを増やすことで成長できる。
- パニックゾーン:過度なストレス。生産性悪化。
メモ:それぞれのゾーンからどうやってラーニングゾーンに導くか。
タックマンモデル
- 形成期:チーム形成直後。そよそよしい。価値観がバラバラ。
- 混乱期:意見のぶつかり。対立。
- 統一期:共通規範やそれぞれの役割が明確。自分がなにをやるべきかがわかる。
- 機能期:リーダー不在でもメンバーの自律ができる。結束。相互サポート。
メモ:混乱期の乗り越えをサポートするために必要なスキル⇒チームビルディング、ファシリテーション
成功の循環モデル
- グッドサイクル:関係の質を高めることから。
- バッドサイクル:結果主義。
メモ:前の会社にいたころはバッドサイクルに思い当たることがしばしば。バッドサイクルからグッドサイクルに転換するためには何が必要か。
ヴァルネラビリティ(vulnerability)
メモ:奥が深そうで意味をとらえきれていない感。
今後の課題
2019/3月の成果
1カ月ごとに学習したことについてYWT形式で振り返ります。
3月の学習内容(YWT)
やったこと
読書
書籍名 | 詳細 | 進捗 |
---|---|---|
達人に学ぶDB設計 徹底指南書 | Amazon | 完了 |
Webを支える技術 | Amazon | 1章~15章まで |
進化的アーキテクチャ | Amazon | 1章~6章まで |
入門 監視 | Amazon | 2章まで |
ASP.NET MVC5実践プログラミング | Amazon | 購入のみ未読 |
ASP.NET MVC
学習対象 | 種別 | 詳細 | 進捗 |
---|---|---|---|
【入門者向け】ASP.NET MVCでWebアプリ開発のノウハウを学ぼう! | 動画学習 | URL | 受講完了 |
Asp.net MVC によるTodoアプリの開発 | チュートリアル | URL | チュートリアル完了 |
自作アプリ開発 | アプリ開発 | - | 昼食レビューアプリ作成を試みたが、EFの罠にハマり頓挫 |
HTML/CSS/JavaScript
学習対象 | 種別 | 詳細 | 進捗 |
---|---|---|---|
はじめてのHTML | 動画学習 | URL | 受講完了 |
はじめてのCSS | 動画学習 | URL | 受講完了 |
他
学習対象 | 詳細 | 結果 |
---|---|---|
Speech Seviceで音声認識 | URL | サンプルコードを書くと、音声認識ができた!(ただし英語のみ) |
自作アプリのデプロイ | - | AzureにDBを構築していないと、実行時エラーになることがわかった。 |
わかったこと
- ASP.NET MVCの仕組みを利用すると、少し記述するだけで簡単にWebサービスができる(そのせいで何が何だかついていけなかった)
- ソースコードが読めないと感じた部分は主にRazorやJavaScriptの記述だった
- 動画学習は自分に合っている
- ASP.NET MVCで自作アプリを作るためにはもう少し基礎学習が必要
- 自分はWebについて本当に何も知らない(初心者本ですら知らないことばかり)
- HTML/CSSは中途半端に知っている部分もあるが基礎が欠落している
- ローテーブル+座椅子の環境で学習すると腰痛が悪化する
次にやること
- JavaScriptの学習もする(→目標に動画学習を追加)
- Webについて学習するための方法を他にも見つける
- 自宅に机と椅子を導入する
5月末までの目標
5月末までに行う目標に対しての進捗をまとめます。(完了したタスクは取り消し線)
Webの基礎
- 読書:Webを支える技術
動画学習:はじめてのHTML動画学習:はじめてのCSS- 動画学習:[HTML/CSS/JavaScript] フロントエンドエンジニアになりたい人の Webプログラミング入門 ←new
所感
目標に対しては順調に進んでいます。
先のことが不安だったりもしますが、現時点では楽しく学習するための仕組みがうまく作用していると感じています。 また予定より多岐にわたった書籍に着手していますが、どの書籍も楽しく学習できています。
まずはこのモチベーションを維持しつつ、基礎学習を続けていきたいと思います。
転職後、最初の1カ月にやったこと(スキル編)
スキル不足を補うために、転職後1カ月以内に取り組んだことについて書こうとしたのですが、 最初の1カ月はどうやってスキル不足を補うかを決めるため、ほとんどの時間を「目標設定」について費やしました。
そのため、目標設定を行うためにしたことをまとめます。
学習の優先度付けを自分でしない
私のスキル面については過去記事に記載している通り、分からないこと・やったことないことが多すぎる状態でした。
そのため学習を始めようにも、何から手を付けてよいかわかりません。
この自分の状態を同僚に相談すると、ASP.NET MVCの学習に目標を絞ってはどうか、と助言をもらいました。
同僚からの助言により、自分で学習の優先度を判断しなかったことで選択肢への不安がなくなり、一つのことに集中することができました。
目標達成の手段を決める
何から手を付けるか決めたうえでどんな手順で学習すべきか、具体的な計画にしました。 ここでも自身の判断だけでは難易度の判断ができなかったため、チームメンバーと相談して行いました。
その中でASP.NET MVCだけでなく少しだけWebの知識も必要だとアドバイスを頂いたため、目標を修正し、以下のような手段を決めました。
3カ月以内(5月末まで)にやること
Webの基礎
個人目標にチームを巻き込む
目標達成のための手段を決めた上で、これから個人的に学習する内容を同僚の誰かに共有したいと思いました。
メンターのような一人の担当者を付けてもらうようなことが出来ないかと聞いてみたのですが、チームで面倒を見るという方針だったのでチーム全員に目標についての共有をすることになりました。
このとき、チームに参画してから3週間が経過してました。
やっと、無駄に焦っていた自分がホッと一息付けたように思いました。
転職後、最初の1カ月にやったこと(メンタル編)
長くなりそうだったので、「メンタル編」「スキル編」に分けようと思いました。 まずは「メンタル編」です。
自分を騙す
こんな優秀なエンジニアだらけの素敵な環境で働けてラッキー♪ みんなに迷惑かけるけど、自分の成長のために好きなだけ勉強させてもらおう!
と、自分を騙すことにしました。
本当は上記のような考え方がとても嫌いです。 けれど、このままではずっとネガティブなことばかり考えていては、自分の行動を全て否定してしまい、動けなくなってしまう、と思いました。
そこで上記の考えを好き嫌いの軸で考えて、嫌いだからやりたくない、という自分を騙すことにしました。 積極的に上記の考えになることで、ポジティブに行動ができるようになり、迷惑をかけない存在に到達することへの近道と考えたためです。
自分を正しく評価をする
自分を騙し、日々を過ごしながらほんの少しできることが増えてきました。
自分ができることなんて、もちろん周りの優秀なエンジニアと比べると意味のないような些細なことばかりです。
そうやって自分のしたことに対して価値を見出さないことで、毎日が辛いのであれば比べなければ良い。相対評価の癖をやめて、絶対評価をすることにしました。
どんなに小さなことでも自分がしたことに対して評価をするために、自分がしたことを文字に書き起こしました。
「分からない」が言える環境を作る
私は新卒の頃に質問をすることにあまり抵抗がない方でした。
自分が社会人として何の力もないことを理解した上で、今自分が分からないことを無くしておくことで今後きっと会社に貢献できるだろう、自分が質問をすることは会社・自分の双方の利益だと考えたからです。
けれど、今回は違いました。
自分をさらけ出す
恥ずかしがる自分を知る
周りがあまりに優秀なエンジニアだったので、私もきっと優秀なエンジニアを期待されているのでは、と考えてしまいました。 そのため、自分をさらけ出すことに恥ずかしさを感じました。
そのため(私が勝手に考えた)周囲からの期待を裏切りたくないと思ってしまい、下手な質問ができずにいました。
新卒の頃の自分と比較し、会社の利益より自分の感情を優先してることに気づきました。 しかし、このままでは会社に何の貢献もできないまま去っていくことになる、と思いました。
スキルが低いことを周知の事実にしてしまう
わからないこと、出来ないことを言うことにしました。
自分から周囲の期待値を落とすことで、私は「何の力もないこと」自他共に理解した上であれば、恥ずかしがるものはなくなります。
例えば
「CSSを書いたのは今日が初めてです。」
「このファイルに書かれていることが1行目から全部理解できていません。」
みたいなことを積極的に発信するようにしました。(もちろんとても辛かったです)
チームメンバーを信じる
教育担当がいないことへの不安
新卒と違って中途入社なので、チームメンバーに私を育てる義理はありません。
まずチームに参画した際に、誰に質問すれば良いか聞いてみましたが、チームメンバーの誰にきいても大丈夫だよ、と言われました。
しかし、担当が明確になっていないことにより、私のような出来ない人の面倒をみるようことを貧乏くじのように感じているメンバーがいたらどうしよう、と不安に思いました。
相手に「質問していいよ」と言わせる
私はエスパーではないので、会話というコミュニケーションでしか知りえる方法はありません。
チームメンバーが全員そろっている場で「自分が質問をすることで、迷惑だと感じている人がいるのではないかと不安に思う」と言いました。 どんな時に質問をしても迷惑でないか、どんな粒度・タイミングなら問題がないか、などを聞きました。
その時に「今のままの質問ペースでいい」「細かなことまで聞いてくれて良いと思っていた」等、メンバーが言ってくれた肯定的な言葉を信じることにしました。 (ここでも言葉の裏を探ろうとしたり、メンバーを疑おうとする心は不要のため、「自分を騙す」ことにしました。)
たくさん愚痴を言う
自分の感情の整理のため、家族や友人にたくさんの弱音を吐きました。
真摯に耳を傾けて、時にはアドバイスをくれるような関係の人がいることは、本当に有難いと思っています。
愚痴を言い続けることがないよう、その人たちのためにも、はやく現状を改善するための行動しないとと思いました。
メンタル面への取り組みについては以上です。
次はスキル不足を補うために取り組んだことについて書きたいと思います。