ピープルウェア

ピープルウェア

を読みました。

 

システム開発における人間関係や職場環境について言及した本です。 

(技術のことは一切出てこない)

1987年初版で、世間一般的には、IT本の名著ということになっています。

 

気になったことをいくつかメモします。

 

■目標値設定者による生産性の違い

目標値を設定した人によって、生産性が変わるというデータ

マネージャー < プログラマーとマネージャー < プログラマー < システムアナリスト < 目標なし

 

マネージャーが目標を設定すると生産性が最も低く、目標なしとした場合に生産性が最も高くなる。誤った見積もりが、作業者のやる気を削ぐとのこと。

→よく分かる。

 

■マネジメント

マネージャーの役割は、人を働かせることにあるのではなくて、人を働かせる気にさせることである。

→管理者の基本として、覚えておきたい。自分が部下として、上司に働く気させられた場面は、上司のすごい仕事振りを見せられたときだ。上司は、部下よりも、質と量を高く働いていないとダメだと思う。

 

プログラマーの能力差

プログラミングコンテストのデータを分析した結果が掲載されていて、最優秀者の測定値は、最低者の約10倍である。

→10倍の性能差!管理をしていると、コイツ使えねえ、どうする!?という場面がある。このデータを見て思うことは、単価が高くても、生産性が高ければ、割に合うということ。弊社の開発者の単価は高くないので、協力会社の開発者に来てもらう場合も、高いとダメとなってしまうが、2人分、3人分のパフォーマンスを出してくれるのであれば、それは安いのである。だけど、生産性の比較なんて通常業務ではできないし、それは、終わったあとに分かることだ。

 

■フロー状態

ひとつのことに没頭し、ほとんど瞑想状態になること。作業を途切れさせない環境が必要で、別作業との切り替えや、電話による作業の中断がフロー状態の妨げとなる。確か、プロジェクトは一人、ひとつが望ましいと書いてあった気もします。

ドラクエ11のゾーン!私はプロジェクトを掛け持ちしているし、マネージャーの管理業務もあり、やることが多すぎて、もうフローに入れません。作業効率を上げたいのだけれど、タスクが多すぎて、集中できない。どうしたものかと思っている。

 

■人材を揃える

マネージャーは、部下の本質的な人格を変化させるほどの影響力を持てないのが普通である。これは、最初に人材を揃えることが何よりも重要だということを意味する。

→部下の育成とよく云われるのだけど、簡単に人は変わらないんだよ。そして、プロジェクト開始時に、優秀な人を揃えるのは難しい。

 

■人的資本への投資の評価

プロジェクトを抜けた人の代わりに、新しい人を入れると、生産性が低下する。

→プロジェクトは、同じメンバーでやりきるのが望ましい。私の勤めていた前の会社は、同一プロジェクトでよく人の入れ替えをしていて、いつも、なんで?と思っていた。

 

■満足感を与える打ち上げ

仕事をいくつかに分割し、その一つひとつが、それなりに満足感を味わえるようにする。

→チームのモチベーション維持に活用したい。

 

人によっていろいろな気づきのある本だと思います。

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

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

を読みました。

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

 

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

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

 

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

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

 

ゲームセンターCX

 

・神奈川ビジネス 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に切り替えて便利だと思う点は、ローカルで簡単にブランチが作れるので、現行バージョンを残しつつ、容易に試行錯誤ができる点。

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