プログラマはサイクリングがお好き・・・なのか？
ITproにて「プログラマはサイクリングがお好き」と題したのエディターズコラムが掲載されていた．
記者の一年間を通じてのプログラマへ取材中で得られた経験値によれば，「プログラマはサイクリングを趣味にしているケースが多い（少なくとも記者の取材範囲に関しては）」らしい．確かにプログラマなサイクリストは僕も何人か知っています．（もっとも，サイクリングが趣味ではないプログラマの方が多いですが．）
実はプログラマはサイクリングがお好きかはどうでもよくて（いきなりタイトルを否定してすみません），その取材相手のあるプログラマの意見について非常に違和感を覚えたのだ．
別のプログラマは，「自転車を組み立ててサイクリングに出かける過程は，プログラミングに似ている」とまでいう。「各パーツ（関数）を組み合わせて，一つの大きな自転車（アプリケーション）を作り出す。そして，作った自転車（アプリケーション）で川辺のサイクリング（実行）なんて最高でしょう」。
自転車は，色々なパーツを組み合わせることで１台の完成車として作り上げられている．確かに，プログラムでも関数（パーツ）を組み合わせてアプリケーション（完成車）を作り出している．でも，これって全然似ていないと思うのだ．
自転車のアーキテクチャ（ソフトウェア方式設計と言うほうが判り易い？）はほぼ固定されており検討の余地はない．作業としては，新規に検討するビジネスロジックは皆無に等しく*1，「ロードレーサーフレームワーク」とか「MTBフレームワーク」とかの上で，パーツを選択していくことになります．例えば「勘定系パッケージソフトのカスタマイズ導入」に近いイメージ．お客さんの要望を聞きだして，最適なフレームワークを選択して，要望に近いパッケージ製品を目利きして，導入現場の状況に合せて切った貼ったしながら組み立てる．自転車ショップの職人さんの難しさ（凄さ）は，SIerの凄腕技術営業さんに近いと思うのです．*2
一方で，プログラムの本質（創造的な営み・難しさ）は，単に関数を組み合わせるトコロにあるのではなく，アーキテクチャ検討にあるのだと思う．入力（「回転角」「重心位置」「クランク踏力」）と出力（「走る」）というインタフェース仕様が決められていて，その実現手法を検討・実装するのがプログラミングの醍醐味なんじゃなかと思うのだ．既存の定番ロジック（自転車アルゴリズム）を使って書くのか，他のアルゴリズム（バイク，キックスクーター，三輪車，ハンドルを手に持って歩く）が良いのか，新規にビジネスロジックを考えるのか，そこがプログラマの腕の見せ所なんだと思います．
個人的には，自転車組み立てよりも，自転車イベントへの参加プロセスの方がプログラミング（ソフトウェア開発）に近いと思います．
- 参加イベントの決定（開発プロジェクトの立ち上げ）
- 目標設定（ソフトウェア要件定義）
- イベント参加計画立案（計画書の策定，リソース確保，）
- 練習メニューの作成（ソフトウェア設計）
- 各種練習メニュー実施・評価（実装・単体テスト）
- イベント想定練習（結合試験）
- 弱点を個別メニューで練習（デバッグ・チューニング）
- イベント直前練習（本番試験）
- イベント本番（運用）
- 反省会（プロジェクト評価）
・・・というか，世の中 自転車でもプログラミングでも「プロジェクト」と名の付く営みならば，必ず似たような構造になるはずだと思うのです．
