エンジニアこそ直感を生かせ！
あなたがプログラムを書くとき、どのように書きますか？ 最初にフローチャートを書きますか？ それとも、いきなり書き出しますか？
わたしはどちらかといえば後者で、とりあえず作ってしまうタイプ。もし、納品の都合でフローチャートを書かなければいけなければ、作り終わった後で書いたり、プログラムから仕様書を作ってくれるツールを使ったりしていました。
わたしは現在、積極的にプログラムを書いているわけではありません（既存のプログラムにカスタマイズする程度）が、プログラムを書いていたころ、「プログラムを先に書く」ということはあまりよくないことだと思っていました。なぜなら、プログラムを書くためには、まず最初に論理的に流れを考えて、綿密に設計することが大切で、それを元にコーディングすると教わっていたからです。設計書をプログラムに置き換えるだけだと。
けれども、わたしはいつもプログラムが先。仕様を聞けば「こうすればいける」というのがなんとなく分かる。それは、本当になんとなく「いける」という感覚なんです。直感とでもいいましょうか。設計なんてしなくても分かる。それは言葉ではうまく説明できないのですけれど、分かるんです。そこで、コアとなる部分をまず形として作ってしまう。それから設計書を後付けするような作り方をしていました。
でも、ウォーターフォール開発の流れからすると、これはよくないこと。
……だと思い込んでいました。
脳機能学者の苫米地英人さんをご存じですか？ 苫米地さんの本の中に、「夢をかなえる洗脳力」という本があります。その中で、プログラミングについて面白いことが書かれています。
例えば、数学が苦手な人は、
「AならばZであることを証明せよ」
といわれて、
「AならばBである。BならばCである……YならばZである。ゆえにAならばZである」
という風に考えるところを、数学が得意な人は、論理的に考えなくても証明の全体像をイメージできると苫米地さんはいいます。プログラムも同様で、頭の中にすでにでき上がっているイメージを単に打ち込んでいく作業だと。
わたしはこの感覚がとてもよく分かるんです。この本の中で、苫米地さんはバグを見つけるときも同様だといっていますが、確かにバグを見つけるときも、「大体あの辺だろうな～」というのは論理を追わなくてもなんとなく直感で分かる。
この本を読んで、「プログラムを先に書くのは間違いではなく、むしろ理想的な形だったんだな」と気付いたんです。プログラマから仕事を変えた後なのが残念ですが（笑）。けれども、この直観力は現在も大いに役立っています。
納品物としてドキュメントを作ることや、後で見たときに何がどうなっているのかを分かるようにしておくのはとても大切なことです。ですから、「わたしは直感でプログラムを作ります。だからドキュメントは作りません！」ということを薦めたいわけではもちろんありません。けれども、もし、あなたが仕様を聞いただけで「パッとひらめく」のでしたら、それはすばらしい才能なんです。そんなトレーニングが、プログラミングを通じてできれば最高ではないかと。
具体的にどうすればいいかは、苫米地さんの本を読んでみてください。この本に書かれている「抽象度を上げる」などの考え方は、オブジェクト指向プログラミングなどにも参考になると思いますよ。
コメント
インドリ
コーティング先行型開発はバグを生み、デスマーチを呼び込みますので危険な考えだと思います。
私の場合、仕様書を見たり、顧客と会話をすれば、設計と実装が同時に脳内に構築されます。
ハッカー達はプログラムを先にしているように見えますが、実は脳内で設計書を書き、その設計に基づきプログラミングをして、その結果を反映して脳内の設計書を書き換え、またプログラミングをして・・・のスパイラル開発をしています。
そういった事も踏まえて、理想的には抽象度の高い言語で設計を書き、それを徐々に抽象度の低い言語で実装するのがベストだと思います。
■インドリさん
コメントありがとうございます。
> コーティング先行型開発はバグを生み、デスマーチを呼び込みますので危険な考えだと思います。
インドリさんはそうお思いなんですね。
私の場合は、「パッとひらめく」感覚が起きるのは、難しい実装のコアとなる部分の場合が多く、コアな部分だけに、ひらめきを元に実装できることが証明できると「やっぱりこれでできるな」と安心できましたね。
もちろん、設計書を作りながら論理的に考えたり、仕様の漏れがないか網羅的に考えるのはとても大切です。設計書を全然書いていないわけではなく、設計書がないと顧客との会話ができないことも多いですしね。
一方、事実として直感は起きるので、そういうものも生かせたらいいのではないかなと思っています。
ビガー
ビガーと申します。
興味深く拝見しました。
既存のシステムが小規模かつ一人もしくは少人数でまわすプロジェクトなら同感です。加えて少人数の場合、各人のスキル粒度が揃っている場合に。
このご時世に新規でスクラッチなんてほとんどないでしょう。
ある程度の規模の会社なら既存のシステムはいろいろな業務が絡んでいる
でしょうし、実装が先というのは現実問題危険かと。
プロトタイプ作成とか検証目的なら当然ありですが。
設計書とかドキュメント類は、エンジニア同士の意思を統一すること、実装を
他人に任せるときや機能拡張時の見積(影響範囲調査とか)参考資料として使う
程度のものなので、アーキテクチャにかかわるもの以外はコードのコメントを
重視する方が身があるかと。
しかしながら、直感とか違和感は大事なシグナルだな～と最近ツクヅク思います。
■ビガーさん
コメントありがとうございます。
> 既存のシステムが小規模かつ一人もしくは少人数でまわすプロジェクトなら同感です。加えて少人数の場合、各人のスキル粒度が揃っている場合に。
直感を活用するのは「自分で責任が負える範囲で」という言い方がいいのかもしれませんね。また、ドキュメントの目的はプログラムを作るだけではなく、意思疎通の目的もありますし、「システム開発にドキュメントは必要ない」…という気はもちろんありませんし、必ず必要なものだと思います。
> プロトタイプ作成とか検証目的なら当然ありですが。
ですね。
> 直感とか違和感は大事なシグナルだな～と最近ツクヅク思います。
今回表現したかったのは、一言で言うとここですね。直感や違和感も情報だと思いますし、活用できたらいいのになぁと思っています。
補足する機会をいただきました。ありがとうございます。
はじめまして、ここでコラムを書かせていただいている生島です。
私も直感ですね。
ただ、技術者の粒度は合わないな…。
多分、音楽とか、料理とかと同じじゃないかなと思っています。
音楽も、料理も、緻密に計算して作る人もいるけれど、感性だけで作る人もいます。
計算だけで作る人もいるかもしれません。
まずは感性で作る人がいて、万人ができるようになるために、その感性を分析してまとめ、理屈で作れるようにしてきた。
それがエンジニアリングですね。
ITの分野は、本来、感性も大事なのですけれど、余りにも軽視しすぎていると思います。
私は周りがよく判っていなかったのですけれど（苦笑）
自分の感性の部分を理屈に置き換える作業を今やっています。
できたら、業界がすごく変わるはずなんですけれど……。
インドリ
もしかしたら誤解されているかもしれないので補足します。
私の意見は直感を否定しているのではなくて、直感と理論両方をたくみに使うべきだという主張です。
設計は直感で実装は理論が基本的に丁度いいと思います。
でもこれは原則論で、実装を直感で思いつき、脳内で設計書を書いて確かめ、実装し・・・という事も多々あります。
脳内設計の能力は修得すると便利ですよ。
■生島さん
コメントあるがとうございます。
（各所で生島さんの記事は拝見しています。）
> まずは感性で作る人がいて、万人ができるようになるために、その感性を分析してまとめ、理屈で作れるようにしてきた。
なるほど。そういう見方もできますね。
> ITの分野は、本来、感性も大事なのですけれど、余りにも軽視しすぎていると思います。
私もそう思います。論理的でないことや数値で表せないことは軽視されがちですね。一方で、「なんとなくそう思った」ことをいかに表現していくかが、ある意味「実力」と言えるのかもしれませんね。プログラミングだけではなく、ドキュメントにも言えることなのかもしれません。
ふと思いついたこと形にしていくトレーニングをすることは、（チーム全員に求めるのは無理としても）プログラミングだけではなく、アイデアを創出するという意味でも大切なのではないかな？と、生島さんのコメントを見て思いました。
■インドリさん
コメントありがとうございます。
> もしかしたら誤解されているかもしれないので補足します。
インドリさんのおっしゃることはよく分かります。誤解はしていないと思います。
> 脳内設計の能力は修得すると便利ですよ。
思いついたことをプログラミング言語で起こせるということは、きっと設計を瞬時にやっているから「できると思う」になるのではないかと思います。
論理的に考えることはとても大切です。さらに「直感を信頼して生かすことも、結構便利ですよ」というのが、今回言いたかったことなんですよね。
「どっちか」ではなく、「どっちも」だと思います。
それぞれのスタイルにはそれぞれのよさがあると思いますし、いろんな考え方があっていいのではないかと思います。
あずK
横から失礼致します。
はじめまして。
自分も興味深く拝見しました。
自分の今の仕事（部署）はWebサービス系の仕事で少人数なもので、
開発作業はスクラッチよりもOSSや既存パッケージのカスタマイズが殆どです。
その際は、ソースコードを読んで脳内に設計書を作成、
その上でニーズに応えるカスタマイズは「こうすればいいのかな」と思った事を
脳内の設計書を書き換えて試行錯誤、という感じで行っています。
まれにSI業務がメインの他部署の方々にカスタマイズの依頼することもありますが、
以前、設計書を作成した上でのコーディング依頼を求められまして＾＾；
そのときはセクショナリズムの壁を感じてしまいました。
「設計書を作って依頼するのが当然だ」という意見もあるかもしれませんが、
個人的には、自分のやり方と同じように「こうすればいいのかな」という直感も用いて
作業して欲しかった、というのが本音でして・・・。
友ぞう
はじめまして。友ぞうと申します。
私はなんとなく分かる気がします。私もどちらかといえば直感派なので・・・
設計書を先にすべきかどうか、というのは意見が分かれるものですね。
どちらでもやりやすいほうでいいじゃん、などと思ってしまいますが。
私個人としては、要求分析と機能仕様書までは先に作成しますが
あとはその仕様を元にプログラムを作成します。
短納期の場合が多いのでプログラムの設計まではやってられないのが実情なのですが。
フローチャートが書けないって言ったら怒られそうですが、
設計書を書き始めると見た目とか体裁とかそちらに気をとられてしまって
無駄に時間を費やしてしまうことがあるんですよね。
だからその分をプログラミングしながら細かい動きを考えるほうが
自分にとっては効率がいいですね。
■あずKさん
コメントありがとうございます。
> 設計書を作成した上でのコーディング依頼を求められまして＾＾；
> そのときはセクショナリズムの壁を感じてしまいました。
どちらが先かというのは置いておいて、特に他部署がまたぐ場合は、意思疎通のために設計書は大きな役割を果たすんでしょうね。ソースだけではそれがいいのか悪いのか、第三者的に確認がとれないので。
意思疎通が目的の設計書は、私はきちんと作りますね。自分の考えが正しいのかを証明しなければなりませんしね。
■友ぞうさん（←「さん」を付け忘れていました。失礼しました。）
> どちらでもやりやすいほうでいいじゃん、などと思ってしまいますが。
私もどちらかというと友ぞうさんと同じですね。
（両方作ることを前提として）頭に起きたことを表現するには、先にコード化するほうが起こしやすい感じがしています。
ユーザと確認するような要求分析や機能仕様はそれがないと確認がとれないのでドキュメントが先。その後のコードに近い部分は、論理はまだできていなくても頭の仲に答えがあるので、フローチャートレベルの設計書を起こさずしてコードを書いて、必要があればソースから設計書を起こす…みたいな流れが、最もやりやすかったですね。ですので、Javaで言えば、Javadocのようなツールが非常にありがたかったです。
> 設計書を書き始めると見た目とか体裁とかそちらに気をとられてしまって
> 無駄に時間を費やしてしまうことがあるんですよね。
確かにそうですね。
としろう
私は直感とは実質経験に裏付けされた脳内ショートカットであると考えます
その経過ゆへか、経験での為に論理的に説明しにくい事が多いと思いますが。
で、直感は、行き詰った局面での仮説的意味でのブレイクスルー
ではあっても、必ずしも正しいとは考えないです。
「もしや」の意味での「ヒント」として採用し
仮説を論理的に検証する
これがインドリさんのいう所を詳細に、あるべき姿というべきではないでしょうか？
例えばアニメ的誇張表現に慣れすぎていては
実際の物理法則とは違うのだという違和感を感じない事も有るでしょう。
経験的印象的なものも疑う必要、検証する必要が有る
スキージャンプでも飛行中、昔は手を動かしていたらしいですが
今は違いますよね
> 私は直感とは実質経験に裏付けされた脳内ショートカットであると考えます
そういう場合もあるかもしれませんし、そうでない場合もあるかもしれません。
たとえば、音楽家が演奏する際に、過去の演奏の繰り返しによって、
楽譜を見ないでも体が反応して音楽を演奏できるかもしれません。
一方、新たな曲を作り出すのは、もちろん経験も必要かもしれませんが、
どちらかといえば「ふと思う」ということから生まれるのではないかと思います。
私が今回お話したかったのは、どちらかと言えば後者のほうです。
もし、前者のお話をするとしたら、
「考えなくても行動できるように経験を積みましょう」とお話すると思います。
> 直感は、行き詰った局面での仮説的意味でのブレイクスルー
> ではあっても、必ずしも正しいとは考えないです。
としろうさんはそのようにお考えなんですね。
私は直感を信頼しているタイプです。
もちろん論理的に考えることもします。それはとても大切なことです。
何が正しくて、何が正しくないか、
二元的に決めるのは少しもったいない気もします。