プログラミングをはじめて変わったこと

こんにちは。現在webエンジニアを目指して勉強中です。
今回はプログラミングの勉強をはじめて良かった、変わったと感じたことについて書こうと思います。
ポイントは次の3点です。

1. 順序立てて説明できるようになった
2. 根性論より仕組みづくり
3. 優秀な人が多いと感じる

まず、私の簡単な自己紹介ですが、新卒で3年ほど医療機器メーカーで営業をしました。その後、webエンジニアを目指して勉強中です。なぜエンジニアを目指そうと思ったかは追々記事にしていきます！


1.順序立てて説明できるようになった

順序立てて話すとか社会人なら当たり前じゃん！と思った方。いやいや、意外と難しいスキルだと思いますよ。だって学校で教わることもないし、論理的な思考の訓練しないと身につかないものだと思います。
営業として働いていたころ、話に文脈がなかったり、相手の理解に任せたりするような会話がたくさんありました。雰囲気で会話しているという感じです。

上司：　唐突に「それやっといて」

自分：「は？？それとは？？いつまでにやればよいの？誰向けにやればよいの？」

こちらから聞かないと何を何のために指示しているのか分からないことも多々ありました。こんなコミュニケーション結構いろんな職場でも日常茶飯事ではないでしょうか。営業は電話でのコミュニケーションも多いですが、私も雰囲気で相手に伝わるだろうと思って話すことも多々ありました。受け手のコミュニケーション能力の高さに委ねて、自分の説明能力のなさをごまかしていました。

いつも一から十まで説明する必要はありませんが、せめて前後の文脈はしっかり説明するべきですよね。プログラミングは一つずつ物事を解決しないと次に進みません。特に分からないエラーがあった場合、いつでも直接人に聞ける訳ではないので、slackなどのコミュニケーションツールを使って文面で聞くこともしばしばあります。そういう時、自分が何をしようとしていて、どこのエラーで詰まっていて、〇〇が原因と推測して取り組んでみたが、解決に至らない。だから教えていただけませんか。と順を追って書かないと通じません。このように、日々プログラミングを勉強していく中でだんだんと順序立てて説明する力がついてきたと感じます。これはプログラミング仲間も言っていました。プログラミングを勉強することはビジネスマンとしても成長することなんだと思います。


2. 根性論より仕組みづくり

先に伝えておきますが、何事も根性は大事です。でも営業でありがちな根性で乗り切る系の精神は間違っていると思います。プログラミング学習は根気がいります。コンピュータは電気信号を読み取っているだけだから、ほとんどのエラーは人為的ミスです。何時間も悩んだ結果、ドット（.）のつけ忘れだったりなんかもあります。こんな時はマジで精神的に辛いです。プログラマーに向いてないとか、本当に自分は頭が悪いなーとネガティブに考えがちです。なので、プログラミング独学の挫折率が高いのも頷けます。でもそれを根性で乗り切ろうとすると学習が嫌なものに変わってしまうし、継続できません。ではどうするのかというと、仕組みづくりです。つまりハマる習慣作りが大切です。これは私が通っていたプログラミング教室（CODEBASE OKINAWA）で教わったことです。やりたいと思うきっかけを散りばめ、やった後に何か喜びを感じられるインセンティブをもうけることが大事です。
わたしは現在、プログラミング教室で週2回アルバイトをしています。また、週末にある勉強会に参加したり、今はハッカソンというイベントで共同開発を訓練しています。プログラミング教室では誰かに教えるということがモチベーションになりますし、共同開発では勉強の成果が実感できるので楽しいです。
耐え忍ぶことに美徳を感じがちですが（もちろん大事）、多くの人はそんなに精神的に強くないので、楽しくできるようにする工夫が必要です。営業時代、上司が「営業は我慢して我慢して売るものだ！」とよく言っていました。でもプログラミングを勉強してからは我慢よりも楽しくできる工夫をすることが大切なんだと思うようになりました。


3 .優秀な人が多いと感じる

エンジニアはずっと勉強して新しい技術をキャッチアップしていかないと淘汰されてしまいます。なので、勉強会やイベントも多いです。そして、勉強会もイベントも好きで参加する人が多いので活気があります。
私は今まで医療機器メーカーにいたのでコメディカル（看護師や臨床工学技師）むけに医療機器の勉強会を開催したり、ドクターの勉強会に参加したりすることがありました。実は結構寝てる人がいたりつまらなそうに聞いている人も多かったです。上に言われてしぶしぶ参加したり、お弁当が食べれるから参加したりという人もいると思います。笑
エンジニアの勉強会に初めて行った時はこのあたりのギャップに驚きました。エンジニア業界はみんなすごく主体的です。（私の意見です）新しい人や技術を柔軟に取り入れていく環境がエンジニアにはあるのかと思います。特に私はプログラミング教室でアルバイトをしていることもあり、学生に関わることも多いですが、積極的に勉強会に参加したり社会人と意見を交わす学生を見ていると、本当に優秀だと感じます。もしかしたら偏った意見かもしれませんが、私の周りには向上心高く取り組んでいる学生が多いです。とても刺激になるし、勉強のモチベーションにも繋がります。

 

最後に

プログラミングの勉強をはじめて半年ほど経ちましたが、プログラミングスキルだけでなく、色んなものの見方がかわったり、仲間から良い刺激を受けています。まだまだ、見えていないことだらけなので一歩一歩進んでいきたいですね。

アソシエーションについて

今日の積み上げはアソシエーション

  1. 多対多の表示の仕方について
  2. 中間テーブル

1. 多対多の表示について

model/orgnizer.rb

class Organizer < ApplicationRecord
  has_many :request_lists, dependent: :destroy
  has_many :exhibitions, through: :request_lists
end

model/request_list.rb

  belongs_to :organazier
  belongs_to :exhibition

model/exhibition.rb

class Exhibition < ApplicationRecord
    has_many :request_lists, dependent: :destroy
    has_many :organizers, through: :request_lists
end

ポイントは dependent: :destroy'　とthrough` dependentは親子関係があるモデルに適応できて、親が削除されれば子も削除される ここでは多対多なのでorganizerにもexhibtionにも設定している 多対多の構造を深掘りするために、exhibition.rbをもう少し詳しく見てみる

class Exhibition < ApplicationRecord
    has_many :request_lists, dependent: :destroy  #中間テーブルに対して紐づいている
    has_many :organizers, through: :request_lists　#throughオプションを使って中間テーブルを通してorganizerと紐づいている
end

exhibitionに紐づいたorganizerを表示させたい時はそれぞれにデータを入れる。

  • リレーションの作成
exhibiton.request_list.create(oranizer_id:1,exhibition_id: 1)
  • 表示
exhibition.organizers

2.中間テーブル

中間テーブルは 'rails g model request_list.rb カラム名' で作成。

model/request_list.rb

  belongs_to :organazier
  belongs_to :exhibition

ハッカソンに初参戦しました！

こんにちは。みんさんハッカソンってご存知ですか？ハッカソンとは簡単に言うとプログラミングの開発イベントです。

わたしは今年の4月からプログラミングの勉強をスタートさせて、現在7ヶ月ほど経ちました。もともと新卒で3年ほど医療機器メーカーの営業マンとして、バリバリ働いていましたが「売ることだけが全て」や「給料が全て」という価値観に合わなかったり、キャリアの見通しができなくて退職を決断しました。

プログラミング自体は、とあるイベントに参加したときに知りました。そこで「自分で作ったプロダクトが誰かの役に立っているのを実感できることが楽しい！」という話に惹かれ興味を持ち始めました。始めは本当にプログラミングについて無知でした。エディタという言葉もよく分からなかったくらい笑。

プログラミング教室に4月から6月まで通い、そこでHTML、CSS、Javascript、Ruby、sinatra、PostgresSQLとwebアプリケーション作成するための基礎を一通り学びました。その後はプログラミング教室のチューター（受講生のサポートをする）として関わりながらRuby on Railsを独学で続けている状態です。✳︎私が通ったプログラミング教室で取材を受けました。

安定した企業を辞めてエンジニアを目指す。｜プログラミング教室6期生奥村さん｜CODE BASE OKINAWA｜note

 

プログラミング教室では卒業生向けに卒業後も学習が自走できるように様々なイベントがあります。その主要イベントの一つとしてβ版ハッカソンがあります。私は今回が初参加です。今回は実際に運用されるサービスを開発します。自分たちが作ったものが使われるのはとてもワクワクしますね。まる１ヶ月で作り上げます！

主な構成やチケット（タスク）は現役エンジニアが作り、私たちはバックエンドとフロンエンドに別れて三人一組で行います。チームは全部で5チームです。開発はRuby on Railsを使います。集合できる時はモブプロ形式で進め、それ以外の時はそれぞれでタスクを進め、早くできた人がpushするという感じです。

わたしはRuby on Railsを勉強していることもあって、バックエンドチームになりました。すでに実務経験がある卒業生がリーダーになり、相談したり教えてもらいながら進めていきます。わたしのチームは実務経験のある方（リーダー）とrailsを触って１ヶ月ほどの方と自分という構成でした。わたしは既にgitの超すごーく基本的な使い方はできていたので、まずはチーム内で全然分からない人に色々と教えます。gitは共同開発を経験しないとあんまり便利さが分からないのでとても勉強になります。また、今回いくつかの外観はscaffoldを利用しました。railsのscaffoldは本当に便利ですよね。コマンドをたたくだけで簡単な掲示板ができます。ログイン機能はモデルに基づいて作成したり、多対多構造の設定などもやりました。なんだかんだ、私たちのチームが一番チケットをマージしてもらえたのが嬉しかったですね。

今回が初参戦ではあったのですが、非常に勉強になったなぁと思うのが、やはりgitとgithubです。

blog.sixapart.jp


branchを切ってpushをした際にoverwrittenというエラーが出る時。とりあえずcommitしないといけないもんだと思っていました。でも「statusを確認して、変更がgitの管理下に置かれていないところは赤になるでしょ？だからcommitしてねって言われているんだよ」と教えてもらい、なるほどと。一例に過ぎませんが、ググったら分かることでも、悩んでいる時に直接教えてもらえるとやはり納得感があります。あとはチーム開発をしないと中々経験できないと思いますが、githubのprojectやissueの使いかたも非常に勉強になります。今まで独学してきたぶんチーム開発はめちゃくちゃ楽しいです。

まだ、始まったばかりですが多くのチケットをマージしてもらえるようにどんどん作っていきたいですね。次回も集まりがあるので、学びを記事にしていこうと思います！

それは仕事？それとも処理？

仕事は一連のサイクルの中で存在する。

そのサイクルの中ではあらゆる人が関係をしており、些細なミスを小さいく捉えることは、信頼を徐々に失うことにつながる。

これまで、私は早いアウトプットのみに注力してきた。つまり巧遅拙速で全てのことをとにかく早く処理する感覚だ。

しかし、これは仕事の本質ではない。

 これにまつわる話で先日、上間天ぷらの上間社長の話で興味深かったことがあった。多くの人は仕事を処理していると言っていた。例えばお弁当を店頭に並べる時、完成したらとにかく並べる従業員が多いらしい。これは多くの人にとって非常に盲点であると思う。仕事の本質は他者への貢献なのだから、この本質を押さえていれば「タイミング」「配置」と考えることは様々出てくるという。

話を戻すと最近の仕事は改めて本質が抜け落ちていたと思う。単純ではあるが渡す書類の内容をしっかりと把握しておくことや、誤字がないか確認することなど。自分の工夫で直せるものを相手の指摘に頼っているうちは仕事の本質を掴んでいるとは言い難い。それはただの処理なのである。

小さな心遣い、思いやり、これらが大切であり、すなわち他者への貢献が仕事の本質である。この想いを忘れないことが重要である。

沖縄で「個」の成長を考える

宜野湾のベイサイド情報センタにて、沖縄で「個」の成長を考えるということで、起業家やこれから起業を考えている人、個の成長に関心がある人が集まりました。

私自信、起業もしくはフリーランスとして動いていきたいと考えているが、今後どのような動きをしていけばよいのかということで情報収集を行うために参加しました。

 

普段は会社員として一定の人間にしか会わないので、考え方や情報が偏りがちになりますが、やはりこういう自主的にこれからを模索する人々と関わることは非常にワクワクしました。

 

内容は受動的なものでもなく、能動的すぎるものでもない形で成長について考えディスカッションすることでした。成長というのは漠然としたキーワードなので答えは見えませんでした。しかし、このような場にいくことで得られるトレンドやベンチャー出身の社員の方々のパッションは非常に刺激を受けました。

 

特に印象的だったことが株式会社がちゆんの代表の話で「弊社は社会的企業なので利益は追わいようにしました」というのは非常に興味深かっかたです。私にとっては会社を経営するうえで利益を追わないという考えはないと思っていましたし、現実問題それで組織が成り立つのかというのが不思議でした。突っ込んでは聞けませんでしたが、詳しく知りたいと思うので情報収集ですね。

 

やはり、動いた先に何かがあると感じた休日でした。

 

 

2025年問題に関して

書評

初投稿

 

アメブロで今まで簡単なブログをつづってきましたが、（というより、適当に思ったことをだらだらと書いていただけ）今後ははてなぶろぐに移行していきたいと思います。

こっちのほうが、なんとなく扱いやすそうだし、面白い記事が多いと思うので。

これまでもそうですが、読了後の感想を書くことが多かったと思います。今後も同じスタンスで読了後の感想を中心に私が生活で感じたことや思っていることを記事にしていきたいと思います。

 

はてばぶろぐ第一弾投稿は医療関係者として把握しておきたい日本の医療問題に関してです。

 

日本医療クライシス　（2015年発行）

渡辺さちこ

アキよしかわ

 

日本の医療制度は喫緊の課題だ。という記事みなさんもどこかで見かけたことぐらいはあるのではないだろうか。国民皆保険が限界について、これはだいぶ前から取り出たされていたように思う。

しかし、どのようなところが問題なのか簡潔にまとめたい。

①国民皆保険制度の限界について

要因は少子高齢化による日本の財政の圧迫。

国の借金は現在1000兆円超といわれているが、その国の借金を大きく圧迫しているのが社会保障費。歳入では賄えないため、当然借金に頼るしかない。日本の借金はデフォルトを起こしたギリシャとは違い、外貨に依存していないため安心というが、本当にそうなのだろうか。（ここは記述したいこととずれるので割愛）

働く人が減るから収入は増えないけれど、高齢者は増えるので、借金は増えますよととても簡単な理由だ。

②日本の医療が直面する課題について

著者らは現在、日本医療が直面している制度的な課題を８つ（実際は9つだが、同じような内容が重複していたので5つ目に含んだ））挙げている。

それらは外国と比べ俯瞰したものになっている。

1つ目が急性期病床が多すぎること（日本は民間病院が多いから、つまり病院を経営している人が多いので中々進まない）←歴史的経緯や急性期がかっこいいなどの思いもある。

2つ目が入院期間が長いこと（DPC制度がうまく機能していない。入院させていたほうが診療点数を稼げる場合などがあるため）

3つ目が診療報酬設計のせいで、いらいないところに看護師が必要以上にいて、必要なところにいないこと。

4つ目が新しい物好きな日本文化のせいで、ハイテク機器が必要以上に色々な病院に配備されてしまうこと。

5つ目が病院数が多すぎることによって、症例の専門性が低くなること。

6つ目が診療点数が稼げるため、入院が不必要な検査や手術の外来シフトが進まない。

7つ目が日本の診療報酬設計は直面している課題に対する、行動の結果がインセンティブにつながらないケースが多いため空回りしている。

8つ目が日本人は大病院信者が多いため、クリニックや中小病院のフィルタ機能がうまく働いていない。