Philosophy
開発者心得
グラフトンノートでは、このような指針で開発に臨んでいます。
- 不可能はない
- お客様の要望を実現するにあたり、様々な障壁があることでしょう。
- 技術的にはどうしても不可能なこともあります。
- だからといって解決できないはずがありません。
- きっとなにかしらのやり方、回避策があるはずです。
- パズルを解くように取り組み、楽しみましょう。
- エレガントに
- 同じ機能でも様々な実現方法があります。
- つまらないやり方ではなく、エレガントな設計をしたいものです。
- フルスタックに、全方位やる
- 「私はその担当ではないから」
- そんな理由でやらないなんて通用しません。
- どんなことからも逃げずに、すべてと向き合いましょう。
- 例えば、なにかライブラリを採用するならば、ライセンスを確認する必要があります。
- 技術者だからといって、法務から目を背けてはいけません。
- 効率よく開発を進めるためには、チームをマネジメントする必要もあるでしょう。
- また、とある開発言語についても知らないから、扱ったことがないから採用しない、
- なんて言わずに採用すべき場合もあるでしょう。
- できなくてもいい、諦めずに取り組む気持ちを持つことから始めましょう。
- 知識と経験に溺れない
- 今この時にだけ通用する知識はいりません。
- 新しい技術を柔軟に取り込んでいきましょう。
- そのときは表面的にとらえるのではなく、本質を理解しましょう。
-
- 最適な手段は、あなたの知識と経験の外にあるかもしれません。
- 今までの経験に囚われることなく、新しい技術を習得しましょう。
- ただ、新しいからと言って飛び付く必要なく、よく吟味しましょう。
- もしかすると使い古された技術が適切かもしれません。
- 対応すべきは不具合ではなく、不都合
- 私たちは不具合だからといって、やみくもに修正しません。
- 本当にすべきことは利用者にとっての不都合を解決することです。
- 例えば、「これは不具合ではなく仕様だ。」と言って修正しないままでは、なにも解決しません。
- たとえ仕様であっても、お客様にとって不都合であるならば修正すべきです。
- あるいは不具合だからといって、お客様に無断で修正してしまうと、意図しない結果となる恐れがあります。
(「はい=0、いいえ=1」としてコーディングしたものの、画面上では「はい=1、いいえ=0」として表示していた。
それをやみくもに修正してしまうと、フラグの意味が反転し、お客様は混乱します。)
-
- 不具合か、仕様か、そんな区分にとらわれずに、より良いものを生み出していきます。
- お客様には好き勝手に無理難題を言ってもらう。私たちが要件を定義する。
- 一般的な受託開発では、発注者が要件定義をすることが多いですが、
- 果たしてそれは適切なのでしょうか。
- 唐突ですが、料理の場合を考えてみます。
- お腹を空かした人がシェフに「なにか美味しいものを作ってくれ」とオーダーします。
- シェフはその人の好みなどを聞き、イメージを膨らませ、美味しい料理をだします。
- その人はきっと満足するでしょう。
- ここで注目したいのは、レシピや調理方法などを誰が考えたのかです。
- 決してオーダーした人ではありません。すべてはシェフが考えたのです。
- ところがシステム開発となると、それが逆転してしまうのです。
- 「ステーキの焼き加減はレアとのことですが、それは何℃で何ミリ秒焼きましょうか。」
- 「ステーキの厚みは何mmにしましょうか。」
- 「下味に使う塩は何グラムほどですか。岩塩でよろしいですか。それとも、、、」
- こんな要件をシェフが聞くわけがありませんし、そもそも食べる人もわかりません。
- それがシステム開発ではお客様が決めなくてはならないのです。
- 「このCSVファイルの定義を教えてください。この項目には最大で何桁ですか、空白になることはありますか。」
- 「レポートデータの集計頻度は日次ですか、それとも2時間ごとですか。それと表示項目を教えてください。項目の順序はこれで決まりですか。」
- お客様はこんなことがしたいのではありません。
- 要件定義はプロに任せるべきです。
- お客様はお望みの物についてイメージだけを語ればいいのです。
- お客様は間違ったオーダーをする。
- お客様に無理難題を言ってもらうとしても、それを鵜呑みにはできません。
- まず考慮すべき点は、理想を語ってくれないことです。
- 極端ですが、「タイムマシンを作ってほしい」とまじめに発注する人はいません。
- それは「そんなものは無理だ」とわかっているから言わないのです。
- システム開発でも同様に、「これは難しいだろうから、こっちの案で頼もう」
- といったことが発生することがあります。
- でも開発者からすると、なんてことない簡単なことだってあるのです。
- 次に考慮すべきは、手段を間違うことです。
- 「これを解決するために、このやり方でやってほしい」と手段を含めて要望されることもあります。
- でも、それがシステムとして適切なやり方ではないかもしれません。
-
- お客様の言ったことから、本当にやるべきことを想像し
- 正しく導いていく必要があるのです。
- お客様の声からは改善しか生まれない。イノベーションは私たちがおこす。
- お客様からの意見や要望はとても大切です。それがシステムを育てていきます。
- ただしそれは、ゆるやかで平凡な成長でしかありません。
- 革新的で飛躍するような成長のためには、私たちがより深く考え抜く必要があります。
- これまでに生み出された素晴らしい製品の発案者は誰でしょうか。
- 決してお客様ではなく、本気で考えたイノベーターたちだと思います。
- 私たちも成さねばなりません。頑張りましょう。