コンタクトフォームへ

Menu

グラフトンノートロゴマーク グラフトンノートロゴ下ライン

ノート

NOTE

だいじなこと

こんにちは。鎌田です。社員番号は3番です。

さて、このサイトは設立7周年を機にリニューアルされたのですが、それに伴ってとあるページが無くなってしまいました。

そのページにはとても大事なことが書かれていたので、ここに転記して今後も忘れないようにしたいと思います。

Philosophy

開発者心得

グラフトンノートでは、このような指針で開発に臨んでいます。

不可能はない

お客様の要望を実現するにあたり、様々な障壁があることでしょう。
技術的にはどうしても不可能なこともあります。
だからといって解決できないはずがありません。
きっとなにかしらのやり方、回避策があるはずです。
パズルを解くように取り組み、楽しみましょう。

エレガントに

同じ機能でも様々な実現方法があります。
つまらないやり方ではなく、エレガントな設計をしたいものです。

フルスタックに、全方位やる

「私はその担当ではないから」
そんな理由でやらないなんて通用しません。
どんなことからも逃げずに、すべてと向き合いましょう。

例えば、なにかライブラリを採用するなら、ライセンスを確認する必要があります。
技術者だからといって、法務から目を背けてはいけません。

効率よく開発を進めるためには、チームをマネジメントする必要もあるでしょう。
マネジメントスキルも身につけましょう。

また、なにかの技術について「知らないから導入しない」「扱ったことがないから使わない」なんて言わずに採用すべき場合もあるでしょう。

はじめからできなくてもいいのです。
諦めずに取り組む気持ちを持つことから始めましょう。

知識と経験に溺れない

今この瞬間だけに通用する知識はいりません。
新しい技術を柔軟に取り込んでいきましょう。
そのときは表面的にとらえるのではなく、本質を理解しましょう。

最適な手段は、あなたの知識と経験の外にあるかもしれません。
今までの経験に囚われることなく、新しい技術を習得しましょう。

ただ、新しいからと言って飛び付く必要はなく、よく吟味しましょう。
もしかすると使い古された技術が適切かもしれません。

対応すべきは不具合ではなく、不都合

私たちは不具合だからといって、やみくもに修正しません。
本当にすべきことは利用者にとっての不都合を解決することです。

例えば、「これは不具合ではなく仕様だ。」と言って修正しないままでは、なにも解決しません。
たとえ仕様であっても、お客様にとって不都合であるならば修正すべきです。

あるいは不具合だからといって、お客様に無断で修正してしまうと、意図しない結果となる恐れがあります。
不具合か、仕様か、そんな区分にとらわれずに、より良いものを生み出していきます。

お客様には好き勝手に無理難題を言ってもらう
私たちが要件を定義する

一般的な受託開発では、発注者が要件定義をすることが多いですが、果たしてそれは適切なのでしょうか。

唐突ですが、料理の場合を考えてみます。
お腹を空かした人がシェフに「なにか美味しいものを作ってくれ」とオーダーします。
シェフはその人の好みなどを聞き、イメージを膨らませ、美味しい料理をだします。
その人はきっと満足するでしょう。

ここで注目したいのは、レシピや調理方法などを誰が考えたのかです。
決してオーダーした人ではありません。
すべてはシェフが考えたのです。

ところがシステム開発となると、それが逆転してしまいます。
「ステーキの焼き加減はレアとのことですが、それは何℃で何ミリ秒焼きましょうか。」
「ステーキの厚みは何mmにしましょうか。」
「下味に使う塩は何グラムほどですか。岩塩でよろしいですか。それとも、、、」

こんな要件をシェフが聞くわけがありませんし、そもそも食べる人もわかりません。
それなのにシステム開発ではお客様が決めなくてはならないのです。

「この項目の定義を教えてください。何桁ですか、空白になることはありますか。」
「レポートデータの集計頻度は日次ですか、それとも2時間ごとですか。それと表示項目を教えてください。項目の順序はこれで決まりですか。」

お客様はこんなことがしたいのではありません。
要件定義はプロに任せるべきです。
お客様はお望みの物についてイメージだけを語ればいいのです。

お客様はときに間違ったオーダーをする

お客様に無理難題を言ってもらうとしても、それを鵜呑みにはできません。
まず考慮すべき点は、理想を語ってくれないことです。

極端ですが、「タイムマシンを作ってほしい」とまじめに発注する人はいません。
それは「そんなものは無理だ」とわかっているから言わないのです。

システム開発でも同様に、「これは難しいだろうから、こっちの案で頼もう」といったことが発生します。
でも開発者からすると、なんてことない簡単な場合だってあるのです。

次に考慮すべきは、手段を間違うことです。
「これを解決するために、このやり方でやってほしい」と手段を含めて要望されることがあります。
でも、それがシステムとして適切なやり方ではないかもしれません。 

お客様の言ったことから、本当にやるべきことを想像し正しく解決していく必要があるのです。

お客様の声からは改善しか生まれない
イノベーションは私たちがおこす

お客様からの意見や要望はとても大切です。
それがシステムを育てていきます。
ただしそれは、ゆるやかで平凡な成長でしかありません。
革新的で飛躍するような成長のためには、私たちがより深く考え抜く必要があります。
これまでに生み出された素晴らしい製品の発案者は誰でしょうか。
決してお客様ではなく、本気で考えたイノベーターたちだと思います。
私たちも成さねばなりません。
頑張りましょう。

一部改変しました。

というわけで開発者としての心得を転記しました。
折を見て見返して、常に意識して、これからも頑張ってまいります。