シブサワ・コウ 0から1を創造する力

シブサワ・コウ 0から1を創造する力

を読みました。

 

昔は「三国志」が漫画、人形劇などで、大好きだったので、光栄のゲームもよく遊んでいました。

ただ、光栄のゲームは高額なので、子どもには、多すぎるシリーズを追えなくなったのか、しばらくすると遊ばなくなりました。

ですが、最近、司馬遼太郎の「国盗り物語」を読んだら、また、無性にやりたくなり、PSPでダウンロードして、遊んでいます。

いまは廉価版があり、昔のゲームが安価に遊べるので、助かります。

 

歴史シミュレーションゲームって、結局、そんなに駆け引きはなくて、同じことの繰り返しになってしまうんですが、実在の人物を操れるというキャラクターものとして不変の面白さがあると思います。

世界観を楽しむのであれば、何度でも遊べる。

また、年齢的にもアクションは、しんどくなってきたので、落ち着いて取り組めるゲームがやりたいという気持ちにもヒットしました。

と、そんな経緯で、本書に興味を持ちました。

 

内容は、シブサワコウ=襟川社長の歩みです。

光栄は、最初は染料問屋だったんですが、奥様からパソコンをプレゼントしてもらい、趣味で始めたゲーム作りを本業にしていったそうです。

もともと、ゲームと歴史が好きでということなんですが、独学で始めたことをここまで発展させているわけで、技術者としても、経営者としてもすごい方だなと思いました。

好きと才能について考えさせられます。

 

光栄はアダルトゲームを作っていた時期があるとか、ジンギスカンは世界で売れなかったとか、ファンには、ゲーム話が非常に興味深いのですが、仕事術の話としても面白いです。

 

仕事術の話としては、困難に前向きに取り組む、商品に自信を持つ、コンセプトが大事とか、一見、普通なことが書いてあるんですが、襟川社長の語り口がとても誠実なので、仕事の基本を見直させられます。

個人的には、部下に仕事を任せるときの基準は、成功の可能性が6割あると感じたときというのは、実践したいなと思いました。

 

メディア露出も多くて、話が面白いので、私が見た動画を貼りますね。

ゲームと歴史が大好きということは疑いがなく、人当たりの良さも好印象で、よりファンになると思います。

 

・神奈川ビジネス Up To Date

 

 

無印良品は、仕組みが9割

無印良品は、仕組みが9割

を読みました。

 

僕がリーダーをしていたプロジェクトが炎上してしまった。

調整で手一杯で、成果物の確認ができないでいたら、各々、好き勝手なものが出来上がっていき、最後、メチャクチャになってしまった。

コーディング規約はあったのだけれど、もっと根本的なところがいろいろとおかしくて、自分の常識は他人の常識ではないことをつくづく実感できました。

まあ、そもそも、コーディング規約すらも、守られていないというね。。

この失敗を繰り返さないために、標準化を考えるようになり、標準化の研修を受けたときに、この本を紹介された。

無印良品が標準化を取り入れたことにより、業績が回復したという話。

V字回復カッコいいですよね。

 

この本の中で実践したいと思ったことをメモ。

■チームリーダーの役割

仕組みを作って、部下の行動を変える。

→部下に、こうしなさい、ああしなさいと云うことだけを、指導というのはどうなのかと思っていたので、こういう考え方は受け入れやすい。

 

■マニュアル

「こうした方が、いいのに」を集める。

「それぐらい、口でいえばわかるのでは?」と思われるようなことまで明文化する。

・何

・なぜ

・いつ

・誰が

を冒頭に記載し、なぜそれが必要なのかを伝える。 

あと、いい具体例、悪い具体例を挙げると分かりやすい。

→この様式でいきます。

 

■提案書は「A4一枚」

会議の準備にかける時間は最小限にとどめて、実行に時間をかける。

→資料はシンプルに。

 

システム開発の標準化として、まだ、何をすべきかが分かっていない。

分野も幅広いし、内容もたくさんあるだろうから、取捨選択して、読むのが苦痛でない程度にシンプルで、なおかつ品質向上が望める内容を目指したい。

難しそう。。

時間をかけて、考えていきます。

新訳 道は開ける

新訳 道は開ける

を読みました。

 

不安にならない方法について、いろいろな事例を挙げて、ひたすらに書かれていたという印象。

まとめると、こんな感じだったと思います。

・1日を区切りとして、過去は振り返らない。

・悩みを分析して、対処する。

・最悪を想定して、備える。

・不安を感じる暇が無くなるくらい、忙しくする。

・時には祈る。

 

超要約ですが、こんなことが、延々と続き、さらには、繰り返し読むことを推奨するとありまして、これらを習慣にするには、確かにそうなんでしょうけれども、他の本も読みたいし。。

まあ、くよくよしてても仕方ないぞってことですね。

ruby on railsでwebアプリケーションを作った

勉強と趣味を兼ねて、ruby on railsでwebアプリケーションを作りましたので、所感を書きます。

 

成果物はこれ。 

午後ローデータベース

みんな大好きテレ東「午後のロードショー」のデータベースです。

日にち、タイトル、特集から映画を検索することができます。

 

まずは学習。

ドットインストールと公式チュートリアルをやりました。

ドットインストール Ruby入門

ドットインストール Ruby on Rails 4入門

railstutorial.jp

 

これで、だいたい概要をおさえました。

あと、分からないことは、調べながら進めていく。

ドットインストールは要点のまとまり具合は、本当に素晴らしいです。

 

開発の流れは、

データベースを設計。

モデルを作成。

コントローラ、ビューを作成。

こんな感じでやっていきました。

 

まず、コマンドでテーブルとモデルを作成。(DDL不要)

作成されたモデルにテーブルの関連を書くと、ActiveRecordというORMでテーブルアクセス処理を提供してくれる。(SQL不要)

この仕組みはCakePHPに似ていて、javaのentityをいちいち作るのは面倒ないので、この単純さは好き。(CakePHPRuby on Railsを基に作られている)

あとは、コントローラに業務処理、ビューに画面生成処理を書いて、ルーティングを設定。

この繰り返しでやりました。

 

ライブラリも管理されていて、サイト情報取得にnokogiriバッチ処理wheneverを使いました。

こういった便利機能が手軽に利用できるところも助かります。

asset pipelineは使いませんでした。

 

開発環境は、以下を利用。

os:CentOS

webサーバ:nginx + unicorn

データベース:sqlite

バージョン管理:git

 

単純なサイトというのもあったと思いますが、印象としては、サクサク開発できて、楽しかった。

このサイト、全然、アクセスがないので、もっと検索されるようにしたいと思います。

最新フロントエンドフレームワークを利用した開発事例!

ヒカ☆ラボの勉強会に参加してきました。

atnd.org

 

テーマも興味があったのですが、社内で勉強会をやろうと計画していて、その参考にという視点でも勉強させてもらいました。

その点についてまとめます。

 

・全体の構成

発表者と別の進行役が、司会進行。

最初に全体の説明をし、各発表。

最後に配布したQRコードから、googleアンケートフォームを使ったアンケートを実施。

アンケート内容は、各発表が、面白かったかとか、今後やってほしいテーマはみたいなものだった。

終了後、軽食付き懇親会。

懇親会を除く時間は1時間40分。

 

・資料について

登壇者は3人でしたが、全員PCはmac

keynoteの資料は、power pointよりも、圧倒的にイケてる。

 

・発表の構成

最初に、自己紹介、会社紹介。

最後は、ご清聴ありがとうございましたで締める。

時間はひとり15分の予定だが、全員押し気味。

時間があれば、質疑応答をする予定だったようだ。

 

・気づいたこと

笑いを入れると盛り上がる。

実演を入れると興味をひく。

 

弊社でやるとしたら、こんな感じがよいかと考えた。

・いろいろな人がいるので、深入りした内容よりも、0ベースから理解できる内容のほうが良さそう。

・アンケートをスマホから回答してもらうのは、エコでスマート。

・懇親会は、軽食を目当てに集客できるかも。

エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法

エンジニアのためのGitの教科書 実践で使える! バージョン管理とチーム開発手法

を読みました。

 

この本は、概念と基本コマンドをそこそこに説明したあと、運用にページを割いて説明しているところが特徴的でした。

バージョン管理は、コマンドは覚えた。さあ、使うぞ!となったときに、じゃあ、みんなでどう使うの?というところが最も重要だと思うので、コマンドだけでなく、運用に比重を置いて言及している点が良かった。

コマンドは数が多いので、必要に応じて、調べ、その中で、よく使うものを覚えていけばいいと思います。

ということで、初学者にお勧めできる内容だと感じました。

 

運用ですが、私がgitを使うときは、git flowを使います。

git flowは、こんな感じ。

qiita.com

 

リリースで特別、何かをすることがあまりないので、releaseブランチは省いて運用しています。あとは、hookで、push時に、最新ソースをテスト環境へデプロイするようにしたら、便利でした。(hookは、svnでも存在する仕組みですが)

自社サービス等で、継続して開発していくようなプロジェクトでは、運用は工夫のしどころだと思うんですが、弊社の業務は一度作ったら終わりということが多く、とりあえず履歴が残ればいっかとなりがち。gitは難しいという理由から、svnを採用したプロジェクトもある。それでも、問題ないのだけれど、gitは、多くの人が使っているものだから、もうシステム開発のスキルとして必要ですね。

 

svnからgitに切り替えて便利だと思う点は、ローカルで簡単にブランチが作れるので、現行バージョンを残しつつ、容易に試行錯誤ができる点。

みんなで覚えて、どう使ったらより快適に開発ができるかということを考え、推進してきたい。

プログラムの生産性

今、進行中のプロジェクトで、システムの想定開発ステップ数を聞かれている。
それに対する実績ステップ数で、製造工程の進捗率を出すのだとか。
作ってみないと分かるわけないのだけど、簡単に分かりませんとも云えないので、
見積もりの開発工数 × プログラムの生産性
で出してみることにした。

プログラムの生産性をいくつにするか。
「ソフトウェア開発白書2014-2015」からプログラム言語ごとの生産性を見てみる。
新規開発、改良の(SLOC/人時)の中央値を抜粋した。
(SLOC/人日)(SLOC/人月)は、それぞれ×8、×160したものとする。


主要開発言語別SLOC生産性の基本統計量(新規開発)

言語 生産性(SLOC/人時) 生産性(SLOC/人日) 生産性(SLOC/人月)
COBOL 5.6 44.8 896
C 5.3 42.4 848
VB 5.8 46.4 928
Java 5.8 46.4 928


主要開発言語別SLOC生産性の基本統計量(改良)

言語 生産性(SLOC/人時) 生産性(SLOC/人日) 生産性(SLOC/人月)
COBOL 3.5 28 560
C 3.5 28 560
VB 4.0 32 640
Java 3.5 28 560

Javaの新規で、1時間に5.8行。
ちょっと、少ない気がするが、慣らすとそんなものなのかな。
ひとまず、これを基準にやってみます。