Hatena::ブログ(Diary)

杉風呂2.0 - A Lifelog -

2014-11-03(月)

[]エンジニアが事業計画を知らなくてモノが作れるのか?

駄文ポエムです。

  • 先のことなんてわからないし、事業計画通りにいくわけがない。だがしかし
    • 何ヶ月後にどのくらいのユーザを集めたいのか、それがどれくらいのトランザクションを発生させるのか知らなくて作れる?
    • たとえYAGNIといっても直近作るfeatureぐらいは知っているべき
  • 事業規模に合わせて段階的にスケールさせていけばいいが、そのタイミングがいつなのか知っているか?
    • プロトタイプレベルの実装とプロダクションレベルの実装は違う
    • 機能が変われば最適なデータモデルやアプリケーションアーキテクチャも違う
    • チーム体制だって違う
  • エンジニアは、トレードオフを都度判断し、決定する
    • エンジニアリング上の判断がサービスの成長や企業の収益に直結する時代
    • 設計を統合したり、ビジネスサイドや経営層にリスクを説明したり諸々提案、交渉する役割を担う人が重要
  • プログラミングできればそれで満足なエンジニアなんてほとんどいない
    • サービスが提供する価値は何か、自分のやったことが会社にどういった利益をもたらすのか、世の中にどう役立つのかを知らないで仕事できないよね
    • にんげんだもの

2013-01-20(日)

[]『リーダブルコード』を他書と読み比べる(その1)

よい本なので、他書と比較しながら再読していきます。短期集中連載のつもり。

1章 理解しやすいコード

ここでは本書の根底となる「すべての原則が生じるテーマ」と「読みやすさの基本定理」について説明がされています。

コードは理解しやすくなければいけない。

コードは他の人が最短時間で理解できるように書かなければいけない。

C++ スタイルブック (IT Architects’ Archive―CLASSIC MODERN COMPUTING)』の「はじめに」には次のように書かれています。

チームが成果を上げるには、誰もが、他の人の書いたコードを読んで理解できなければならない。

Code Craft ~エクセレントなコードを書くための実践的技法~』1章「防御的プログラミングの技法」には次のように書かれています。

簡潔性よりも明瞭性を重視してコードを書く

簡潔ではあるのものの混乱を招くおそれのあるコードと、明瞭ではあるものの長く退屈に感じられる可能性のあるコードのどちらかを選べる状況では、洗練性には多少欠けるとしても、誤解なく明確に意図を読み取れるコードの方を使用します。(中略)自分が書いたコードが誰かに読まれる可能性があるのかを考えてみてください。そのコードの保守を比較的経験の浅いプログラマーに任せなければならない場合もあるかもしれません。その担当者がコードのロジックを理解できないとしたら、間違いが起きることは必至でしょう。複雑な構文や言語仕様を巧みに利用した小技を使えば、演算子の優先順位を知り尽くした博識ぶりを見せつけることはできるかもしれませんが、それによってコードの保守性は無残に損なわれてしまいます。「コードは常にシンプルに」が鉄則です。

Javaプログラミングの処方箋 (Programmer’s foundations)』には、逆に読みにくいコードがもたらす弊害について書かれています。

このようなコードは非常に読みにくく、このあとにこのコードを読む人に誤解を与えます。また、一度このような「汚いコード」が入ると、その汚いコードがほかにもどんどん波及していきます。元のコードが美しければ、それを「汚す」には勇気がいりますが、もともとが汚ければ誰しもコードを綺麗に保とうとしなくなります。

プログラマのためのサバイバルマニュアル』には次のように表現されています。

人は、複雑さの逆と言われると、単純を思い浮かべる。しかし、私たちの分野には避けられない複雑さがあるので、いつでも単純なコードが書けるとは限らない。複雑さの反対語としてより適切なのは、明快である。あなたのコードがしていることは、読者にとって明解だろうか。

プログラマのためのサバイバルマニュアル』は上記文章のあとで「2つの明快」について説明が続くのですが、「避けられない複雑さ」というのが気になります。『Developer's Code 本物のプログラマがしていること』(電子書籍もあるよ!)第4章「複雑さ」に面白いことが書かれています。

ほとんどのアイデアーーー見た目にはシンプルなアイデアーーーはその詳細に立ち入るとひどく複雑なものになる。高いレベルで考えている限り、アイデアはいつもシンプルだ。(中略)詳細に分け入ってみれば、ロジックのどこに穴があるのか、そのすべての場所が見えてくる。詳細とはそういうものなんだ。最後まで考え抜かれていないアイデア(つまりほとんどのアイデア)はこの時点で、複雑であることから逃れられなくなる。(中略)僕らは不十分であることを恐れている。そこにその答えがある。何かをシンプルに構築すると、それが十分なもののような気がしないんだ。

『Developer's Code』ではこのあと、複雑さを「コードが書くのが難しい」ことと複雑さがユーザに転移してしまった「使うのがむずかしい」ことの2つを引き起こし、「複雑さを表に出さない」こと、コードの複雑さを嫌うあまり「リファクタリングをあまりに早い段階で行うことの危険性」についての議論になっていきます。

コーディングの際にバイブル的な本として有名な『CODE COMPLETE 第2版 上 完全なプログラミングを目指して』を参照してみると、5.2.1「ソフトウェアの鉄則: 複雑さへの対応」に、Fred Brooksの定義を引用していますね。

Brooksによれば、ソフトウェア開発を難しくするのは、本質的な(essential)問題と偶発的な(accidental)問題という、2種類の問題であるという。

どうやら、複雑さへの対応として読みやすさが重要であるようですね。また、『CODE COMPLETE』5.2.2「設計に望ましい特性」に設計の内部特性を10個挙げています。

  • 最小限の複雑さ
  • 保守性
  • 粗結合
  • 拡張性
  • 再利用性
  • 高いファンイン
  • 低いファンアウト
  • 移植性
  • 無駄のなさ
  • 階層化

このうち、保守性がリーダビリティに関係あります。

保守の容易さとは、保守プログラマのために設計することである。保守プログラマがあなたの書いているコードについてどのような質問をするか常に想像しよう。保守プログラマを顧客と見なし、見ればすぐわかるようなシステムを設計しよう。

Kent Beckは『実装パターン』で次のように述べています。

何をシンプルとするかは人それぞれだ。ツールと技術を知り尽くしたプログラマから見たシンプルは、初心者には複雑すぎるかもしれない。相手を意識したときに、よい文章が生まれるように、よいプログラムも読み手を意識したときに生まれる。読み手の少し上を行くのはよいが、あまり複雑すぎると、相手にされなくなってしまう。(中略)コミュニケーションとシンプルは一体となって働くことが多い。余分な複雑性が減少すると、システムの理解が容易になる。コミュニケーションを重視すれば、どの複雑性を捨てるべきかが明確になる。

コミュニケーションまで含めているのがKent Beckらしいですね。相手あっての読みやすさということでしょうか。読みやすさが重要ということが十分に意識できたので、明日は2章「名前に情報を詰め込む」に入りたいと思います。

2007-09-01(土)

[]XP祭り2007に行ってきたよ

※後で追記するのでブックマーク等はちょっと待って下さい。

注意:発表資料に書いてなかったことを中心にメモしています。できるだけ本人の表現で書いたつもりですが、聞き間違い、意図の取り違えがある可能性があります。

「トリアージプロジェクトマネージメント 」 (相馬純平さん・株式会社ラグザイア)


そういえば、僕が今年の新人1名に最初に与えた課題は、相馬さんの『WEB+DB PRESS Vol.38』の「新人歓迎企画 これからのソフトウェア開発者に求められること」を読んで書評をまとめ、TracWikiにアップロードさせる、というものだったなぁ。


  • かつてのソフトウェア学習法
    • 昔はソースをネットでぐぐれない。タンスの中からファイルを探し出して読むといったやりかた。
  • 見積もり方法
    • 世の中には「えいや」という便利な言葉がありまして、部長が言うわけですよ。「えいやで、ざっくり見積もってくれ」と。
  • 昔はウォーターフォール
    • 後戻りのないWFもあるらしいが、政府も含め通常は、修正する場合は滝をもう一本起こす。
    • クローズドだった時代は見積もりが今より外れにくかったが、オープンになって見積もりが合いにくくなった。
    • コンベもあるし、予算は厳しい。結局契約時にいくらもらえたか。
  • 反復型へ
    • 結局ケツカッチンで開発者にしわ寄せがくる。
  • アジャイルへ
    • XPやAgileは無法地帯、開発者天国みたいなイメージを持たれる。
    • 少なくとも見積もりしないでコンベに行ったら間違いなく受注できない。
  • XPの力
    • XPは反復型でリスクが少なくて、ペアプロとかリファクタリングできれいなコードが書ける。
    • でもXPのパワーはそれで終わりじゃないだろ!
  • アジャイルの誤解
    • 反復型を期間を非常に短くするとアジャイルになるか?違う。
  • 4つの要素
    • コスト、機能、品質、納期(新人教育でよく習うような。)4つのいくつかに余裕を取る。
  • PMになりたくない理由
    • 会場で挙手を募る。PMになりたい人は一人もおらず、なりたくない人には半数以上が手を挙げる。
    • リーダーは
      • 進捗を「見る」
      • お客さんに謝る
      • ごきげんを伺う
      • ピザを買ってくる
    • ことしかできない。
    • → 計画駆動型では、4つの要素をロックインして中が埋まるのを眺めているだけ
  • 技術者に大事な能力2つ
    • 理解する能力
    • 思いつく能力
  • もともと結果がユーザにはあるはず(今見えなくとも徐々に見えてくる)
    • エンドユーザはIT化の前に業務分析を結構やっていることが多い。経営上、目的は必ずあるはず。
    • 3つはロックインされていることが多いので、1つを動かせるように交渉する。
    • ラグザイアではどうしているか
      • 顧客の前でガンガンつくる(リードタイムの長そうな機能のみ仮実装)
      • Railsでもまだ画面のリードタイムが長い(HTMLだから)。
      • UIはUI専用言語、専用環境にまかせる(昔からUIだけでもMS製品を使ってみたかった。今ならAdobe AIRやMS Silverlightがある。)
      • 今は実装のリードタイムがどんどん短くなってきているので、検討も速くしなくては間に合わない
    • エピソードをひとつ
      • あるEU企業に「ある会社に見積もりを出したら200億と言われた。相馬さんのとこならいくらか見積もってよ?」と言われ、次の週に、若干チープではあるが完成品を持っていき、その場で顧客の「こここうしてよ」を聞いて変更していった。
  • TPMにおける要素が測定できると非常に説得力がある
  • 契約形態
    • いままでで最悪のプロジェクト
      • 3000万という額は決まり
      • 機能がなくてあるのは要求だけ
      • 作っていて途中で実現できないことに気づくと「貸しだ」と言われる。
      • ユーザ企業が不動産や金融だとかなりヤクザなことを言ってくる(ITベンチャーも)
    • 両極端しか存在しない契約形態
      • 一括請負
        • 受ける方が負担
      • SES契約
        • 顧客が負担
    • ラグザイアの順請負契約(実際は個々の契約で少しずつ違う)
      • 今の所上手くいっている

時間に余裕があったのでここからアドリブでした。

  • とにかくまずは業務分析(たしか、必ずしもSEでなくてもよい、というようなことを言われたと思う)、次にシナリオの抽出。
  • 価値の単位
    • ログイン機能は価値じゃない。ユーザ登録画面と一体で価値がある。さくさく動くのは価値じゃない。
    • お客さんが価値を受け取る単位を抽出する
  • 技術力
    • 一番最初に大事な機能を作って動く状態を維持しながら検討を続ける
    • →きれいなコードを書く技術(リファクタリング、名づけ等)が重要
  • これらの技術がないと開発が進むにしたがって検討に対する実装のスループットが追いつかなくなってくる。

Q&A

  • 機能を最初に決めなくて大丈夫か?

逆に「本当に決めてしまって大丈夫か?」ときいてみればいい。オンライントレードの企業やベンチャー企業はは小さい投資で最大の効果を得たいと考えているところが多い。@ITの記事も参照してほしいとのこと。

  • 受託開発ではなくパッケージ開発ではどうか?

(すみません。suginoyは聞き逃しました。実績があるということだけは覚えています。)

  • 信頼を最初に得るのは難しいのでは?

小さいところからコツコツやるしかない。また、技術教育を重視していて、セールス的な「できます」は言わせないようにしている。

  • (上記回答に関して)営業にも徹底しているのか?

このあたりは今の代表と気があって一緒にやっていけると思ったところなのだが、営業の人も開発を経験しなくてはいけない。「あれやってみないとわかんないよね。意外とハマるから。」というのがわかる。

  • 今までの説明ではまだ本当に信用してもらえるのかという懸念がある

SIは整体師に似ていると言える。マッサージしてもらう前に効果を約束させるのか?延長するかどうかはサービスを受けてみてから決めるはず。こちらは技術をもってサービスを提供する。また、ラグザイアでは開発プロセスに効果測定と提案がある。効率性を信用してもらう。次の号の『WEB+DB PRESS』誌にラグザイアの代表が提案書の書き方について寄稿するので参考にしてほしい。

  • 業界には非効率だからこそお金がもらえている事実がある。大きな会社に通用するのか。

SIerが大きくある意味があるのか?ほとんどないはず。絵描きの事務所が大きくて意味があるのか?SI業界は競争がフェアじゃない。