プログラマーの仕事とは解くべき問題を発見することである
プログラマーという仕事について書いてみます。
この記事を読んで欲しい人
- テクノロジーが苦手な経営者/起業家
- プログラマーと仕事をしている経営者/起業家
- プログラマーがどんなことをしているのか知りたい人
プログラミングとは？
ある人にプログラマーって何をしてるように見えるか聞いたところ「黒い画面に向かって何かを書いてる人」と返ってきました。
プログラミングが分からない人からすると、それくらい謎なんでしょうね。
SF作家のアーサー・C・クラークは「十分に発達した科学技術は、魔法と見分けがつかない」と言ったけどプログラミングもそれに近いところがあります。
プログラミングを書くまでは、何が出来上がるか、目に見えないし、中身がどうなっているのかも見えません。
目に見えないが故にプログラミングが分からない人（例：マーケティングやセールス）とプログラマーで会話が衝突する場面に何度か出会したことがあります。
プログラムというもの自体、 実質的に、ものが動く仕組みの巨大な記述です。
この記述のことをアルゴリズムと言います。
アルゴリズムとは、ある特定の問題を解く手順を、単純な計算や操作の組み合わせとして明確に定義したもの。
プログラミングとは、特定の問題とそれを解く手順のことです。
小さな単位で「特定の問題とそれを解く手順」を書いて、それを膨大に組み合わせたものがITシステムです。
プログラマーは、特定の問題を定義して、それを順番に解くということをひたすらやっています。
プログラミングで最も難しいのは問題を解くことではなく、どの問題を解くかを決めることだ
プログラミング（特定の問題を定義して、それを解く作業）を書いても最初から意図した通りに動くことは稀だったりします。
これを上手く動かす作業のことをデバッグと言います。
デバッグとは、コンピュータプログラムに潜む欠陥を探し出して取り除くこと。
プログラマーは多くの時間をデバッグに費やしています。
多くのプログラマーと仕事をしてきましたが優れたプログラマーは、問題定義の切り口が優れています。
例えば定義した問題の中に複数の問題が含まれていると解き方が複雑になってデバッグに多くの時間を費やしてしまいます。
問題定義が優れていると解き方も簡単な記述になりますし
他との組み合わせもやりやすくなります。
優れたプログラマーを観察していると最初からコードを書くのではなく
問題定義に時間をかけているんです。
プログラミングで最も難しいのは問題を解くことではなく、どの問題を解くかを決めることです。
問題の解き方は、”作る”から”利用する”へ
問題の解き方はどうしているのでしょうか？
優れた問題の解き方は、世の中の頭の良い人達の解き方を利用すること。
頭の良い人達がライブラリ、フレームワーク、オープンソース、Web API、SaaS、IaaSといった方法で公開しています。
ゼロからコードを作ることは少なくて、いかにこれらを上手く利用して組み合わせるかを考えています。
問題の解き方はそれら適切な組み合わせを知っているかに価値があります。
視野と解像度
さて、プログラマーがいかに上手く問題を定義して、上手く問題を解いても
ビジネスゴールを理解していなければ、そのプログラムは無駄になるでしょう。
ここで視野の広さが大切になってきます。
よく「視野を広げる」とか「視野が狭い」とか言いますよね。
開発の中だけに閉じず、視野を広げてマーケティングやセールスチームと会話することが大事になってきます。
次に解像度も大事です。
解像度（かいぞうど）とは、ビットマップ画像における画素の密度を示す数値である。
すなわち、画像を表現する格子の細かさを解像度と呼び、一般に1インチをいくつに分けるかによって数字で表す。
ここでは解像度を理解の深さや密度のことを指して使っています。
昔やっていたのは、開発ミーティングにゲストでお客さんに参加してもらって、お客さんの口からペインを伝えてもらいました。
設計書にペルソナやペインを書いて伝えるよりも
お客さんの口から直接伝えてもらった方が温度感と臨場感も一緒に伝わるので解像度が上がるんですね。
ビジネスゴールは、ビジネス領域における問題定義と言い換えることもできます。
問題定義が間違っている/もしくは間違って理解していたら
それを解く方法であるITシステム（プロダクト含む）がいかに優れていても、そのITシステムは無駄になるでしょう。
目玉の数さえ十分あれば、どんなバグも深刻ではない
Linuxを開発したリーナス・トーバルズは、"目玉の数さえ十分あれば、どんなバグも深刻ではない"と言っています。
Linuxのプロジェクトでは、数万人のプログラマーがアクティブに参加しています。
このプロジェクトでは、誰かが問題を発見して、他の誰かが解決しています。
数万人規模が参加しているから常に優れた問題定義が出来て、優れた解き方をしている。
リーナス・トーバルズの偉業はこの開発モデルを発明したことにあると言われています。
以前、スタートアップで開発チームを立ち上げた時に、このモデルを参考に20人のプログラマーに参加してもらって、ひたすら問題定義とそれを解くことをやってもらいました。
※上手くいったこと/上手くいかなかったこと/どうやって低予算でこのモデルを構築したかは、気が向いたら別の記事で書きます。
スタートアップの起業家はプログラマーに似ているところがある
スタートアップが失敗する理由は、アイデアが悪いからではなく、顧客の問題を正しく捉えて、最適な解決策を講じられるようになる前に、経営資源（お金やモチベーション）が尽きてしまうからです。
問題を理解して、解き方を模索し続けるという意味において起業家とプログラマーは似ているところがあります。
経営者/起業家の方には、プログラマーに開発タスクを依頼してやってもらうという関係性ではなく、プログラマーと共に顧客の問題を発見し、解き方を共に考えるような関係性になれば良いように思います。
この記事が気に入ったらサポートをしてみませんか？