GGG

プログラミング言語やソフトウェア開発について思ったことを書いてます

Ruby on Rails エンジニアになりました。

IT企業にてRuby on rails エンジニアになりました。

ソフトウェアエンジニアとしてスクリプト言語をひとつマスターしたい。 フルタイムでスクリプト言語の経験を積みたいと思ったしだいです。

PowershellVBAは過去に作業の自動化でコード書いたことありましたが片手間でやっておりました。

前職は、半導体製造装置メーカーで、この辺のことをやってました。 約8年間勤務した次第です。

今後もぬくぬく過ごすのも悪くなかったのですが、 仕事に慣れてきた、なんか楽だなと思ってしまいました。

人生は一度限り、チャレンジしてみたいと思った次第です。

そして、自分の前職の経歴を書いてみてわかったんですが 案外、マネージメント関係の仕事してたんだなww

よく使う?最近使ったgit command

これまでGitの操作はSourceTreeによるGUI操作が多かった。

転職して職場が変わったらCUI操作がメインになった。

ここ最近、使ったコマンドを一覧にしてみた。

Git command

一覧

command Description
git init カレントディレクトリにリポジトリ生成
git add --all ステージへ全てのファイルを追加する
git reset ステージ上のファイルをUnstageする
(コミット対象から外す)
git remote add origin <remote-repository-pass> リモートリポジトリ名 origin へ <remote-repository-pass>を追加
git push -u origin --all 登録している origin へリモートリポジトリへ push
git push origin --tags ローカルで付けたタグを全てリモートリポジトリへ反映させる
git push origin <タグ名>
git checkout -b <branch-name> ブランチ名<branch-name>のブランチを生成し、<branch-name>へチェックアウトする
git checkout -f 作業内容をクリアして、直前のコミットの状態にする。
git checkout <branch-name>  ブランチ名<branch-name>をチェックアウトする
git branch ブランチ一覧を表示する。
git branch -d <branch-name> ブランチ名<branch-name>を削除する
git status 変更状態を表示する。
git commit -m "You write something here for what you modify." メッセージをコマンドライン上で指定しコミットする。
git log 過去のコミットメッセージを表示する。
git merge <branch-name> 現在のブランチにブランチ<branch-name>をマージする。
git rm --cached <file-name> gitのトラック対象から外す
git tag <タグ名> タグ <タグ名> をセットする
git reset HEAD <ファイル名> 「git add (ステージング)」した<ファイル名>を取り消す(アンステージする)

リポジトリの生成

カレントディレクトリにリポジトリを生成する
$ git init 

ステージ , アンステージ

ステージに移動する
$ git add --all
アンステージする
$ git reset

リポジトリ状態表示

git status

リポジトリのトラック対象から除外

$ git rm --cached foobar.txt

リモートリポジトリとして<remote-repository-pass>登録

git remote add origin <remote-repository-pass> 

コミット

コマンドラインにコミットメッセージを含めてコミットする
git commit -m "You write something here for what you modify."

【感想】ハードワークでも折れないこころの作り方

ペンタゴン式 ハードワークでも折れない心のつくり方

書経

表題の通りでこころが折れそうになったので読もうと思った。

読書期間

2-3日

まとめ

定義

折れない心とは?

竹のようなしなやかなこころ

もう少し具体的には、「柔軟性」、「自分自身の弱さを認識し、受け入れること」

どうやって作るのか?

自分自身を知る

  • 何について不安・恐さを感じるのか?
    • 書き出してみると良い
  • 弱い部分を知り、認める。
  • 価値観を知る。
  • 固定観念を知り、排除する。

日ごろの鍛錬

  • 日ごろから柔軟性を磨く。求められたときに準備無しには急に対応できない。

    • 基本を何度も繰り返し、いつでもできるようにする。
    • 実践形式のシミュレーションによる学習
  • 何を磨くのか?

    • 客観的な情報をもとに考えること。
    • 呼吸法
      • 理想的な呼吸法
      • タクティカル・ブリージング
  • ON , OFF をしっかり作る
    • OFF : 瞑想の導入
    • ON : 適度な緊張

実践でこころを強くする

  • まず戦略(プラン)をありき
    • プランはたたき台
    • 詳細までつくる
  • 視点を変える。

問題解決のステップ

  1. まず、何を解決するのか決める

    1. 何を決めるのか
    2. 目的は何か
    3. 制約条件は何か
  2. OODAループを用いて解決する

    1. Observe
    2. Orient
    3. Decide
    4. Act

折れた場合、折れそうになった場合

  • 根本原因を突き止めること。
    • 見えるものが原因とは限らない。
      • e.g ) 仕事の成果が出ない(悪化した)のは、もしかしたらプライベートに問題を抱えてるのかもしれない。
  • 本書では、ストレストリガーという表現をしている。

自分なりのやりかた(不安を解消する方法)

不安の明確化

何に不安があるのか、パニックになってわからない状況になったらまず冷静になる。 どうやったら冷静になるのか?

何に恐怖や不安を感じるのか、思いつくまま書き出してみる。 (ブレインストーミング的に)

解決策の模索 ( Observe )

書き出した内容(不安なこと)について、どうやったら解決できるのか?

・自分自身で解決方法を思いつくまま書いてみる。 ※実現できるかどうかはどうでもよい・ (ブレインストーミング的に)

→ とにかく情報を出す。出すことで整理される。

解決するための方向付けを導き出す。(Orient)

  • 出た情報を元に具体的なやり方(解決方法)に落とし込む。
  • 優先順位と実現性を出す。
  • 実現性については第三者に相談もいい。

試す項目を決定する。(Decide)

  • 上位三位について,それぞれ下記のことをやる

    1. 頭の中でシミュレーションする
    2. 納得がいったら、"やる"リストに入れる。
      • 納得が行かなかったら、保留にする。
  • 保留の項目は Orientに戻り別の実現方法を考える。

問題解決をするために動く (Act)

  • 実際に行動に移す。   

参考URL

OODAループ - Wikipedia

【感想】Webを支える技術

Webを支える技術 ―― HTTP,URI,HTML,そしてREST WEB+DB PRESS plus

書経

機械メーカーのソフトウェアエンジニアからIT業界のWebエンジニアへ転職。 研修の中でご推薦書ということで、現職の先輩社員からのご推薦(借りた)。

読書期間

2週間

感想

副題にも記載している通り、HTTP,URI,HTML,REST に関する説明およびWebサービスの設計指針について記載。

特定のプログラミング言語やデータベースなどについては触れらていない。 これからWebサービスを開発する入門者向けの書籍としても良いかもしれない。当方は、まさにその状況で読んだ。

WEBサービス開発は未経験の私にとっては、少々難しい印象を受けた。

しかしながら、 RESTやURI,HTTPなどについての基本的なこと。 設計するにあたって意識することが多少分かった気がする。

名言?

「WebサービスとWebAPIは分けて考えない。」

上記の言葉が何度も登場していた。

メモ

  • XML
    1. 独自フォーマットは作り出さない。
    2. まず、要件に該当する既存フォーマットを探す。
    3. 既存のフォーマットに不足があれば、機能を付加して使う。
  • 設計指針
    • リンクをたどること -> アプリケーションの状態遷移
      • HTMLのリンクで設計する
    • URIをクライアントで組み立てない。

【感想】20代で始める大好きなことの見つけ方

20代で始める大好きなことの見つけ方 (だいわ文庫)

書経

家族が貸してくれた。

読書期間

3日程度

紹介

20代前半(主に大学生?)が対象のようです。

非常に平易に書いてあるため読み進めやすい。

好きなことを仕事にしたい! でも自分の好きなことが分からないという方にオススメの書籍。 どうやったら見つけられるのか? ヒントが書いてあります。

著者が下記のように述べている通り、答えは自分の中にあります。

記憶の中のあなたは、自分の大好きなこと(もの)をすでに知っている。

印象的な言葉

  1. 挫折(心が折れる)は真剣にがんばった証拠
  2. 健全なリスクテイカーにならないと人生にワクワクはない。
  3. メンターや志を同じにする存在の大切さ。

【感想】トヨタで学んだ「紙一枚!」にまとめる技術

トヨタで学んだ「紙1枚!」にまとめる技術

購入経緯

書籍の帯に思考整理法 と書いてあったので気になった。

読書期間

2-3時間

紹介

若手~中堅社会人の方にオススメ。

「紙1枚」にまとめる技術について紹介。

その技術というのは思考整理法のことである。

それは次の3ステップからなる。

  1. 整理
  2. 考えをまとめる
  3. 伝える

これらについて具体的にどうすればいいのか?が記載されている。 即効性が高い目から鱗な書籍なんじゃないかなと思う。

フレームワークとしては下記の2点が紹介されている。(著者オリジナル)

  1. エクセル1
  2. ロジック3

紙一枚というのはA3 or A4 のことのようです。

紙のレイアウトも記載しているが、思考整理法が秀逸。

感想

他のビジネス書にも記載されていることが多く記載されている印象。

それだけ重要なことなんだと思う。

結果(紙一枚)よりも思考プロセスが非常に参考になる。

かなり具体的な方法が記載されているため、とりあえず試すことができる。

個人的には「整理」のフェイズで使用する「エクセル1」と呼んでいるフレームワークが簡単で良い。

ひとりブレインストーミング的に使える。

手始めの「アイディア出し」の段階で重宝しそうである。

トヨタで学んだ「紙1枚!」にまとめる技術

トヨタで学んだ「紙1枚!」にまとめる技術

  • 作者:浅田すぐる
  • 発売日: 2015/02/10
  • メディア: 単行本(ソフトカバー)

【感想】ワンランク上の問題解決技術

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ

書経

本書で紹介しているファンクショナル・アプロ―チとはどういうものか気になった。

読書期間

2日間

紹介

著者は建設コンサルタントをされている方のようです。 ファンクショナル・アプローチなる手法を用いて大幅なコスト削減などを達成できたそうで その実績・経験に基づいてこの手法の実践的な使い方を紹介。

技術畑出身の方にとっては理解が早いと思います。 技術系ではない方にとっては視点の切り替えが必要なので難解に感じるかもしれません。

特にモノづくりをされている若手~中堅エンジニアの方にオススメしたいです。

職場の同僚や上司に読んでもらいたかった・・・・。

この本に出会うのがあと2-3年早かったら・・と思うとなんだか悔しい限りです。

日々の業務で「小手先」「場当たり的」な改善ばかりでは劇的な改善はできません。

ファンクショナル・アプローチとは?

問題解決のための手法の一つ。

見かけの現象や手段に惑わされずに、対象の機能面(本質的な目的)を見極める。

それは何のため、誰のため(に存在するのか)? を追求し改善点を探る手法。

英語ではValue Analysis Functional Approach と言うらしい。

そもそも問題解決とはどうやって行うのだろうか?

著者はI・S・S・U・E分解と呼んでいる。

問題解決のプロセスを分解すると5つに分解することができると語っている。 問題解決は下記のプロセスに沿って行う改善活動と考えて差支えなさそうだ。

  1. Identification --- 問題解決の認識
  2. Specification --- 改善点の特定
  3. Selection --- 解決手段の選択
  4. Utilization --- 解決手段の適用
  5. Evaluation --- 改善効果の評価

ファンクショナル・アプローチは、そのうちのStep1,2で使う手法の一つ。

一言でいうと、ファンクショナル・アプローチは『問題点を分析する技術』かな。

著者のコンサル業務の規模を考えると比較的大規模な改善に特に有効。 根本的に見直しをする際のアプローチとしてぜひ活用したい技術である。 もちろん自分のやりたいことの本質を見つけるためなどの日々の生活にも役立つ技術である。

GE社の「Lawrence Delos Miles」氏が提案したアプロ―チらしい。

書籍には実例を交えて1-5の全ステップを通してのやり方・考え方が記載されています。

いろいろな問題解決方法

  1. 仮説検証法
  2. 品質管理法 (トレーサビリティ)
    • (e.g.) 生産工場のラインで使われている。
  3. 情報分析法 (データ・マイニング法)
  4. 類型置換法 (テンプレート、モデル化)
  5. 機能分析法 (ファンクショナル・アプローチ)

思考のプロセス

イメージ

 - 見た目を分析→本質を見極めること。
 - 見た目の現象(=外側)の把握 → 本質(=内側)の把握
 - 細部を理解 → 全体の理解
  1. 問題点(≒事実)を書き出す
    • 手段から発生する現象を把握する
  2. 問題点が発生している機能(=システム)を実現する仕組みを理解する。
  3. 問題点が発生している機能(=システム)が提供する(本質的な)目的を考える。
  4. 目的を実現するための理想の改善案を考える。

 ※今まで行われていた"常識"、"当たり前のこと"から脱却することが重要である。

本質的な目的に到達したら、次は改善案のアイデア出し段階。 以降は一般的なモノなんじゃないかと思う。

感想

ファンクショナル・アプローチは技術畑から生まれた問題解決技術。

当方、エンジニアリング業務を長年やっているのだが、この考え方は非常にしっくりくる。

常にできているか?というと微妙なところ。まだまだ修行中の身。

というのも、これまでの職場では「対象の原理・原則を理解して設計する」ことを大切にしており本来どうあるべきか?が話されていた。

実際は、諸々の理由で「理想」の形にできず妥協案を探ることになる。

著者のような大規模プロジェクトではないが、日々の業務で「これは何のため?(=目的)」を意識することで このような考え方は習得可能で精練できると思う。

できるようになるためには、 「これは何のため?」問答を日々の生活の中でも続けることが重要だと著者も語っている。

これまでと同じ業務であっても考え方を変えるだけで、さらにレベルアップできると思う。 頑張っていきたい。

どうやら、著者はファンクショナル・アプローチのワークショップや講演会を行っているようだ。 機会があれば話を聞いてみたいところです・・・。

参考URL

Lawrence D. Miles - Wikipedia