チーフデザイナーとプロジェクトマネージャ、どちらが上に立つべきか | タイム・コンサルタントの日誌から
宮崎駿の映画「風立ちぬ」は、ゼロ戦の設計者・堀越二郎を題材にした物語だ。堀越は実在の人物だが、映画全体は評伝ではなく、フィクションの色彩が強い。とはいえ、物語は主人公・二郎による新型飛行機の設計を軸として展開していき、その部分は比較的史実に近い。だから、一種の製品開発プロジェクトのストーリーとしても、見ることができる。その中における主人公の職務上のポジションは、「設計主任」だ。設計主任とは何か、その役割は開発プロジェクトのプロジェクト・マネージャーとは何が違うのか。そんなことを、今回は考えてみたい。 設計主任に対応する英語はいくつかありうるが、チーフ・デザイナーあたりが最も一般的だろう。ところで、チーフ・デザイナーというと、もう一つ思い出すストーリーがある。ハインラインの「月を売った男」だ。これは月世界旅行の夢にとりつかれた主人公ハリマンが、月ロケットを完成させるまでの物語である。小説が書
コミットコメントを意地でも書かせたい - almost nearly dead
コミットコメントを意地でも書かせたいと思うことがあります。 でも意外と書いてもらえなかったりします。 酷い場合だと バグ修正 とか 対応した だけ書いてあったりします。 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 単にエラーだと障碍だと騒ぐ人達が居るので、コメントの重要性をエラーメッセージで語りかけるようにもしてたりします(笑) 以下はTracLightning環境下で動作する(はず)のScriptです。*1 キーワードの定期的な見直しは必要ですが、コメントを書かないとコミットできなくなるので意識付けを行うのには有用だと思います。コミットコメントが書いてもらえないと悩んでいる方は試してみては如何でしょうか。 ＃結構やっ
思考停止ワードとコミットログとコードコメント - 勘と経験と読経
古い記事になるのだけれど、バージョン管理ツールにコミットログのNGワードを登録するという話が面白かった。ソフトウェアは思考がそのまま品質につながるようなところがある。思考停止に近しいワードを禁止してしまうのも手かもしれない。 コミットログのNGワード 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 コミットコメントを意地でも書かせたい - almost nearly dead 単にコメント無しを規制するだけではなく、思考停止してしまうようなワードを禁止しているのが素敵。 また、これに加えて会社名や人名も禁止してしまうのはうまいやり方だと思う。人の名前が出てくるとそこで情報が隠蔽されてしまうし、「問題 VS 我々」のスタンス
問題解決のデッドロックを叩き壊す、とにかく考えを前に進めるための方法
「とにかく書け」とか「とにかく読め」という話を何回か書いてきた。 （「とにかく書け」という記事） ・「自分の書く文章は価値がない」を抜け出すライティング・マラソンという方法←自己検閲を振り切って書きなぐるために 読書猿Classic: between / beyond readers ・心理学者が教える少しの努力で大作を書く／多作になるためのウサギに勝つカメの方法 読書猿Classic: between / beyond readers （「とにかく読め」という記事） ・聞けば身も蓋もない１冊を３０分で読む方法と習慣 読書猿Classic: between / beyond readers どんなやり方がよいか考えあぐねて、ぐるぐる逡巡しているくらいなら、とにかく取り掛かった方が早いし速い。 やり方を改善するにしても、試行錯誤の中で行わないと結局うまくいかない。 書くこと・読むこと以上に、
システム自炊法による栄養摂取アーキテクチャの構築 - 太陽がまぶしかったから
腹一杯食べながらの栄養不良 「腹一杯食べながらの栄養不良」。単身赴任者は南洋の島々に送られた兵士のようなものであると著者は表現します。エターナル・フォース・ボッチ（孤独に死ぬ）の呪いを掛けれた私はさしずめ神風特攻隊のようなものです。本書が指摘する単身赴任や多忙をきっかけに食生活が乱れて体調を崩すというあるある話に耳が痛いです。 多忙になったり、通勤時間が増えたり、人間関係等の問題があったりすると物理的な時間制約や気力減退から外食が多くなり、ストレス解消で好きなものだけを食べてしまったり、下手をすればスナック菓子と酒だけで済ましてしまう事もでてきてしまいます。当然太るし、栄養素も足りません。『ナリワイをつくる:人生を盗まれない働き方』ではベンチャー企業で多忙な生活をして毎日ハーゲンダッツを食べていたら肌荒れになって「これはあかん」と思ったみたいな話が出てきますが、まさにです。 『エンタープラ
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
仕様書で駆動される生産管理システムの開発事例<第26回関西IT勉強宴会>
ついにXEAD Driverで動く生産管理システムを 公開されました 。その記念講演でした。 場所はいつもの通りシナジーマーケティングさんに無償で会議室をお借りしました。本当にありがたいと思っています。梅田界隈で、20名程度の会議室を貸して頂ける企業がありましたらお声をお...
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
