ミニ四駆（DCR-01）をつくってみた
タミヤ ミニ四駆PROシリーズ No.46 DCR-01 デクロスー01 MAシャーシ 18646
- 出版社/メーカー: タミヤ(TAMIYA)
- 発売日: 2017/05/27
- メディア: おもちゃ＆ホビー
- この商品を含むブログを見る
30歳になって久しぶりに面白そうだったから、ミニ四駆をつくってみた。
作ったのはDCR-01って車種。
このミニ四駆がすごいのは車でいうところのミッドシップレイアウトになっているところ。
昔のミニ四駆はリアエンジン（モーター）だったけど、こいつはなんと車体中央にモーターが！
これによって、だいたいバランスが50：50に近くなり、安定性が向上する。
こんなところで大好きな車の知識が活きるとは思わなかった。
プラスアルファで初心者がつけるといいとおすすめされていた「トライパーツセット」もつけてみた。
タミヤ グレードアップパーツシリーズ No.476 MAシャーシ ファーストトライパーツセット 15476
- 出版社/メーカー: タミヤ(TAMIYA)
- 発売日: 2014/03/22
- メディア: おもちゃ＆ホビー
- この商品を含むブログを見る
めっちゃかっこいい。。。
早く走らせたい！！！
AIとRPAについて
概要
AIとRPAの違いが自分の中でごっちゃになってきたので、それぞれの定義と今後についてまとめていく。
RPAの定義とは
RPAとは「Robotic Process Automation」の略称である。
読んで字の如く、ロボットによる業務自動化である。
あくまで、現段階での話だが、
RPAは業務を自動化してくれるツールやソフトウェアと位置づけられている。
そしてそれはルールベースでの自動化である。
そのあたりはこのサイトがわかりやすく解説してくれている。
AIの定義とは
データを蓄積することで新しいルールを自分で見つける自律的な存在と言える。
それはアルファ碁のような例を考えればわかりやすい。
こちらもチャットボットのように業務自動化をしている。
これからについて
RPAについてはまだルールベースだが、これがAIと融合することで、自律的にルールを生成しながら業務を自動化する存在になると考えられる。
このことからRPAとAIは今後、概念の境界線が曖昧になっていくと考えられる。
Pythonでtwitterのbotつくってみた
以下の手順にお手軽にbotを作ることができた。
１．準備
1.Twitter Appにアクセス
2.[Create New App]で新規appを作成する
3.各種keyを手に入れる
・Consumer Key(API Key)
・Consumer Secret(API Secret)
・Access Token
・Access Token Secret
２．ソース
import tweepy
#認証
consumer_key = 'XXXXX'
consumer_secret = 'XXXXX'
access_token = 'XXXXX-XXXXX'
access_token_secret = 'XXXXX'
auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
auth.set_access_token(access_token, access_token_secret)
api = tweepy.API(auth)
api.update_status('テスト')
これだけで完成。
ただし、「update_status」は重複内容のツイートはエラーとなるので要注意。
新年度に思うこと
今朝のこと
今朝、少し早く会社へ出社したら、めっちゃエレベーターが混んでいた。
新入社員とかが多いのかと思ったけど、観察してみるとそうでもない。
単純に新年度で社長訓示とかがあったのかなと。。。
改めて自分のことを考える①
これまでの自分の価値感としては、「自分の成長」って感じだったけど、最近はそうでもないのでは？と感じてきた。
それは転職とかを真剣に検討した際に自分の信念とか志とかを棚卸ししたり、アイディアとかを書き出したりして感じたこと。
自分の信念としては
・「いらない人や価値がない人はいない」
・「人には誰しも強みがある」
が挙げられる。
これはあまり褒められた家庭環境にいなかったこと、自分が褒められて認められたときの原初体験からきている。
そのルーツを紐解いたときに、ふと自分の中から今までの自己成長という価値観から、自分の信念を貫き通すことにシフトした気がする。
自己成長はあくまでツールであって、ゴールではない。
ゴールとしては自分の信念を形にすることだと考えた。
その観点で考えるとやっぱり今の会社と自分の信念の方向性に疑問を持たざるを得ない。
そのことも踏まえてキャリアカウンセラーに相談しよう。
改めて自分のことを考える②
最近かなり自分は能力が低いのではないか？とか考えるけど、そりゃやったことないことやねんから当たり前やん！
全然知らない分野で見たことも触ったこともないツール導入の見積もりつくって課題管理しろってどだい無理やろ！
この子は管理させるよりも作業させた方がいいんじゃないってPM⇒PLに言われ、若干凹むけど、その方が自分としては楽できるし、勉強させてもらえる思えるからいいや。
管理だけとかやったら出来る気がするし、たぶん慣れたら全部出来るんやろなーと想像しながら粛々とやっていく。
自分はそこまで極端に能力的に低くないけど、知らないことや初回ってやつに極端に弱い傾向があるから、そこをFWとか根本の考え方でカバーできるようにならないとっていう課題はわかったから問題ない。
正直、もはやあまり出世とかにも興味なくなったし、どちらかといえばどうやったら自分が考えてるサービスを実現できるのかのほうが興味が湧いてきた。
やはり副業して起業するのが一番かも。
「なぜ、システム開発は必ずモメるのか？」感想②
「なぜ、システム開発は必ずモメるのか？」の設計編まで読んだので、その感想を書いていきます。
設計
印象に残っているのは、中身が重要ではなく、業務がつつがなく実行できるかどうかが重要であるということ。
判決においても上記の内容が重視されており、稼働後にバグがあっても代替措置があればシステムの瑕疵にはあたらないとされている。
エンジニアとしては美しいシステムをつくるという部分に固執しがちであるが、ユーザ目線やシステム化の目的と照らし合わせれば至極最もだと言える。
また、設計書についての著作権についても触れられている。
設計書はただ単純に誰でも作れる内容であれば、著作権は発生しない。
なぜなら、設計者の独自の考えが表現されたものでなければ著作権は発生しないからである。
「なぜ、システム開発は必ずモメるのか？」感想①
「なぜ、システム開発は必ずモメるのか？」の要件定義～プロジェクト計画編まで読んだので、その感想を書いていきます。
概要
本の内容としては、現実に発生した判例を元にどのようにトラブルを回避していけばよいかを描いている。
ITの本らしく各工程ごとに解説をしてくれており、会話形式で展開されていくため、エンジニアには内容が入ってきやすい。
要件定義
全体を通して言われていることは、昨今の潮流である「要件定義はユーザの責任」だけではないということが語られている。
例えば、他システムからインターフェイスされるデータの形式が想定と全然違うために取り込めないという事例の場合である。
開発経験が少ないユーザに要件定義時点で他システムへのヒアリングしたりすることを自発的にすることはないだろう。
なぜならそもそもそんなことをしなければならないという意識がユーザ側にはないためである。
ベンダはそういったリスクを考慮してユーザに対してそうした動きを促す必要があり、それもプロジェクト管理責任であるというのが、裁判所の判例としてある。
専門家のベンダがきちんとガイドする必要があるということである。
逆にユーザ側も要件定義書が本来のシステム化の方針（業務のどこがどのように変わるのか）や目的（システム化によるメリット）を達成できるのかを当事者意識を持って検証しなければならない。
ユーザもベンダも双方がひざをき合わせて、腹を割ってとことん本気でシステム化について、議論しないとよいシステムは出来ないことが語られている。
プロジェクト計画
まず、リスク管理がプロジェクト管理の要であるといっている。
システム化におけるリスクとして、ユーザ側の人事異動による担当者変更も挙げられている。
そこでの引継ぎはもちろんユーザ側のリスクであるが、そういったリスクが発生した場合にどのように対応するのかを考えておく必要がある。
まとめ
この本に書いてあることはソフトウェア工学やPMBOKで語られていることであり、理想論であるが、理想論を知らないとそこから現実に何を引き算して適用すればよいかわからない。
そういった視点でもこの本の有用性は高いと思う。
